Extreme Anzahl DNS-Lookups mit Kopano und Problem beim inaktivem zweiten Domänenkontroller

Apps & App Center
#1

Hi,

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.

12:05:34.985691 IP kopano01.alf.local.49650 > adm-dc-2012.alf.local.domain: 47600+ SRV? _kerberos._udp.alf.local. (48)
12:05:34.985961 IP adm-dc-2012.alf.local.domain > kopano01.alf.local.49650: 47600* 2/0/2 SRV adm-dc0.alf.local.:88 0 100, SRV adm-dc-2012.alf.local.:88 0 100 (170)

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”

Hilf uns leider gar nicht :frowning:

Ich wäre über jede Hilfe dankbar.

Stefan.

#2

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

Eine Lösung die ich sehe wäre mit SSO für die WebApp zu arbeiten. In diesem Fall wird die SSO Session für die Anmeldung am Backend genutzt und muss nicht permanent ausgehandelt werden. SSO ginge z.B. mit OpenId Connect und Request for feedback: Script to setup SSO for Kopano WebApp (through OpenID Provider App).

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.

#3

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.

#4

Daher ja zukünftig Token basierte Authentifikation mittel OpenID Connect.

#5

OP hier: Nachtrag:

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      ---
Mastodon