Microsoft Active Directory już macie postawione, albo to pierwsza instalacja, albo już posiadacie wygrzane środowisko. Zobaczmy jednak co można zmienić w świeżo utworzonej domenie, aby zapewnić jej większe bezpieczeństwo. Pominę etap promowania kontrolera domeny, ponieważ jest mnóstwo poradników w internecie, jak to zrobić. No chyba, że jesteście zainteresowani – dajcie znać w komentarzach. Do tej analizy użyjemy oprogramowania PingCastle.
Dla naszych celów użyję świeżo skonfigurowanego środowiska, ale takie same kroki możecie wykonać również na już istniejącej infrastrukturze, aby wyrobić sobie pewne nawyki i zestaw dobrych praktyk administracyjnych.
Wydawałoby się, że nowe środowisko Active Directory będzie już w pełni przygotowane na przyjęcie pierwszych użytkowników – teoretycznie tak. Jednak jak zaraz zobaczycie można wykonać pewne kroki, które pozwolą na zachowanie większego bezpieczeństwa AD. Dla naszego pokazowego środowiska raport prezentuje się następująco:
Szczególnie rzuca się w oczy sekcja kont uprzywilejowanych (Privileged Accounts), punktacja jest najwyższa w całym raporcie i od niej byśmy zaczęli listę punktów „do zrobienia”:
Już od dłuższego czasu jest mocna rekomendacja, aby wrażliwe konta w wysokimi uprawnieniami miały zaznaczoną opcję uniemożliwiającą wydanie ticketu delegowanego kontu z tym ustawieniem, np. konto usługi może zażądać wydania ticketu delegowanego dla konta administratora domeny. Co za tym idzie usługa zyskała by podniesione uprawnienia administratora. Dlatego, aby uniknąć takich sytuacji warto oznaczać wszystkie konta uprzywilejowane – z podwyższonymi uprawnieniami właśnie tym atrybutem – Konto jest poufne i nie może zostać delegowane.
Chyba jeden z najprostszych punktów do odhaczenia. Dobre praktyki mówią, aby w grupie Schema Admins nie było kont administratorów. Powinny być one dodawane tylko na czas zmian schematu Active Directory, po czym konto które modyfikowało schemat warto usunąć. A samą grupę monitorować jakie konta są do niej dodawane czy usuwane.
Domyślnie kosz w Active Directory jest wyłączony. Nie wpływa on co prawda bezpośrednio na bezpieczeństwo środowiska AD, ale chroni domenę przed przypadkowym lub celowym usunięciem elementów. Domyślnie usunięte obiekty są przetrzymywane przez 180 dni, w tym czasie można odzyskać obiekt wraz ze wszystkimi atrybutami, po upływie tego czasu (Tombstone) obiekt można jeszcze odzyskać przez kolejne 180 dni, ale tylko i wyłącznie z podstawowymi informacjami.
Włączyć go można za pośrednictwem Powershella:
Enable-ADOptionalFeature -identity 'CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=krbtgt,DC=pl' -Scope ForestOrConfigurationSet -Target 'krbtgt.pl'
Anomalie – kolejna sekcja, do której warto zajrzeć
LAPS (Local Administrator Password Solution) – to jest temat na osobny wpis. W skrócie dodatek, który automatycznie zmienia hasła administratorów lokalnych na komputerach podłączonych do domeny. Hasła są przechowywane w Active Directory (tak, zwykłym tekstem), ale dostęp do nich jest z użyciem dodatkowych ACL, więc uprawnienia do tych haseł można wydzielić. Instalacja wymaga rozszerzenia schematu AD, ustawienia odpowiednich ACL i instalacji agenta na komputerach w domenie. Zarządzanie złożonością haseł i częstotliwością ich zmiany odbywa się przez polityki GPO.
Konfiguracja polityki zbierania logów audytowych z kontrolerów domeny. Bardzo przydatne do wykrywania anomalii w środowisku, począwszy od poprawnych i błędnych logowań użytkowników, przez zmiany w grupach zabezpieczeń, po błędy podczas wystawiania ticketów Kerberosowych.
Więcej na temat optymalnego ustawienia logów audytowych możecie znaleźć w tym artykule.
Polityka haseł – warto o nią dbać i dostosowywać do aktualnych standardów bezpieczeństwa. Domyślnie polityka haseł ustawiona jest bardzo liberalnie, a w czasach gdy moc obliczeniowa kart graficznych jest ogromna złamanie hasła metodą Brute Force jest relatywnie szybkie – to kwestia minut, ewentualnie godzin, w zależności od złożoności.
Ścieżka w GPO, gdzie znajdziecie ustawienia dotyczące polityki haseł: Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Account Policies -> Password Policy
Będąc jeszcze w temacie polityki haseł, warto rozważyć wprowadzenie osobnej, bardziej restrykcyjnej polityki dla kont uprzywilejowanych – bazując na fine-grained password policies.
Ustalając polityki haseł dla poszczególnych rodzajów kont nie możecie zapomnieć o Managed Serviced Accounts – tzw. konta techniczne, serwisowe z „automatyczną” zmianą hasła.
Podsumowując, czy to podczas uruchomienia Active Directory, czy podczas administracji już istniejącym środowiskiem warto je audytować regularnie, aby wiedzieć co w trawie piszczy 🙂
Więcej w kolejnych częściach 🙂
