Donnerstag, 17. September 2015

schannel Fehler durch fehlerhaften Java LDAPS Sync

Domaincontroller und Eventlogs...

Plötzlich tauchten auf einem Domaincontroller im System Eventlog etliche Schannel Errors auf.

Error 17.09.2015 09:04:15 Schannel 36887 None
A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code is 46.

Die Detailansicht gibt dann zusätzlich noch die Process- und Thread-ID aus. Anhand derer kann man mit dem Task Manager den Prozess ermitteln. In dem Fall war es lsass.exe. Also die Authentifizierungsschnittstelle des DC.

Laut http://blogs.msdn.com/b/kaushal/archive/2012/10/06/ssl-tls-alert-protocol-amp-the-alert-codes.aspx handelt es sich dabei um ein "Certificate unknown" Fehler.

Man würde erwarten, dass Windows auch das Quellsystem benennt, welches diesen Fehler erzeugt. Dem ist aber nicht so. Mehr als die oben beschriebenen Infos bekommt man nicht.

Wenn man nach "schannel log level" und ähnlichem googelt kommt man immer wieder auf den Punkt, dass man das Log Level im Eventlog erhöhen. Siehe https://support.microsoft.com/en-us/kb/260729. Allerdings bringt einen das hier nicht weiter, da die Fehlermeldung nicht detaillierter wird, sondern nur zusätzlich Warnungen und ggf. erfolgreiche TLS Handshakes gemeldet werden. Weiterhin kein Hinweis auf das Quellsystem.

Also Sysinternals procmon gestartet. Den Filter auf "Process Name" contains "lsass" und "Operation" auf "TCP Accept" gesetzt und gewartet.
Anhand des Logs und der zugehörigen Eventlog Einträge konnte ich das Quellsystem dann mühelos ermitteln.

Es handelte sich um Atlassian Confluence und ich hatte Tage zuvor ein Upgrade durchgeführt und bei diesem den Import des Root CA Zertifikates der Enterprise CA vergessen. Dadurch hat Confluence die ganze Zeit erfolglos versucht die Accounts abzugleichen.

Der Import erfolgt übrigens per keytool:

"c:\Program Files\Atlassian\Confluence\jre\bin\keytool.exe" -importcert -alias "RootCA_xxx Root CA"  -keystore "c:\Program Files\Atlassian\Confluence\jre\lib\security\cacerts" -file "\\server\RootCA_xxx Root CA.crt"

Dort dann "changeit" als Passwort und am Ende noch mal "yes" um das als Trusted zu markieren. Das muss man dann bei jedem Upgrade wiederholen.

Das Confluence selbst nutzt bei uns eine .pfx Datei um selbst per SSL erreichbar zu sein. Das merkt man dann eher wenn das nicht mehr funktioniert...

Aufgefallen war das erst nicht, da die Anmeldung selbst per ADFS Plugin erfolgt und es sich auch noch um das Testsystem handelt.

Wieder was gelernt...

Update:

Am Ende war es garnicht die cacerts sondern eine Änderung in der Java Runtime welche jetzt bei Confluence 5.8.10 mitgeliefert wird. Zum Glück viel mir dieser Bug schon bei Stash auf da ich dort schon die aktuellste Runtime nutzte.

https://jira.atlassian.com/browse/CONF-34975

Als Workarounf hilft hier "-Djdk.tls.trustNameService=true" als Java Startup Option dem Service hinzuzufügen.

Die Config für den Service ruft man folgendermaßen auf (der Name des Service kann sich unterscheiden und muss aus dem Serviceeintrag in services.msc ermittelt werden):

"c:\Program Files\Atlassian\Confluence\bin\tomcat8w.exe" //ES//Confluence060114171110