Gdzie przechowywać poufne dane w usłudze Active Directory?

11

Zasadniczo przechowuję klucz prywatny (Hash) w dowolnym atrybucie OctetString w Active Directory.

Moje pytanie brzmi: jaki atrybut jest domyślnie bezpieczny i czy warto przechowywać tam prywatne dane? Wartość tę należy traktować podobnie do hasła, do którego nawet administratorzy nie powinni mieć dostępu (jeśli to możliwe), podobnie jak bieżące hasło AD.

Oto początek listy atrybutów, które są domyślnie włączone w domenie Windows 2008R2 + Exchange 2010.

alternatywny tekst

Aktualizacja:

Czy ktoś wie o atrybucie „Octet String”, który domyślnie nie udostępnia uprawnień „do odczytu” wszystkim użytkownikom w domenie? Nie chcę publicznie przechowywać mojego skrótu i ​​pozwolić komuś zbudować tęczowy stół na podstawie skrótów.

goodguys_activate
źródło

Odpowiedzi:

11

Problem, z którym zmaga się większość ludzi podczas przechowywania danych w AD

  • Rozszerzanie schematu (co często ma konsekwencje polityczne dla firmy)

  • Korzystanie z istniejącego atrybutu i edycja uprawnień (co powoduje wzdęcie AD / ACL, które zwiększa DIT i rozmiar replikacji)

Istnieje alternatywa ... najlepszym moim zdaniem jest użycie tej mniej znanej funkcji AD, aby wziąć istniejący atrybut i oznaczyć go jako Poufny.

Oto szczegóły dotyczące procesu


Domyślne uprawnienia w Active Directory są takie, że uwierzytelnieni użytkownicy mają ogólny dostęp do odczytu wszystkich atrybutów. Utrudnia to wprowadzenie nowego atrybutu, który powinien być chroniony przed odczytaniem przez wszystkich.

Aby temu zaradzić, dodatek SP1 dla systemu Windows 2003 wprowadza sposób oznaczenia atrybutu jako POUFNY. Ta funkcja została osiągnięta przez modyfikację wartości searchFlags dla atrybutu w schemacie. SearchFlags zawiera wiele bitów reprezentujących różne właściwości atrybutu. Np. Bit 1 oznacza, że ​​atrybut jest indeksowany. Nowy bit 128 (7. bit) określa atrybut jako poufny.

Uwaga: nie można ustawić tej flagi na atrybutach schematu podstawowego (pochodzących od „góry”, takich jak nazwa pospolita). Możesz ustalić, czy obiekt jest podstawowym obiektem schematu, używając LDP do wyświetlenia obiektu i sprawdzając atrybut systemFlags obiektu. Jeśli ustawiony jest 10. bit, jest to obiekt schematu podstawowego.

Gdy usługa katalogowa przeprowadza kontrolę dostępu do odczytu, sprawdza poufne atrybuty. Jeśli tak, to oprócz dostępu do READ_PROPERTY, usługa katalogowa będzie również wymagać dostępu CONTROL_ACCESS do atrybutu lub jego zestawu właściwości.

Domyślnie tylko administratorzy mają dostęp do wszystkich obiektów CONTROL_ACCESS. Dlatego tylko administratorzy będą mogli odczytać poufne atrybuty. Użytkownicy mogą przekazać to prawo dowolnej grupie, której chcą. Można to zrobić za pomocą narzędzia DSACL, skryptów lub wersji LDP R2 ADAM. W chwili pisania tego tekstu nie można używać edytora ACL UI do przypisywania tych uprawnień.

Proces oznaczania atrybutu Poufne i dodawania użytkowników, którzy muszą wyświetlić atrybut, składa się z 3 kroków

  1. Określanie, który atrybut oznaczyć jako poufny lub dodanie atrybutu, aby oznaczyć jako poufny.

  2. Oznaczanie jako poufne

  3. Przyznanie właściwym użytkownikom uprawnienia Control_Access, aby mogli wyświetlić atrybut.

Aby uzyskać więcej informacji i instrukcje krok po kroku, zapoznaj się z następującym artykułem:

922836 Jak oznaczyć atrybut jako poufny w systemie Windows Server 2003 z dodatkiem Service Pack 1

http://support.microsoft.com/default.aspx?scid=kb;EN-US;922836

goodguys_activate
źródło
1
Downvoter: Dlaczego otrzymało -1?
goodguys_activate
Słyszałem, że poufny bit może nałożyć znaczną karę wydajności. Czy znasz jakieś dokumenty, które to potwierdzają lub obalają?
Nic.
@Nic post, że jako pytanie ... najpierw o nim usłyszałem
goodguys_activate
2

W tym celu zawsze możesz rozszerzyć usługę Active Directory o nowe pole.

Oto dokument zawierający instrukcje dotyczące dodawania nowego atrybutu i ograniczania uprawnień do atrybutu.

Zoredache
źródło
Dziękuję Ci. Moim celem jest użycie istniejącego atrybutu, jeśli to możliwe, ponieważ moi klienci są bardziej paranoiczni, jeśli chodzi o to ... mają zbyt dużo FUD w tym podejściu ... Mam nadzieję na coś natywnego, jeśli to możliwe.
goodguys_activate
Rozumiem ich niechęć, ale nie sądzę, że istnieją jakieś dobre atrybuty kandydata, które nie są używane i zabezpieczane zgodnie z wymaganiami.
Zoredache,
1

Wartość tę należy traktować podobnie do hasła, do którego nawet administratorzy nie powinni mieć dostępu (jeśli to możliwe), podobnie jak bieżące hasło AD.

To nie jest poprawne, nawet nie jest złe. Hasło nie jest przechowywane. Hash jest przechowywany, a administratorzy domeny mogą uzyskać do niego dostęp. W rzeczywistości możesz nawet skonfigurować AD do przechowywania hasła w odwracalnym szyfrowaniu, jeśli chcesz.

W AD nie ma nic, z czego można by powstrzymać administratorów domeny. Jeśli usuniesz prawa, a nawet odmówisz, administrator domeny może przejąć własność i dodać się z powrotem. Jest to w przeciwieństwie do NDS firmy Novell, gdzie administrator jednostki organizacyjnej może nieodwołalnie zablokować administratorów wyższego poziomu.

Najlepsze, co możesz zrobić, to użyć istniejącego lub nowego atrybutu i ograniczyć dostęp. Możesz uniemożliwić administratorom dostęp do niego, a także włączyć inspekcję tego atrybutu, aby każda zmiana dostępu lub uprawnień była rejestrowana.

mfinni
źródło
Przechowuję jednokierunkowy skrót hasła specyficznego dla mojej aplikacji.
goodguys_activate
Należy to do komentarza, ponieważ w żaden sposób nie odpowiada na pytanie.
MDMarra,
Mark - moje ostatnie dwa zdania są odpowiedzią na pytanie „Gdzie przechowywać poufne dane w usłudze Active Directory?”
mfinni
@Maker - To ma sens i jest to bardzo podobny scenariusz do linku, który @Zoredache opublikował powyżej. To jest natywna odpowiedź: użyj istniejącego lub nowego atrybutu i ogranicz dostęp. Moją dodatkową sugestią, jeśli klient koncentruje się na bezpieczeństwie, jest włączenie kontroli tego atrybutu.
mfinni
@Maker - jeśli to naprawdę skrót jednokierunkowy, to i tak jest już dość bezpieczny, prawda?
mfinni