Univention Bugzilla – Bug 20051
LDAPSASL_MECH=gssapi
Last modified: 2021-06-15 16:49:23 CEST
Derzeit verwenden die "ldap*"-Tools per Default unterschiedliche SASL-Mechanismen: # for host in m... a... o... n... l... u... s... xen1 xen2 xen4; do ssh "$host" "echo -n \"\$HOSTNAME \`uname -m\` \"; ldapwhoami </dev/null 2>&1 | grep ^SASL/"; done m... x86_64 SASL/GSSAPI authentication started a... x86_64 SASL/DIGEST-MD5 authentication started o... i686 SASL/DIGEST-MD5 authentication started n... x86_64 SASL/DIGEST-MD5 authentication started l... x86_64 SASL/DIGEST-MD5 authentication started u... x86_64 SASL/DIGEST-MD5 authentication started s... x86_64 SASL/DIGEST-MD5 authentication started xen1 x86_64 SASL/DIGEST-MD5 authentication started xen2 x86_64 SASL/GSSAPI authentication started xen4 i686 SASL/DIGEST-MD5 authentication started Dabei ist nicht ganz klar, warum welcher Rechner welches Verfahren standardmäßig verwendet. DigestMD5 und CramMD5 setzen voraus, daß das Plaintext-Passwort im LDAP gespeichert ist, was IMHO nicht der Fall ist und auch nicht per UCL-Variable konfiguriert werden kann (slapd.conf#password-hash}. Da UCS in der Standardinstallation Kerberos verwendet, wäre als Default GSSAPI sinnvoll. Dies kann in der /etc/ldap/ldap.conf per SASL_MECH=gssapi oder über die Shell-Umgebungsvariable LDAPSASL_MECH=gssapi konfiguriert werden. Eine weitere Schwierigkeit ist, daß wohl nur auf dem Master die zugehörige Kerberos-Prinzipal "ldap/${hostname}.${domainname}@${kerberos/realm}" existiert; auf einem Backup bzw. Slave scheitert die Authentifizierung dann mit folgender Meldung: # LDAPSASL_MECH=gssapi ldapwhoami SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (see text) (Server (ldap/xen2.opendvdi.local@OPENDVDI.LOCAL) unknownA)
(In reply to comment #0) > Derzeit verwenden die "ldap*"-Tools per Default unterschiedliche > SASL-Mechanismen: > # for host in m... a... o... n... l... u... s... xen1 xen2 xen4; do ssh "$host" > "echo -n \"\$HOSTNAME \`uname -m\` \"; ldapwhoami </dev/null 2>&1 | grep > ^SASL/"; done > m... x86_64 SASL/GSSAPI authentication started > a... x86_64 SASL/DIGEST-MD5 authentication started > o... i686 SASL/DIGEST-MD5 authentication started > n... x86_64 SASL/DIGEST-MD5 authentication started > l... x86_64 SASL/DIGEST-MD5 authentication started > u... x86_64 SASL/DIGEST-MD5 authentication started > s... x86_64 SASL/DIGEST-MD5 authentication started > xen1 x86_64 SASL/DIGEST-MD5 authentication started > xen2 x86_64 SASL/GSSAPI authentication started > xen4 i686 SASL/DIGEST-MD5 authentication started > Dabei ist nicht ganz klar, warum welcher Rechner welches Verfahren > standardmäßig verwendet. Das liegt meines Wissens daran, welche SASL-Module installiert sind und das hängt davon ab, welche Software bei der Auswahl verwendet wurde, beispielsweise ob die Mail / Groupware Pakete installiert sind. > DigestMD5 und CramMD5 setzen voraus, daß das Plaintext-Passwort im LDAP > gespeichert ist, was IMHO nicht der Fall ist und auch nicht per UCL-Variable > konfiguriert werden kann (slapd.conf#password-hash}. > Da UCS in der Standardinstallation Kerberos verwendet, wäre als Default GSSAPI > sinnvoll. Dies kann in der /etc/ldap/ldap.conf per SASL_MECH=gssapi oder über > die Shell-Umgebungsvariable LDAPSASL_MECH=gssapi konfiguriert werden. Wir hatten das schon mal versucht, allerdings funktioniert das Setzen in der ldap.conf nicht, ggf. funktioniert das mittlerweile: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=202641 > Eine weitere Schwierigkeit ist, daß wohl nur auf dem Master die zugehörige > Kerberos-Prinzipal "ldap/${hostname}.${domainname}@${kerberos/realm}" > existiert; auf einem Backup bzw. Slave scheitert die Authentifizierung dann mit > folgender Meldung: > # LDAPSASL_MECH=gssapi ldapwhoami > SASL/GSSAPI authentication started > ldap_sasl_interactive_bind_s: Local error (-2) > additional info: SASL(-1): generic failure: GSSAPI Error: > Miscellaneous failure (see text) (Server > (ldap/xen2.opendvdi.local@OPENDVDI.LOCAL) unknownA) Das ist wohl ein Problem in der Testumgebung, meines Wissens ist das mit 2.4 Final kein Problem gewesen.
libsasl2-2 ist laut /usr/share/doc/libsasl2-2/README.configure-options mit folgender Option übersetzt worden: --with-configdir=/etc/sasl:/usr/lib/sasl2 /etc/sasl/ gibt es nicht, dafür das Verzeichnis /etc/sasl2/, in dem derzeit nur die Konfigurationsdatei für libvirtd liegt; diese wird zwar derzeit nicht verwendet, tut so aber schon mal garnicht. Für OpenLDAP muß man das abweichende Verzeichnis /etc/ldap/sasl2/ benutzen: # ldapsearch -xLLLZb '' -sbase supportedSASLMechanisms dn: supportedSASLMechanisms: NTLM supportedSASLMechanisms: PLAIN supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: LOGIN # echo "mech_list: EXTERNAL PLAIN LOGIN gssapi" >/etc/ldap/sasl2/slapd.conf # /etc/init.d/slapd restart # ldapsearch -xLLLZb '' -sbase supportedSASLMechanisms dn: supportedSASLMechanisms: PLAIN supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: LOGIN Weder eine /etc/sasl/slapd.conf noch eine /etc/sasl2/slapd.conf haben bei meinen Tests funktioniert. Ein "strace -e t=file slapd" zeigt, daß statt dessen versucht wird /etc/ldap/sasl2/slapd.conf zu öffnen. Daneben tut auch /usr/lib/sasl2/slapd.conf EXTERNAL muß unbedingt angegeben werden, sonst funktioniert ein Simple-Bind (und damit auch dir Kerberos5-Tools) nicht mehr! (In reply to comment #1) > Wir hatten das schon mal versucht, allerdings funktioniert das Setzen in der > ldap.conf nicht, ggf. funktioniert das mittlerweile: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=202641 MECH_LIST in /etc/ldap/ldap.conf funktioniert bei mir: # for m in plain login ntlm cram-md5 digest-md5 gssapi; do sed -i "/SASL_MECH/d" /etc/ldap/ldap.conf ; echo "SASL_MECH $m" >>/etc/ldap/ldap.conf ; echo -n "$m " ; setsid ldapwhoami -Z </dev/null 2>&1 | grep SASL/ ; done plain SASL/PLAIN authentication started login SASL/LOGIN authentication started ntlm SASL/NTLM authentication started cram-md5 SASL/CRAM-MD5 authentication started digest-md5 SASL/DIGEST-MD5 authentication started gssapi SASL/GSSAPI authentication started Zu slapd.conf: <http://www.techienuggets.com/Comments?tx=63405> Doku zu Cyrus SASL: <http://postfix.state-of-mind.de/patrick.koetter/surviving_cyrus_sasl.pdf>
Kein Blocker für 3.0
*** Bug 27579 has been marked as a duplicate of this bug. ***
Similar for EXTERNAL: It would be nice if the local UNIX socket would be usable by any local user and "authz-regexp" would match the local ID to the LDAP user: # ldapwhoami -H ldapi:/// -Y EXTERNAL SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn:gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth # chmod 0777 /var/run/slapd/ldapi # su - MyAdmin $ ldapwhoami -Q -H ldapi:/// -Y EXTERNAL dn:gidNumber=5001+uidNumber=2069,cn=peercred,cn=external,cn=auth # $EDITOR /etc/univention/templates/files/etc/ldap/slapd.conf.d/30univention-ldap-server_head authz-regex gidNumber=[0-9]+.uidNumber=([0-9]+),cn=peercred,cn=external,cn=auth ldap:///dc=phahn,dc=dev??one?(uidNumber=$1) # ucr commit /etc/ldap/slapd.conf # /etc/init.d/slapd restart # chmod 0777 /var/run/slapd/ldapi # su - MyAdmin $ ldapwhoami -Q -H ldapi:/// -Y EXTERNAL dn:uid=myadmin,ou=frankfurt am main,dc=phahn,dc=dev Currently giving any user write access is a bad idea because of the following ACL: > access to * > by sockname="PATH=/var/run/slapd/ldapi" write
This issue has been filed against UCS 2.4. UCS 2.4 is out of maintenance and many UCS components have vastly changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS versions, please use "Clone this bug". In this case please provide detailed information on how this issue is affecting you.