UCS AD Connector Probleme

bitbone_support1 · November 3, 2016, 10:42am

Hallo,

wir haben einen Kunden, bei dem zum Test eine UCS in der Core Edition installiert wurde.

Connection zum AD hat auch wunderbar funktioniert. Leider funktioniert die Verbindung aber seit dem 11.10 nicht mehr laut Logs, was aber erst letzte Woche auffiel (da es ein Testsystem ist)
Laut Kunden fanden keinerlei Änderungen an der Firewall oder dem AD statt; Windows Updates wurden auch nicht eingespielt.

Im connector.log erschien zu dem Zeitpunkt zu dem es nicht mehr funktioniert hat folgende Meldung

11.10.2016 08:25:40,93 LDAP        (WARNING): Exception during search_ad_changes
11.10.2016 08:25:40,93 LDAP        (WARNING): Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.7/univention/connector/ad/__init__.py", line 2154, in poll
    changes = self.__search_ad_changes(show_deleted=show_deleted)
  File "/usr/lib/pymodules/python2.7/univention/connector/ad/__init__.py", line 1157, in __search_ad_changes
    returnObjects = search_ad_changes_by_attribute( 'uSNCreated', lastUSN+1 )
  File "/usr/lib/pymodules/python2.7/univention/connector/ad/__init__.py", line 1147, in search_ad_changes_by_attribute
    return self.__search_ad( filter=usnFilter, show_deleted=show_deleted)
  File "/usr/lib/pymodules/python2.7/univention/connector/ad/__init__.py", line 1104, in __search_ad
    rtype, rdata, rmsgid, serverctrls = self.lo_ad.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)
UNAVAILABLE: {'desc': 'Server is unavailable'}

Und danach kamen nur noch diese Meldungen:

11.10.2016 08:25:50,116 MAIN        (------ ): DEBUG_INIT
11.10.2016 08:25:50,139 LDAP        (ERROR  ): Failed to lookup AD LDAP base, using UCR value.

Zudem erscheinen im connector-status.log erscheint seitdem auch folgende Meldung:

Thu Nov  3 10:02:06 2016
 --- connect failed, failure was: ---

Traceback (most recent call last):
  File "/usr/share/pyshared/univention/connector/ad/main.py", line 290, in main
    connect()
  File "/usr/share/pyshared/univention/connector/ad/main.py", line 184, in connect
    baseConfig['%s/ad/listener/dir' % CONFIGBASENAME])
  File "/usr/lib/pymodules/python2.7/univention/connector/ad/__init__.py", line 696, in __init__
    self.open_ad()
  File "/usr/lib/pymodules/python2.7/univention/connector/ad/__init__.py", line 887, in open_ad
    self.get_kerberos_ticket()
  File "/usr/lib/pymodules/python2.7/univention/connector/ad/__init__.py", line 866, in get_kerberos_ticket
    raise kerberosAuthenticationFailed('The following command failed: "%s"' % string.join(cmd_block))
kerberosAuthenticationFailed: The following command failed: "kinit --no-addresses --password-file=/etc/machine.secret ucs-01$"

 ---     retry in 30 seconds      ---

Irgendwelche Ideen zur Lösung?
Neustarts usw blieben bislang ohne Erfolg. Zudem wurde auch schon getestet, hier die Zugangsdaten vom Admin für das kinit zu konfigurieren (auch ohne Erfolg)
Führt man den kinit aus, erscheint immer “kinit: Password incorrect” (auch mit Admin User ist dies erschienen)

Moritz_Bunkus · November 3, 2016, 12:38pm

Moin,

dass sich nichts geändert hat, das kann eigentlich nicht sein Sonst würde es ja noch gehen.

Testen Sie zuerst, ob die Konfiguration des AD-Connectors noch stimmig ist. Dazu führen Sie einfach »univention-adsearch« aus. Dieser nimmt die vorhandenen Konfigurationseinstellungen und führt damit ein »ldapsearch« gegen den AD-Server aus.

Wenn hier keine Verbindung zustande kommt, so schauen Sie sich als nächstes die Konfiguration des AD-Connectors an. Diese ist in UCR-Variablen abgelegt. Die Variablen können Sie sich mit dem folgenden Befehl anzeigen lassen:

ucr search --brief connector/ad

Testen Sie weiterhin, ob die DNS-Auflösung auf dem UCS-Server funktioniert. Der in den erwähnten UCR-Variablen hinterlegte Servername muss auf dem UCS-Server auflösbar sein. Das testen Sie mit dem folgenden Befehl:

host $(ucr get connector/ad/ldap/host)

Gruß,
mosu

bitbone_support1 · November 9, 2016, 10:19am

Hallo,

danke für die schnelle Antwort.
Die Ausgaben der Befehle scheinen noch immer valide.

Ich habe aber mittlerweile nach weiterer Rücksprache mit dem Kunden die Info erhalten, das scheinbar doch Windows Updates auf den Domain Controllern eingespielt wurden.

Irgendwelche Ideen, was sich hier durch Windows Updates geändert haben könnte, das die Verbindung fehlschlägt?

Im Security Log auf dem DC erhält der Kunde seitdem auch die abgelehnten Anfragen geloggt mit den folgenden Infos:
Ticketoptionen 0x40000000
Fehlercode 0x18
Typ vor der Authentifizierung 2

Moritz_Bunkus · November 9, 2016, 10:30am

Moin,

das ist ein Kerberos-Fehler. Bitte stellen Sie sicher, dass die Uhrzeit auf den AD- und UCS-Servern übereinstimmt.

Gruß,
mosu

bitbone_support1 · November 9, 2016, 10:35am

Hallo,

Zeit passt auch bis auf Millisekunden

offset -0.234130 sec

Moritz_Bunkus · November 9, 2016, 10:49am

Ist der Account im AD inzwischen evtl. gesperrt?

bitbone_support1 · November 9, 2016, 11:18am

Das würde ich persönlich ausschließen, da wir den kinit auch mit dem aktiven Administratoren Account probiert haben und hier auf die gleichen Probleme gestoßen sind.
Ich habe aber gerade nachgefragt und warte auf die aktuelle Antwort (handelt sich aber hierbei um ein Computerkonto, da die ucs sich hierfür selbst eines zur Authentifizierung anlegt)

bitbone_support1 · November 9, 2016, 1:46pm

Ich habe mittlerweile eine Rückmeldung des Kunden
Das Konto ist definitiv nicht gesperrt

Sonst noch irgendwelche Ideen?

Moritz_Bunkus · November 9, 2016, 1:58pm

Nein, tut mir leid. Das Googlen nach der von Ihnen erwähnten Windows-Fehlermeldung liefert zwar diverse Problemfälle, aber da können bzw. sollten Sie selber mal Googlen und schauen, welche davon evtl. zutreffen könnten. Die typischen wären Uhrzeit & Kontosperrung.

bitbone_support1 · November 9, 2016, 2:01pm

Einiges davon habe ich selbst schon probiert.
Meine Vermutung ist mittlerweile, das sich evtl das Maschinen Konto resettet hat (oder es wurde resettet)
Kann man die Domain Verbindung nochmal “von vorne starten”?
Denn ich wüsste nicht auf Anhieb, wie ich das aktuelle Passwort des Maschinen Kontos so herausfinden könnte

Moritz_Bunkus · November 9, 2016, 2:51pm

Muss das Konto evtl. sein Passwort ändern (z.B. Richtlinie alle X Tage Passwortänderung)? Passwort abgelaufen?

Setzen Sie’s doch einfach Windows-seitig neu. Was Sie anschließend UCS-seitig machen müssen, ist in der Admin-Doku beschrieben.

Gruß,
mosu

cpzengel · February 14, 2021, 9:24am

Danke für den Hinweis.
Habe hier einen Domain Member UCS der an einenm DC UCS hängt

Das System verliert alle paar Tage wohl das Kennwort oder läuft ab.
Wenn ich das machine.secret vom Member wieder ins Konto auf dem DC eintrage gehts wieder.

Wie kann ich das verhindern?

Das Zurücksetzen der Passwörter durch die Passwort-Gruppe kann für sensible Benutzer oder Gruppen (z.B. Domänen-Administratoren) verhindert werden. Mit den Univention Configuration Registry-Variablen ldap/acl/user/passwordreset/protected/uid undldap/acl/user/passwordreset/protected/gid können Benutzer und Gruppen konfiguriert werden. Mehrere Werte müssen durch Kommas getrennt werden. Nach Änderungen an den Variable ist es erforderlich, den LDAP-Server über den Befehl /etc/init.d/slapd restart neu zu starten. In der Standardeinstellung werden die Mitglieder der Gruppe Domain Admins vor Passwortänderungen geschützt.

geht das auch für Computerkonten?

Liebe Grüsse
c