Thursday, November 19th, 2009...12:50 am
userPassword
Jump to Comments
Cisza, cisza, cisza … przerywana przygotowaniami na przykład do sesji na Windows Community Launch do której wygłoszenia w dniu wczorajszym zaprosili mnie organizatorzy (materiały będą na stronie WCL). Aż tutaj znalazł sie temat …
Jeden ze znajomych inżynierów (pozdrowienia) podrzucił mi wczoraj szybkie pytanie związane z atrybutem userPassword. Jako że problem który pytanie wywołał, samo pytanie jak i atrybut jest ciekawy to pomyślałem że i na bloga się nada … więc zaczynajmy od opisu samego atrybutu.
Zachowanie, które zaobserwował nasz inżynier w ramach swoich prac związanych z czymś innym to fakt, że atrybut ten po wykonaniu pewnych operacji w katalogu przechowywał hasło ustawione dla użytkownika w postaci czystego tekstu … tak, tak, o mój boże, o matko, łolaboga i tak dalej … czysty tekst i hasło zawsze wywołuje takie skojarzenia.
Oczywiście nie oznacza to że hasło to było dla wszystkich dostępne, w końcu dalej obowiązują w katalogu uprawnienia, które ograniczają dostęp użytkowników do poszczególnych atrybutów. Ale fakt pozostawał faktem … ONO tam było.
Matched DNs:
Getting 1 entries:
>> Dn: CN=jan Kowalski,OU=DRLab,DC=w2k,DC=pl
4> objectClass: top; person; organizationalPerson; user;
1> cn: jan Kowalski;
1> sn: Kowalski;
1> userPassword: P@ssw0rd!;
Wbrew pozorom zachowanie takie jest jak najbardziej oczekiwane i nie ma co zgłaszać błędu na connect :). A wszystko to przez pewną dualność zachowania atrybutu userPassword.
userPassword …
userPassword to atrybut o tyle ciekawy, że zachowanie związane z jego obsługą zależy od konfiguracji oraz poziomu domeny. W zależności od tych ustawień atrybut ten może:
- być traktowany jako każdy inny atrybut tekstowy do którego można zapisać dowolną wartość
- umożliwiać zmianę hasła dla obiektów klasu user i inetOrgPerson z użyciem LDAP.
W tym pierwszym przypadku, gdy domena działa w trybie niższym niż Windows 2003 oraz odpowiednia flaga atrybutu dsHeuristics, który kontrluje zachowanie katalogu w tym aspekcie nie została ustawiona atrybut ten jest zwyczajnym atrybutem tekstowym, do którego można wpisać dowolną wartość. Spróbujmy …
admod -b "CN=jan Kowalski,OU=DRLab,DC=w2k,DC=pl" userPassword::P@ssword!!1
AdMod V01.10.00cpp Joe Richards (joe@joeware.net) February 2007
DN Count: 1
Using server: w2003r2base.w2k.pl:389
Directory: Windows Server 2003Modifying specified objects…
DN: CN=jan Kowalski,OU=DRLab,DC=w2k,DC=pl…The command completed successfully
A teraz odczyt:
adfind -b "CN=jan Kowalski,OU=DRLab,DC=w2k,DC=pl" -s base userPassword
AdFind V01.40.00cpp Joe Richards (joe@joeware.net) February 2009
Using server: w2003r2base.w2k.pl:389
Directory: Windows Server 2003dn:CN=jan Kowalski,OU=DRLab,DC=w2k,DC=pl
>userPassword: 5040 7373 776F 7264 2121 311 Objects returned
Jak widać mogliśmy zapisać i odczytać wartość tego atrybutu. Jak każdego innego … jednak nie oznacza to że zmieniliśmy hasło użytkownika. Po prostu zapisaliśmy wartość do atrybutu w katalogu.
Jeżeli jednak ustawimy 9-ty znak wartości atrybutu dsHeuristics na wartość 1 (w zasadzie każdą inną niż 0 lub 2) to zapisy do tego atrybutu nabierają innego znaczenia. Pisząc do tego atrybutu jakąś wartość wywołujemy operację resetu lub zmiany hasła dla użytkownika. W takim wypadku atrybut ten jest atrybutem “tylko do zapisu” i jego wartość nie może być odczytana. Zobaczmy ….
Najpierw modyfikacja dsHeuristics:
admod -b "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuratio
n,DC=w2k,DC=pl" dsHeuristics::000000001AdMod V01.10.00cpp Joe Richards (joe@joeware.net) February 2007
DN Count: 1
Using server: w2003r2base.w2k.pl:389
Directory: Windows Server 2003Modifying specified objects…
DN: CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=w2k,DC
=pl…The command completed successfully
A teraz próba zmiany wartości atrybutu jak poprzednio:
admod -b "CN=jan Kowalski,OU=DRLab,DC=w2k,DC=pl" userPassword::P@ssword!!1
AdMod V01.10.00cpp Joe Richards (joe@joeware.net) February 2007
DN Count: 1
Using server: w2003r2base.w2k.pl:389
Directory: Windows Server 2003Modifying specified objects…
DN: CN=jan Kowalski,OU=DRLab,DC=w2k,DC=pl…: [w2003r2base.w2k.pl] Error 0×35
(53) - Unwilling To Perform
Błąd …. dlaczego błąd??? Zmiana hasła poprzez ten atrybut w przypadku Active Directory możliwa jest tylko poprzez połączenie zabezpieczone SSL. To spróbujmy więc wykonać to samo używając połączenia LDAPS:
admod -b "CN=jan Kowalski,OU=DRLab,DC=w2k,DC=pl" userPassword::P@ssword!!1 -ssl -h w2003r2base.w2k.pl:636
AdMod V01.10.00cpp Joe Richards (joe@joeware.net) February 2007
DN Count: 1
Using server: w2003r2base.w2k.pl:636
Directory: Windows Server 2003Modifying specified objects…
DN: CN=jan Kowalski,OU=DRLab,DC=w2k,DC=pl…The command completed successfully
A teraz odczyt:
adfind -b "CN=jan Kowalski,OU=DRLab,DC=w2k,DC=pl" -s base userPassword
AdFind V01.40.00cpp Joe Richards (joe@joeware.net) February 2009
Using server: w2003r2base.w2k.pl:389
Directory: Windows Server 2003dn:CN=jan Kowalski,OU=DRLab,DC=w2k,DC=pl
1 Objects returned
Jak widać nie udało się to nam … atrybut ten nie nie może być odczytany, może jednak być użyty do wykonania operacji zmiany hasła z użyciem protokołu LDAP.
problem …
Problem o jakim rozmawiałem z naszym PFE to użycie KTPASS do wygenerowania pliku keytab dla konta, używanego przez usługę Unix (niezorientowanych odsyłam do materiałów z mojej sesji z MTS 2009). W przypadku, gdy KTPASS zostanie użyty w środowisku, w którym userPassword traktowane jest jako normalny atrybut, pozostanie on widoczny w atrybutach użytkownika. Najwyraźniej KTPASS próbuje wykonać zmianę hasła na obiekcie z użyciem LDAP:
ktpass -princ HOST/ubuntu.w2k.pl@W2K.PL -mapuser ubuntu$@W2K.PL -ptype KRB5_NT_SRV_HST -mapop set -pass P@ssw0rd1 -out ubuntu.keytab
(…)
Reset UBUNTU$’s password [y/n]? y
Key created.
Output keytab to ubuntu.keytab:
Keytab version: 0×502
keysize 60 HOST/ubuntu.w2k.pl@W2K.PL ptype 3 (KRB5_NT_SRV_HST) vno 2 etype 0×17
(RC4-HMAC) keylength 16 (0xae974876d974abd805a989ebead86846)
A teraz ADFIND:
adfind -b "CN=ubuntu,OU=DRLab,DC=w2k,DC=pl" -s base userPassword
AdFind V01.40.00cpp Joe Richards (joe@joeware.net) February 2009
Using server: w2003r2base.w2k.pl:389
Directory: Windows Server 2003dn:CN=ubuntu,OU=DRLab,DC=w2k,DC=pl
>userPassword: 5040 7373 7730 7264 31
Najwyraźniej KTPASS próbuje ustawić hasło użytkownika poprzez LDAP pisząc do atrybutu userPassword i dlatego możemy w odpowiednich warunkach je zobaczyć po wykonaniu tej operacji.
Oczywiście po ustawieniu flagi w ramach dsHeuristics również i operacje wykonane przez KTPASS (lub inne narzędzie korzystające z LDAP do zmiany hasła) nie pozwalają na odczyt hasła.
Zachowanie takie nie dotyczy tylko KTPASS ale każdego narzędzia lub skryptu, który spróbuje zmodyfikować ten atrybut używając LDAP.
rozwiązanie …
Jeżeli powyższe zachowanie katalogu nam przeszkadza najprostszym rozwiązaniem jest po prostu włączenie mechanizmu zmiany hasła przez LDAP poprzez modyfikację wartości atrybutu dsHeuristics jak to zostało pokazane powyżej.
W innym wypadku należy być po prostu świadom tego zachowania i nie być przerażonym, jeżeli ktoś przyjdzie do nas (audytor!!!) i powie …. A tam jest hasło !!!. Zawsze możemy je z tego atrybutu usnąć, ale pamiętajmy, że dostęp do niego nie jest otwarty – na straży stoją jeszcze ACLe na obiektach i atrybutach w katalogu.
Leave a Reply