Probleme bei samba4-Ldap-bind ach Upgrade auf 3.1-1

Nach dem Upgrade meldet

==> /var/log/univention/connector-s4-status.log <== Wed Jul 17 22:52:21 2013 Warning: Can't initialize LDAP-Connections, wait... Warning: Can't initialize LDAP-Connections, wait...

Wie kann ich prüfen, warum der bind fehlschlägt, und was muss ich tun, um das Problem zu beheben?

Von den Windows-Rechnern in meiner Domäne ist aktuell kein Zugriff auf Samba-Freigaben möglich, ebensowenig das Browsen der Netzwerkumgebung…

be-team

edit

Habe versucht, auf dem Master die Join-Skripte zu Samba4 neu auszuführen und bekomme Fehler:

[code]# univention-run-join-scripts --ask-pass
univention-run-join-scripts: runs all join scripts existing on local computer.
copyright © 2001-2013 Univention GmbH, Germany

Enter DC Master Account : Administrator
Enter DC Master Password:

Search LDAP binddn Permission denied (publickey,gssapi-keyex,gssapi-with-mic,keyboard-interactive).
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,keyboard-interactive).
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,keyboard-interactive).


  • Running join scripts failed! *

  • Message: binddn for user Administrator not found

[/code]

Was kann denn hier passiert sein, dass der bind in die Binsen geht?

Was sagt denn /var/log/univention/upgrade.log?

Hallo,

1.) Ausgabe von:

univention-check-templates

2.)

univention-ldapsearch

3.) System Rolle?

Hallo,

@DBGTMaster & SirTux: Danke für die Anregungen!

Hier aber bitte nicht den kompletten Dump inklusive Produktivdaten anhängen, sofern es in der Zwischenzeit einen self-heal gab :wink: als Test besser:

univention-ldapsearch -s base dn

@be-team:
Bitte prüfen Sie zusätzlich einmal folgendes:

kinit Administrator

Die Datei /var/log/univention/upgrade.log können Sie gern auch in Ihrer nächsten Antwort anhängen.

Mit freundlichen Grüßen,
Tim Petersen

Hallo zusammen und Danke für die Antworten.

Jetzt die gewünschten Infos meinerseits:

Systemrolle ist PDC. Installiert physisch auf HP Microserver.

root@projects:~# univention-check-templates

…kommt ohne Fehlermeldung und sonstige Ausgabe zurück.

Für Administrator ist das machine.secret nicht zugänglich:

Administrator@projects:~$ univention-ldapsearch
/etc/machine.secret: Permission denied

Aber root darf:

root@projects:~# univention-ldapsearch Administrator
(...)
# 109, xxx.xxx.xxx.in-addr.arpa, dns, be-team.org
dn: relativeDomainName=109,zoneName=xxx.xxx.xxx.in-addr.arpa,cn=dns,dc=be-team,
 dc=org

# search result
search: 3
result: 0 Success

# numResponses: 472
# numEntries: 471

Mit Kerberos scheint es ein Problem zu geben:

root@projects:~# kinit Administrator
Administrator@BE-TEAM.ORG's Password:
kinit: krb5_get_init_creds: unable to reach any KDC in realm BE-TEAM.ORG

Das Logfile /var/log/univention/updater.log habe ich angehängt. Eine Datei upgrade.log habe ich nicht gefunden.

be-team
updater.zip (38.1 KB)

Hallo,

die updater.log ist auf den ersten Blick unauffällig.

[quote=“be-team”]

root@projects:~# univention-ldapsearch Administrator [...] [/quote]
kurz am Rande: Dieser Befehl durchsucht das komplette LDAP und listet Attribute die auf Administrator matchen.

Was Sie vermutlich wollten und auch in diesem Kontext sinnvoll erscheint, wäre das Benutzerobjekt anzuzeigen:

univention-ldapsearch uid=Administrator

Parallel hängen Sie bitte einmal die Ausgabe des folgenden Befehls an:

ucr search --brief kerberos

Mit freundlichen Grüßen,
Tim Petersen

Hallo Herr Petersen,

ja, bezüglich commandline und ldap im besonderen habe ich noch nicht ausgelernt…

Hier die ucr-Ausgabe:

root@projects:~# ucr search --brief kerberos
kerberos/adminserver: projects.be-team.org
kerberos/adminusers: <empty>
kerberos/afscell: <empty>
kerberos/allow/weak/crypto: <empty>
kerberos/autostart: no
kerberos/defaults/debug: <empty>
kerberos/defaults/dns_lookup_kdc: <empty>
kerberos/defaults/dns_lookup_realm: <empty>
kerberos/defaults/enctypes/permitted: <empty>
kerberos/defaults/enctypes/tgs: <empty>
kerberos/defaults/enctypes/tkt: <empty>
kerberos/defaults/forwardable: <empty>
kerberos/defaults/kdc_timesync: <empty>
kerberos/defaults/proxiable: <empty>
kerberos/domain_realms: <empty>
kerberos/enable/524: <empty>
kerberos/enable/kaserver: <empty>
kerberos/enable/kerberos4: <empty>
kerberos/kadmin/default/keys: <empty>
kerberos/kdc: <empty>
kerberos/kpasswdserver: projects.be-team.org
kerberos/password/quality/ascii_lowercase: <empty>
kerberos/password/quality/ascii_uppercase: <empty>
kerberos/password/quality/check: yes
kerberos/password/quality/diff_ok: <empty>
kerberos/password/quality/dig_credit: <empty>
kerberos/password/quality/low_credit: <empty>
kerberos/password/quality/min_length: <empty>
kerberos/password/quality/oth_credit: <empty>
kerberos/password/quality/up_credit: <empty>
kerberos/realm: BE-TEAM.ORG
kerberos/v4tickets: <empty>
kerberos/autostart: no

Ich denke da haben wir den Übeltäter. Der kdc läuft dann wohl nicht. Da hat vermutlich jemand dem Wert geändert und nach dem Upgrade wurde vermutlich das System erstmalig neugestartet. Führen Sie das mal aus:

/etc/init.d/heimdal-kdc start
ucr set kerberos/autostart=yes

Danke SirTux!

Isch werd verrückt - et geht wieda! :slight_smile:

Es sind doch eine ganze Reihe Komponenten, die ordentlich zusammen spielen müssen, damit alles läuft. LDAP, samba4, s4-connector, kerberos. Ohne Höllenhund geht nichts - logisch. Wieder dazu gelernt.

be-team

EDIT

Zu früh gefreut (teilweise). Nach dem Start des Kerberos konnte ich zwar sofort wieder die Netzwerkumgebung durchsuchen (daher mein erfreuter Kommentar oben) - aber ein Zugriff auf die Freigaben funktioniert nach wie vor nicht.

Weiterhin

==> /var/log/univention/connector-s4-status.log <==
Warning: Can't initialize LDAP-Connections, wait...

@SirTux: Good Catch! :slight_smile:
@Be-Team: Schön, dass es wieder funktioniert.

Mit freundlichen Grüßen,
Tim Petersen

Siehe vorheriger EDIT - der Catch von SirTux war gut, aber offensichtlich habe ich noch ein weiteres Problem.

Habe samba4 sowie den s4-connector restarted. Kann ich irgendwo noch einen Debug-Level hochdrehen oder weitere Tests durchführen?

be-team

Hallo,

ich habe leider einen wesentlichen Fakt übersehen - unter Samba 4 darf heimdal-kdc nicht laufen, da hier ein eigener Kerberos-Dienst bereitgestellt wird!
Bitte setzen Sie die Autostart-variable wieder auf “no” und stoppen heimdal-kdc:

ucr set kerberos/autostart=no /etc/init.d/heimdal-kdc stop

Anschließend hängen Sie uns bitte einmal die Datei /var/log/samba/log.samba an.

Mit freundlichen Grüßen,
Tim Petersen

Hallo Herr Petersen,

angehängt jetzt das Samba-Log. Außerdem direkt nach dem Befehl # /etc/init.d/samba4 restart habe ich noch folgendes in den Logfiles gefunden:

==> /var/log/univention/connector-s4.log <==
  File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 96, in _ldap_call
    result = func(*args,**kwargs)
OBJECT_CLASS_VIOLATION: {'info': "attribute 'sambaNTPassword' not allowed", 'desc': 'Object class violation'}

be-team
log.samba.txt (8.15 KB)
ucr-samba4-settings.txt (734 Bytes)

Hier noch ein kurzer Auszug aus dem Syslog. Sind das Folgefehler bezüglich DNS-Updates?

Jul 18 16:48:12 projects named[10693]: error (FORMERR) resolving 'rating.testeo.de/A/IN': 208.76.58.185#53 Jul 18 16:48:14 projects named[10693]: DNS format error from 208.76.58.185#53 resolving 253.189.106.87.in-addr.arpa/PTR for client 192.168.12.101#49180: non-improving referral Jul 18 16:48:14 projects named[10693]: error (FORMERR) resolving '253.189.106.87.in-addr.arpa/PTR/IN': 208.76.58.185#53 Jul 18 16:48:14 projects named[10693]: DNS format error from 208.76.58.185#53 resolving content.copmedia.de/A for client 192.168.12.101#51181: non-improving referral Jul 18 16:48:14 projects named[10693]: error (FORMERR) resolving 'content.copmedia.de/A/IN': 208.76.58.185#53 Jul 18 16:49:03 projects named[10693]: samba_dlz: starting transaction on zone be-team.org Jul 18 16:49:03 projects named[10693]: client 192.168.12.107#51168: update 'be-team.org/IN' denied Jul 18 16:49:03 projects named[10693]: samba_dlz: cancelling transaction on zone be-team.org Jul 18 16:49:04 projects named[10693]: samba_dlz: starting transaction on zone be-team.org Jul 18 16:49:04 projects named[10693]: samba_dlz: allowing update of signer=admin001\$\@BE-TEAM.ORG name=ADMIN001.be-team.org tcpaddr= type=AAAA key=1208-ms-7.70-2b5b568b.8771a080-e904-11e2-ec83-88ce35596954/160/0

Nach dem restart des univention-s4-connector habe ich jetzt folgende Einträge im Log:

==> /var/log/univention/connector-s4.log <== 18.07.2013 17:05:46,934 LDAP (PROCESS): sync to ucs: Resync rejected dn: CN=horst-pro,CN=Computers,DC=be-team,DC=org 18.07.2013 17:05:46,956 LDAP (PROCESS): sync to ucs: [windowscomputer] [ modify] cn=horst-pro,cn=computers,dc=be-team,dc=org 18.07.2013 17:05:47,104 LDAP (ERROR ): failed in post_con_modify_functions 18.07.2013 17:05:47,105 LDAP (ERROR ): Traceback (most recent call last): File "/usr/lib/pymodules/python2.6/univention/s4connector/__init__.py", line 1323, in sync_to_ucs f(self, property_type, object) File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/password.py", line 783, in password_sync_s4_to_ucs_no_userpassword password_sync_s4_to_ucs(s4connector, key, ucs_object, modifyUserPassword=False) File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/password.py", line 774, in password_sync_s4_to_ucs s4connector.lo.lo.modify(ucs_object['dn'], modlist) File "/usr/lib/pymodules/python2.6/univention/uldap.py", line 505, in modify self.lo.modify_s(dn, ml) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 322, in modify_s return self.result(msgid,all=1,timeout=self.timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 422, in result res_type,res_data,res_msgid = self.result2(msgid,all,timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 426, in result2 res_type, res_data, res_msgid, srv_ctrls = self.result3(msgid,all,timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 432, in result3 ldap_result = self._ldap_call(self._l.result3,msgid,all,timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 96, in _ldap_call result = func(*args,**kwargs) OBJECT_CLASS_VIOLATION: {'info': "attribute 'sambaNTPassword' not allowed", 'desc': 'Object class violation'}

Nachtrag:

jetzt funktionieren sowohl Browsing der Domäne als auch Zugriff auf die Freigaben sowohl von Win7 Pro als auch von XP Pro Clients wieder wie vor dem Ugprade. Warum, weiß ich leider nicht. Hmm.

Aber: Die Python-Fehler im s4-connector-log sind nach wie vor da.

Einzige Vermutung, was hier die Veränderung zum Guten bewirkt haben kann, ist dieser Befehl, den ich nach Lektüre von http://forge.univention.org/bugzilla/show_bug.cgi?id=22600 abgesetzt hatte (in der Hoffnung, evtl. auf eine aussagefähige Fehlermeldung zu stoßen). Der lief aber erfolgreich durch.

ldapsearch -Y GSSAPI

Wenig später funktionierten Browsing und Freigabenzugriff wieder - ob das mit dem vorgenannten Befehl zu tun hatte, scheint mir aber zweifelhaft.

Hier meine Shell-Historie (showlogs ist ein kleines Skript, das mir die letzten paar Zeilen aller während der letzten n Minuten geänderten Dateien unterhalb von /var/log liefert).

531 ucr set kerberos/autostart=no 532 /etc/init.d/heimdal-kdc stop 533 less /var/log/samba/log.samba 534 /etc/init.d/samba4 restart 535 showlogs 1 536 less /usr/lib/python2.6/dist-packages/ldap/ldapobject.py 537 ucr shell | grep samba4 538 showlogs 1 539 less /var/log/syslog 540 /etc/init.d/univention-s4-connector restart 541 showlogs 1 542 cd /var/log 543 cd univention/ 544 less connector-s4.log 545 ldapsearch -Y GSSAPI

Bleiben noch die “non-improving referral” Einträge von named im syslog. Die scheinen aber den Betrieb nicht zu stören (jedenfalls kann ich die im syslog monierten IP-Namen alle per nslookup und dig auflösen). Beispielsweise:

[code]# dig @192.168.12.230 +trace yahoo.it
; <<>> DiG 9.8.0-P4 <<>> @192.168.12.230 +trace yahoo.it
; (1 server found)
;; global options: +cmd
. 25806 IN NS m.root-servers.net.
. 25806 IN NS l.root-servers.net.
. 25806 IN NS a.root-servers.net.
. 25806 IN NS c.root-servers.net.
. 25806 IN NS b.root-servers.net.
. 25806 IN NS k.root-servers.net.
. 25806 IN NS f.root-servers.net.
. 25806 IN NS i.root-servers.net.
. 25806 IN NS g.root-servers.net.
. 25806 IN NS j.root-servers.net.
. 25806 IN NS e.root-servers.net.
. 25806 IN NS d.root-servers.net.
. 25806 IN NS h.root-servers.net.
;; Received 364 bytes from 192.168.12.230#53(192.168.12.230) in 2 ms

it. 172800 IN NS nameserver.cnr.it.
it. 172800 IN NS r.dns.it.
it. 172800 IN NS c.dns.it.
it. 172800 IN NS dns.nic.it.
it. 172800 IN NS m.dns.it.
it. 172800 IN NS a.dns.it.
;; Received 409 bytes from 192.112.36.4#53(g.root-servers.net) in 48 ms

yahoo.it. 10800 IN NS ns3.yahoo.com.
yahoo.it. 10800 IN NS ns5.yahoo.com.
yahoo.it. 10800 IN NS ns1.yahoo.com.
yahoo.it. 10800 IN NS ns2.yahoo.com.
yahoo.it. 10800 IN NS ns7.yahoo.com.
;; Received 125 bytes from 192.12.192.5#53(dns.nic.it) in 55 ms

yahoo.it. 300 IN A 87.248.120.148
yahoo.it. 300 IN A 77.238.178.122
yahoo.it. 86400 IN NS ns5.yahoo.com.
yahoo.it. 86400 IN NS ns3.yahoo.com.
yahoo.it. 86400 IN NS ns1.yahoo.com.
yahoo.it. 86400 IN NS ns2.yahoo.com.
yahoo.it. 86400 IN NS ns4.yahoo.com.
;; Received 237 bytes from 68.180.131.16#53(ns1.yahoo.com) in 33 ms
[/code]

Ist das einen neuen Thread wert?

Mein Produktionsproblem ist jetzt erstmal vom Tisch, auch wenn ich nicht verstehe warum.

Danke soweit für alle Tipps!

be-team

Hallo,

samba: using 'standard' process model [2013/07/18 15:34:31, 0] ../source4/smbd/service_stream.c:342(stream_setup_socket) Failed to listen on 0.0.0.0:88 - NT_STATUS_ADDRESS_ALREADY_ASSOCIATED [2013/07/18 15:34:31, 0] ../source4/kdc/kdc.c:672(kdc_add_socket) Failed to bind to 0.0.0.0:88 TCP - NT_STATUS_ADDRESS_ALREADY_ASSOCIATED [2013/07/18 15:34:31, 0] ../source4/smbd/service_task.c:35(task_server_terminate) task_server_terminate: [kdc failed to setup interfaces] [2013/07/18 15:34:31, 0] ../source4/smbd/server.c:212(samba_terminate) samba_terminate: kdc failed to setup interfaces [2013/07/18 16:35:55, 0] ../source4/smbd/server.c:371(binary_smbd_main) samba version 4.0.3 started. Copyright Andrew Tridgell and the Samba Team 1992-2012 [2013/07/18 16:35:56, 0] ../source4/smbd/server.c:484(binary_smbd_main) samba: using 'standard' process model

Klingt so, als wäre samba4 bereits gelaufen…? Eventuell hatte sich ein samba Dienst im Hintergrund erhängt…

Hallo,

ich vermute die Meldungen der Art

non-improving referral named[10693]: error (FORMERR) resolving 'content.copmedia.de/A/IN': 208.76.58.185#53

sind so in Ordnung, da die Ursache hier vermutlich extern ,d.h. von content.copmedia.de getriggert wurde.

Sofern die domänenweite DNS-Auflösung keine Auffälligkeiten aufweist würde ich hier von keinem Problem ausgehen.

Mit freundlichen Grüßen,
Tim Petersen

Hallo,

Samba4 scheint soweit ordentlich zu laufen. @DBGTMaster: Es kann schon sein, dass es bei den verschiedenen Restarts der Dienste zwischenzeitlich zu einem Problem kam. Die vom Samba4 aufgespannte Domäne funktioniert jetzt aber bezüglich Anmeldungen und Zugriff auf Freigaben.

@Herr Petersen: Die DNS-Meldungen lege ich erst einmal ad acta.

Mein Problem mit dem connector-s4.log scheint mir jetzt aber wieder auf die Füße zu fallen: Ich kann mich am Nagios-Webfrontend nicht mehr anmelden. Habe dazu einen neuen Thread gestartet [url]Anmeldung am Nagios-Webinterface nicht möglich].

==> /var/log/univention/connector-s4.log <== File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 96, in _ldap_call result = func(*args,**kwargs) OBJECT_CLASS_VIOLATION: {'info': "attribute 'sambaNTPassword' not allowed", 'desc': 'Object class violation'}

Dieser hier kann als geschlossen betrachtet werden.

Danke für alle Tipps und Kommentare!
be-team

Mastodon