Daardie LDAP-wagwoordfout is dalk glad nie die gebruiker se wagwoord nie

Om ’n gebruiker se wagwoord terug te sit is die verkeerde eerste stap wanneer die log net sê dat ’n binding geweier is. By ’n gidsinprop is daar meer as een binding in ’n enkele aanmelding, en die weiering kan aan die diensrekening behoort wat die soektog doen. Om die gebruiker se geloofsbriewe in daardie geval terug te sit, verander niks. Dit sluit ook iemand uit wat nooit die probleem was nie.

Een aanmelding, verskeie bindings

’n Konfigurasie met ’n toegewyde gidsrekening voer gewoonlik vier stappe in volgorde uit, en enigeen van hulle kan die aanmelding beëindig.

connect to the directory and establish the configured TLS protection
bind as the configured service account
search for the user entry using the search base and filter
open a second connection and bind as that user, then evaluate groups

Die inprop bou sy gebruiker-verifikasieverbinding deur dieselfde helper wat die eerste verbinding hanteer, so daardie helper kan misluk terwyl dit verbind, terwyl dit TLS onderhandel, of terwyl dit as die diensrekening bind. Die hoëvlak-boodskap oor ’n wagwoord word later gegenereer, en dit dra nie watter identiteit betrokke was nie. Daarom kan die foutteks alleen jou nie sê of die gebruiker of die diensrekening geweier is nie.

Lees die reëls voor die boodskap, en let op die oomblik wanneer die fout gebeur het. ’n Weiering by die opstart, voordat enige gebruiker opdaag, wys na die gekonfigureerde rekening of die eindpunt. ’n Weiering wat net vir een persoon verskyn, ná ’n suksesvolle soektog, wys na daardie persoon se inskrywing of rekeningstatus.

Koppel die fout aan ’n identiteit

Die praktiese reël is om drie dinge saam op te teken: wanneer dit misluk het, watter bewerking aan die gang was, en watter identiteit aangebied is. Sonder daardie drietal lyk twee heel verskillende foute identies in ’n log wat net die laaste sin hou.

As die gekonfigureerde rekening misluk, ondersoek daardie rekening en die verbinding voordat jy enige gebruikerrekord aanraak. As die gebruiker-binding misluk ná ’n suksesvolle soektog, ondersoek die inskrywing wat die soektog teruggegee het eerder as die een wat jy aangeneem het dit sou teruggee. Die twee paaie deel ’n boodskap en niks anders nie. Skryf neer watter een jy uitgeskakel het, want die volgende persoon sal presies dit vra.

Die onderskeidende naam is data, nie ’n raaiskoot nie

Om ’n naamkomponent te verander omdat dit onbekend lyk, is ’n algemene manier om ’n werkende konfigurasie te breek. Die verstekplek vir gebruikervoorwerpe in Active Directory is ’n houer met die naam Users, en ’n houer is nie dieselfde soort voorwerp as ’n organisatoriese eenheid met ’n soortgelyke naam nie.

Vra die gidsadministrateur vir die rekening se werklike onderskeidende naam, of lees dit uit die voorwerp self. Albei die volgende kan in hul eie gids korrek wees, en daarom moet nie een van hulle uit die geheue getik word nie.

CN=VPN Bind,CN=Users,DC=corp,DC=example
CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example

’n Skuif of ’n hernoeming verander daardie waarde terwyl die rekening en wagwoord geldig bly, so ’n konfigurasie wat verlede kwartaal gewerk het, kan hierdie een misluk sonder dat iemand aan ’n geloofsbrief geraak het. Vergelyk die gekonfigureerde string met die gids se huidige kenmerk ná enige herorganisasie. Doen dit ook ná ’n stil migrasie, nie net ná ’n gerapporteerde onderbreking nie.

’n Soekbasis is nie ’n diensrekening nie

Die bind-identiteit en die soekbasis beantwoord verskillende vrae: as wie die inprop verifieer, en waar dit na mense soek. ’n Suksesvolle binding gevolg deur geen passende gebruiker nie, is ’n probleem met die soekbereik, die filter of leestoestemming, en om die rekening se onderskeidende naam met die gebruikers se basis te vervang, verander niks daaraan nie.

Bevestig dat die diens die konfigurasie gelaai het wat jy verander het, en dat sy eindpunt, TLS-vertroue en verifikasiemetode ooreenstem met ’n werkende administratiewe toets. ’n Handmatige opsoek met ’n ander rekening, of teen ’n ander domeinbeheerder, is nie ’n gelykwaardige eksperiment nie.

Kontroleer die gestoorde geheim, en kontroleer of die rekening geaktiveer, verval of gesluit is, sonder om die wagwoord enige plek te druk. Vervaldatum is maklik om te mis, want die rekening hou aan werk tot die dag dat dit nie meer doen nie. ’n Sluiting wat van ’n onverwante diens geërf is, is net so stil. Nie een van die twee toestande lewer ’n boodskap wat die diensrekening noem nie.

Groepreëls kom laaste

Magtiging loop nadat die bindings geslaag het, so ’n groepkontrole kan nie die oorsaak van ’n bind-fout wees nie, en om die groepvereiste te verwyder kan een nie herstel nie. As die aanmelding nou die groepfase bereik, is die oorblywende probleem lidmaatskap, nie geloofsbriewe nie.

Om die diensrekening breë gidsregte te gee om die fout te laat verdwyn, verander die toegangsbeleid van die hele ontplooiing. Behandel dit as ’n sekuriteitsbesluit met sy eie hersiening, nie as ’n oplossing vir ’n boodskap wat jy nog nie aan ’n identiteit toegeskryf het nie.