Hallo zusammen,
während des Updates meines UCS DC auf Version 4.2 scheint einiges schief gelaufen zu sein.
Die Join-Scripte selbst liefen alle durch, unter Domänenbeitritt wurden keine Fehler angezeigt. Allerdings funktionierte nach dem Update weder DNS in der Domäne noch konnten sich Domänennutzer auf den Rechnern einloggen.
Ein Blick in /var/log/univention/join.log lieferte einen ersten Hinweis:
RUNNING 98univention-samba4-dns.inst
2017-05-27 14:22:16.822729055+02:00 (in joinscript_init)
Waiting for RID Pool replication: done.
Note: samba-tool user add is deprecated. Please use samba-tool user create for the same function.
User 'dns-verwaltung' created successfully
Expiry for user 'dns-verwaltung' disabled.
Modified 1 records successfully
Added 1 records successfully
ERROR(runtime): uncaught exception - (-1073741823, 'Undetermined error')
File "/usr/lib/python2.7/dist-packages/samba/netcmd/__init__.py", line 176, in _run
return self.run(*args, **kwargs)
File "/usr/lib/python2.7/dist-packages/samba/netcmd/ntacl.py", line 239, in run
lp, use_ntvfs=use_ntvfs)
File "/usr/lib/python2.7/dist-packages/samba/provision/__init__.py", line 1609, in setsysvolacl
set_gpos_acl(sysvol, dnsdomain, domainsid, domaindn, samdb, lp, use_ntvfs, passdb=s4_passdb)
File "/usr/lib/python2.7/dist-packages/samba/provision/__init__.py", line 1514, in set_gpos_acl
passdb=passdb)
File "/usr/lib/python2.7/dist-packages/samba/provision/__init__.py", line 1477, in set_dir_acl
setntacl(lp, path, acl, domsid, use_ntvfs=use_ntvfs, skip_invalid_chown=True, passdb=passdb, service=service)
File "/usr/lib/python2.7/dist-packages/samba/ntacls.py", line 128, in setntacl
smbd.set_nt_acl(file, security.SECINFO_OWNER |security.SECINFO_GROUP | security.SECINFO_DACL | security.SECINFO_SACL, sd2, service=service)
open: error=2 (No such file or directory)
Not updating samba4/sysvol/sync/cron
[...]
2017-05-27 14:22:39.503854954+02:00 (in joinscript_save_current_version)
EXITCODE=0
Eine google-Suche zu Teilen der Fehlermeldung lieferte den folgenden Beitrag: http://samba.2283325.n4.nabble.com/Problems-with-samba-tool-ntacl-sysvol-reset-td4718590.html#a4718720
Dort lag das Problem darin, dass die Samba Datenbank Einträge für GPOs enthielt, die jedoch nicht (mehr) im entsprechenden sysvol-Verzeichnis vorhanden waren. Auf dem DC war dann tatsächlich auch das sysvol-Verzeichnis leer - obwohl hier bis vor dem Update jede Menge GPOs abgelegt waren! Der Zeitpunk des “Verschwindens” der GPOs lässt sich anhand der automatischen Backups von sysvol gut nachvollziehen:
-rw-r--r-- 1 root root 13205375 Mai 25 03:00 sysvol.2017-05-25.tar.bz2
-rw-r--r-- 1 root root 13205375 Mai 26 03:00 sysvol.2017-05-26.tar.bz2
-rw-r--r-- 1 root root 13205375 Mai 27 03:00 sysvol.2017-05-27.tar.bz2
-rw-r--r-- 1 root root 494 Mai 28 03:00 sysvol.2017-05-28.tar.bz2
-rw-r--r-- 1 root root 494 Mai 29 03:00 sysvol.2017-05-29.tar.bz2
Im Laufe des 27. Mai wurde das Update eingespielt, und die GPOs verschwanden…
Nachdem die GPOs wieder hergestellt waren lief zumindest das samba4-dns join script durch, allerdings waren die DNS und Authentifizierungs-Probleme nicht gelöst. Nach Umstellen des DNS-Backends für Bind von samba4 auf LDAP klappt momentan wenigstens die Namensauflösung - die internen Daten stimmen also.
Es bleibt das Problem, dass sich Benutzer nicht authentifizieren können. Domänenbenutzer mit servergespeicherten Profilen bekommen die Fehlermeldung, dass sie keine Berechtigung zum Zugriff auf das Profil haben, Domänenbenutzer mit lokal gespeicherten Profilen werden mit temporären Profilen eingeloggt und können mangels Berechtigung nicht auf Ressourcen im Netzwerk zugreifen.
Ein “smbclient -L //[server]/ -U [Domänenbenutzer]” liefert
Kinit for [Domänenbenutzer] to access [server] failed: Client not found in Kerberos database
session setup failed: NT_STATUS_LOGON_FAILURE
Ein “kinit [Domänenbenutzer]” scheitert entsprechend:
kinit: krb5_get_init_creds: Client ([Domänenbenutzer]) unknown
Die Ausgabe von “univention-ldapsearch uid=[Domänennutzer] | grep -i krb” für einen existierenden Domänenbenutzer sieht eigentlich gut aus (keys verkürzt!)
krb5PrincipalName: [Domänenbenutzer]
objectClass: krb5Principal
objectClass: krb5KDCEntry
krb5MaxLife: 86400
krb5MaxRenew: 604800
krb5KDCFlags: 126
krb5Key:: MB2h
krb5Key:: MFSh
krb5Key:: MESh
krb5Key:: MDyh
krb5Key:: MDyh
krb5KeyVersionNumber: 4
Als (wohl) einziger Benutzer kann derzeit der UCS Account “Administrator” erfolgreich ein kinit durchführen… Was kann ich denn noch tun, um dieses Problem einzugrenzen und zu beheben?
Danke schonmal für die Hilfe!!!
Beste Grüße
Stefan Falge