Hasło DSRM powiązane z użytkownikiem domenowym

2 września 2015 at 08:02

Hasło DSRM (Directory Services Restore Mode) przez wielu administratorów jest (NIESTETY) traktowane po macoszemu. Często sprowadza się to do jego wpisania przy promowaniu kontrolera domeny i zapomnieniu. W niektórych wypadkach wynika to z przekonania, że przecież zawsze owe hasło można zmienić poceniem:

– Zawsze – pod warunkiem, że usługi katalogowe działają prawidłowo i możesz je wystartować! O tym już mało kto pamięta… W pozostałych przypadkach wynika z przekonania, że AD zawsze będzie działać prawidłowo, że to przecież prosta usługa i nic się z nią złego nie dzieje, a w razie czego odtworzy się z backupu – taa jasne… powodzenia Na szczęście już jakiś czas temu Microsoft pomyślał o takich Kamikaze i wydał Hotfix’a umożliwiającego synchronizację hasła DSRM z kontem użytkownika domenowego. (Poprawka dla systemów Windows Server 2008; nowsze mają ją już wbudowaną). Poprawkę można znaleźć pod linkiem: https://support.microsoft.com/en-us/kb/961320 Jak działa ta funkcjonalność? 1. Należy utworzyć dowolnego użytkownika domenowego (bez dodawania do żadnych grup typu Domain Admins, Enterprise Admis etc.) 2. Zainstalować ww. Hotfix’a na kontrolerach domeny po czym je zrestartować. (Jeśli mamy nowsze niż 2008 ten krok pomijamy). 3. Zalogować się interaktywnie na kontrolerze domeny i wprowadzić następujące polecenia:

I gotowe. Nie ma konieczności wprowadzania starego ani nowego hasła […]

Czyszczenie metadanych Active Directory po awarii kontrolera domeny

16 kwietnia 2015 at 13:37

Cytując klasyka – „Nie myli się ten kto nie robi niczego”. Bywają sytuacje nieprzewidziane, gdzie awarii ulega któryś z kontrolerów domeny i nie bardzo jest sposób na przywrócenie mu pełnej funkcjonalności. Pozostaje więc usunięcie kontrolera domeny, posprzątanie bazy Active Directory i wypromowanie nowego kontrolera. Pamięć często choć dobra – bywa krótka… więc jako przypomnienie procedura sprzątania metadanych Active Directory po awarii kontrolera domeny. Zakładając, że kontroler, który uległ awarii nie utrzymywał żadnej z ról FSMO (jeśli utrzymywał trzeba je awaryjnie przejąć) procedura powinna wyglądać mniej więcej tak: 1. Zalogowanie się na działający kontroler domeny z uprawnieniami administratora domeny. 2. Uruchomienie jako administrator powershell’a / wiersz poleceń 3. Uruchomienie narzędzia ndtsutil:

4. Przejście do trybu oczyszczania metadanych Active Directory:

5. Wybranie połączenia:

6. Połączenie z działającym (np. lokalnym) kontrolerem domeny:

7. Powrót do wyższej instancji

8. Przejście w tryb wyboru celu

9. Wy listowanie dostępnych domen

10. Wskazanie numery domeny, gdzie znajdował się kontroler domeny, który uległ awarii

11. Wy listowanie dostępnych lokacji

12. Wskazanie numeru lokacji, w której był nasz kontroler domeny:

13. Wy listowanie wszystkich obiektów kontrolerów domeny we wskazanej lokacji Active Directory

14. Wskazanie konkretnego kontrolera domeny […]

Upgrade Active Directory (Unsupported, but better…)

23 lutego 2015 at 14:33

Weźmy na tapetę temat wykonania upgrade’u Active Directory. Z jednej strony temat bardzo zawiły ze względu na możliwe powikłania, komplikacje i zależności. Z drugiej strony sprowadza się zasadniczo do wykonania dwóch poleceń. Jednakże te dwa polecenia w skrajnym wypadku mogą rozłożyć cały BackOffice Twojej organizacji, atesty na środowiskach testowych i akceptacyjnych i tak najczęściej nie dają jasnych odpowiedzi na wszystkie pytania. Czy jest więc jakiś bezpieczniejszy sposób wykonania upgrade’u Active Directory? Oczywiście jest, ale o tym za chwilę Przypomnijmy sobie po krótce jak teoretycznie wygląda proces upgrade’u Active Directory jeśli chcemy podnieść poziom funkcjonalności domeny powiedzmy z 2008 R2 do 2012 R2: 1. Rozszerzenie schematu Active Directory 2. Przygotowanie domen Active Directory 3. Upgrade’y/zastąpienie kontrolerów domen nowszymi systemami operacyjnymi 4. Podniesienie poziomów funkcjonalności domen 5. Podniesienie poziomów funkcjonalności lasów. * Zakładamy, że mamy cale AD pod kontrolą Windows Server 2008R2 i przechodzimy na Windows Server 2012 R2   OK – wyodrębniliśmy kilka zasadniczych kroków – zastanówmy się teraz, która faza jest krytyczna i niesie ze sobą nieodwracalne (albo trudne do odwrócenia) skutki? Zasadniczo najbardziej krytyczne są punktu 1-2. Dlaczego? Ano dlatego, że rozpropagowanego w Active Directory schematu nie da się (w prosty sposób) przywrócić… Procedura przywrócenia sprowadza zasadniczo do odtworzenia […]

© Marcin Krzanowicz