W poprzednim artykule wyjaśniłem główne powody, dla których Microsoft zdecydował się na powrót do technologii RODC w systemie Windows Server 2008. W tym artykule kontynuujemy serię i przejdziemy do praktycznych aspektów pracy z kontrolerami domeny tylko do odczytu.
Poświadczenia użytkownika
W poprzednim artykule powiedziałem, że wszystkie informacje o wszystkich użytkownikach domeny nie są przesyłane do kontrolerów domeny RODC. W rzeczywistości informacje o kontach użytkowników są nadal przechowywane na RODC; hasła użytkownika po prostu nie są replikowane na takim kontrolerze domeny. A jeśli ktoś ukradnie kontroler domeny z oddziału, nie będzie mógł użyć informacji z bazy danych Active Directory, aby uzyskać hasła użytkownika.
Atrybuty użytkownika
Domyślnie hasła są jedynym atrybutem użytkownika, który nie jest replikowany do kontrolera domeny tylko do odczytu. Możliwe jest jednak ręczne skonfigurowanie systemu Windows, aby zapobiec replikacji innych atrybutów użytkownika..
Więc w jakich przypadkach można użyć tej funkcji? Jeśli używasz Active Directory tylko jako mechanizmu uwierzytelniania, najprawdopodobniej nie będziesz go potrzebował. Należy jednak pamiętać, że istnieją organizacje, które w dużym stopniu polegają na bazie danych Active Directory, która służy nie tylko do uwierzytelniania..
Dość często w dużych organizacjach korzystających z różnych aplikacji i baz danych użytkowników, aby zmniejszyć liczbę błędów i zduplikować informacje o użytkownikach, wolą korzystać z jednego miejsca do przechowywania wszystkich informacji o pracownikach (telefony, adresy, kontakty itp.) Oraz świetne miejsce do tego jest Active Directory.
Na przykład znam jedną organizację, która opracowała aplikację do zarządzania personelem, której używają na swoim terenie. Chociaż większość danych jest przechowywana w bazie danych SQL, rzeczy takie jak nazwiska pracowników, stanowiska, numery telefonów itp. przechowywane w Active Directory jako atrybuty konta. A w bazie danych SQL Server przechowywane są dane, takie jak numery TIN, informacje o wynagrodzeniach, a ta baza danych nie zawiera nazwisk pracowników. Jedyną rzeczą, która łączy bazy danych AD i SQL, jest numer pracownika obecny w obu bazach danych.
Podałem ten przykład, aby wyjaśnić, że w wielu organizacjach poufne informacje mogą być zawarte w atrybutach użytkownika AD. A jeśli takie informacje nie są wymagane w oddziale, możesz zablokować ich replikację na kontrolerze domeny oddziału.
Inną cechą technologii kontrolera domeny tylko do odczytu jest to, że taki kontroler można również skonfigurować jako serwer DNS tylko do odczytu. Zasadniczo oznacza to, że jeśli atakujący uzyska dostęp do serwera kontrolera domeny tylko do odczytu, nie będzie w stanie sparaliżować korporacyjnego DNS.
Kwestie administracyjne
Jestem pewien, że do tej pory masz wiele pytań na temat administracji rodc. Spróbuję natychmiast odpowiedzieć na niektóre z nich.
W jaki sposób użytkownicy są uwierzytelniani, jeśli kontroler domeny nie ma informacji o swoich hasłach??
Jest tutaj sztuczka. Jak wiadomo, hasło jest powiązane zarówno z kontem użytkownika, jak i kontem komputera. Domyślnie kontroler domeny tylko do odczytu przechowuje tylko własne hasło (hasło do konta komputera) i hasło do specjalnego konta o nazwie „krbtgt”, które jest używane przez protokół Kerberos.
Ponieważ hasła nie są przechowywane lokalnie; wszystkie żądania uwierzytelnienia są przekierowywane do zwykłego kontrolera domeny, którego nagrywanie jest dozwolone. Jeśli chcesz, aby użytkownicy mogli logować się do systemu, nawet jeśli nie jest dostępny żaden zwykły kontroler, musisz włączyć funkcję buforowania hasła. Gdy buforowanie jest włączone, pamięć podręczna przechowuje hasła tylko do tych kont, które zostały uwierzytelnione na kontrolerze domeny. I nawet jeśli twój kontroler domeny jest zagrożony, ty z innego kontrolera możesz zawsze zidentyfikować te konta, których hasła zostały zapisane w pamięci podręcznej na Rodc.
Praca administracyjna z rodc
W wielu oddziałach kontroler domeny jest często wykorzystywany również jako serwer aplikacji. A jeśli w takim biurze nie ma osobnego specjalisty IT, możesz wyznaczyć kogoś z biura na administratora kontrolera rodc bez nadawania mu uprawnień administratora do całej domeny (możesz przeczytać post o delegowaniu uprawnień do zarządzania kontrolerowi domeny rodc). W ten sposób będzie miał prawa tylko do lokalnej administracji takiego serwera i nie będzie mógł niczego zmieniać ani psować w Active Directory. W rezultacie taki użytkownik będzie miał prawo instalować aktualizacje oprogramowania i wykonywać inne codzienne zadania związane z administrowaniem i utrzymywaniem serwera. Przypisywanie kogoś jako administratora kontrolera domeny tylko do odczytu jest podobne do procedury wyznaczania konkretnego użytkownika lub grupy jako administratora lokalnego dla członka lub serwera autonomicznego.
Linki do wszystkich artykułów z tej serii:
Praca z kontrolerami domeny tylko do odczytu (RODC) (część 1)
Praca z kontrolerem domeny tylko do odczytu (część 2)
Praca z kontrolerem domeny tylko do odczytu (część 3)
