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

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.

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.

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

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.

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.