Na moim angielskojęzycznym blogu popełniłem już dłuższy czas temu wpis o tym jak korzystać z atrybutów poufnych dostępnych w Windows 2003. Niestety nigdy nie udało mi się znaleźć czasu na przetłumaczenie go na polski – jeżeli jest zainteresowanie takową zlokalizowaną wersją to prosżę o komentarz.
Patrząc na statystyki jest to jeden z bardziej popularnych artykułów w ramach tego bloga (2950 odsłon). Najbardziej popularne są wpisy o rozszerzeniu schematu (5532 odsłon) i o atrybucie drink w AD (4118 odsłon).
Wychodzi na to, że czytelnicy mojego bloga najpierw rozszerzają schemat, potem coś piją i będąc pod wpływem próbują coś ukryć w AD. Całkiem ciekawe 
.
Patrząc na popularność tego tematu postanowiłem trochę go uzupełnić w odniesieniu do Windows 2008. Sposób dokonywania zmian w schemacie się nie zmienił, atrybut drink nadal tam jest – padło dlatego właśnie na atrybuty poufne.
W tej dzidzinie w Windows 2008 też się nic nie zmieniło, nadal możemy z tych atrybutów korzystać. Pojawiły się jednak dwa elementy, które mogą wpływać na sposób ich użycia:
- kontrolery domeny tylko do odczytu (RODC)
- inspekcja wartości zmienianych atrybutów.
Kontrolery domeny w trybie do odczytu (RODC)
RODC to kontroler, który przechowuje kopię bazy danych w trybie tylko do odczytu. Przeważnie powodem do wdrożenia tego typu kontrolera jest konieczność umieszczenia tego typu serwera w lokalizacji, którą nie jest *zaufana*. Może to oznaczać placówkę bez odpowiednich zabezpieczeń lub w strefie DMZ. Z tego powodu możemy również nie chcieć replikować do tych kontrolerów naszych poufnych danych.
Windows 2008 dostarcza możliwości ograniczenia listy atrybutów poprzez dodanie atrybuty do zestawu Filtered Attribute Set (FAS). FAS to zestaw atrybutów, które nie są replikowane do RODC i usuwane są na przykład z danych IFM używanych do promocji RODC. Przynależność atrybutu do FAS kontrolowana jest przez jeden z bitów atrybutu searchFlags w deifnicji atrybutu w schemacie. Używając przykład z mojego postu dotyczącego konfiugracji atrybutów poufnych i atrybuty lbUserPesel. Atrybut ten oznaczony jest jako poufny poprzez wartość hex 0×40 lub decymalnie 64 w ramach wartości searchFlags.
adfind -b CN=lb-UserPesel,CN=Schema,CN=Configuration,DC=w2k,DC=pl
-s base -flagdc searchFlagsAdFind V01.37.00cpp Joe Richards (joe@joeware.net) June 2007
Using server: LHFDC1.w2k.pl:389
Directory: Windows Longhorndn:CN=lb-UserPesel,CN=Schema,CN=Configuration,DC=w2k,DC=pl
>searchFlags: 128 [CONFIDENTIAL(128)]
Dodanie atrybutu do FAS możliwe jest poprzez ustawienie odpowiedniego bitu reprezenotwanego przez wartośc hex 0×200 lub decymalnie 512. Aby utworzyć atrybut poufny, który będzie należał również do FAS należy ustawić oba bity, a więc wartość hex 0×280 lub decymalnie 640:
adfind -b CN=lb-UserPesel,CN=Schema,CN=Configuration,DC=w2k,DC=pl
-s base -flagdc searchFlagsAdFind V01.37.00cpp Joe Richards (joe@joeware.net) June 2007
Using server: LHFDC1.w2k.pl:389
Directory: Windows Longhorndn:CN=lb-UserPesel,CN=Schema,CN=Configuration,DC=w2k,DC=pl
>searchFlags: 640 [CONFIDENTIAL(128);EXCL_RODC_PAS(512)]
(W opisie bit odpowiedzialny za FAS wskazany jest jako PAS. Ta nazwa została zmieniona w trakcie rozwoju produktu).
Po wykonaniu takiej zmiany atrybut nie będzie replikowany do RODC a jeżeli już był tam obecny to zostanie usunięty z lokalnej bazy danych AD na RODC.
Tutaj jedna uwaga, przekazana podczas sesji Jorge na ostatnim DEC, a z którą ja się jak najbardziej zgadzam. Przed wdrożeniem RODC warto pomyśleć, które atrybuty chcemy włączyć do FAS i wprowadzić te zmiany przed promocją pierwszego RODC. W ten sposób unikamy ich replikacji do RODC.
Inspekcja wartości zmienianych atrybutów
Windows 2008 wprowadza nowy mechanizm inspekcji zmian w katalogu umożliwiając zapis w ramach danych inspekcji wartości zmienianych atrybutów. Dla każdej operacji zmiany atrybutu poddanego inspecji w dzienniku zdarzeń zostaną zapisane dwa zdarzenia, odpowiednio ze starą i nową wartością atrybutu, powiązane ze sobą wartością core correlation ID.
Jakkolwiek użyteczna, ta funkcjonalność może doprowadzić do tego, że wartość naszego poufnego atrybutu zostanie zapisana w dzienniku zdarzeń, przez to potencjalnie ujawniona niepożądanej osobie. Zobaczmy więc co zostanie zalogowane w dzinniku przy zmianie wartości atrybutu z użyciem ADMOD.EXE:
admod -b “CN=Joe Doe,OU=SensitiveDataUsers,DC=w2k,DC=pl” lbUserPesel::123456789
W dzienniku zabezpieczeń (Security log) znajdziemy trzy zdarzenia:
W zdarzeniach o EventID 5136 znajdziemy szczegółowe informacje na temat dokonanych zmian (usunałem nadmiarowe infomracje w celu poprawienia czytelności danych):
(…)
Object:
DN: CN=Joe Doe,OU=SensitiveDataUsers,DC=w2k,DC=pl
GUID: CN=Joe Doe,OU=SensitiveDataUsers,DC=w2k,DC=pl
Class: user
Attribute:
LDAP Display Name: lbUserPesel
Syntax (OID): 2.5.5.4
Value: 123456789
Operation:
Type: Value Deleted
Correlation ID: {baa43f87-336d-4d83-a4fb-5aa397bc23b9}
(…)
==========================================================
Object:
DN: CN=Joe Doe,OU=SensitiveDataUsers,DC=w2k,DC=pl
GUID: CN=Joe Doe,OU=SensitiveDataUsers,DC=w2k,DC=pl
Class: user
Attribute:
LDAP Display Name: lbUserPesel
Syntax (OID): 2.5.5.4
Value: 1234567890
Operation:
Type: Value Added
Correlation ID: {baa43f87-336d-4d83-a4fb-5aa397bc23b9}
(…)
Jak widać poprzednia i nowa wartość atrybutu oznaczonego jako poufny została zapisana w danych dziennika zdarzeń. W ten sposób zostaje ona udostępniona tym, którzy posiadają dostęp do dziennika zdarzeń lub systemu gromadzącego dane z tegoż dziennika.
Windows 2008 pozwala jednak na ograniczenie logowania danych o zmiwanach wartości atrybutów poprzez odpowiednią modyfikację atrybutu searchFlags. Tym razem należy w tym celu zmodyfikować odpowiedni bit poprzez nadanie wartości hex 0×100 lub decymalnie 256. Aby więc nasz poufny i będący w zestawie FAS atrybut dodatkowo ochronić przed logowaniem wartości należy ustawić wartość searchFlags na hex 0×380 lub decymalnie 896:
adfind -b CN=lb-UserPesel,CN=Schema,CN=Configuration,DC=w2k,DC=pl -s base -flagdc searchFlags
AdFind V01.37.00cpp Joe Richards (joe@joeware.net) June 2007
Using server: LHFDC1.w2k.pl:389
Directory: Windows Longhorn
dn:CN=lb-UserPesel,CN=Schema,CN=Configuration,DC=w2k,DC=pl
>searchFlags: 896 [CONFIDENTIAL(128);EXCL_RODC_PAS(512);UNKNOWN_FLAGS(256)]
Jeżeli teraz wykonamy zmiane do naszego atrybutu, zobaczymy, że w dzienniku zdarzeń zostanie zalogowane tylko jedno zdarzenie o Event ID 4662, a brakuje zdarzeń o Event ID 5136:
Nasz atrybut jest teraz chroniony przed niepowołanym dostępem, replikacją do RODC i zapisem wartości w dzienniku zdarzeń.
W zasadzie to tyle w temacie … mam nadzieję, że informacje są chociaż trochę użyteczne.
Przy okazji … czy ktoś z Was korzysta z atrybutów poufnych (innych niż domyślnie wprowadzane jako takie do schematu przez chociażby Microsoft)?