CPasswords i zmiana haseł w GPO

27 stycznia 2015 at 07:07

Od czasu wprowadzenia GPP (Group Policy Preferences) automatyczna zmiana haseł kont lokalnych stała się prosta łatwa i przyjemna. Niestety przyszedł dzień 13.05.2014 i znaleziona (znana już wcześniej) „luka” bezpieczeństwa spowodowała, że Microsoft całkowicie wycofał się z możliwości zmiany haseł dla kont lokalnych z wykorzystaniem GPP… Co więcej nie dotyczyło to tylko nowych systemów operacyjnych, lecz wraz z zainstalowaniem którejś z kolejnych poprawek – wycięło tą możliwość również z już działających starszych systemów.

O co tak naprawdę zrobiono tyle szumu? – Burza w szklance wody :)
Przeanalizujmy z czego wynika zamieszanie:

1. Zarówno GPO jako i GPP są utrzymywane na zasobie SYSVOL w postaci plików konfiguracyjnych XML oraz towarzyszących im metadanych.

2. Aby móc pobrać i przetworzyć GPO lub GPP należy mieć do nich uprawnienia – uprawnienia z GPO są przenoszone na SYSVOL

3. Atrybut CPassword jest szyfrowany 32-bitowym AES’em i w takiej postaci jest zapisywany do pliku XML

 

Zatem zamiast zmienić szyfrowanie na bezpieczniejsze – Microsoft wyciął możliwość zarządzania hasłami lokalnymi w jakże prosty i intuicyjny sposób… Swoją drogą wystarczyło być świadomym administratorem i do GPO obsługującego hasła lokalne przyciąć uprawnienia jedynie dla stacji domenowych (odebrać uprawnienia odczytu i przetworzenia zasad użytkownikom) – dzięki czemu użytkownik w swoim imieniu nie będzie w stanie odczytać hasła na SYSVOLu :) Oczywiście mając uprawnienia lokalnego administratora da się działać w kontekście systemu operacyjnego i w ten sposób próbować odczytać hasło, ale z drugiej strony mając lokalnego admina można odczytać inne hasła wprost z lokalnej bazy SAM i nie jest to „Rocket Science”. Więc bezpieczeństwo bezpieczeństwem, ale zdrowy rozsądek przede wszystkim…

Teraz zasadnicze pytanie – ja obsługiwać globalną zmianę hasła lokalnego administratora w lesie Active Directory? Instalować jakieś darmowe programiki ściągane z Internetu robiące na dobrą sprawę nie wiadomo co? (Jeśli ktoś uważa to za bezpieczniejsze… ) Wykonywać „Invoke” zmiany hasła licząc na to że akurat wszystkie stacje są wpięte do sieci? Czy zwyczajnie wykorzystać do tego GPO tak jak przedtem? :)

Jeśli zdecydujesz się na ostatnie rozwiązanie to wcale nie musisz wycinać aktualizacji i przywracać systemu do stanu wcześniejszego wystarczy przygotować sobie pliczek CSV, w którym znajdą się nazwy kont lokalnych oraz ich hasła. Struktura pliku CSV, który nazywać się będzie „Local_accounts.csv”

Login;Password
Administrator;P@sswordLocalZAQ!2wsx

Następnie tenże plik umieszczamy na SYSVOLU w dedykowanym folderze powiedzmy pod nazwą „LocalAccounts” i zapisujemy tam również plik skryptu Powershella, który zawierać będzie „jedną” linijkę:

Tak, wiem – to wcale nie jest jedna „rurka”, więc de facto to nie jedna linijka, ale chodziło o ukazanie łatwości przywrócenia możliwości zarządzania hasłami lokalnymi przez GPO. Co robi ww. skrypt?

1. Importuje plik CSV z loginami i hasłami z SYSVOL’a

2. Dla każdego wpisu – jeśli istnieje konto o takim loginie – zmienia mu hasło na zgodne z plikiem CSV.

3. Jeśli nie istnieje konto lokalne o podanym loginie – Tworzy je nadając mu hasło z zaczytanego pliku CSV.

 

Co jeszcze trzeba zrobić żeby zaczęło działać w ramach GPO?

1. Zmienić uprawnienia do pliku CSV tak aby:

  • Konta komputerów (Domain Computers) miały uprawnienia odczytu oraz odczytu i wykonania
  • System (kontrolery domeny) miały pełne uprawnienia do pliku
  • Administratorzy przedsiębiorstwa, domeny mieli uprawnienia odczytu, zapisu i modyfikacji – żeby mogli okresowo zmieniać hasła lokalnych kont.

2. Utworzyć GPO, przypiąć je do jednostki organizacyjnej, w której są stacje robocze. Ograniczyć zakres stosowania GPO jedynie do stacji komputerów a następnie przypisać ww. skrypt jako skrypt uruchamiany podczas startu systemu operacyjnego:

Computer Configuration -> Policies -> Windows Settings -> Scripts -> Startup

* Jeśli nie ma możliwości uruchamiania skryptów bez podpisu cyfrowego – należy skrypt najpierw podpisać z użyciem certyfikatu wystawionego przez wewnętrzne CA lub certyfikatu zewnętrznego
* Jeśli w domenie są stacje starsze niż Windows 7, to należy skrypt Powershella uruchomić wcześniej z cmd lub vbs’a.