wir nutzen UCS/Kopano mit der WebApp und einer Anbindung an ein Microsoft AD. Wir beobachten hier eine extrem hohe Anzahl von SRV-DNS-Anfragen und eine extrem hohe Anzahl von Kerberos-Verkehr.
Wir haben ~ 100 Benutzer und sehen ~ in einer Minute,
~ 2.500 DNS Lookups und ~ 2.500 Kerberos-Requests.
Ist jetzt jedoch ein Kerberos-Server nicht erreichbar, läuft unser Kopano in ständige Timeouts und ist nahezu unbenutzbar.
Kerberos scheint hier zwar timeouts zu kennen ( kdc_timeout, max_retries), bei der extrem hohen Anzahl, läuft man aber scheinbar in ~ 10 Timeouts in Folge, bis ein Request abgeschlossen ist.
Wie könnte man das umgehen?
Dass bei mehreren DCs, einmal einer nicht erreichbar ist, ist gängige Praxis. Aufgrund der hohen Requests, ist dies für Kopano aber fatal.
Eine Anfrage an den Support blieb erfolglos (KS-46820: Million of DNS lookups)
O-Ton-Kopano: “In general, Kopano sends out a lot of queries to the LDAP server to check for authentications and[sic] permissions”
Dazu sollte man sagen dass das obige Zitat aus der ersten Antwort auf das Ticket entnommen wurde und im weiteren Ticketverlauf noch andere Empfehlungen gemacht wurden.
Das Problem ist generell folgendes:
Univention ist Teil einer Windows Domäne und hat dadurch selbst keinen Zugriff auf Passwörter
Wenn sich also jetzt ein User am Univention LDAP anmeldet wird im Hintergrund eine Anmeldung per Kerberos gemacht um zu verifizieren ob die an Kopano übergebenen Credentials korrekt sind (vereinfacht gesprochen)
Wenn ein Nutzer in der Kopano WebApp arbeitet, dann ist jede Interaktion zwischen WebApp und kopano-server eine neue Session, muss also einen Bind am Univention LDAP machen
Ich kann mich auch dunkel daran erinnern dass die Univention Kollegen noch eine andere Lösung bezüglich des Kerberos Auth hatten, diese fällt mir aber spontan nicht ein.
Danke für die schnelle Antwort. Die generelle Frage ist, wieso das Design so ist, dass jeder Klick eine neue Session erfordert. Jetzt haben wir hier nur 100 Testuser. Es gibt vermutlich deutlich größere Installationen. Der Overhead dahinter ist enorm (DNS-Lookups für jeden Request, Kerberos/LDAP-Requests für jeden Klick).
Für das zweite Problem, wenn ein DC nicht erreichbar ist, haben wir jetzt selbst einen unschönen Workaround gefunden:
Ein statischer host-Eintrag, der den nicht verfügbaren DC, auf den verfügbaren DC mapped.
Der statische Host-Eintrag war eine schlechte Idee, dadurch ging der AD-Connector nicht mehr.
Somit wieder mit ‘unset’ entfernt.
Fehlermeldung für die Nachwelt:
failure was: ---
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/univention/connector/ad/main.py", line 302, in main
connect()
File "/usr/lib/python2.7/dist-packages/univention/connector/ad/main.py", line 190, in connect
baseConfig['%s/ad/listener/dir' % CONFIGBASENAME]
File "/usr/lib/python2.7/dist-packages/univention/connector/ad/__init__.py", line 863, in __init__
self.open_ad()
File "/usr/lib/python2.7/dist-packages/univention/connector/ad/__init__.py", line 1138, in open_ad
self.lo_ad.lo.sasl_interactive_bind_s("", auth)
File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 962, in sasl_interactive_bind_s
res = self._apply_method_s(SimpleLDAPObject.sasl_interactive_bind_s,*args,**kwargs)
File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 931, in _apply_method_s
return func(self,*args,**kwargs)
File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 244, in sasl_interactive_bind_s
return self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls),sasl_flags)
File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 106, in _ldap_call
result = func(*args,**kwargs)
LOCAL_ERROR: {'info': 'SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Unknown error -1765328377)', 'desc': 'Local error'}
--- retry in 30 seconds ---
