Wednesday, March 4th, 2009...12:59 am

Zmieniał będziesz hasło swoje …

Jump to Comments

Polityki haseł różne zawsze były swojego rodzaju utrapieniem, przynajmniej dla tych którzy te hasła muszą zmieniać. W szczególności dla administratorów utrapieniem potrafiły być regularne procedury zmiany haseł:

  • lokalnych administratorów
  • usług
  • i co tam jeszcze wymyślicie


(cc) F8th

W przypadku kontrolerów domeny dochodziło jeszcze zawsze hasło Directory Services Restoration Mode (DSRM). Hasło to przechowywane jest lokalnie na każdym z kontrolerów domeny w czymś na kształt lokalnego SAM. Problem jaki to powoduje to fakt, że hasło to musi być zmieniane lokalnie na kontrolerze domeny i jak dotąd nie było żadnego wygodnego mechanizmu wykonywania tej operacji.

Dostępne opcje do wykonania tej operacji to:

  • użycie setpwd.exe z Windows 2000, które świetnie się sprawdzał przy zmianie hasła DSRM. Dean Wells napisał nawet skrypt, który używa setpwd.exe do zmiany hasła DSRM na wszystkich kontrolerach domeny.
  • ntdsutil.exe, który w tym zastosowaniu jest nieszczególnie wygodny w użyciu.

Cóż … problem dostrzeżono i niedawno pojawił się artykuł KB 961320 o wszystko tłumaczącym tytule “A feature is available for Windows Server 2008 that lets you synchronize the DSRM Administrator password with a domain user account”. Świetnie … pierwsze co przyszło mi do głowy to:

  • Tworzymy odpowiednie konto
  • Tworzymy odpowiedni obiekt definujący oddzielną politykę haseł, którą przypisujemy do tego konta
  • Ustalamy procedurę zmiany hasła tego jednego konta co określony czas.

I wszyscy są szczęśliwi (w szczególności departamenty bezpieczeństwa :)) .Brzmi lepiej niż dobrze … problem rozwiązany. Koledzy którzy jednak przeczytali ten artykuł szybciej niż ja zwrócili mi uwagę na zapis:

This command synchronizes the DSRM Administrator password one time. If you want to perform another synchronization, you must run this command again.

Więc jest lepiej, ale nie tak różowo jak by mogło być (dlaczego różowy akurat jest symbolem dobrej sytuacji???). Jeżeli chcemy skorzystać z tej opcji widziałbym to jako kroki które opisałem powyżej uzupełnione o:

  • Na wszystkich kontrolerach domeny tworzymy zaplanowane zadanie, które wykonuje polecenie ntdsutil w określonych okresach czasu.

Jest lepiej, nie musimy skryptować poleceń z podaniem hasła wprost, możemy na hasło nałożyć odpowiednią politykę ale jednak … nadal musimy polegać na zaplanowanych zadaniach.
Wygląda to tak jakby pracę nad tym rozwiązaniem utknęły w połowie drogi … miejmy więc nadzieję, że za jakiś czas posuną się dalej i dostaniemy w pełni zarządzalne rozwiązanie, gdzie zmian hasła na wskazanym koncie wymusi synchronizacje tego hasła do konta DSRM.
Ale tak czy inaczej warto o tym pamiętać, ponieważ rozwiązanie to znacznie ułatwia implementacje sensownej polityki w zakresie zarządzania hasłem DSRM. W szczególności w sieciach gdzie mamy więcej niż dwa kontrolery domeny :).

Leave a Reply