Ten problem niestety jest przy każdym środowisku z Windowsem Server w domyślnej konfiguracji, lecz bez obaw – jest na to rozwiązanie. Problemem są wyłączone domyślne polityki firewalla w Windowsach, więc wystarczy je włączyć. Oczywiście robi się to polityką GPO, bo nie wyobrażam sobie takie coś wklepywać na 100 komputerach.
Należy włączyć następujące polityki firewalla w ruchu przychodzącym:
Instrumentacja zarządzania Windows (ruch przychodzący ASync)
Instrumentacja zarządzania Windows (ruch przychodzący DCOM)
Instrumentacja zarządzania Windows (ruch przychodzący WMI)
Zdalne zarządzanie usługami (RPC)
Zdalne zarządzanie usługami (RPC-EPMAP)
Zdalne zarządzanie zaplanowanymi zadaniami (RPC)
Zdalne zarządzanie Zaporą Windows Defender (RPC-EPMAP)
Na zrzucie ekranu można zobaczyć poniżej jak wyglądają ustawienia:
Oczywiście nie trzeba ich tworzyć ręcznie. Wystarczy otworzyć Zaporę Windows Defender z zabezpieczeniami zaawansowanymi, znaleźć pasujące nazwy i poprzeciągać do GPO. Od razu wszystko się ładnie doda. Po utworzeniu obiektu GPO można go na spokojnie przypiąć do korzenia drzewa AD, dzięki czemu obiekt będzie zmieniał ustawienia firewalla we wszystkich komputerach w domenie – tego chcemy.
Po tym należy odczekać 2 godziny, aż komputery kliencie same spróbują pobrać nową konfigurację GPO z domeny lub można zrestartować maszyny – to da nam ten sam skutek – maszyny będą miały zmienione ustawienia firewalla.
Gdyby ktoś był leniwy – tutaj kopia polityk, którą można sobie zaimportować. Do tego trzeba zrobić nowy obiekt, a potem kliknąć prawym i Importuj ustawienia….
Z istotnych rzeczy należy wybrać folder, w którym jest nasz plik ZIP z polityką.
Jako część mojej pracy inżynierskiej musiałem skonfigurować mechanizm uwierzytelniania oparty o domenę Active Directory. Założeniem było to, by użytkownicy z podłączonymi komputerami do domeny miały móc się logować bez jakiegokolwiek problemu do dwóch sieci Wi-Fi oraz do portów na switchu. Postaram się opisać jak wszystko skonfigurować od zera.
W każdym przypadku potrzebujemy serwera RADIUS. Są tutaj różne opcje, ponieważ można zainstalować serwer FreeRadius, lecz z faktu, że korzystałem w tym projekcie ze środowiska bazującego na Windowsach skorzystałem z roli Serwera zasad sieciowych (Network Policy Server).
Mechanizm działania jest dosyć prosty: użytkownik wykonuję próbę połączenia się z siecią po czym dostaje odpowiedź od urządzenia (access point lub switch), że musi się dodatkowo autoryzować i ten próbuje dokonać autoryzacji swoim kontem komputera lub aktualnie zalogowanego użytkownika w AD. Access point/switch komunikują się z serwerami RADIUS będąc ich klientami w celu sprawdzenia czy dany użytkownik ma mieć prawo do korzystania z zasobu (definiuje się to na podstawie grup użytkowników/komputerów). W trakcie połączenia klienta RADIUS z serwerem ci wykorzystują klucz współdzielony w celu uwierzytelnienia się. W przypadku, gdy użytkownik jest w grupie zdefiniowanej dla zasady przypisanej do klienta RADIUS – dostaje połączenie. W innym przypadku zostaje odrzucony.
Zanim zaczniemy instalować NPSa musimy mieć wcześniej wdrożony urząd certyfikacji (Usługi certyfikatów Active Directory). Myślę, że wkrótce taki poradnik pojawi się na mojej stronie (jeśli tak się stanie to dodam link tutaj do niego). Tak czy siak, gdy mamy to za sobą to instalujemy tą rolę:
Wybieramy Instalacja oparta na rolach lub oparta na funkcjach. Potem wybieramy serwer z listy, klikamy Dalej > i wybieramy Usługi zasad sieciowych i dostępu sieciowego i Dodaj funkcje. Potem Dalej >, Dalej >, Dalej > i Zainstaluj.
Po tym rola powinna być zainstalowana i powinniśmy zacząć konfigurację serwera.
Konfiguracja RADIUS dla sieci Wi-Fi na FortiGate
W tym scenariuszu będę bazował na urządzeniu FortiWiFi 60E, które ma wbudowaną kartę bezprzewodową. Na początku należy otworzyć okno Serwera zasad sieciowych, po czym zdefiniować nową zasadę poprzez wybranie w oknie Konfiguracja standardowa opcję Serwer usługi RAIDUS na potrzeby bezprzewodowych i przewodowych połączeń 802.1X i klikamy Skonfiguruj połączenia 802.1X.
Na dobrą sprawę nie ma znaczenia czy wybierzemy połączenia bezprzewodowe czy nie, bo i tak będziemy modyfikować zasadę tak, by brała pod uwagę adres IP klienta RADIUS zamiast przeznaczenia, ale z faktu, że to miało być dla Wi-Fi zaznaczamy opcję Bezpieczne połączenia bezprzewodowe i nazywamy jakoś zasadę, np. fortigate wifi.
Na następnej karcie kreatora należy zdefiniować klientów RADIUS, którzy będą się łączyli w ramach zasady RADIUS. Na początku nie ma żadnych, więc należy dodać przyciskiem Dodaj… nowego. Po tym należy zdefiniować pole Przyjazna nazwa, która jest po prostu nazwą klienta, a następnie adres IP lub jego FQDN. Z faktu, że dla moich klientów mam wcześniej przygotowane nazwy DNS, wpisałem po prostu fortigate.serba.local, co w moim przypadku odpowiada adresowi 192.168.30.1. Po tym definiujemy wspólny klucz tajny na dole okienka dwa razy. Powinien być długi i powinniśmy sobie go zapisać, bo taki klucz też trzeba będzie zdefiniować w FortiGate. Po tym zapisujemy i idziemy dalej.
Następnie wybieramy typ protokołu EAP dla tworzonej przez nas zasady i tutaj wybieram opcję Microsoft: Chroniony protokół EAP (PEAP). Gdy klikniemy Konfiguruj…, możemy sprawdzić lub zmienić jaki certyfikat będzie wykorzystywany przy komunikacji z klientem. W moim przypadku certyfikat był już wskazany, a ten się wygenerował po postawieniu AD CS (automatycznie, wystarczyło zrestartować serwer i mogłem się cieszyć certem z własnego urzędu).
Następnie należy dodać grupy, które mogą się autoryzować w ramach tej zasady. W moim założeniu dostęp mają wszyscy użytkownicy i wszystkie komputery będące w domenie, więc dodajemy grupy Użytkownicy domeny oraz Komputery domeny tak jak ja poniżej:
Następny punkt wykonuje się tylko i wyłącznie w przypadku FortiGate’a – definiujemy przesyłany parametr tekstowy, który służy do identyfikacji sieci. To działa tak, że FortiGate jest w stanie szukać polityki z konkretnym parametrem. Jeśli w różnych sieciach autoryzujemy różne grupy, możemy mieć takie ciągi znaków różne w różnych regułach, np. siec-handlowcy i siec-marketing, dzięki czemu dwie grupy mogą być inaczej brane pod uwagę przy logowaniu.
W oknie Konfigurowanie elementów kontroli ruchu w sieci klikamy po prawej Konfiguruj…, następnie wybieramy kartę Atrybuty specyficzne dla dostawcy. Domyślnie jest zdefiniowany jeden o nazwie atrybutu Ventor-Specific, klikamy na niego i Edytuj…. Po tym pojawi się okno Informacje o atrybutach i tutaj klikamy Dodaj…, a następnie otworzy się kolejne okno (szał!) Informacje o atrybutach specyficznych dla dostawcy i tutaj należy podać kod dostawcy 12356, zaznaczyć opcję Tak, jest zgodny pod kątem zgodności z RADIUS RFC i kliknąć Konfiguruj atrybut…. Tutaj zmieniamy Format atrybutu na Ciąg i wpisujemy wartość, którą chcemy określić daną politykę, byśmy mogli ją potem wskazać w FortiGate. W moim przypadku to wifi-fortigate. Ten parametr jest ogólnie opcjonalny; zobaczycie za niedługo dlaczego. Po tym wszędzie klikamy OK i Dalej na końcu.
Okienny rozgardiasz związany z milionem podopcji.
W ten sposób mamy prawie wszystko gotowe po stronie serwera:
Pod koniec trzeba zmienić nieco parametry warunkowe dla naszej zasady. Otwieramy Zasady żądań połączeń, znajdujemy naszą zasadę, klikamy prawym i Właściwości. W karcie Warunki usuwamy wszystko i klikając na dole Dodaj… dodajemy nowy warunek: Adres IPv4 klienta dostępu. Po tym jeszcze raz Dodaj… i tutaj podajemy adres IP naszego FortiGate’a.
Końcowo powinno wyglądać to tak (jeśli u Was też to tak wygląda to można zapisać ustawienia):
Po tym warto zmienić jeszcze 1 rzecz: metody uwierzytelnieniaw w zasadach sieciowych. W Zasady > Zasady sieciowe odnajdujemy naszą zasadę, klikamy na nią prawym i Właściwości. W zakładce Ograniczenia, w opcji Metody uwierzytelnienia odznaczamy opcje uwierzytelnianie z szyfrowaniem firmy Microsoft (MS-CHAP) i zostawiamy zaznaczone Uwierzytelnianie z szyfrowaniem firmy Microsoft wersja 2 (MS-CHAP-v2). Jeśli macie tak, jak na zrzucie ekranu – można zapisać.
Nie można zapomnieć o tym, by odblokować port dla RADIUSa na firewallu. Ruch musi być odblokowany dla portów TCP i UDP 1812, 1813, 1645, 1646 (dwa ostatnie dla starych urządzeń) dla połączeń przychodzących i wychodzących pomiędzy serwerem RADIUS a jego klientami (w naszym przypadku FortiGate, AP i switch z Netgear). Ja akurat zrobiłem na taką potrzebę politykę GPO:
Po zapisaniu wystarczy kliknąć prawym OU, w którym znajdują się serwery NPS (w moim przypadku są postawione na kontrolerze domeny) i wybrać Aktualizacja zasad grupy…, a następnie potwierdzić.
Efekty widać tutaj:
Tak samo odblokowujemy ruch do reguł wychodzących.
W interfejsie FortiGate, w User & Authentication > RADIUS Servers należy kliknąć Create New i zdefiniować profil w przykładzie jak niżej, przy czym w moim przypadku w IP/Name podałem FQDNy serwerów NPS, które posiadam (skonfigurowałem tak samo drugi serwer, by mieć redundancję, na koniec pokażę jak skopiować z serwera drugi wszystkie ustawienia). Do tych serwerów w polu Secret definiujemy klucz tajny, który definiowaliśmy na początku w zasadzie.
Następnie, po zapisaniu tych ustawień należy w User & Authentication > User Groups należy utworzyć grupę klikając Create New oraz w Remote Groups kliknąć Add, potem z listy Remote Server wybieramy wcześniej zdefiniowany profil RADIUSa i w Groups wybieramy Any jeśli nie chcemy określać się co do zasad, które zdefiniowaliśmy lub wybierając Specify możemy określić parametr, który zdefiniowaliśmy wcześniej w polu specyficznym dla dostawcy (w naszym przypadku wifi-fortigate).
Mając to trzeba edytować profil SSID w WiFi & Switch Controller > SSIDs lub stworzyć nowy klikając Create New > SSID. W Name definiujemy nazwę profilu (w moim przypadku (serba-corp-wifi), potem w WiFi Settings, w SSID definiujemy nazwę WiFi (w moim przypadku serba.local), w Security Mode wybieramy WPA2 Enterprise i w Authentication należy wybrać RADIUS Server i wybrać profil, który wcześniej zdefiniowaliśmy (w moim przypadku serba.local_radius). Mając zdefiniowane SSID możemy je przypisać do FortiAPków lub do interfejsu Software Switch, w którym są interfejsy, którym są podłączeni użytkownicy przewodowo. Poniżej przykład:
W ten sposób możemy zalogować się do sieci Wi-Fi nawet przez telefon z Androidem:
Tutaj ustawienia z telefonu. Warto dodać certyfikat CA do telefonu, by móc go wybrać.
I tutaj efekt końcowy.
Efekt końcowy widoczny z komputera, który jest członkiem AD:
Możemy to też przygotować wcześniej dodatkową polityką GPO, która dodaje sieć Wi-Fi o naszym SSID tak jak w zrzucie ekranu poniżej, ponadto niżej też konfiguracja zabezpieczeń dla profilu:
Konfiguracja RADIUS dla sieci Wi-Fi na AP od Netgear
Przykład jest prezentowany na urządzeniu Netgear WAC505. Scenariusz jest prawie taki sam, jak w przypadku definicji zasady dla FortiGate’a z drobną różnicą – nie definiujemy żadnego atrybutu specyficznego dla urządzenia i definiujemy dodatkowego klienta RADIUS na początku kreatora. Tak samo definiujemy inne ustawienia. W mojej konfiguracji klient posiada FQDN wac.serba.local, który odpowiada adresowi IP 192.168.30.253. Ten model, który mamy w przykładzie obsługuje też konfigurację przez chmurę, ja akurat definiuję ustawienia lokalnie. Pewnie jak bym miał takich access pointów 10 to definiowałbym to przez chmurę, bo łatwiej wszystko skonfigurować.
Na początku w w Configuration > Security > RADIUS Settings definiujemy adresy IP serwerów RADIUS, porty wykorzystywane do komunikacji oraz klucze współdzielone.
Potem, w Configuration > Wireless > Basic w karcie WLAN Settings należy wybrać SSID, w którym chcemy umożliwić na autoryzację kontami AD i wybrać w Network Authentication opcję WPA2-enterprise.
Po tym możemy dodać tak samo profil Wi-Fi jak w przypadku FortiGate’a. Jak widać poniżej, sieć działa:
I widok z komputera będącego w AD:
Konfiguracja RADIUS dla sieci przewodowej ze switchem marki Netgear
W tym scenariuszu wdrożenia posługiwałem się przełącznikiem Netgear GS716T.
Scenariusz wygląda bardzo podobnie jak w poprzednich politykach – tworzymy nową zasadę na serwerze zasad sieciowych (NPS) korzystając z opcji Bezpieczne połączenia przewodowe (Ethernet) w oknie Wybieranie typu połączeń 802.1X, usuwamy warunki połączenia klienta dla zasad żądań połączeń i definiujemy adres klienta jako adres switcha (w moim przypadku jest to adres netgear.serba.local (192.168.30.254).
Tak wyglądają warunki dla zasad żądań połączeń:
Tak wyglądają dla zasad sieciowych:
I tak wygląda profil klienta RADIUS dla switcha:
Dalsza część jest do ustawienia na switchu. Zaczynamy od zdefiniowania adresów DNS, które mają być wykorzystywane przez przełącznik (w System > Management > DNS > DNS Configuration) poprzez dodanie wszystkich adresów kontrolerów domeny w naszej sieci. Po wpisaniu wartości w puste pole należy kliknąć na dole Add.
Następnie w System > Management > IP Configuration należy się upewnić, że adres IP switcha się pokrywa z tym, który zdefiniowaliśmy w zasadzie w NPSie. W naszym przypadku jest w porządku.
Następnie w Security > Management Security > RADIUS > Server Configuration należy dodać wpisy adekwatne do środowiska:
Server Address: dc1.serba.local
Authentication Port: 1812
Secret Configured: Yes
Secret: tutaj podajemy klucz współdzielony
Active: Primary/Secondary, wybieramy w zależności tego, który serwer ma być wykorzystywany w autoryzacji w pierwszej kolejności
Message Authenticator: Disable
Po tym klikamy na dole Add i tak samo dodajemy serwer dc2.serba.local. Efekt końcowy wygląda tak:
Następnie w Security > Management Security > Authentication List > Dot1x Authentication List należy ustawić dla pola dot1xList w kolumnie 1 wartość Radius. i zatwierdzić kliknięciem Apply.
Teraz, w Security > Port Authentication > Advanced > Port Authentication należy zdefiniować w kolumnie Port Control odpowiednią opcję. Możliwości to:
Auto – ustawienie zależy od globalnego ustawienia pod kątem autoryzacji (ustawimy je na końcu). W domyślnych ustawieniach przełącznika autoryzacja nie jest wymagana.
Authorized – podłączone urządzenia w tym trybie nie przechodzą żadnej autoryzacji nawet, gdy ta jest włączona globalnie.
Unauthorized – brak możliwości autoryzacji pod wskazanym portem.
MAC Based – ustawienia są bazowane na tym, co jest zdefiniowane w ACL dla adresów MAC.
Dla wykonania testu ustawiłem port 1 i 2 w trybie Auto, resztę w trybie Authorized. Dzięki temu możemy na 2 portach testować czy komunikacja z RADIUS działa poprawnie, by potem móc ja włączyć dla reszty switcha.
Na końcu, w Security > Port Authentication > Advanced > 802.1X Configuration włączamy opcję Port Based Aurthentication State i zapisujemy klikając Apply. W ten sposób wszystko jest skonfigurowane po stronie switcha, więc zobaczmy efekty na urządzeniu, które jest w AD i urządzeniu, które w nim nie jest.
Obsługa 802.1X w Windowsie jest domyślnie wyłączona, więc włączamy ją zmienieniem ustawień usługi Automatyczna konfiguracja sieci przewodowej zmieniając Typ uruchomienia na Automatyczny oraz klikając Uruchom, by zaczęła działać.
Wygodniej jest stworzyć politykę GPO, która to nam ustawi na każdym komputerze, więc ta powinna mniej więcej wyglądać tak (dodam, że w tej polityce zmiana ustawień usługi WlanSvc okazała się niepotrzebna):
Tutaj można zobaczyć efekt końcowy:
Ponadto, w Security > Port Authentication > Advanced > Port Summary można zobaczyć, że na porcie 1 Port Status to Authorized:
W przypadku komputera, który nie jest członkiem AD akcja wygląda tak:
Niedawno się tym zajmowałem i w sumie dobrze by było się podzielić takim skryptem. Jest on nieco zmodyfikowany w stosunku, do tego co znalazłem na tej stronie.
Na początku próbka danych, która powinna być zapisana w pliku CSV:
firstname;lastname;username;email;streetaddress;city;zipcode;state;country;department;password;telephone;jobtitle;company;ou
Miron;Trawiński;mtrawinski;mtrawinski@serba.website;aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Mikołaj;Staszewski;mstaszewski;mstaszewski@serba.website;aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Adam;Rekowski;arekowski;arekowski@serba.website;aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Joachim;Grabiński;jgrabinski;jgrabinski@serba.website;aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Norbert;Ewertowski;newertowski;newertowski@serba.website;aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Aureliusz;Wręczycki;awreczycki;awreczycki@serba.website;aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Heronim;Ambroży;hambrozy;hambrozy@serba.website;aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Piotr;Jaroszek;pjaroszek;pjaroszek@serba.website;aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Miłosz;Szcześniak;mszesniak;mszesniak@serba.website;aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Eustachy;Kowalewski;ekowalewski;ekowalewski@serba.website;aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Dorian;Kłopotowski;dklopotowski;dklopotowski@serba.website;aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Olgierd;Zaniewski;ozaniewski;ozaniewski@serba.website;aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Gracjan;Zambrzycki;gzambrzycki;gzambrzycki@serba.website;aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Fabian;Ciura;fciura;fciura@serba.website;aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Piotr;Skonieczny;pskonieczny;pskonieczny@serba.website;aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Poniżej tworzenie OU oraz użytkowników w CSV (warto zwrócić uwagę, że pozycja Państwo jest zdefiniowana jako PL, a nie Polska ze względu na to, że w tym polu daje się Country Code.
<#Import active directory module for running AD cmdlets#>
Import-Module activedirectory
<#Create main OU#>
$baseDN = "DC=SERBA,DC=LOCAL"
$baseOU = "OU=it.supra.tf"
$baseOUstring = $baseOU + "," + $baseDN
<#New-ADOrganizationalUnit -Name "SUPRA" -Path $baseOU#>
if (Get-ADOrganizationalUnit -Filter "distinguishedName -eq '$baseOUstring'") {
Write-Host "$baseOUstring already exists."
} else {
New-ADOrganizationalUnit -Name $baseOU -Path $baseDN
}
<#Create OU's#>
$OUs = @("Dyrekcja","Handlowy","Marketing","Ksiegowosc","Rozwojowy","Prawny","Logistyczny","Techniczny")
<#Loop through each name of the OU to create them#>
foreach ($OUcreate in $OUs) {
$fullOUstring = "OU=" + $OUCreate + "," + $baseOUstring
Write-Output $fullOUstring
if (Get-ADOrganizationalUnit -Filter "distinguishedName -eq '$fullOUstring'") {
Write-Host "$OUcreate already exists."
} else {
New-ADOrganizationalUnit -Name $OUcreate -Path $baseOUstring
}
}
<#Store the data from ADUsers.csv in the $ADUsers variable#>
$ADUsers = Import-csv -Delimiter ";" -Path .\bulk-users-polska.csv
<#Loop through each row containing user details in the CSV file#>
foreach ($User in $ADUsers)
{
<#Read user data from each field in each row and assign the data to a variable as below#>
$Username = $User.username
$Password = $User.password
$Firstname = $User.firstname
$Lastname = $User.lastname
$OU = $User.ou <#This field refers to the OU the user account is to be created in#>
$email = $User.email
$streetaddress = $User.streetaddress
$city = $User.city
$zipcode = $User.zipcode
$state = $User.state
$country = $User.country
$telephone = $User.telephone
$jobtitle = $User.jobtitle
$company = $User.company
$department = $User.department
$Password = $User.Password
<#Check to see if the user already exists in AD#>
if (Get-ADUser -F {SamAccountName -eq $Username})
{
<#If user does exist, give a warning#>
Write-Warning "A user account with username $Username already exist in Active Directory."
}
else
{
<#User does not exist then proceed to create the new user account
Account will be created in the OU provided by the $OU variable read from the CSV file#>
New-ADUser `
-SamAccountName $Username `
-UserPrincipalName "$Username@serba.local" `
-Name "$Firstname $Lastname" `
-GivenName "$Firstname" `
-Surname "$Lastname" `
-Enabled $True `
-DisplayName "$Firstname $Lastname" `
-Path "$OU" `
-City "$city" `
-Company "$company" `
-State "$state" `
-StreetAddress "$streetaddress" `
-Country "$country" `
-PostalCode "$zipcode" `
-OfficePhone "$telephone" `
-EmailAddress "$email" `
-Title "$jobtitle" `
-Department "$department" `
-AccountPassword (convertto-securestring $Password -AsPlainText -Force) -ChangePasswordAtLogon $False -PasswordNeverExpires $True -CannotChangePassword $True
}
}
Get-ADUser -Filter 'Name -like "*"' -SearchBase 'OU=it.supra.tf,DC=SERBA,DC=LOCAL' -Properties DisplayName | ForEach-Object {Set-ADUser $_ -Office 'SERBA Downtown'}
Get-ADUser -Filter 'Name -like "*"' -SearchBase 'OU=Techniczny,OU=it.supra.tf,DC=SERBA,DC=LOCAL' -Properties DisplayName | ForEach-Object {Set-ADUser $_ -Office 'SERBA Headquarters'}
Get-ADUser -Filter 'Name -like "*"' -SearchBase 'OU=Dyrekcja,OU=it.supra.tf,DC=SERBA,DC=LOCAL' -Properties DisplayName | ForEach-Object {Set-ADUser $_ -Office 'SERBA Headquarters'}
I na koniec tworzenie kont w Exchange dla tych użytkowników (istotne – ten skrypt musi być odpalony przez Exchange Management Shell):
Import-Module activedirectory
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
<#adding everyone in that specified company#>
$users = Get-ADUser -Filter {company -eq "it.supra.tf"}
Write-Output $users
foreach($user in $users)
{
Enable-Mailbox -Identity $user.SamAccountName
}
Hyper-V ma upierdliwą cechę – blokuje działanie innych hypervisorów, przez co jeśli Hyper-V działa, nie mogę pracować na wirtualkach np. na VMware Workstation czy Oracle VM VirtualBoxie. Rozwiązanie jest proste:
bcdedit /set hypervisorlaunchtype off
Po restarcie Hyper-V będzie wyłączone i nie trzeba go usuwać z systemu. Jeśli chcemy je włączyć z powrotem, wystarczy wykonać:
Potem taki CSR musimy wykorzystać do podpisania certyfikatu w naszym CA. Jeśli pobierzemy plik w formacie DER zamiast Base-64, można go skonwertować w ten sposób:
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 administrator@supratest.local (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!
