Univention Bugzilla – Bug 28379
Samba4 DC Joinfehler bei univention_server_join: kadmin Can't contact LDAP server
Last modified: 2012-12-12 21:10:09 CET
Beim Erneuten Join eines DC Salve mit Samba4 tritt zur Zeit immer mal wieder folgender Fehler auf, der sich bei wiederholten Versuchen auch geben kann (bei mir immer bei dritten Versuch..) root@slave12:~# univention-join univention-join: joins a computer to an ucs domain copyright (c) 2001-2012 Univention GmbH, Germany Enter DC Master Account : Administrator Enter DC Master Password: Search DC Master: done Check DC Master: done Stop LDAP Server: done Stop Samba 4 Server: done Search ldap/base done Start LDAP Server: done Search LDAP binddn done Sync time done Join Computer Account: done ************************************************************************** * Join failed! * * Contact your system administrator * ************************************************************************** * Message: univention-server-join: joins a server to an univention domain copyright (c) 2001-2012 Univention GmbH, Germany ldap_dn="cn=slave12,cn=dc,cn=computers,dc=arucs3i8,dc=qa" kadmin: KerberosPasswd="VHGfSSpu" kadm5_create_principal: ldap_sasl_bind_s: Can't contact LDAP server kadmin: adding ldap/slave12.arucs3i8.qa: ldap_sasl_bind_s: Can't contact LDAP server **************************************************************************
Das ist reproduzierbar, wenn als Benutzer Administrator gejoint wird. Der ldap-Eintrag wird per kadmin -l hinzugefügt und kadmin -l verwendet das ldapi Interface. Ein strace in univention-server-join zeigt es: connect(4, {sa_family=AF_FILE, path="/var/run/slapd/ldapi"}, 110) = -1 EACCES (Permission denied)
*** Bug 24104 has been marked as a duplicate of this bug. ***
Option 1: Domain Admins bekommen Zugriff auf das ldapi-Interface. Option 2: Domain Admins bekommen Zugriff auf cn=kerberos (das ist derzeit nur eingeschränkt) und das Objekt wird per UDM Modul oder per ldapmodify angelegt.
(In reply to comment #3) > Option 2: Domain Admins bekommen Zugriff auf cn=kerberos (das ist derzeit nur > eingeschränkt) und das Objekt wird per UDM Modul oder per ldapmodify angelegt. Das ist soweit umgesetzt, es gibt ein UDM Modul um solche Objekte anzulegen. Der Zugriff auf cn=kerberos bestand bereits. Es fehlt noch ein Test, ob nach der Installation einer UCS 3 Umgebung (ohne Samba 4) ldapsearch -Y GSSAPI auf Master und Backup funktioniert.
Tests waren erfolgreich.
Neu Join funktioniert, aber danach funktioniert GSSAPI nicht mehr: root@slave:~# kinit root@ARUCS31I5.QA's Password: kinit: krb5_get_init_creds: Client (root@ARUCS31I5.QA) unknown root@slave:~# kinit 'slave$' slave$@ARUCS31I5.QA's Password: root@slave:~# ldapsearch -Y GSSAPI 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/slave.arucs31i5.qa@ARUCS31I5.QA) unknown)
(In reply to comment #6) > Neu Join funktioniert, aber danach funktioniert GSSAPI nicht mehr: > > > root@slave:~# kinit > root@ARUCS31I5.QA's Password: > kinit: krb5_get_init_creds: Client (root@ARUCS31I5.QA) unknown > root@slave:~# kinit 'slave$' > slave$@ARUCS31I5.QA's Password: > root@slave:~# ldapsearch -Y GSSAPI > 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/slave.arucs31i5.qa@ARUCS31I5.QA) > unknown) Ich habe ein weiteres Testsystem mit UCS 3.1 ohne S4 aufgesetzt. Dort funktioniert es auf dem Slave auch nach dem Re-Join ohne Probleme. Gibt es Hinweise in der join.log, heimdal.log oder syslog? kadmin -l get ldap/$(hostname -f)
Ich kann es weder in einer S3 noch in einer S4 Umgebung reproduzieren.
Verified: * Auch in einer Samba4 Umgebung funktioniert es nach Durchlauf der Replikation.
UCS 3.1-0 has been released: http://forum.univention.de/viewtopic.php?f=54&t=2125 If this error occurs again, please use "Clone This Bug".