LDAP - Debian/Etch: User-Passwort als User ändern geht nicht

[duser100]

Hallo,

Hab hier das Problem (wie schon in ´nem anderen Thread angedeutet) daß ich das Passwort von den LDAP-Usern nicht von den Usern selbst umstellen lassen kann:

Mit passwd:

Code: Alles auswählen

 
Enter login(LDAP) password:
New password:
Re-enter new password:
LDAP password information update failed: Unknown error
shadow context; no update referral
passwd: Permission denied
passwd: password unchanged

Oder mit ldappasswd -x -W -D uid= .... usw

Code: Alles auswählen

Enter LDAP Password:
Result: Server is unwilling to perform (53)
Additional info: shadow context; no update referral

Der Eintrag soll nicht über ´nen Update Referral eingetragen werden (der Server an dem der User angeloggt ist, ist zugleich der LDAP-Server) - darum denke ich ist der Hinweis mit dem Update Referral lediglich eine Info daß es hier nicht klappte und auch kein Update Referral eingetragen ist (wo er es statt dessen versuchen sollte wenn er hier nicht schreiben darf/soll).

Aus dem Logfile (dn entry durch Beispiel ersetzt):

Code: Alles auswählen

slapd[3454]: send_ldap_result: conn=41 op=0 p=3
slapd[3454]: send_ldap_response: msgid=1 tag=97 err=0
slapd[3454]: conn=41 op=0 RESULT tag=97 err=0 text=
slapd[3454]: connection_get(21): got connid=41
slapd[3454]: connection_read(21): checking for input on id=41
slapd[3454]: ber_get_next on fd 21 failed errno=11 (Resource temporarily unavailable)
slapd[3454]: do_extended
slapd[3454]: conn=41 op=1 PASSMOD
slapd[3454]: bdb_dn2entry("uid=beispiel,ou=users,ou=LAND,ou=Gruppe,dc=gibts,dc=nicht")
slapd[3454]: send_ldap_extended: err=53 oid= len=0
slapd[3454]: conn=41 op=1 RESULT oid= err=53 text=shadow context; no update referral

Passwörter ändern geht lediglich als LDAP-Admin.
Selbst andere Einträge als das Passwort kann ich mit dem User selbst nicht ändern (z.B. 'gecos').

Access-Liste slapd.conf (admin durch Beispiel ersetzt):

Code: Alles auswählen

access to attrs=userPassword,shadowLastChange
        by dn="cn=admin,dc=gibts,dc=nicht" write
        by anonymous auth
        by self write
        by * none

access to dn.base="" by * read

access to *
        by dn="cn=admin,dc=gibts,dc=nicht" write
        by * read

Selbst wenn ich da statt none oder read write einsetzte ändert das nichts. Anloggen als LDAP-User klappt hingegen.


Hat jemand eine Idee die hier weiterhilft?

Mfg,
duser100

[duser100]

Problem ließ sich teilweise umgehen indem die 'rootbinddn' für den LDAP-Admin im '/etc/libnss-ldap.conf' und '/etc/pam_ldap.conf' gesetzt wurde. Das wollte ich so zwar eigentlich nicht - und ich meine das sollte auch nicht nötig sein (denn der selbe User sollte sein Passwort auch ohne 'root' ändern können - spätestens wenn er sein altes Passwort nochmal einklopft) aber immerhin kann ich jetzt die Passwörter per 'passwd' am Server auch als User ändern. Mit ´nem LDAP-Client funktioniert es nach wie vor nicht.
Auch nützt mir die Lösung nichts wenn sich die User auf einem anderem Server authentifiziert haben (wo z.B. jeder auch 'root' sein darf) - denn da müsste ich ansonsten wohl ebenso das LDAP-Admin Passwort rumliegen lassen und das will ich eigentlich nicht zur freien Entnahme verstreuen.

[Mebuh]

Hört sich für mich nach ACL Problem an.
Ich muss aber leider gestehen, dass meine nicht viel anders aussieht.

Code: Alles auswählen

# users can authenticate and change their password
access to attrs=userPassword,sambaNTPassword,sambaLMPassword,sambaPwdLastSet,sambaPwdMustChange
        by dn="cn=samba,ou=DSA,dc=something" write
        by dn="cn=smbldap-tools,ou=DSA,dc=something" write
        by dn="cn=nssldap,ou=DSA,dc=something" write
        by self write
        by anonymous auth
        by * none
# some attributes need to be readable anonymously so that 'id user' can answer correctly
access to attrs=objectClass,entry,gecos,homeDirectory,uid,uidNumber,gidNumber,cn,memberUid
        by dn="cn=samba,ou=DSA,dc=something" write
        by dn="cn=smbldap-tools,ou=DSA,dc=something" write
        by * read
access to *
        by self read
        by * none

Hab' das ganze mit smbldap-tools gemacht, daher das ganze andere Zeug.
Aber bei mir funktioniert es.
Der einzige Unterschied ist so wie ich das sehe, die Reihenfolge.

Sorry, dass ich dir nicht explizit weiterhelfen kann.

Mebuh

[duser100]

Ob das wirklich an den ACLs liegt bezweifle ich mitlerweile, denn wenn ich folgendes einstelle...

Code: Alles auswählen

access to * by * write

...dann sollten doch Tür und Tor offen stehen? Das sollte freilich nicht so bleiben - aber wenn nicht mal das hilft?


Mfg,
duser100

[duser100]

@Mebuh: Mit was änderst du (bzw. die User) das Passwort (passwd?) ? Bzw. hast auch du das LDAP-Admin-PW im pam_ldap.secret bzw. libnss-ldap.secret drin? Weil so funktionierts ja hier auch... ist aber nicht wirklich die ultimative Lösung.

Mfg,
duser100

[Mebuh]

Ich kann die Passwörter ganz normal mit 'passwd' ändern (sowohl als User als auch als root für die User).
Und das rootbinddn Passwort liegt im Klartext in /etc/pam_ldap.secret bzw. /etc/libnss-ldap.secret

Gruß,
Mebuh

[duser100]

Danke für die Info Mebuh.

Ich kann auf diese Art und Weise (mit LDAP-Admin-PW in den besagten .secret Files) sogar als User das Passwort per 'passwd' ändern wenn ich den ganzen Block hier rausnehme und slapd neu starte:

Code: Alles auswählen

#access to attrs=userPassword,shadowLastChange,gecos
#        by dn="cn=admin,dc=lisec,dc=com" write
#        by anonymous auth
#        by self write
#        by * none

Das heißt für mich sieht das so aus als ob er sich um die ACLs eigentlich gar nicht gross kümmert sondern es nur deswegen funktioniert weil die User halt dann Rechte vom LDAP-Admin bekommen (über Pam oder was auch immer) - und/oder aber die ACLs so falsch sind. Nachdem er aber schon -so weit ich mich erinnere- beim Installieren von libpam-ldap und libnss-ldap nach dem LDAP-Admin-Passwort fragt vermute ich da nichts gutes.

Folgende Probleme:

*) Das Passwort könnte im Moment wohl auf all jenen Servern vom User selbst geändert werden auf denen ich bereit bin das LDAP-Admin-Passwort zu platzieren. Das ist aber nicht überall gewünscht. Man stell sich vor ein Server wird irgendwo auf der Welt gehackt. Das ist zwar immer unschön aber das braucht deswegen nicht unbedingt alle User auf der Welt kümmern. Oder aber es gibt einen Server auf dem auch normale User zu Testzwecken 'root' sein dürfen. Die hätten dann nicht nur Kontrolle über den einen Server sondern über alle LDAP-User.

*) Ich hab keinen Weg gefunden das Passwort auch mit ´nem LDAP-Client zu ändern. Damit schaff ich es zwar mich als User zu authentifizieren und Einträge zu lesen - kann aber nichts verändern. Ich vermute das ist das selbe Problem und natürlich könnte ich das "lösen" in dem ich einfach jedem User das LDAP-Admin-Passwort gebe. Wenn ich das nicht will heißt es im Moment wohl Aussenstellen können nicht mal selbst ihre Telefonnummern eintragen oder updaten.

[Mebuh]

Na ja, die aufwändige Lösung wäre für jede Aussenstelle (oder Gruppen davon) eigene Accounts zu erstellen und bei denen dann die ACLs entsprechend zu setzen, oder?

z.B.

Code: Alles auswählen

cn=Aussen1,ou=DSA,dc=<deineDomain>
cn=Aussen2,ou=DSA,dc=<deineDomain>
cn=Aussen3,ou=DSA,dc=<deineDomain>
cn=Intern,ou=DSA,dc=<deineDomain>

und dann:

Code: Alles auswählen

access to dn.regex="ou=Aussen1,ou=Users,dc=<deineDomain>"
        by dn="cn=Aussen1,ou=DSA,dc=<deineDomain>" write
        by dn="cn=Intern,ou=DSA,dc=<deineDomain>" write
        by * none
...

Aber so genau kenn' ich mich mit den ACLs nicht aus (->Tutorialgestört )

Gruß,
Mebuh

[duser100]

Wie weit meinst du daß die ACLs vom slapd.conf vom slapd berücksichtigt werden? Das löst ja das Problem nicht wirklich wenn ich jemanden von Aussen Zugriff geben wollte wenn ich nicht mal selbst drauf schreiben darf (ausser als LDAP-Admin)?

Sobald ich das LDAP-Admin Passwort nämlich angebe dürfen die User ihr Passwort verändern - selbst dann wenn einzig allein der LDAP-Admin per ACLs im slapd.conf schreiben darf. Wo bleiben da die ACLs? Wieso dürfen die User das dann immer noch (wenn nicht deswegen weil die ACLs mit dem LDAP-Admin-Account umgangen werden)?

Wenn ich das LDAP-Admin Passwort hingegen nicht in den .secret Files speichere dann kann ich auch testweise folgendes reinschreiben (und es funktioniert trotzdem nicht):

access to attrs=userPassword by * write

oder überhaupt:

access to * by * write

Wie kann ich noch mehr Rechte vergeben als 'jeder darf überall hin schreiben'? Oder versteh ich hier was falsch? Wenn aber nicht mal das klappt was soll dann ACL-mässig helfen?


Mfg,
duser100

[duser100]

Hab mittlerweile festgestellt daß es auf ´nem CentOS5 LDAP-Server funktioniert.
Nehm ich die selben ACLs dann auf dem Debian LDAP-Server dann klappt´s Passwort ändern nicht (von ´nem Client aus).

Code: Alles auswählen

access to attrs=userPassword,shadowLastChange
        by dn="cn=admin,dc=irgendwo,dc=irgendwas" write
        by anonymous auth
        by self write
        by * none

access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
access to *
         by self write
         by users read
         by anonymous auth

access to * by * read

[duser100]

Problem ist gelöst.

Der Fehler lag wohl darin daß am Masterserver eine 'updatedn' angegeben war. Ich erklär mir das jetzt so daß er dann meinte er dürfe hier gar nicht schreiben (zumindest nicht als User) und sollte irgendwo einen anderen Server kontaktieren. Nachdem´s aber der Master war und zudem kein 'referal' zum Weiterreichen angegeben wurde, war dann Schluss und es gab Fehler.