Probleme mit heimdal-kdc des OpenXchange6

UCS - Univention Corporate Server
,
#1

Hallo,

wir benutzen seit zwei Wochen den OX6 in Verbindung mit UCS.
Alle paar Tage tritt das Phänomen auf, dass alle Dienste, die sich gegen
UCS authentisieren müssen, dies nicht können. Es gibt timeouts.

Ein Neustart des heimdal.kdc bringt dann in Zusammenhang
mit “etwas probieren” in bspw. /etc/pam.d/imap Linderung, aber
das Problem besteht nach wie vor immer wieder und lässt sich
auch leider nicht weiter spezifizieren.

Das log /var/log/heimdal-kdc.log ist voll von Einträgen der Art:
011-10-13T16:39:51 Failed to verify AP-REQ: Ticket expired
2011-10-13T16:39:51 Failed parsing TGS-REQ from IPv4:9.9.9.9 (geändert - (IP vom OX6-Server))

Was können wir tun?

Vielen Dank und Gruß
Andreas Donath

#2

Hallo,

ohne etwas konkretere Informationen lässt sich hier nur schwer eine Aussage treffen, daher im folgenden einige Fragen:
[ul]
[li]Welche UCS-/OX-Version ist im Einsatz?[/li]
[li]Funktioniert Kerberos generell (z.B. “kinit” als Administrator)?[/li]
[li]Mit welchen Diensten gibt es Probleme und wie/wo äußern sich die Timeouts?[/li]
[li]Welche Änderungen haben Sie in der PAM-Konfiguration vorgenommen?[/li][/ul]

Mit freundlichen Grüßen
Janis Meybohm

#3

Hallo,

zu ihren Fragen:
Version: 6.20.0 Rev24 (2011-08-29 15:23:07)
Kerberos funktioniert, es können Tickets mit kinit erstellt werden
Dienste die Probleme haben: IMAPS/SMTPS - (somit indirekt auch Webmail)
Änderungen an den pam-Konfigs : keine - alles wurde wieder in den
Ursprungszustand zurück gesetzt. Man konnte nur beobachten, dass

  • nimmt man das pam_krb5 Module heraus - es “weiter geht”.
    Was natürlich nicht wirklich ein Option ist, sondern für uns nur eine
    Möglichkeit war, dass Problem näher einzugrenzen.

Wir sind in der Sache scheinbar aber etwas weiter gekommen.
Symptomatisch für die Situation ist, dass testsaslauth mit einem entsprechenden
Test-Accounts nicht funktionert:

testsaslauthd -u Test.User@my.domain.de -p GEHEIM

Bringt normaler Weise ein:

0: OK "Success."

In unserem Fall steht es einfach.
D.h. es sind alle Dienste betroffen, die saslauth verwenden.

In /etc/default/saslauthd haben wir jetzt folgenden Parameter geändert:

[code]# How many saslauthd processes should we run? (default: 5)

A value of 0 will fork a new process for each connection.

THREADS=0
[/code]
Seitdem ist das Problem nicht wieder aufgetreten.

Gruß
Andreas Donath

#4

Hallo,

dieses Verhalten ist vermutlich auf memory leaks im saslauthd zurück zu führen die u.U. zur Folge haben das einzelne Threads des saslauthd Beendet werden. Da dadurch weniger Anfragen parallel bearbeitet werden können, kommt es häufig zu Anmeldeproblemen.

Wir haben hierzu unter [bug]13358[/bug] einen Eintrag in unserem Bugtracking-System. Ab UCS 2.4-3 könne Sie die Anzahl der saslauthd Treads auch über die UCR-Variable “mail/saslauthd/threads” definieren.

Mit freundlichen Grüßen
Janis Meybohm

Mastodon