Wycieczka do nowego lasu cz.1

Tym razem coś konkretnego, zamiast niepopularnych frazesów w felietonach. O to krótka historia mojej przygody z migracją do nowej domeny. Zakładam, że taka sytuacja może się komuś przytrafić, choć wiem - nie robi się tego raz w miesiącu. Już kilka razy wspominałem, że jestem leniwy. Dlatego jak największą część prac chciałem zautomatyzować, tak, by samo przeniesienie końcówek do nowej domeny było możliwie proste i jak najmniej czasochłonne.

Wstęp

Tytułem wstępu i łatwiejszego zrozumienia całości odrobina teorii. W domenie starej (którą będę nazywał OLD) działały dwa kontrolery domeny, po jednym w dwóch oddziałach, które komunikowały się po VPN. Oba postawione były na windows server 2003. W mieście A na czas migracji postawiony zostanie serwer w nowej domenie (którą będę nazywał NEW) na systemie windows server 2008. Domena OLD i NEW pozostaną w relacji wzajemnego zaufania. W mieście B stoi kontroler domeny na serverze 2003, zostanie on przeinstalowany, a następnie dcpromowany do domeny NEW. W sieci stoi również Sharepoint na WSS 3.0. Użytkownicy posiadają podpięte zasoby w oparciu o skrypt uruchamiany przy logowaniu usera. Skrypt sprawdza w jakich grupach znajduje się user i podpina dedykowane dla nich zasoby. Kilkadziesiąt usług działa w oparciu o konta domenowe, w tym autentykacja do połączeń VPN.

Cel - nie przerywając pracy pracowników oraz zapewniając najmniejsze zmiany, przeniesienie komputerów do nowej domeny.

Co i jak, czyli teoria

Przyznaje, że nie była to moja pierwsza, duża migracja domeny. To była druga. Wiedziałem więc, jak zareaguje system na logowanie nowego usera - załaduje nowy profil, dla nowego sida.

sid składa się bowiem z informacji o tym, skąd pochodzi user (czyli dla komputerów pracujących w grupach lokalnych są to komputery lokalne, a dla komputerów w domenie domena właśnie), oraz o samym userze. User JohnDoe, który znajduje się w domenie AD to tak naprawdę AD\JohnDoe, albo JohnDoe@AD

Na szczęście jest też dość prosty sposób, by zmusić system do zmiany domyślnego dla użytkownika miejsca przechowywania profilu. Klucz:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

przechowuje w podkluczach podstawowe dane o userze (przy czym każdy podklucz to własne sid usera), w tym klucz ProfileImagePath, który wskazuje usytuowanie profilu. W generalnej większości w czasie przenoszenia usera JohnDoe do domeny NEW koniecznie będzie wyedytowanie wartości nowego klucza usuwając po prostu ".NEW" z końca stringa.

Dzięki temu ogromną część ustawień aplikacji znajdujące się w folderze Dane Aplikacji oraz Ustawienia Lokalne zostanie pomyślnie zaimportowana. Do tego również można wyeksportować całą gałąź rejestru HKEY_CURRENT_USER.

Ale... bo zawsze są jakieś ale. Ale przecież dane w folderach userów (przy ustawieniach domyślnych) są dość restrykcyjnie zabezpieczone (czyli pełny dostęp dla użytkowników z grupy administratorzy, pełny dostęp dla właściciela profilu, wyłączone dziedziczenie z elementów nadrzędnych przez główny folder i włączone dla podfolderów, właścicielem użytkownik SYSTEM). W tym przypadku posłużyłem się narzędziem xcacls.vbs (równie dobrze można użyć Icacls, który jest wbudowany w systemy windows vista i 7, ale niestety miałem zbyt wiele windows xp). Założenie było proste. Automat loguje się na komputer z uprawnieniami administratora i grantuje uprawnienia fullcontrol dla użytkownika z nowej domeny. Nie miałem czasu na analizę wszystkich folderów i plików. Po prostu FullControl dla nowego usera. Składnia polecenia:

XCACLS.vbs nazwa_uzytkownika /E /S /F /T /G SID#sid_usera:F

Dokładny opis możliwości xcacls.vbs znajdziecie tutaj.

Cały skrypt był uruchamiany przez psexec, o którym już kiedyś pisałem.

Migracja kont do domeny

To powinno być wcześniej. Ale jakoś wena poniosła. W tym konkretnym przypadku przenieść musiałem userów z konkretnego OU do dokładnie tak samo odwzorowanego OU w domenie NEW. Ilość narzędzi do robienia tego można liczyć w setkach. Tymczasem mnie odpowiada bardziej sytuacja, gdy dokładnie wiem co się dzieje. I tutaj na przeciw wyszedł mi... PHP. A dokładniej doskonała klasa adLDAP. Dzięki niej pobrałem najpierw wszystkie OU, które mnie interesowały z domeny OLD i utworzyłem w domenie NEW, potem to samo zrobiłem z userami, na końcu sprawdziłem grupy, do których należą użytkownicy i przeniosłem je. Dokumentacja adLDAP jest na tyle dobra, że nie powinno to nastarczyć żadnych problemów. Nadmienię tylko, że wersja 4.0, którą używałem miała jeden mały błąd, który dość łatwo można wyłapać, a związany jest ze zmianą standardu zapisu nazw zmiennych. Od tego czasu adLDAP miał już dwa kolejne releasy, być może zostało już to poprawione.

Sharepoint

Tutaj sprawa jest jeszcze prostsza. Serwer shrepoint najprawdopodobniej pozostanie w domenie OLD, więc należało tylko zmigrować konkretnych użytkowników. Całe sprawa została rozwiązana poleceniem:

stsadm -o migrateuser -newlogin NEW\JohnDoe -oldlogin OLD\JohnDoe

Chyba nie trzeba nikomu tłumaczyć?

Dostęp do zasobów

Tutaj też nie będzie trudno. Wymieniany wcześnie xcacls.vbs, gdy poda mu się tylko folder lub plik, bez pozostałych parametrów, zwróci listę ACL dla obiektu. Teraz już tylko parsowanie i wyszukanie wszystkich wystąpień nazwy domeny OLD i wydanie odpowiedniego polecenia dla domeny NEW.

Całe przygotowanie potrwało trzy dni (okres wakacyjny, nie wszyscy są w pracy, nie do każdego kompa miałem dostęp).

A w następnych częściach

... choć może się okazać, że będzie tylko jedna część. Bo kolejne części zaplanowane są na praktyczną część, czyli co poszło nie tak, jak zaplanowaliśmy. Musze jednak nieskromnie przyznać, że w mieście A wszystko poszło dobrze (prawie). Natomiast w mieście B... to już inna historia. Zapraszam za parę dni.