[Closed] Authentifizierung schlägt nach Update auf UCS 4.2 fehl

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

Wie ist die Ausgabe von

univention-s4connector-list-rejected

EDIT: Ansonsten verweise ich auch schon mal auf die SDB

Danke schonmal für die schnelle Antwort, den SDB-Artikel gehe ich später durch.

 univention-s4connector-list-rejected 

liefert folgende Ausgabe (gekürzt)

UCS rejected

    1:   UCS DN: relativeDomainName=XXX,zoneName=10.168.192.in-addr.arpa,cn=dns,dc=XXX,dc=XXX
          S4 DN: <not found>
         Filename: /var/lib/univention-connector/s4/1495886369.310671

    2-66 [Ähnliche Einträge für diverse hosts]

S4 rejected

    1:    S4 DN: CN=Print Operators,CN=Builtin,DC=xxx,DC=xxx
         UCS DN: <not found>
    2:    S4 DN: DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=xxx,DC=xxx
         UCS DN: <not found>
    3:    S4 DN: DC=@,DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=xxx,DC=xxx
         UCS DN: <not found>
    4:    S4 DN: DC=h.root-servers.net,DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=xxx,DC=xxx
         UCS DN: <not found>
    5-62 [Ähnliche Einträge für diverse hosts]

        last synced USN: 3730

EDIT: Hier noch die “passenden” Auszüge aus /var/log/univention/connector-s4.log:

01.06.2017 14:01:09,205 LDAP        (PROCESS): sync from ucs:   Resync rejected file: /var/lib/univention-connector/s4/1495886368.827337
01.06.2017 14:01:09,313 LDAP        (WARNING): sync failed, saved as rejected
        /var/lib/univention-connector/s4/1495886368.827337
01.06.2017 14:01:09,314 LDAP        (WARNING): Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 987, in resync_rejected_ucs
    if self.__sync_file_from_ucs(filename, append_error=' rejected'):
  File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 839, in __sync_file_from_ucs
    object = self._object_mapping(key, object, 'ucs')
  File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 1768, in _object_mapping
    object = function(self, object, dn_mapping_stored, isUCSobject=(object_type == 'ucs'))
  File "/usr/lib/pymodules/python2.7/univention/s4connector/s4/dns.py", line 264, in dns_dn_mapping
    show_deleted=False)
  File "/usr/lib/pymodules/python2.7/univention/s4connector/s4/__init__.py", line 1230, in __search_s4
    rtype, rdata, rmsgid, serverctrls = self.lo_s4.lo.result3(msgid)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 476, in result3
    resp_ctrl_classes=resp_ctrl_classes
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 483, in result4
    ldap_result = self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 106, in _ldap_call
    result = func(*args,**kwargs)
NO_SUCH_OBJECT: {'info': '00002030: No such Base DN: DC=10.168.192.in-addr.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,DC=xxx,DC=xxx', 'desc': 'No such object'}
01.06.2017 14:01:19,601 LDAP        (PROCESS): sync to ucs: Resync rejected dn: DC=7c330039-7852-423b-93d1-c9d7423ea12b,DC=_msdcs.xxx.xxx,CN=MicrosoftDNS,DC=ForestDnsZones,DC=xxx,DC=xxx
01.06.2017 14:01:19,606 LDAP        (PROCESS): sync to ucs:   [           dns] [    modify] relativeDomainName=7c330039-7852-423b-93d1-c9d7423ea12b._msdcs,zoneName=xxx.xxx,cn=dns,dc=xxx,dc=xxx
01.06.2017 14:01:19,607 LDAP        (ERROR  ): Unknown Exception during sync_to_ucs
01.06.2017 14:01:19,608 LDAP        (ERROR  ): Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 1497, in sync_to_ucs
    result = self.modify_in_ucs(property_type, object, module, position)
  File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 1280, in modify_in_ucs
    self.__set_values(property_type, object, ucs_object)
  File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 1187, in __set_values
    for attr_key in self.property[property_type].attributes.keys():
AttributeError: 'NoneType' object has no attribute 'keys'

Beste Grüße

Stefan Falge

Das scheint ja leider ein größeres Problem zu sein. Zur Fehlerbehebung würde ich diesen SDB-Artikel durcharbeiten.

Aber sofern möglich würde ich an deiner Stelle das fehlgeschlagene Upgrade analysieren und anschließend das Upgrade wiederholen.

Habe mich testweise für eine Reprovisionierung von Samba entschieden wie in diesem SDB beschrieben.

Danach waren die host-bezogenen rejects verschwunden und die Benutzer wurden von kinit erkannt, hatten jedoch abgelaufene Passwörter. Wie hier beschrieben mit

samba-tool domain passwordsettings set --max-pwd-age=0

die entsprechenden Domäneneinstellungen geändert und kinit lief wieder.

Jetzt tauchten allerdings in den rejects die Domänenbenutzer auf, das log verwies auf eine “unique index violation on objectSid” hin. Mit einem samba.tool dbcheck --fix konnte das zwar behoben werden (die Benutzer bekamen neue IDs), aber an den Berechtigungsfehlern im Netzwerk änderte das nichts…

Hier habe ich aufgehört, gerade spiele ich das Backup ein und werde das update neu angehen…

Danke nochmal für die schnelle Hilfe!!!

Mastodon