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.

(cc) Somewhat Frank

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 2003

Modifying 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 2003

dn:CN=jan Kowalski,OU=DRLab,DC=w2k,DC=pl
>userPassword: 5040 7373 776F 7264 2121 31

1 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::000000001

AdMod V01.10.00cpp Joe Richards (joe@joeware.net) February 2007

DN Count: 1
Using server: w2003r2base.w2k.pl:389
Directory: Windows Server 2003

Modifying 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 2003

Modifying specified objects…
   DN: CN=jan Kowalski,OU=DRLab,DC=w2k,DC=pl…: [w2003r2base.w2k.pl] Error 0x35
(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 2003

Modifying 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 2003

dn: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: 0x502
keysize 60 HOST/ubuntu.w2k.pl@W2K.PL ptype 3 (KRB5_NT_SRV_HST) vno 2 etype 0x17
(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 2003

dn: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