Niektóre strony nie mają wbudowanego trybu ciemnego (aka dark mode) i przez mój światłowstręt cierpię o 2 w nocy. Z pomocą przychodzi plugin Stylish, który można wykorzystywać w przeglądarkach Google Chrome (i wszystkich innych bazujących na Chromium) i Mozilla Firefox. Dzięki temu strona zamiast wyglądać tak:
Google Chrome (i inne przeglądarki oparte o Chromium)
Na początku trzeba wejść na tę stronę i kliknąć Dodaj do Chrome, a następnie w komunikacie kliknąć Dodaj rozszerzenie.
Mozilla Firefox
Wchodzimy na tę stronę i klikamy na Dodaj do Firefoksa, a następnie zatwierdzamy klikając Dodaj.
Opera
Wchodzimy na tę stronę i klikamy na Dodaj do Opery. Na Operze akurat instalujemy program, który bazuje na Stylishu, lecz docelowo działa tak samo.
Następne kroki
Po dodaniu należy wejść na stronę, której wygląd chcemy zmienić, kliknąć ikonkę Stylisha i zaakceptować warunki korzystania wtyczki.
Potem możemy zainstalować skin dla danej strony, ale aktualnie nie ma żadnych opublikowanych, więc po prostu dodamy nowy. Klikamy na przycisk opcji u góry okienka wtyczki i Create New Style.
W przypadku Opery ze Stylusem należy kliknąć na ikonkę wtyczki, a następnie na link pod Napisz styl dla. Wtedy otworzy nam się to samo, co w innych przeglądarkach.
Otworzy nam się nowe konto, w którym musimy zdefiniować wygląd skina. Na górze, po lewej wpisz nazwę skina (w moim przypadku tf2pickup.pl), następnie zaznacz Enabled pod nazwą. Teraz w sekcji *Code 1 wklej kod, którym zmieniasz wygląd strony (mój kod poniżej):
Akurat to użycie integracji nie daje aż takich korzyści w stosunku do integracji AD na przykład z FortiGate’m, ale nadal można to wykorzystać w ciekawy sposób niespecjalnie pocąc się przy konfiguracji. Założenie jest dosyć proste – umożliwić logowanie się na konta z domeny Active Directory (najnornalniejszej na świecie, żadne udziwnienia w postaci AD na QNAPie czy tym podobne) oraz umożliwić konkretnej grupie w AD korzystanie z uprawnień administracyjnych (aka korzystanie z polecenia sudo).
Moje środowisko składa się z dwóch kontrolerów domeny, ad1.serba.local (192.168.30.2) i ad2.serba.local (192.168.30.3). Do tego są inne hosty w sieci, które są totalnie nieistotne. Jak FQDNy wskazują, moja nazwa domeny to serba.local. Grupa, której damy uprawnienia administracyjne w Linuksach to wbudowana grupa AD Administratorzy domeny. Adres sieci to 192.168.30.0/24 i pierwszy użyteczny adres to adres routera. Przykład integracji opieram na Windowsach Server 2019 v. 1809, Xubuntu 19.10 i Red Hat Enterprise Linux 8.0. Dobrałem takie 2 dystrybucje Linuksa ze względu na to, że one i ich pochodne (przy czym Ubuntu jest pochodną Debiana te podobieństwo działa w drugą stronę) są bardzo podobne w konfiguracji, więc w jednym poradniku będzie można zobaczyć jak zrobić taką integrację na większości dystrybucji. W praktyce powinniśmy być w stanie zintegrować dowolną dystrybucję Linuksa posiadając zainstalowane w systemie odpowiednie pakiety.
Integracja AD na (X)ubuntu
Na początku zaczynamy od instalacji potrzebnych pakietów:
Następnie edytujemy plik /etc/samba/smb.conf w sekcji [global] (ta sekcja zaczyna się pod tym nagłówkiem, a kończy się z miejscem kolejnego):
workgroup = SERBA #tutaj nazwa NETBIOS domeny
client signing = yes
client use spnego = yes
kerberos method = secrets and keytab
realm = SERBA.LOCAL #koniecznie dużymi literami
security = ads
idmap config *: range = 10000-20000 #bez dodania tego parametru nie przechodził test cfg
Po wykonaniu zmian warto przetestować, czy wszystko w tym pliku konfiguracyjnym jest OK, w innym wypadku sługi smbd i nmbd nie uruchomią się po restarcie. Robimy to poleceniem sudo testparm:
Następnie edytujemy /etc/sssd/sssd.conf (ten plik domyślnie nie istnieje, więc nie zdziwcie się, jeśli pliku nie będzie):
[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3
[pam]
reconnection_retries = 3
[sssd]
domains = serba.local #tutaj nazwa domeny małymi literami
config_file_version = 2
services = nss, pam
default_domain_suffix = SERBA.LOCAL #tutaj domena dużymi literami
full_name_format = %1$s #dzięki tej linijce nie musimy wpisywać `użytkownik@domena` tylko wystarczy `użytkownik`
[domain/serba.local] #małymi literami domena
ad_domain = serba.local #ponownie domena małymi literami
krb5_realm = SERBA.LOCAL #tym razem domena dużymi literami
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash #definiujemy shell dla logujących się użytkowników AD, może być inny
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%d/%u #składnia: /home/<nazwa-domeny>/<nazwa-uzytkownika>
access_provider = ad
auth_provider = ad
chpass_provider = ad
access_provider = ad
ldap_schema = ad
dyndns_update = true
dyndns_refresh_interval = 43200
dyndns_update_ptr = true
dyndns_ttl = 3600
Po stworzeniu konfiguracji musimy zabezpieczyć plik w ten sposób, by inni poza rootem nie mieli do niego dostępu:
[active-directory]
os-name = Linux Ubuntu
os-version = 19.04
[service]
automatic-install = yes
[users]
default-home = /home/%d/%u
default-shell = /bin/bash
[serba.local]
user-principal = yes
fully-qualified-names = no
[providers]
samba = no #bez tej linijki są problemy z logowaniem ze wskazaniem uprawnień grup do logowania poprzez realm
Mając to zrobione musimy zrestartować usługi, które konfigurowaliśmy:
# systemctl restart smbd nmbd sssd realmd
Następnie możemy sprawdzić, czy mamy połączenie z domeną pobierając „bilecik” z KDC poprzez polecenie kinit określając nazwę użytkownika@domenę, z której się logujemy:
# kinit [email protected]
Password for [email protected]:
# /etc/sssd > klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: [email protected]
Valid starting Expires Service principal
02.04.2020 21:04:52 03.04.2020 07:04:52 krbtgt/[email protected]
renew until 09.04.2020 21:04:49
Po tym możemy dołączyć naszym Linuksowym hostem do domeny AD. Najpierw sprawdźmy, czy jesteśmy w stanie wykryć domenę w naszej sieci poleceniem realm discover -v NAZWA.DOMENY:
I teraz już na serio dołączamy do domeny poleceniem realm join NAZWA.DOMENY -U konto_admina -v:
# realm join SERBA.LOCAL -U rserba -v
* Resolving: _ldap._tcp.serba.local
* Performing LDAP DSE lookup on: 192.168.30.3
* Performing LDAP DSE lookup on: 192.168.30.2
* Successfully discovered: serba.local
realm: Już dołączono do tej domeny
Powtarzamy poleceniem net ads join -k:
# net ads join -k
Using short domain name -- SERBA
Joined 'SUPRA-VM' to dns domain 'serba.local'
Następnie musimy ograniczyć logowanie do tego hosta poprzez wskazanie grupy, która może się logować oraz reszty, która tego robić nie może. Pierwszym poleceniem blokujemy dostęp wszystkim użytkownikom, a następnie dodajemy grupę, która może się logować do tego systemu. Wszyscy członkowie tej grupy mogą się zalogować.
# realm deny -a
# realm permit --groups 'serba.local\Administatorzy domeny'
Przed zalogowaniem się musimy też umożliwić automatyczne tworzenie katalogów dla użytkowników (w innym wypadku na dobrą sprawę użytkownicy AD nie będą w stanie normalnie funkcjonować w systemie na własnych prawach):
# pam-auth-update
Po otwarciu okna zaznaczamy Create home directory on login i dajemy OK:
Warto też sprawdzić plik /etc/nsswitch.conf, w sekcjach passwd, group i shadow, netgroup, services i sudoers powinno być dopisane na końcu sss:
Po tym powinniśmy dodać do /etc/pam.d/common-account linijkę na samym dole pliku:
I teraz instalujemy winbind po to, by móc wykorzystać konta AD w ekranie logowania:
# apt install winbind
Usługa winbind.service powinna się uruchomić od razu po instalacji. Sprawdźmy, czy możemy pobrać użytkowników i grupy z AD poleceniami wbinfo -u i wbinfo -g:
# wbinfo -u
SERBA\administrator
SERBA\gość
SERBA\krbtgt
SERBA\fsso
SERBA\rserba
SERBA\smatuszczyk
SERBA\serviceacc
SERBA\mblaszczyk
SERBA\dkania
# wbinfo -g
SERBA\komputery domeny
SERBA\kontrolery domeny
SERBA\administratorzy domeny
SERBA\użytkownicy domeny
SERBA\goście domeny
SERBA\twórcy-właściciele zasad grupy
SERBA\kontrolery domeny tylko do odczytu
SERBA\klonowalne kontrolery domen
SERBA\protected users
SERBA\administratorzy kluczy
SERBA\dnsupdateproxy
SERBA\wydawcy certyfikatów
SERBA\serwery ras i ias
SERBA\grupa z replikacją haseł na kontrolerach rodc
SERBA\grupa bez replikacji haseł na kontrolerach rodc
SERBA\dnsadmins
SERBA\administratorzy schematu
SERBA\administratorzy przedsiębiorstwa
SERBA\kontrolery domeny tylko do odczytu na poziomie organizacji
SERBA\administratorzy kluczy przedsiębiorstwa
Jak widać, działa. Sprawdźmy, czy jesteśmy sprawdzić informacje o użytkowniku rserba:
Na końcu dodamy grupę Administratorzy domeny do /etc/sudoers i umożliwimy na logowanie poprzez interfejs graficzny (wykorzystując menedżer wyświetlania LightDM). Edytujemy /etc/sudoers (plik określający kto w tym systemie może korzystać z polecenia sudo) poleceniem visudo (jak root) i dodajemy linijkę:
#%SERBA\\administratorzy\ domeny ALL=(ALL:ALL) ALL #nieadekwatny do przykładu
#%administratorzy\ [email protected] ALL=(ALL:ALL) ALL #nieadekwatny do przykładu
%administratorzy\ domeny ALL=(ALL:ALL) ALL
Potem edytujemy plik /usr/share/lightdm/lightdm.conf.d/60-xubuntu.conf (na dobrą sprawę możemy sobie nawet sami utworzyć nowy plik w katalogu /usr/share/lightdm/lightdm.conf.d i upewnić się, że będzie miał prawidłową składnię) i dodajemy:
Dzięki temu trzeba będzie wpisać w pole logowania nazwę użytkownika i hasła i w ten sposób będzie można się logować na pulpit tak samo, jak lokalni użytkownicy. Zmiany są widoczne po restarcie usługi lightdm.service, więc możemy po prostu uruchomić system ponownie i wszystko powinno już wejść w życie.
Przy okazji próbując zmienić konto poprzez polecenie su - nazwa_usera_ad możemy sprawdzić czy ograniczenia na logowanie działają:
supra@supra-vm > ~ > su - rserba
Hasło:
rserba@supra-vm:~$ exit
wylogowanie
supra@supra-vm > ~ > su - smatuszczyk
Hasło:
su: Uwierzytelnienie się nie powiodło
W ten sposób wszystko działa poprawnie, przetestujmy sudo:
Okej, na tym etapie musimy też edytować plik /etc/krb5.conf:
# To opt out of the system crypto-policies configuration of krb5, remove the
# symlink at /etc/krb5.conf.d/crypto-policies which will not be recreated.
includedir /etc/krb5.conf.d/
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
udp_preference_limit = 1
rdns = false
pkinit_anchors = FILE:/etc/pki/tls/certs/ca-bundle.crt
spake_preauth_groups = edwards25519
default_realm = SERBA.LOCAL #tak, domena musi być z dużej litery
default_ccache_name = KEYRING:persistent:%{uid}
[realms]
SERBA.LOCAL = { #tutaj podobnie
kdc = serba.local #nie wpisujemy poszczególnych kontrolerów domeny, jeśli discovery działa to nie ma sensu podawać tutaj FQDNa kontrolera
admin_server = serba.local #podobnie, w obu przypadkach podajemy z małych liter nazwę domeny
}
[domain_realm]
.serba.local = SERBA.LOCAL #w obu przypadkach z dużej litery domena
serba.local = SERBA.LOCAL
Okej, mając to ustawione zastosujmy konfigurację poleceniem authconfig --enablesssd --enablesssdauth --enablelocauthorize --enablemkhomedir --update:
[root@rhel8 ~]# authconfig --enablesssd --enablesssdauth --enablelocauthorize --enablemkhomedir --update
Running authconfig compatibility tool.
The purpose of this tool is to enable authentication against chosen services with authselect and minimum configuration. It does not provide all capabilities of authconfig.
IMPORTANT: authconfig is replaced by authselect, please update your scripts.
See man authselect-migration(7) to help you with migration to authselect
Warning: These options are not supported anymore and have no effect:
--enablelocauthorize
Executing: /usr/bin/authselect check
Executing: /usr/bin/authselect select sssd with-mkhomedir --force
Executing: /usr/bin/systemctl enable sssd.service
Executing: /usr/bin/systemctl stop sssd.service
Executing: /usr/bin/systemctl start sssd.service
Executing: /usr/bin/systemctl enable oddjobd.service
Executing: /usr/bin/systemctl stop oddjobd.service
Executing: /usr/bin/systemctl start oddjobd.service
Dobra, teraz upewnijmy się, że /etc/sssd/sssd.conf wygląda mniej więcej tak (jeśli nie, warto to nieco skorygować):
Jeśli zmienimy cokolwiek, restartujemy usługę (od razu sobie warto ustawić ją tak, by uruchamiała się wraz ze startem systemu):
# systemctl start sssd //w dokumentacji jest service sssd start
# systemctl enable sssd //w dokumentacji jest chkconfig sssd on
Po tym zrestartowałbym system. Na końcu musimy zdefiniować kto może faktycznie się logować do swoich kont administracyjnych:
sudo realm deny -a
sudo realm permit --groups 'serba.local\Administratorzy domeny'
Na końcu dodamy grupę Administratorzy domeny do /etc/sudoers za pomocą visudo:
#%SERBA\\administratorzy\ domeny ALL=(ALL:ALL) ALL #nieadekwatny do przykładu
#%administratorzy\ [email protected] ALL=(ALL:ALL) ALL #nieadekwatny do przykładu
%administratorzy\ domeny ALL=(ALL:ALL) ALL
Na dobrą sprawę to tyle. GDM (menedżer wyświetlania w RHEL 8) nie wymaga dodatkowych modyfikacji, by umożliwić użytkownikom z AD logowanie się na swoje konta w interfejsie graficznym. Wspominając o Fortigate – z pewnego powodu agent FSSO nie widzi logowań na hostach z Linuksem, więc jeśli ktoś by wiedział jak to rozwiązać – zostawcie komentarz.
Gdy mamy zintegrowanego agenta FSSO z AD to możemy tworzyć polityki firewalla bazując na zalogowanych kontach użytkownika, lecz ma to jest problem. W tym założeniu jeden użytkownik korzysta w jednym czasie z jednego komputera. W przypadku, gdy ma się w organizacji wdrożony serwer do pulpitów zdalnych domyślnie będziemy widzieli cały czas 1 konto korzystające z komputera (konto, które zalogowało się jako ostatnie do serwera terminali). To oznacza, że jeśli ostatnim kontem będzie np. konto dyrektora mającego pełny dostęp to wszyscy podłączeni przez pulpity zdalne do tego serwera taki dostęp będą mieć. W drugą stronę – jeśli ostatnią osobą będzie przyjmijmy rekruter to wszyscy podłączeni będą mieli takie same ograniczenia w wykorzystywaniu sieci jak on.
Przykład potencjalnego problemu
Dlatego też mając agenta FSSO należy korzystać z agenta TS (terminal server) dla Fortgate’a. Instalacja jest prosta. Na tej stronie możemy znaleźć link do progrania najnowszej wersji TS Agenta po zalogowaniu, przejściu do Download > Firmware images, wybierając urządzenie FortiGate wybieramy też niżej zakładkę download, przechodzimy do najnowszej wersji urządzenia i koniec końców tak jak na zrzucie poniżej wybieramy instalator TSAgent_Setup_5.0.0827.msi.
Po ściągnięciu i wrzuceniu pliku na wspomniany serwer terminali musimy przejść przez szybki proces instalacji.
Klikamy Next.
Zatwierdzamy warunki umowy licencyjnej i Next.
Nie zmieniamy katalogu instalacyjnego, Next.
Next.
I Finish. W ten sposób mamy wdrożonego agenta.
Jak widać z poziomu Fortinet Signle Sign On Agent Configuration agent TS jest wykrywany i działa.
To oznacza, że tym razem nie powinno być problemu z sesjami. Z poziomu Monitor > Firewall User Monitor po kliknięciu Show all FSSO Logins możemy zobaczyć wielu użytkowników zalogowanych na maszynie z adresem 192.168.30.5, poza tym w sekcji Method agent to FSSO Citrix. To akurat jest jednoznaczne.
Następnie na postawie polityk z poprzedniego posta (zwykli użytkownicy nie mają dostępu do kategorii z obciążających przepustowość + stron związanych z graniem), admini domenowi nie mają restrykcji. W ramach testu stworzyłem RemoteApp, którym jest Google Chrome (najłatwiejsza opcja na sprawdzenie jak jest realizowany web filtering dla konkretnych użytkowników). Jak widać, tutaj jest zablokowany dostęp:
Tutaj też:
A tutaj nie (zalogowane konto to konto admina). Wszystko się zgadza.
Jak widać, było to łatwiejsze, niż się wydawało.
Podłączenie drugiego kontrolera domeny do FSSO
Do tego najlepiej mieć jakiś wydzielony host, który zbiera logowania ze wszystkich miejsc (kontrolery domeny i serwery terminali). W moim przypadku to host z Windowsem 10, który nazywa się fsso-collector. UPDATE: to jednak nie jest potrzebne, ponieważ można po prostu zainstalować Collector Agenta na dwóch kontrolerach domeny i na wzajem się nasłuchiwać.
Ogólnie pod kątem instalacji należy podążać za przykładem, który przedstawiłem tutaj, a gdy mamy już kwestię uprawnień dla konta użytkownika serwisowego i konfigurację zapory sieciowej za sobą to powinniśmy podłączyć agenty DC do naszego nowego collectora wraz z agentem TS, który też jest w środowisku. Nie różni się też bardzo tym od instalacji z 1 agentem TS – po prostu mamy dwa kontrolery domeny na liście:
Ja akurat na dc1 miałem już agenta, lecz na dc2 nie, dlatego też po instalacji na dc2 należy wykonać restart systemu:
W przypadku dc1 jedynie otrzymamy informację, że wszystko jest gotowe.
Musimy też podpiąć agenta TS, który w moim przypadku jest jeszcze podpięty do starego collectora z poprzedniego przykładu, więc na dobrą sprawę by to zmienić musimy uruchomić TS Config:
Potem wystarczy w oknie poniżej kliknąć Run as administrator i zmienić adres w Fortinet SSO Collector Agent IP/Port na nowy, w moim przypadku 192.168.30.6. Po tym klikam przycisk Save&close. UPDATE: w przypadku posiadania Collector Agentów należałoby wpisać adresy obu CA, więc zamiast 192.168.30.6 powinno być 192.168.30.2;192.168.30.3.
Następnie w Fortigate, w Security Fabric > Fabric Connectors możemy zwrócić, że nasz connector ma status down:
Następnie definiujemy poprawny adres collectora i hasło w polu Primary FSSO Agent, po czym klikając Apply & Refresh. Potem można kliknąć OK by sprawdzić status połączenia:
Dodałem tutaj zaznaczoną opcję Trusted SSL Certificate, gdzie zaznaczyłem certyfikat mojego urzędu CA w organizacji. Polecam zapoznać się z tym postem, ponieważ tutaj omówiłem to, jak takie certyfikaty konfigurować. To jest opcjonalne, ale przydatne. W przypadku korzystania z SSL musimy się upewnić, że nasz FortiGate poprawnie rozwiązuje nazwy DNS z naszej domeny oraz w profilu LDAP Profile jak i w profilu FSSO Agent on Windows AD są zdefiniowane adresy FQDN kontrolerów domeny zamiast adresów IP. W innym wypadku certyfikaty nie zostaną uznane jako prawidłowe i niektórzy robią jakieś krzywe myki z ignorowaniem poprawności certyfikatów, czego nie polecam.
Swoją drogą, tutaj jak widać collector zbiera informacje z agentów DC. Warto nie zapomnieć zdefiniować hasło, które podajemy w Fabric Connectorze w sekcji Authentication zakładając, że mamy zaznaczoną opcję Require authenticated connection from FortiGate:
Ostatnim elementem, który musimy zmienić jest obiekt serwera LDAP w Fortigate, lecz takiej zmiany nie możemy zrobić z poziomu GUI, bo mamy tylko 1 pole adresowe dla serwera LDAP (ustawienie jest w User & Device > LDAP Servers):
Na wdrożeniach staram się zawsze używać połączenia szyfrowanego, ponieważ dzięki temu nie da się w komunikacji wyłapać loginów i haseł, które wpisują użytkownicy np. w polu logowania do FortiGate’a. Wymaga to wdrożenia AD CS, zaimportowania certyfikatu CA do FortiGate’a (tutaj napisałem jak zmienić nazwę na łatwo wyszukiwalną) i wybrania go z listy. Nie ma znaczenia, czy korzystamy z LDAP over STARTTLS czy over SSL/TLS.
Taką operację musimy wykonać z poziomu CLI:
supra-forti # config user ldap
supra-forti (ldap) # edit serba.local
supra-forti (serba.local) # set secondary-server dc2.serba.local
supra-forti (serba.local) # end
W przypadku, gdy mamy trzy kontolery domeny, możemy w obiekcie zdefiniować trzeci kontroler za pomocą pola tertiary-server, na przykład:
supra-forti # config user ldap
supra-forti (ldap) # edit serba.local
supra-forti (serba.local) # set tertiary-server dc3.serba.local
supra-forti (serba.local) # end
W ten sposób, jak widać byłem w stanie zalogować się na swoje konto administracyjne pomimo tego, że pierwszy kontroler domeny był wyłączony:
W tym poradniku opiszę krok po kroku jak wykorzystać domenę
Active Directory w Fortigate, by móc tworzyć polityki bazowane na
użytkownikach/grupach AD. Porady są napisane w oparciu o urządzenie FortiWiFi
60E z systemem FortiOS 6.2.3.
Na samym początku należy zdefiniować serwer DNS w ustawieniach Fortigate’a po to, by Fortigate mógł rozwiązywać nazwy DNS w domenie, w moim przypadku serba.local. Zrobimy to w Network > DNS (w moim przypadku adres 192.168.30.2):
Po tym należy zdefiniować serwer LDAP w zakładce User & Device > LDAP Servers klikając przycisk Create New:
Następnie uzupełniamy pola w następujący sposób:
Name: nazwa profilu, dowolna,
Server IP/Name: adres IP/nazwa FQDN kontrolera domeny, można tutaj dodać jeden kontroler domeny (drugą można dodać w CLI),
Server Port: port, który używamy do komunikacji z LDAPem, dla LDAP to jest domyślnie 389, dla LDAP 636 (TCP),
Common Name Identifier: podajemy tutaj pole obiektu, na podstawie której wyszukujemy użytkownika w AD. Te pole jest wykorzystywane też przy logowaniu jeśli zintegrujemy np. logowanie administracyjne do Fortigate’a. Na przykład: cn w moim przypadku to by było Radosław Serba, sAMAccountName to rserba, a userPrincipalName to [email protected]. Najlepiej korzystać z jednego z tych dwóch ostatnich pól.
Takie pole można sobie sprawdzić w przystawce Użytkownicy i komputery usługi Active Directory mając zaznaczoną opcje Widok > Opcje zaawansowane. Poniżej przykład z zaznaczonym polem userPrincipalName:
Distinguished Name: w tym polu określamy DN obiektu w Active Directory na podstawie którym szukamy obiektów znajdujących się gałąź niżej. W przypadku wskazania początku drzewka, czyli samej domeny, mamy możliwość wyszukiwania we wszystkich podfolderach typu Users i dowolnym OU znajdującym się w domenie. Zakładając, że domena się nazwa serba.local DN to DC=serba,DC=local. Każdy segment nazwy domeny jest oddzielany przecinkiem i wstawiany do osobnego elementu DC. Tutaj można znaleźć więcej przykładów konfiguracji.
Bind type: w tym polu określamy sposób wyszukiwania obiektów, to jak one działają jest dobrze opisane tutaj. W moim przypadku korzystam z opcji Regular.
Username: definiujemy użytkownika, który najlepiej jeśli będzie wykorzystywany do odpytywania AD pod kątem tego gdzie jakie obiekty się znajdują. Potem z tego samego konta możemy korzystać w agencie FSSO. Podajemy po prostu nazwę użytkownika w formacie domena\użytkownik, w moim przypadku SERBA\fsso.
Password: to jest raczej oczywiste.
Secure Connection: gdy zaznaczone, włączamy komunikację z LDAPS, w którym musimy załączyć certyfikat w polu Certificate oraz określić sposób protokół w polu Protocol.
Po wszystkim warto sobie sprawdzić czy mamy połączenie z serwerem poprzez kliknięcie Test Connectivity. Jeśli mamy status Successful to wszystko jest w porządku. Poprzez Test User Credentials możemy sprawdzić czy jeśli byśmy potem zintegrowali np. logowanie do strony konfiguracyjnej Fortigate’a czy nasz login by zadziałał poprawnie. Poniżej przykład:
Następnie, aby wykorzystywać FSSO należy zainstalować poszczególne komponenty w odpowiednich miejscach:
Domain Controller (DC) agent – musi być zainstalowany na każdym kontrolerze w domenie,
Citrix/Terminal (TS) agent – musi być zainstalowany na każdym terminalu jak ten od Citrix, VMware Horizon 7.4 czy Usługi pulpitów zdalnych w Windows Server,
Collector (CA) agent – zbiera dane z logowania z agentów DC lub poprzez bezpośrednie odpytanie z AD (z wykorzystaniem LDAP). Maksymalnie na urządzenie można podpiąć takich agentów 5. CA korzysta z portów 8000 TCP (komunikacja z Fortigate’ami) oraz UDP 8002 (komunikacja z agentami DC). W przypadku dużych instalacji można wykorzystać FortiAuthenticator zamiast CA. W przypadku instalacji z wieloma kontrolerami domeny najlepiej taki CA zainstalować na maszynie niebędącej kontrolerem domeny, lecz pracującym 24/7.
W przypadku posiadania Microsoft Exchange Server istnieje także możliwość analizowania logowania do takiego serwera, najprostszym rozwiązaniem jest przekierowanie logów z serwera Exchange na inny serwer na którym jest zainstalowany agent AD, który kontaktuje się z CA.
By pobrać potrzebne pliki, należy się zalogować na stronie https://support.fortinet.com, następnie przejść do zakładki Download > Firmware images:
Najlepiej ściągnąć plik zaczynający się na FSSO_Setup, bo zawiera on agenta DC i CA. W tym przypadku FSSO_Setup_5.0.0287_x64.exe. Znajdziemy to po wybraniu sekcji FortiGate, karty Download, a następnie wybierając ścieżkę /FortiGate/v6.00/6.2/6.2.3/FSSO/ (oczywiście w przypadku nowszych wersji najlepiej wybrać najnowszą).
Zanim zaczniemy instalację, warto utworzyć wcześniej wspomnianego użytkownika serwisowego, w moim przypadku jest to fsso. Możemy to zrobić w przystawce Użytkownicy i komputery usługi Active Directory:
Powinniśmy też dodać tego użytkownika do grupy Czytelnicy dziennika zdarzeń (na stałe, eng. Event Log Readers) oraz Administratorzy domeny (na czas instalacji agentów, eng. Domain Admins).
Następnie możemy przystąpić do instalacji. Klikamy Next.
Następnie akceptujemy warunki i postanowienia umowy licencyjnej.
Następnie zostawiamy ścieżkę instalacyjną programu bez zmian.
Na tym etapie wskazujemy wcześniej utworzone konto. Będzie ono wykorzystywane do uruchamiania usługi FSSO. Podajemy dane logowania według podanego w oknie schematu i przechodzimy dalej.
W następnym polu zostawiamy pola zaznaczone i wybieramy tryb Advanced, następnie przechodzimy dalej.
Na końcu klikamy dalej, by rozpocząć instalację agenta.
Po instalacji zostawiamy zaznaczoną opcję Launch DC Agent Install Wizard.
Tutaj wskazujemy adres IP maszyny, na której jest agent CA. W moim przypadku jest to kontroler domeny, bo ten przypadek zakłada 1 kontroler domeny i mam wszystkie agenty na jednej maszynie, stąd wskazany adres w polu Collector Agent IP address to 192.168.30.2. W Collector Agent listening port nie wykonujemy zmian i przechodzimy dalej.
Wskazujemy z listy domeny, w których chcemy monitorować logowania użytkowników. W moim przypadku jest tylko jedna, więc pozostawiam ją zaznaczoną i przechodzę dalej.
Następnie wybieramy użytkowników, dla których nie monitorujemy logowania. Są to po prostu konta do usług, takie jak np. krbtgt. Po zaznaczeniu przechodzimy dalej.
Teraz wskazujemy kontrolery domeny na których będziemy monitorować logowania. W tym przypadku mam 1 kontroler, więc też pozostawiam go jako zaznaczony. Monitorowanie może się odbywać na dwa sposoby: DC Agent Mode (wymaga instalacji agenta DC) i Polling Mode (odpytywanie bezpośrednio kontrolerów domeny o logowania). Osobiście odradzam z korzystania z Polling Mode szczególnie w dużych środowiskach, bo ta metoda nie jest dokładna i czasami nie wyłapuje logowań użytkowników, gdy ci się logują na konta w tym samym czasie (jeśli wszyscy w organizacji zaczynają pracę w tym samym czasie to właśnie tak jest). Polecam tryb DC Agent Mode i tutaj go zaznaczyłem. Przechodzimy dalej, przy czym warto wziąć pod uwagę to, że po tym etapie ten agent DC zostanie zainstalowany na wskazanych kontrolerach domeny.
Po instalacji należy zrestartować system na kontrolerze domeny, dlatego też zatwierdzamy monit.
Następnie musimy wykonać kilka zmian dla naszego konta serwisowego, by było ono skonfigurowane bezpiecznie, poza tym musimy odblokować porty w firewallu do umożliwienia komunikacji z Fortigate’m. Otwieramy Edytor rejestru (regedit).
Następnie przechodzimy do klucza Komputer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Fortinet\FSAE\collectoragent, klikamy na ten folder PPM i wybieramy Uprawnienia… i dodajemy naszemu użytkownikowi serwisowemu uprawnienia Pełna kontrola do modyfikacji tej gałęzi rejestru.
Po dokonaniu zmian klikamy OK.
W taki sam sposób zmieniamy uprawnienia temu użytkownikowi do zawartości katalogu instalacyjnego agenta: C:\Program Files (x86\Fortinet\FSAE tak, by ten miał uprawnienia Pełna kontrola.
Gdy mamy to za sobą, możemy temu użytkownikowi usunąć członkostwo w grupie Administratorzy domeny. Nadal trzeba o tym pamiętać, by był w grupie Czytelnicy dzienników zdarzeń (jest w ukrytym folderze Builtin).
Następnie tworzymy politykę GPO, która nie pozwala na logowanie tego konta na komputerach. Z faktu, że to konto ma być wykorzystywane tylko do usług, możemy zabronić takiego wykorzystywania. Tworzymy obiekt zasad grupy na początku drzewka klikając na niego PPM i wybierając Utwórz obiekt zasad grupy w tej domenie i umieść tu link….
Następnie definiujemy nazwę obiektu.
Po tym klikamy na niego PPM i wybieramy Edytuj….
Przechodzimy do opcji Konfiguracja komputera > Zasady > Ustawienia systemu Windows > Ustawienia zabezpieczeń > Zasady lokalne > Przypisywanie praw użytkownika i w zasadzie Odmowa logowania lokalnego zaznaczamy Definiuj następujące ustawienia zasad oraz dodajemy naszego użytkownika serwisowego.
Następnie powinniśmy zrobić drugi obiekt zasad grupy dla kontrolerów domeny, w którym pozwalamy na logowanie jako usługa dla wspomnianego konta serwisowego. Po stworzeniu obiektu klikamy PPM na obiekt, następnie Edytuj….
Przechodzimy do opcji Konfiguracja komputera > Zasady > Ustawienia systemu Windows > Ustawienia zabezpieczeń > Zasady lokalne > Przypisywanie praw użytkownika i w zasadzie Logowanie w trybie usługi zaznaczamy Definiuj następujące ustawienia zasad oraz dodajemy naszego użytkownika serwisowego.
Następnie tworzymy trzeci obiekt dla kontrolerów domeny, w którym zdefiniujemy polityki Zapory Windows Defender. Przechodzimy w edytorze zarządzania zasadami grupy do Konfiguracja komputera > Zasady > Ustawienia systemu Windows > Ustawienia zabezpieczeń > Zapora Windows Defender z zabezpieczeniami zaawansowanymi > Zapora Windows Defender z zabezpieczeniami zaawansowanymi – LDAP://<adres obiektu> > Reguły przychodzące (lub Reguły wychodzące), klikamy na puste pole PPM i wybieramy Nowa reguła….
W kreatorze wybieramy regułę, w której definiujemy porty i definiujemy je następująco:
Reguły przychodzące: TCP 8000, TCP 8001, UDP 8002
Reguły wychodzące: TCP 8000, TCP 8001, UDP 8002
W następnym etapie wygląda to tak:
Następnie zezwalamy na połączenie.
W zastosowaniu reguły możemy zostawić ustawienia domyślne (wszystkie poziomy).
Na końcu definiujemy nazwę reguły i klikamy Zakończ.
Powtarzamy to dla portu UDP 8002, a potem powtarzamy obie reguły dla ruchu wychodzącego.
Po dodaniu reguł to powinno wyglądać mniej więcej tak:
Następnie musimy upewnić się, że FSSO Agent jest poprawnie skonfigurowany. Otwieramy Fortinet Single Sign On Agent Configuration i definiujemy hasło w przy zaznaczonym polu Require authenticated connection from Fortigate. Istotne jest to, że to nie jest te same hasło jak do konta serwisowego na prawach którego pracuje usługa dla agenta FSSO.
Teraz musimy podłączyć tego agenta w Fortigate’cie. Otwieramy stronę Security Fabric > Fabric Connectors, a następnie klikamy na Create New.
Następnie z listy connectorów w sekcji SSO/Identity wybieramy Fortinet Single Sign-On Agent.
Następnie w Name definiujemy nazwę profilu, w Primary FSSO Agent definiujemy FQDN/adres IP naszego serwera z agentem FSSO (w moim przypadku dc1.serba.local/192.168.30.2), potem w polu Password hasło, które definiowaliśmy w konfiguracji FSSO. W LDAP server wybieramy nasz zdefiniowany wcześniej profil serwera LDAP (w moim przypadku nazywa się serba.local), następnie User group source wybieramy opcję Collector Agent. Po tym można kliknąć Apply & Refresh.
W efekcie, gdy poczekamy chwilę i wejdziemy do ustawień
ponownie, zobaczymy, że liczba w Users/Groups zmieni się z 0 na ilość
naszych obiektów w AD (w moim przypadku 114). Poza tym, będąc w Security Fabric
> Fabric Connectors jeśli widzimy zieloną strzałkę do góry – to oznacza
poprawnie nawiązane połączenie. W moim przypadku miałem problem na początku z
firewallem, bo nie odblokowałem portów i z tego względu strzałka była w dół na
czerwono.
Sprawdzenie działania agenta FSSO w praktyce jest dosyć proste – wystarczy przejść do Monitor > Firewall User Monitor, a następnie na górze kliknąć Show all FSSO Logons i sprawdzić, czy są zalogowani jacyś użytkownicy (logowanie musi nastąpić po uruchomienia agenta FSSO na maszynie):
Mając to skonfigurowane możemy zrobić 2 rzeczy: dodać dostęp administracyjny administratorom domeny i stworzyć grupy lokalne w Fortigate’cie, które będą zawierały grupy z Active Directory, które docelowo będą wykorzystane w politykach bezpieczeństwa.
Dodanie dostępu administracyjnego do Fortigate bazującego na grupie w AD
Tutaj musimy stworzyć grupę bazującą na obiektach odczytywanych bezpośrednio przez LDAP (bez użycia agenta FSSO). W User & Device > User Groups klikamy Create New:
W Type zostawiamy zaznaczoną opcję Firewall, następnie w sekcji Remote Groups klikamy przycisk Add:
Następnie po otworzeniu karty po prawej stronie wybieramy w polu Remote Server nasz skonfigurowany obiekt serwera LDAP (w moim przypadku serba.local). Następnie w wyszukiwarce możemy wpisać frazę, która nas interesuje, nacisnąć Enter by uruchomić wyszukiwanie i kliknąć PPM na element listy i wybrać Add selected, a następnie kliknąć OK.
Po dodaniu wygląda to tak:
Klikamy OK. Następnie przechodzimy do System > Administrators i Create New i z listy wybieramy opcję Administrator:
W Username wpisujemy cokolwiek, w Type wybieramy Match all users in a remote server group, definiujemy profil administracyjny (definiuje uprawnienia administratora) w Administrator profile (maksymalne uprawnienia to grupa super_admin) i definiujemy w Remote User Group definiujemy grupę, którą przed chwilą stworzyliśmy. Po tym dajemy OK.
W przypadku, gdybyśmy chcieli korzystać z FortiTokenów dla tych użytkowników – musimy zdefiniować administratorów wpisując właściwą nazwę użytkownika w Username i wybierając w Type opcję Match a user on a remote server group.
Stworzenie polityk firewalla bazujących na obiektach AD
Na samym początku musimy utworzyć grupy bazujące na FSSO. W User & Device > User Groups klikamy Create New:
Definiujemy w Name nazwę grupy, następnie wybieramy w Type opcję Fortinet Single Sign-On (FSSO) i w Members klikając plusa, a następnie w wyszukiwarce wyszukujemy grupę, która nas interesuje i klikamy na nią LPM, a potem klikamy OK:
Dla przykładu utworzyłem 2 grupy bazujące na grupach w AD Administratorzy domeny (mają pełne uprawnienia administracyjne na wszystkich komputerach w domenie) i Użytkownicy domeny (wszyscy użytkownicy w domenie).
Następnie przechodzimy do Policy & Objects > IPv4 Policy i tam tworzymy polityki, w których definiujemy w polach:
Name: wedle uznania,
Source: wskazujemy podsieć, w której znajdują się użytkownicy AD oraz grupę AD względem której chcemy definiować dostęp np. domain admins LDAP z mojego przykładu,
Destination: lokalizacja, dla której chcemy wskazać dostęp, dla wszystkich adresów wybieramy obiekt all,
Schedule: always, bo chcemy by reguła działała cały czas,
Service: ALL, bo chcemy, by reguła działała względem wszystkich portów TCP/UDP/ICMP,
Action: ACCEPT, bo chcemy przepuścić ruch.
Następnie w sekcji Security Profiles defiinujemy konkretne polityki bezpieczeństwa, na przykład nie włączamy web filteringu, bo w końcu administratorzy muszą mieć możliwość, by testować połączenie 😉.
Potem w podobny sposób tworzymy politykę z użyciem drugiej grupy i tam dajemy jakiś filtr web filteringu. Potem z faktu, że wszyscy członkowie Administratorzy domeny są członkami grupy Użytkownicy domeny, ustawiamy politykę z administratorami wyżej. Jeśli ktoś nie jest adminem, wtedy względem jego ruchu zostanie zastosowana polityka poniżej.
Jak widać, dodałem też osobą politykę dla kontrolera domeny, bo jednak jeśli nie weźmiemy go pod uwagę (a z reguły nikt na nim nie jest zalogowany) to ten serwer nie będzie mógł się z niczym łączyć. Oczywiście to można skonfigurować lepiej niż na zrzucie ekranu, po prostu to jest szybki przykład działania w praktyce.
Troubleshooting FSSO
Jeśli macie brak połączenia w ustawieniach Fabric Connectora, problemy najczęściej są cztery:
Nieodblokowane porty na firewallu,
Nieprawidłowe hasło do agenta FSSO,
Niewystarczające uprawnienia dla konta serwisowego, na prawach którego pracuje agent FSSO,
Niepoprawnie skonfigurowany adres DNS w Fortigate prowadzący do domeny AD.
Linki do dobrych poradników do troubleshootingu można znaleźć tutaj i tutaj:
Do troubleshootingu najlepiej sobie uruchomić CLI i w nim wykonać 2 polecenia:
To spowoduje, że będziemy widzieli pojawiające próby połączenia się z agentem FSSO przez Fortigate’a. Warto po tym wykonać polecenie:
diagnose debug authd fsso server-status
Wynik wygląda tak:
supra-forti # diagnose debug application authd 8256
Debug messages will be on for 30 minutes.
supra-forti # diag debug enable
supra-forti # diagnose debug authd fsso server-status
Server Name Connection Status Version Address
----------- ----------------- ------- -------
serba.local connected FSSO 5.0.0287
Tutaj wszystko jest w porządku, ale jeśli Connection
Status nie jest connected, a w Version nie ma wersji agenta
FSSO – to oznacza, że firewall blokuje nam połączenie pomiędzy Fortigate’m a
agentem.
Jeśli otrzymujemy w konsoli regularnie coś wyglądającego jak to:
Server challenge:
7b 6e 93 2d 40 37 90 24 0a 00 0e 67 92 2a 82 06
MD5 response:
1b d7 74 10 cd 29 c5 e6 53 2b 6d de a0 c5 d1 1f
_process_auth[FSSO_collector]: server authentication failed, aborting
disconnect_server_only[FSSO_collector]: disconnecting
To oznacza, że albo hasło w agencie FSSO nie zgadza się z
tym w konfiguracji Fabric Connectora albo nasze konto serwisowe nie ma wystarczających
uprawnień na którymś z etapów, który jest opisany wcześniej.
Jeśli pojawia się coś takiego to wszystko jest w porządku z połączeniem z agentem:
fsae_io_ctx_process_msg[serba.local]: received heartbeat 111010
fsae_io_ctx_process_msg[serba.local]: received heartbeat 111011
fsae_io_ctx_process_msg[serba.local]: received heartbeat 111012
fsae_io_ctx_process_msg[serba.local]: received heartbeat 111013
fsae_io_ctx_process_msg[serba.local]: received heartbeat 111014
fsae_io_ctx_process_msg[serba.local]: received heartbeat 111015
Tym razem postaram się opisać pokrótce jak krok po kroku sprawić, że możemy logować się kontami z AD do interfejsu konsoli do zdalnego zarządzania serwerem iRMC. iRMC jest narzędziem out-of-band management serwera, dzięki czemu możemy z poziomu takiej witryny sprawdzić, czy serwer jest włączony, czy jego wszystkie komponenty są sprawne lub też nie czy też zdalnie zainstalować system operacyjny lub też zdalnie go obsługiwać. Co ważne, taki interfejs daje nam taką przewagę nad RDP/VNC, że możemy mieć dostęp do serwera będąc np. w ustawieniach BIOS serwera, więc te rozwiązanie pracuje niezależnie od systemu operacyjnego, który pracuje na hoście.
EDIT: Zdecydowałem się rozszerzyć nieco ten post o certyfikat SSL i wykorzystanie LDAP over SSL. Staram się to teraz wdrażać wszędzie, więc tutaj też powiem o tym więcej.
Certyfikat SSL
Zanim zaczniemy, musimy mieć wcześniej wdrożony urząd certyfikacji (na przykład dzięki usłudze certyfikatów Active Directory) i to jest coś, czego tutaj nie będę omawiał. Zanim wygenerujemy żądanie podpisania certyfikatu, warto się zastanowić jaka będzie nasza nazwa hosta. W moim przypadku jest to irmc-vhost1.serba.local ze względu na to, że mogę zawsze mieć wiele serwerów z iRMC, przez co same irmc.serba.local mogłoby być kiepskim rozwiązaniem po kupnie drugiej maszyny. Na początku zdefiniowałem w DNS przypisany do adresu iRMC, by można go było potem używać zamiast adresu IP. Efekt widać poniżej:
Następnie za pomocą OpenSSL stworzyłem klucz oraz wygenerowałem żądanie certyfikatu. Nie będę się o tym rozpisywał – opisałem cały proces tutaj. W stosunku, co jest w podlinkowanym poradniku należy zmienić jedynie CN oraz DNS.1 na irmc-vhost1.serba.local. Po wygenerowaniu CSRki można bić do serwera i wygenerować certyfikat SSL. Jeśli mamy zainstalowaną funkcję urzędu certyfikacji o nazwie Rejestracja w sieci Web dla urzędu certyfikacji, możemy podpisać żądanie przez stronkę urzędu, co zalecam robić, bo jest po po prostu proste i przyjemne. Adres takiej strony to http://<adres-ca>/certsrv. W moim przypadku jest to https://dc1.serba.local/certsrv (zmieniłem kilka ustawień w IIS, by mieć połączenie po HTTPS ;))
Na początku należy się zalogować swoim kontem administracyjnym w AD:
Następnie należy wybrać Żądanie certyfikatu.
Następnie wybieramy zaawansowane żądanie certyfikatu.
Na tym etapie musimy otworzyć nasz plik CSR w jakimś edytorze tekstu, skopiować zawartość i wkleić w pole żądania. Ponadto, musimy wybrać szablon certyfikatu, dzięki czemu określamy przeznaczenie certyfikatu, który generujemy. To, co nasz interesuje to Serwer sieci Web. Po tym klikamy Prześlij >.
Po tym pobieramy certyfikat w formacie Base-64.
Ponadto, musimy pobrać certyfikat urzędu certyfikacji, co możemy zrobić na stronie głównej urzędu poprzez opcję Pobierz certyfikat urzędu certyfikacji, łańcuch certyfikatów lub listę CRL, a następnie mając zaznaczoną metodę kodowania Base 64, następnie klikając Pobierz certyfikat urzędu certyfikacji.
Następnie musimy się zalogować do interfejsu iRMC i wgrać certyfikaty urzędu certyfikacji oraz certyfikatu SSL wraz z kluczem prywatnym, który wykorzystaliśmy przy wygenerowaniu CSRki. W Tools > Certificates > Current CA Certificate for CAS and SMTP należy kliknąć Load from File (stronę trzeba rozwinąć i znajdziemy przycisk w dolnej części karty po prawej stronie.
Następnie należy kliknąć Select…, wybrać plik CA i po tym kliknąć Upload. W ten sposób mamy zainstalowany certyfikat CA. Następnie wrzucamy certyfikat w Certification Authorities for eLCM rozwijając opcje, klikając Add, następnie w From file wybierając plik i zatwierdzając przyciskiem Add:
Efekt końcowy wygląda tak:
Na końcu rozwijając Current SSL/TLS Certificate należy kliknąć Load from File, a następnie w polu SSL/TLS public key dodać plik wygenerowanego certyfikatu SSL, a w SSL/TLS private key należy umieścić klucz prywatny, którym wygenerowaliśmy CSRkę, to wygląda tak:
Po tym klikamy Upload. Jesteśmy ponadto informowani, że należy wykonać restart iRMC w celu zastosowania zmian, więc klikamy Reboot iRMC.
No i czekamy.
Przed restartem systemu strona była wyświetlana jako niezaufana:
Po restarcie mamy wynik osiągnięty:
Teraz można przejść do integracji.
Integracja SSO
Do integracji należy skorzystać z drugiej płyty ServerView, którą można ściągnąć na stronie producenta po wybraniu swojego modelu urządzenia pod tym linkiem.
Następnie po otwarciu pliku .iso znajdującego się w Archiwum należy odnaleźć plik SVS_LdapDeployer.zip w ścieżce <litera-obrazu>:\SVSSoftware\Software\RemoteView\iRMC_Tools\SVS_LdapDeployer. Kopiujemy go na komputer, na którym:
Jesteśmy zalogowani na konto administracyjne w domenie i mamy do niej dostęp (najlepiej nie logować się bezpośrednio na kontrolerze domeny),
Po rozpakowaniu archiwum otwieramy zawartość i kopiujemy plik Configuration_InitialDeploy_ActiveDirectory.xml do katalogu, w którym znajduje się plik SVS_LdapDeployer.jar.
Następnie edytujemy wspomniany plik .xml. W następującej linii poprawiamy adres na adres naszego kontrolera domeny. Jeśli na serwerze nie używa się SSLa do szyfrowania komunikacji, powinno się zmienić port na 389 i zmienić wpis SSLEnabled na false:
Dzięki temu programik do tworzenia drzewa OU ServerView spyta nas o hasło przed rozpoczęciem pracy. Następnie w sekcji Data mamy do zdefiniowania role:
<Roles>
<Role name ="Administrator" >
<Privilege name ="IpmiLanOem" />
<Privilege name ="IpmiSerialOem" />
<Privilege name ="iRMCsettings" />
<Privilege name ="RemoteStorage" />
<Privilege name ="UserAccounts" />
<Privilege name ="VideoRedirection" />
<Privilege name ="CfgConnectionBlade" />
<Privilege name ="RedfishAdmin"/>
</Role>
<Role name ="Maintenance">
<Privilege name ="IpmiLanOem" />
<Privilege name ="IpmiSerialOem" />
<Privilege name ="iRMCsettings" />
<Privilege name ="VideoRedirection" />
<Privilege name ="RedfishOperator"/>
</Role>
<Role name ="Operator">
<Privilege name ="IpmiLanOperator" />
<Privilege name ="IpmiSerialOperator" />
<Privilege name ="VideoRedirection" />
<Privilege name ="RedfishOperator"/>
</Role>
<Role name ="Monitor">
<Privilege name ="IpmiLanUser" />
<Privilege name ="IpmiSerialUser" />
<Privilege name ="RedfishReadOnly"/>
</Role>
<Role name ="CustomRole">
<Privilege name ="IpmiLanUser" />
<Privilege name ="IpmiSerialUser" />
<Privilege name ="VideoRedirection" />
</Role>
</Roles>
Z reguły nie ma potrzeby posiadania tylu ról, dlatego usuwam wszystkie poza adminem, docelowo wygląda to tak:
<Roles>
<Role name ="Administrator" >
<Privilege name ="IpmiLanOem" />
<Privilege name ="IpmiSerialOem" />
<Privilege name ="iRMCsettings" />
<Privilege name ="RemoteStorage" />
<Privilege name ="UserAccounts" />
<Privilege name ="VideoRedirection" />
<Privilege name ="CfgConnectionBlade" />
<Privilege name ="RedfishAdmin"/>
</Role>
</Roles>
Potem, w sekcji Departments zmienam w Department name na nazwę domeny bez końcówki, więc w tym przypadku ustawiłbym serba, poza tym wyrzucam usunięte role poniżej:
<Departments>
<!--
# any number of departments possible
# !!! Name of Department and associated roles need to be changed !!!
-->
<Department name ="DeptX">
<!--
# List of associated roles.
# any number of roles, but only from roles defined above
-->
<Role name ="Administrator" />
<Role name ="Maintenance" />
<Role name ="Monitor" />
<Role name ="CustomRole" />
</Department>
</Departments>
Po zmianie:
<Departments>
<!--
# any number of departments possible
# !!! Name of Department and associated roles need to be changed !!!
-->
<Department name ="serba">
<!--
# List of associated roles.
# any number of roles, but only from roles defined above
-->
<Role name ="Administrator" />
</Department>
</Departments>
Po wykonaniu zmian zapisuję plik i otwieram konsolę PowerShell lub Wiersz poleceń z uprawnieniami administracyjnymi:
Po tym przechodzę do ścieżki z programem SVS_LdapDeployer i
odpalam polecenie:
Zostaniemy zapytani o hasło i podczas wpisywania jest ono widoczne.
Po wykonaniu tej czynności powinniśmy mieć gotowe drzewko w AD.
Teraz należy utworzyć konto, które będzie wykorzystywane w iRMC w celu sprawdzania kto jest członkiem tej grupy Administrator, a następnie należy dodać je do tej grupy wraz ze wszystkimi kontami użytkowników, które mają mieć dostęp do iRMC. Należy dodać konta użytkowników, a nie grupy ze względu na to, że iRMC nie obsługuje z jakiegoś powodu dziedziczenia członkostwa w grupach. Na potrzeby usługi utworzyłem konto serviceacc:
Nastęonie zanim zacznie się konfigurować profil domeny należy skonfigurować serwery DNS dla naszej domeny w Settings > Network Management > DNS:
Enable DNS: zaznaczone
DNS Configuration: Obtain from DHCP odznaczone
DNS Domain: po prostu nazwa naszej domeny
DNS Search Path: możemy też podać nazwę naszej domeny, dzięki temu dc1.serba.local == dc1. Nie wiem w sumie jak można to wykorzystać, ale ogólnie to jest najlepsza opcja konfiguracji.
DNS Server 1, 2 i 3: tutaj podajemy adresy DNS, z których korzystamy.
W moim przypadku efekt wygląda tak:
Po dodaniu kont do grupy musimy zdefiniować ustawienia w iRMC, dzięki któremu iRMC będzie wiedziało jak komunikować się z AD. Po zalogowaniu się do iRMC otwieramy u góry kartę Settings, następnie User Management po lewej stronie i z niej rozwijamy ustawienia Lightweight Directory Access Protocol (LDAP).
Następnie wpisujemy tutaj dane (Backup LDAP Server jest opcjonalny, jeśli posiadasz drugi kontroler domeny to warto go tu wpisać):
Global Configuration
Enable LDAP: zaznaczone
Enable LDAP SSL/TLS: wedle preferencji, w moim przypadku zaznaczone
Disable Local Login: ta opcja wyłącza możliwość logowania się z kont lokalnych, odradzam zaznaczanie jej
Directory Server Type: Active Directory
Primary LDAP Server
Server: dc1.serba.local
Network Port: 389
SSL/TLS Network Port: 636
Backup LDAP Server
Server: dc2.serba.local
Network Port: 389
SSL/TLS Network Port: 636
Directory Configuration
Authorization Type: ServerView LDAP Groups with Authorization Settings on LDAP Server
Department Name: serba
Domain Name: serba.local
Groups Directory as Sub-tree from Base DN: (puste)
W tej konfiguracji wyżej korzystam z FQDN serwerów – warto o tym pamiętać, by ustawić w konfiguracji serwer DNS tak, by wskazywał na nasze kontrolery domeny, dzięki czemu nazwy będą rozwiązywały się poprawnie. Potem przechodzimy do sekcji, w której określamy użytkownika, z którego korzystamy do komunikacji z AD i pole obiektu AD, z którego korzystamy:
Tutaj definiujemy:
Access Configuration
Authentication LDAP Username: serviceacc
Authentication LDAP Password: *********
Confirm Password: *********
Principal User DN: (puste)
Append Base DN to Principal User DN: odznaczone
Enable Enhanced User Login: zaznaczone (opcjonalne)
User Login Search filter: (&(objectClass=person)(sAMAccountName=%s))
Pole obiektu AD, po którym iRMC wyszukuje użytkownika domyślnie to cn, dlatego ja to zmieniam na sAMAccountName, bo wtedy korzystamy z takiego samego loginu jak do Windowsa. Takie pole można sobie sprawdzić w przystawce Użytkownicy i komputery usługi Active Directory mając zaznaczoną opcje Widok > Opcje zaawansowane. Poniżej przykład z zaznaczonym polem userPrincipalName:
W ten sposób można się logować na konta z Active Directory. Warto sobie w takiej sytuacji zmienić hasło dla konta lokalnego admin na długie ze względów bezpieczeństwa.
Efekt końcowy wygląda następująco:
UPDATE: Dzisiaj w trakcie wdrożenia na Windowsie Server 2019 Essentials miałem taki problem, że po wykonaniu instrukcji powyżej nie byłem w stanie stworzyć sobie drzewka w AD i otrzymywałem błąd:
- The keystore location is not accessible.
- The keystore's password is not correct.
- The keystore you specified is not the one generated during encryption.
Please try again or reset the password.
Rozwiązanie jest takie, by podać login i hasło do konta, którym się autoryzujemy w parametrach w plaintext:
Zawsze polecam zmieniać hasło na takie, które można pokazać przed innymi, a potem zmienić z powrotem na bezpieczne; w innym wypadku róbmy takie operacje będąc w zaufanym gronie osób (to znaczy często w osobności).
Druga rzecz to jest to, że w katalogu z szablonami są pliki Configuration_InitialDeploy_ActiveDirectory.xml i Configuration_InitialDeploy_AD.xml. W tym poradniku korzystałem z tego pierwszego.
Nie wiem jak dużo ludzi słyszało o tym narzędziu, jedno jest pewne. Jakoś działa. Kiedy musimy z niego korzystać? Na pewno wtedy, jeśli dwie firmy czy dwa oddziały łączą się w jeden. To ogólnie może być spory problem – co jeśli na przykład jeden oddział pracuje na staruszku Windows Server 2003, a drugi śmiga na nowości, czyli Windowsie Server 2016 czy 2019? Sytuacja się komplikuje, a pomysłów może brakować. Często ludzie wtedy zastanawiają się na postawienie domeny od zera, lecz czy to ma sens? Trzeba podłączyć wszystkie systemy od zera. Tam, gdzie mamy skonfigurowane usługi powiązane z domeną – do piachu i od nowa.
Rozwiązaniem jest ADMT (Active Directory Migration Tool). Stare narzędzie od Microsoftu, które pozwala na migrację obiektów pomiędzy domenami. Pozwala nam na przenoszenie:
kont użytkowników (z profilami użytkowników i hasłami do kont),
grup użytkowników,
kont komputerów (z uprawnieniami),
kont wykorzystywanych do usług, np. konto serwisowe dla UTMa, które ma na celu sprawdzanie dziennika zdarzeń w poszukiwaniu informacji logowaniach użytkowników na konkretnych komputerach w domenie,
raportowania.
Ja akurat w tym poście przerobię przykład na nowszych kontrolerach domeny, to znaczy będę przenosił obiekty z Windowsa Server 2008 R2 na 2019. Jeśli macie starsze systemy (np. Windows Server 2003 czy 2003 R2), warto sobie w takiej sytuacji postawić taki Windows Server 2008 R2 tymczasowo. I tak będziemy go potrzebowali, bo nie zrobimy bezpośredniej migracji z Windowsa Server 2003 (brak obsługi DFSR, SMBv1)/2003 R2 (SMBv1). To akurat opisałem już tutaj – może się przydać.
Przygotowanie do pracy
Zanim zaczniemy, przedstawię środowisko, które mamy do dyspozycji:
Stara domena:
Nazwa domeny: nowadomena.local (tak, wiem, że nazwa jest myląca w tym poradniku)
W powyższym przykładzie zastosowałem pewne uproszczenia, mianowicie zwykle będzie tak, że oba serwery będą w dwóch różnych podsieciach. Do migracji elementów w domenie kontrolery (przynajmniej jeden po obu stronach) muszą mieć między sobą łączność, czyli np. muszą mieć umożliwiony routing i odblokowany ruch na firewallu. Aby nawiązać relację zaufania między kontrolerami domeny one muszą między sobą być w stanie rozwiązywać nazwy DNS, czyli kontroler ad-2008-r2 będący kontrolerem domeny nowadomena.local musi być w stanie rozwiązać nazwy z domeny supratest.local, a serwer ad-2019 będący kontrolerem domeny supratest.local musi być w stanie rozwiązywać nazwy w domenie nowadomena.local, stąd należy ustawić na tych hostach preferowane serwery DNS tak, by serwery wskazywały na siebie na wzajem. Z faktu, że są kontrolerami domeny, drugorzędnym serwerem DNS są one same, dzięki czemu rozwiązują nazwy we własnych domenach.
Instalacja narzędzi do migracji
Swoją drogą, nie wiem jak na Windowsie Server 2003 R2, ale na Windowsie Server 2003 nie byłem w stanie używać ADMT, więc w takich przypadkach trzeba instalować ADMT na Windowsie Server 2008 (R2). Na samym początku warto zacząć od instalacji Microsoft SQL Server 2008 (NIE R2), a po tym trzeba zainstalować Service Pack 1 do tej wersji SQLa. W instrukcji skorzystamy z darmowej wersji Express. Przejdźmy przez etap instalacji. Po odpaleniu instalatora wybieramy tylko funkcję Database Engine Services:
Następnie pozostawiamy nazwę instancji jako SQLEXPRESS (właściwie wszystkie te pola można zostawić bez zmiany i iść dalej).
Teraz musimy wskazać konto, które będziemy wykorzystywać jako konto obsługujące usługi serwera SQL. Ja wybrałem konto ZARZĄDZANIE NT\SYSTEM (w angielskim Windowsie NT AUTHORITY\SYSTEM).
Następnie wybieramy tryb uwierzytelniania Mixed Mode i definiujemy domyślne hasło do bazy danych. Dodałem też konto Administrator jako konto administracyjne dla SQLa.
Potem wystarczy jedynie klikać dalej i w ten sposób przejdziemy przez proces instalacji. Po tym musimy też zainstalować SQL Server 2008 Service Pack 1 (od niedawna odnośnik do niego na stronie Microsoftu jest niedostępny, więc jeśli tego potrzebujesz, spróbuj znaleźć plik o nazwie SQLServer2008SP1-KB968369-x64-ENU.exe (wersja 64-bitowa) lub SQLServer2008SP1-KB968369-x86-ENU.exe (wersja 32-bitowa) w Internecie):
Gdy mamy to za sobą, możemy przejść do instalacji ADMT. Pobierzemy je tutaj. Na samym początku musimy wskazać instancję bazy danych, z której chcemy korzystać. Wskazuję .\SQLEXPRESS. Ta kropka na początku oznacza, że to jest ta sama maszyna, na której pracujemy (po prostu maszyna lokalna).
Następnie wybieramy, że nic nie importujemy.
I to tyle, po tym powinien się ten program zainstalować. Poza tym musimy jeszcze zainstalować ADMT Password Export Server, ale do tego dojdziemy później.
Tworzenie relacji zaufania między domenami
Następnym krokiem jest stworzenie dwustronnej relacji zaufania między domenami. By to zrobić, należy w konfiguracji DNS obu domen stworzyć conditional forwarder na wzajem, czyli w DNSie nowadomena.local musi być conditional forwarder do supratest.local i w DNSie supratest.local musi być conditional forwarder do nowadomena.local. Ponadto musimy w obu domenach utworzyć strefy do wyszukiwania wstecz (rDNS). Warto zrestartować serwery po wykonaniu tych czynności – w moim przypadku dalszy etap nie dział dojść do skutku pomimo tego, że zrobiłem wszystko poprawnie, a po restarcie magicznie zaczęło działać.
By to zrobić, klikamy na drzewku serwera DNS w gałąź Strefy wyszukiwania wstecznego PPM i wybieramy Nowa strefa…
Na początku wybieramy strefę, którą chcemy utworzyć. Nas interesuje strefa podstawowa.
Następnie w pierwszym oknie kreatora wybieramy opcję Do wszystkich serwerów DNS uruchomionych na kontrolerach domeny w tym lesie: nowadomena.local:
Potem musimy wskazać, czy strefa będzie dotyczyć IPv4 czy IPv6. Wybieramy IPv4.
Następnie wskazujemy identyfikator sieci dla strefy rDNS, czyli w moim przypadku to 192.168.162.x:
Pod koniec, w ustawieniach aktualizacji dynamicznych wybieramy opcję Zezwalaj tylko na zabezpieczone aktualizacje dynamiczne (zalecane dla Active Directory).
W ten sposób mamy utworzoną strefę wyszukiwania wstecz i musimy to samo zrobić na drugim kontrolerze domeny. Następnie by utworzyć usługę warunkowego przesyłania dalej klikamy na gałąź Usługi warunkowego przesyłania dalej PPM i wybieramy Nowa usługa warunkowego przesyłania dalej….
Teraz w polu Domena DNS definiujemy nazwą domeny, do której przesyłamy zapytania DNS dalej, czyli na kontrolerze domeny supratest.local wskazujemy domenę nowadomena.local i poniżej w sekcji Adresy IP serwerów głównych wskazujemy adres serwera DNS tej domeny, czyli 192.168.162.11. Jeśli w waszej organizacji jest więcej niż jeden serwer DNS w domenie, należy wtedy zaznaczyć opcję Przechowaj tę usługę warunkowego przesyłania dalej w usłudze Active Directory i replikuj ją w następujące serwery: i wybieramy z listy Wszystkie serwery DNS w tym lesie.
Analogicznie robimy to samo dla domeny supratest.local na kontrolerze domeny nowadomena.local:
Mając to gotowe możemy w końcu nawiązać relację zaufania w przystawce Domeny i relacje zaufania usługi Active Directory klikając prawym na nazwę naszej domeny i Właściwości.
Następnie wybieramy zakładkę Zaufania i klikamy przycisk Nowe zaufanie….
Jeśli widzisz takie opcje w pierwszym oknie wyboru – to oznacza, że prawdopodobnie nie wykonałeś któregoś z poprzednich kroków. Ja tak miałem i zorientowanie się w czym popełniłem błąd zajęło mi tak z dobre 20 minut.
Jeśli wszystko jest okej, powinieneś zobaczyć takie opcje wyboru (wybieramy typ zaufania Zaufanie lasu):
Następnie wybieramy kierunek zaufania jako dwukierunkowy:
Teraz wskazujemy utworzenie zaufania dla tej domeny i określonej domeny.
Następnie musimy podać poświadczenia do konta administracyjnego w tej drugiej domenie. Zwróćcie uwagę, że ja tą czynność wykonuję z kontrolera domeny supratest.local!
Jako zakres uwierzytelniania dla użytkowników lasu nowadomena.local wybierzemy Uwierzytelnienie dla całego lasu.
Na końcu powinniśmy potwierdzić przychodzące i wychodzące zaufanie, więc tak też zaznaczamy.
Ostatnie machnięcia pędzlem przed rozpoczęciem migracji
I cyk, gotowe. Mamy relację zaufania pomiędzy dwoma domenami. Teraz przydadzą nam się jeszcze 3 rzeczy przed rozpoczęciem migracji:
dodane uprawnień do grup administracyjnych w domenach nawzajem,
zainstalowanie Password Export Server,
wyłączenie firewalla na stacjach końcowych.
W grupie Administratorzy członkami są:
użytkownik Administrator,
grupa Administratorzy domeny (Domain Admins),
grupa Administratorzy przedsiębiorstwa (Enterprise Admins).
W momencie pisania tego posta znalazłem posta, który dobrze opisuje do czego te grupy są, polecam zerknąć tutaj, by zaczerpnąć dobrej lekturki! Tak czy siak, musimy tych członków grupy dodać nawzajem z obu domen, dzięki czemu w moim przykładzie w obu grupach Builtin\Administratorzy (Builtin\Administrators) lista członków będzie wyglądała następująco:
Teraz warto zainstalować ADMT Password Export Server. Na początku musimy utworzyć plik klucza szyfrującego, bo będzie nam potrzebny w instalacji. Zrobimy to za pomocą następującego polecenia (oczywiście możemy zmienić ścieżkę pliku i hasło):
cd C:\Windows\ADMT
admt.exe Key /Option:Create /SourceDomain:NOWADOMENA.LOCAL /KeyFile:C:\FileMigPass.pes /KeyPassword:Pass@123
Po pobraniu instalatora i uruchomieniu go zostaniemy poproszeni o ten plik klucza, co zrobiliśmy wyżej i o podanie hasła do niego:
Następnie musimy wskazać konto, na którego prawach będzie pracowała usługa serwera haseł. Ja wskazałem tutaj konto [email protected] (jak sam zrzut ekranu sugeruje te konto musi móc pracować w trybie usługi):
Po instalacji serwera haseł musimy zrestartować serwer, na którym wykonaliśmy instalację, a następnie włączyć jego usługę w przystawce Usługi (services.msc), usługa nazywa się Password Export Server Service:
Na koniec polityką GPO wyłączymy firewall we wszystkich systemach w firmie (zakładając, że wykorzystują jedynie Zaporę systemu Windows. W przystawce Zarządzanie zasadami grupy tworzymy nowy obiekt GPO klikając PPM na Obiekty zasad grupy i wybieramy Nowe, następnie wpisujemy nazwę polityki i zatwierdzamy.
Możemy ją od razu przeciągnąć i upuścić pod OU Komputery zakładając, że tam są wszystkie komputery, które chcemy przenosić (tam jest nasz host ENDPOINT-1 do przeniesienia). Następnie klikamy na obiekt PPM i wybieramy Edytuj….
Następnie przechodzimy do Konfiguracja komputera > Zasady > Szablony administracyjne > Sieć > Połączenia sieciowe > Zapora systemu Windows > Profil domeny i wyłączamy opcję Zapora systemu Windows: chroń wszystkie połączenia sieciowe. To samo wykonujemy na kontrolerze domeny w drugiej domenie.
Domyślnie po 90 + od 0 do 30 minut polityka wejdzie w życie na stanowiskach końcowych. Możemy przyspieszyć ten proces wykonując na tych maszynach polecenie gpupdate /force. Jeśli masz innego firewalla w systemie (np. jeśli korzystasz z ESET Endpoint Security) – powinieneś do wyłączenia antywirusa wykorzystać dedykowane narzędzia do tego, czyli w przypadku ESETa jest to konsola ESMC (ESET Security Management Center). Dla ciekawskich, tutaj opisano z jakich portów korzysta ogólnie Active Directory.
W ten sposób firewall jest wyłączony i możemy zacząć prawdziwą migrację.
Migracja kont użytkowników, grup, komputerów, zabezpieczeń i haseł
Zaczynamy od uruchomienia ADMT (Active Directory Migration Tool). W nim, klikamy prawym na górę drzewka i wybieramy opcję, która nas interesuje. Z faktu, że musimy zrobić migrację komputera, musimy wykonać migracje (we wskazanej kolejności):
użytkowników,
grup użytkowników,
translację zabezpieczeń,
migrację haseł (to się robi już na etapie migracji użytkowników),
komputerów.
Zaczniemy więc od migracji użytkowników kreatorem User Account Migration Wizard. Musimy na początku wskazać źródłową i docelową domenę względem których wykonujemy migrację. Wskazałem w Source domenę nowadomena.local i w Targetsupratest.local.
Następnie wybieramy Select users from domain, ponieważ chcemy wybierać użytkowników do migracji z drzewa AD, a nie z pliku.
Następnie wskazujemy użytkowników dodając ich z drzewka. Ja już dodałem dwóch:
Potem wskazujemy OU do którego przenosimy użytkowników w docelowej domenie. Nie stworzysz OU w nowej domenie z tego kreatora, więc jeśli planujesz jakiś konkretny schemat drzewa to przygotuj sobie go przed migracją. Wystarczy kliknąć w odpowiedni element drzewka po kliknięciu Browse… w domenie i to spowoduje, że adres się sam uzupełni.
W następnej części kreatora zostaniemy spytani, czy chcemy też migrować hasła użytkowników. Z faktu, że mamy już wdrożony ADMT Password Export Server, skorzystamy z tego. Wybieramy opcję Migrate passwords. Wskazujemy też kontroler domeny z którego migrujemy takie hasła, w moim przypadku to jest ad-2008-r2.nowadomena.local.
Następnie musimy określić w jaki sposób ma być realizowana migracja kont użytkowników. Aby uniknąć problemów wybieram opcję Target same as source. To powoduje, że jeśli konto jest włączone to docelowo też będzie na drugiej domenie i odwrotnie. Wybieram też na dole Migrate user SIDs to target domain. To jest istotne przy migracji komputerów z tego względu, że profile użytkownika i uprawnienia plików (np. na udziałach sieciowych) są do takiego SIDa przypisane i z tego powodu chcielibyśmy, by ten SID użytkownika się nie zmieniał. Poza tym musimy dać Tak w obu monitach, bo bez tego migracja SIDów się nie wykona:
Potem, musimy zdecydować czy chcemy dokonać translacji profili mobilnych, zaaktualizować uprawnienia użytkownika i przenieść grupy, w których jest użytkownik. Opcji jest więcej, w skrócie zaznaczamy wszystkie:
Kolejna rzeczy to wybór właściwości obiektów, które przenosimy. W skrócie nie wykluczamy żadnych, więc przechodzimy dalej bez zmieniania czegokolwiek.
Ostatnią rzecz, którą wybieramy jest decyzja co ma zrobić kreator, gdy pojawią się problemy w postaci konflików (np. przenosimy obiekt, który już istnieje w domenie docelowej). Najlepszym rozwiązaniem jest przeniesienie bez migracji obiektów z konfliktami i przejrzenie ich ręcznie by zobaczyć co właściwie jest nie tak, czy obiekty dotyczą takiej samej osoby i potem można uruchomić ten sam kreator ponownie, gdy się rozwiąże problem (np. przez usunięcie starego obiektu w docelowej domenie).
W ten sposób dotarliśmy do końca kreatora. Po kliknięciu Zakończ rozpocznie się proces migracji (okienko po prawej). Kliknąłem też View Log, by pokazać Wam jak wyglądają logi z takiej migracji.
Okej, teraz przejdźmy do migracji zabezpieczeń, którą trzeba wykonać przed migracją komputerów. Na tym etapie musimy mieć przygotowane komputery, które przenosimy w taki sposób, że:
mają możliwość rozwiązywania nazw DNS w nowej domenie,
mamy możliwość korzystania z uprawnień administracyjnych z obu domen,
maszyny NIE mogą być uśpione/we wstanie wstrzymania,
tak jak wcześniej to zmienialiśmy komputery najlepiej gdyby miały wyłączony firewall na czas migracji tak, aby agenty ADMT mogły się szybko zainstalować i wykonać ich robotę,
taką translację powinniśmy robić na komputerach bez zalogowanych użytkowników. Dzięki temu nie mamy żadnych błędów przy translacji.
Jeśli jesteśmy pewni, że to jest zrobione i możemy odpalić kreator Security Translation Wizard:
W tym procesie przyzwyczaimy się do tego widoku…
Wybieramy opcję Previously migrated objects.
Tutaj zostawiamy tak samo jak poprzednio, bo przenosimy nadal z domeny nowadomena.local do supratest.local.
Wskazujemy komputery dla których translacja ma być wykonana poprzez drzewko z domeny wskazując opcję Select computers from domain, następnie wybieramy komputery, które nas interesują.
Poza wybraniem komputerów wskazujemy dodatkowo w polu Additional trusting domain domenę nowadomena.local.
Następnie zaznaczamy wszystkie pola. Po prostu.
W następnym polu zaznaczamy opcję Add, bo jeśli coś pójdzie nie tak to w żaden sposób nie zmodyfikujemy obiektów w naszej domenie.
Następnie po tym otworzy nam się okno Active Directory Migration Tool Agent Dialog, w którym taki proces migracji się odbywa. Jest on nieco bardziej rozbudowany, bo migracja nie odbywa się natychmiast, dzięki mamy czas po zakończeniu kreatora, by upewnić się, że komputery są gotowe do migracji. Na początku wybieramy Run pre-check dzięki czemu sprawdzimy, czy agent się poprawnie zainstaluje na maszynie końcowej. Dopiero po tym możemy wykonać translację.
Jeśli otrzymujesz po pre-checku następujący błąd:
ERR2:7666 Unable to access server service on the machine 'computer.domain.com'. Make sure netlogon and workstation services are running and you can authenticate yourself to the machine. hr=0x800706ba. The RPC server is unavailable
To oznacza, że firewall blokuje połączenie, ogólnie te błędy się sprawdza w View Migration Log. Po prostu wyłącz firewall i wtedy zadziała. Jeśli stan Pre-check jest Passed, możemy wybrać Run pre-check and start agent operation. Oczywiście wtedy Agent Dialog pominie test i zajmie się tym, czym właściwie ma. Jeśli mieliście zalogowanych użytkowników na danej stacji, to translacja zakończy się z ostrzeżeniami.
W innym wypadku nie powinno być problemu jak tutaj (po prostu uruchomiłem dla tego samego komputera kreator ponownie):
Okej, w takim razie w tym momencie doszliśmy do etapu przewodniego tego posta – migracji komputerów. Odpalamy kreator Computer Migration Wizard. Na samym początku wskazujemy domeny tak samo jak poprzednio:
Potem wskazujemy komputer(y) tak samo jak w kreatorze translacji zabezpieczeń (opcją Select computers from domain i wybierając je z drzewka):
Następnie wskazujemy DN dla docelowego OU, w którym ma się znajdować komputer po przeniesieniu do domeny (tak samo jak w migracji użytkowników/grup wskazujemy miejsce w drzewku, a adres się sam uzupełni):
Tak jak poprzednio, zaznaczamy wszystkie elementy do translacji.
Podobnie jak w poprzednim kreatorze, zaznaczamy opcję translacji zabezpieczeń Add (choć ja zaznaczyłem Replace na zrzucie).
Potem określamy czas, po jakim migracja się rozpocznie. Jeśli pracownicy pracują przy komputerach i są tego świadomi, że będzie wykonywana taka migracja lub ich po prostu nie ma, warto zaznaczyć 0 – po prostu migracja rozpocznie się natychmiast.
Podobnie jak w przypadku migracji użytkowników nie wykluczamy żadnych atrybutów obiektów ani nie migrujemy obiektów, jeśli pojawi się jakiś konflikt pomiędzy domenami (lecz teraz nie między obiektami użytkowników/grup, a obiektami komputerów).
Na koniec obiekt zostanie skopiowany i na maszynie powinien odpalić się ten sam proces przygotowania instalacji agenta ADMT jak w przypadku translacji zabezpieczeń.
Tutaj po zakończeniu migracji możemy zobaczyć, że komputer się restartuje…
i kończymy sukcesem, bo podłączył się do nowej domeny.
Co prawda nie mam screenshota z przeniesionego hosta, ale po zalogowaniu się do użytkownika, z którego korzystałem na tej przeniesionej maszynie mogłem się zalogować do tego samego profilu, lecz przy pierwszym logowaniu musiałem zmienić hasło (starym hasłem było hasło dotychczasowe ze starej domeny). I tyle, w ten sposób można zrobić migrację komputerów dzięki ADMT!
Sporo informatyków w różnych organizacjach ma jeden duży problem – jego organizacja nie ma lub nie chce przeznaczać środków na IT. Nie ma kasy na nowy serwer, nie ma kasy na Windowsa Server 2019 (Essentials lub Standard) i nie ma kasy na licencje CAL (w przypadku wersji Standard). W takiej sytuacji pojawia się pomysł: „hej, w końcu na QNAPie i Synology jest funkcja kontrolera domeny, postawmy domenę na tym”. Moja sugestia:
Nie rób tego.
Dlaczego? To, że ta funkcja w tych systemach tak się nazywa nie znaczy, że oferuje dokładnie to samo, co kontroler domeny w Windowsie z prawdziwego zdarzenia. By oszczędzić Ci włosów, które byś sobie wyrwał(a) z głowy w trakcie pracy na tym, postanowiłem samemu przekonać się na własnej skórze jak to działa w praktyce.
Przygotowanie do testów
Mam w domu QNAPa TS-453A z 8 GB RAMu z 4 dyskami 2 TB marki WD. klientami są maszyny wirtualne, które stawiałem w środowisku VMware Workstation Pro 15.x. Założenie jest proste – podłączyć do niego maszyny i próbować sprawdzić jak zachowuje się domena oraz jaka jest jej charakterystyka. Prędzej czy później w firmach znajdują się środki, więc pewnie kiedyś taka domena po jakimś czasie zostałaby przeniesiona na nowy kontroler domeny.
Praktyka
Na początek podłączyłem sobie Windowsa Server 2016 do tej domeny, bo chciałem przenieść domenę na drugi kontroler (zainstalowałem na tym Windowsie rolę Usługi domenowe Active Directory). Chciałem to zrobić w sposób, który opisałem tutaj. Nie wyszło, dlaczego? Przed startem podniesienia drugiego kontrolera domeny otrzymuję komunikat, że serwer RPC nie jest dostępny, ani, że serwer nie jest w stanie skontaktować się z aktualnym kontrolerem poprzez WMI.
Próba promocji Windowa Server 2016 do roli kontrolera domeny
Na tym etapie zrezygnowałem. Może inny Windows Server da radę? Sprawdziłem na 2019, to samo.
Próba promocji Windowa Server 2012 do roli kontrolera domeny
Powyżej zrzut ekranu z 2012 – też to samo, 2012 R2 – te same efekty. Sprawdziłem sobie poziom funkcjonalności lasu i domeny – Windows Server 2008 R2. To oznacza, że te hosty powinny się bez problemu podłączać.
Jak spróbowałem podłączyć system Windows Server 2008 R2 (ze starszymi nie próbuję, ten i tak już nie jest wspierany) do domeny to otrzymałem taki komunikat:
W dużym skrócie – nie podepniesz go do domeny. W takiej sytuacji myślę sobie – ale przecież możemy zrobić relację zaufania pomiędzy domenami i tak przenieść wszystkie obiekty w AD wraz ze wzorcami na nowy serwer. Z tym pomysłem też się przejechałem, bo jak otworzyłem DNSa na koncie Administratora to dostałem to:
W QNAPie jest zakładka do zarządzania DNSem, wygląda ona tak:
Opcje związane z zarządzaniem usługami do warunkowego przekierowania tu nie istnieją, a bez tego nie zrobimy dwustronnej relacji zaufania. Nie wiem jak, ale potem byłem już w stanie dostać się do ustawień DNSa z poziomu przystawki MMC, ale nadal przy wspomnianych ustawieniach dostaję to:
Dzięki temu możemy zapomnieć o przeniesieniu obiektów z tej domeny. Zobaczmy jeszcze jak wygląda zarządzanie politykami GPO:
Ustawienia kontrolerów domeny w domenie na QNAPie
Ustawienia kontrolerów domeny w domenie na Windowsie Server
Widzicie różnicę? Bo ja tak, nie ma wielu ustawień. Miałem też problem ze stworzeniem nowej polityki, właściwie tego nie byłem w stanie zrobić, ale nie zrobiłem z tego zrzutu ekranu. Trochę poszperałem w Internecie i znalazłem instrukcje do konfiguracji DNSa w Sambie: https://lists.samba.org/archive/samba/2018-December/219978.html Ponadto tutaj jest więcej informacji na temat konfiguracji DNS w Sambie: https://wiki.samba.org/index.php/DNS_Administration
Konkluzja
Nie jestem magikiem od AD póki co, ale to mi śmierdzi – sporo rzeczy, które działa normalnie w Windowsowym AD DS albo wymaga kombinacji jak niczym Justyna Kowalczyk w biathlonie, lecz przed komputerem i niektóre rzeczy po prostu nie działają tak, jak powinny. Czy pocenie się przed kolejnym wyzwaniem stawianym przez to, że Samba nie jest standardowym serwerem AD jest warte świeczki i pieniędzy, które można przeznaczyć na Windowsa Server? Moim zdaniem nie.
