WAP und Wildfly und JSESSIONID

Ein Windows Server 2012 R2 als WAP vor einem Wildfly.
Jeder erste Request einer Seite führte zu fehlerhaften Bildern.

Stellte sich heraus, beim ersten Aufruf setzt der Wildfly einen Session Cookie "JSESSIONID".

Im Response dieser ersten Seite werden die URLs auf Objekte aber auch mit der SessionID in der URL versehen.

Sieht dann so aus <img src="/irgendeinbild.jpg;JSESSIONID=lkdfksadhfhui34h">.
Das geht ohne WAP super. Das geht auch mit IIS und ARR super.

Stellt sich heraus ein Bug beim Encoding.

Scheint auch nicht nur Java Appserver zu treffen sondern Outlook Web Apps.

https://support.microsoft.com/en-us/kb/3042127

Der Hotfix soll auch das JSESSIONID Problem beheben.

Siehe auch: https://social.technet.microsoft.com/Forums/windowsserver/en-US/108a3fe5-be53-40b3-a3a8-f37263987755/web-application-proxy-and-urlencode-problem-with-repsonse-from-appliation?forum=winserver8gen


Da der Browser selbst nach dem ersten Request den Session Cookie an den Server sendet wird beim wiederholten Request auch auf den Session Cookie in der URL verzichtet (außer der Browser hat Cookies aus...).

HP Pavilion x2 Probleme bei Reinstallation Windows 10 Enterprise

Für ein Projekt benötigten wir ein kleines Tablet mit der Möglichkeit dieses in die Domain zu integrieren.

Die HP Produktseite beschreibt das Gerät mit "Windows 10 Home Edition 64 bit". Das ist jedoch falsch. Installiert ist 32 Bit.

Der Versuch ein 64 Bit Betriebssystem zu installieren scheitert dann auch zusätzlich weil das UEFI Bios auch nur 32 Bit ist.

Damit blieb nur das Erstellen eines UEFI USB Installationsmedium mit "Windows 10 Enterprise 32 Bit". Das funktionierte dann auch problemlos.

Fast alle Treiber fanden sich beim Hersteller unter der entsprechenden Produktseite.
Es fehlte jedoch noch ein "Bosch Multisensor" Treiber. Diesen fand man dann bei älteren Pavilion Geräten als "Bosch Multisensor Driver - sp71466.exe" für Windows 8.1 32 Bit. Dieser funktioniert ebenfalls.

Jetzt konnte der Kiosk Mode in Windows 10 mit klassischer Shell genutzt werden (benötigt Windows 10 Enterprise) https://technet.microsoft.com/de-de/library/mt219051(v=vs.85).aspx um die Nutzung auf eine Anwendung zu beschränken.

IIS ARR and WAP on the same 2012 R2 server

http redirect should be in WAP on Windows Server 2016. But what until then?

I did not see any official statement about running ARR with IIS and WAP on the same 2012 R2 server, so I just tried and it seems to work fine.

I use the IIS only for http redirect and WAP for https.

And I use the IIS for some http -> https redirects. That was another thing I missed in the WAP.
For this you only need the IIS role and "HTTP Redirect" feature. The redirected request does to the WAP and will be forwarded to the internal server.

Just installed the IIS Role and got the ARR Components from:

http://www.iis.net/downloads/microsoft/application-request-routing

http://www.iis.net/downloads/microsoft/url-rewrite

Manual x64 downloads at the bottom.

When creating a Server farm, you still see the https destination Port, but if you didn't create a https Binding in IIS it will not be used.

As far I did not see any problems with that.

With Powersehll "Get-Webbinding" you could see what Bindings you have in the IIS.

With "netsh http show sslcert" you see the SSL Cert Bindings (from WAP and/or IIS).

Keep in mind that WAP and IIS use the same http.sys kernelmode service.

KB3046017 konnte nicht installiert werden "Path not found"

Auf einem Windows Server 2012 R2 Terminalserver konnte das KB3046017 nicht installiert werden.

Fehlerbeschreibung:

Installation Failure: Windows failed to install the following update with error 0x80070003: Security Update for Windows (KB3046017).

Hinter der Fehlernummer steckt "Path not found". Mit Procmon kam ich nicht weiter, da dort zu viel geloggt wurde.

Ein "SFC /Scannow" fand korrupte Dateien und reparierte sie:

2015-10-27 10:42:26, Info                  CSI    00000970 [SR] Verify complete

2015-10-27 10:42:26, Info                  CSI    00000971 [SR] Repairing 8 components

2015-10-27 10:42:26, Info                  CSI    00000972 [SR] Beginning Verify and Repair transaction

2015-10-27 10:42:27, Info                  CSI    00000973 [SR] Repairing corrupted file [ml:520{260},l:154{77}]"\??\d:\Users\Default\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch"\[l:36{18}]"Server Manager.lnk" from store

2015-10-27 10:42:27, Info                  CSI    00000974 [SR] Repairing corrupted file [ml:520{260},l:154{77}]"\??\d:\Users\Default\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch"\[l:34{17}]"Control Panel.lnk" from store

usw.

Es stellte sich heraus, dass die Umstellung des Profilpfades für neue Profile von c:\ nach d:\ zu dem Problem führte. Direkt nach dem Durchlauf von "sfc /scannow" konnte das Update installiert werden.

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

HP SSM und fehlende Silent Installation von Intel Treibern

Wir nutzen HP SSM zur Nachinstallation von gerätespezifischen Treibern für unsere HP Elitebooks.
Nachdem eine neue Generation (850 G2) bestellt wurde, kam es bei der unbeaufsichtigten Installation zu Meldungen.

"Intel Multiple Package Installation Tool" meldete, dass es den jeweiligen Treiber erfolgreich installiert hat.

Betroffen waren die SP:

sp69959.exe "Intel 7260_3160 Wireless LAN Driver"
sp69976.exe "Intel Bluetooth driver"

Nach einiger Analyse stellte sich durch die Nutzung von Sysinternals "Process Explorer" heraus, dass beim Kommandozeilenaufruf, welcher an den Installer übergeben wurde, der letzte Buchstaben verloren geht.

Betroffen war die Version 3.2.2.1 unter Windows 8.1. Eine älter Version 3.0.6.1 zeigte das Verhalten nicht.

Workaround 1: Ältere SSM Version nutzen

Workaround 2: Die jeweilige .cva anpassen:

Den Eintrage:

SilentInstall="InstMultiPkg.exe" /silent

durch

SilentInstall="InstMultiPkg.exe /silent"

ersetzen.

Interessanterweise wird das dann nicht so aufgerufen sondern am Ende kommt beim Installer die Kommandozeile an:

"InstMultiPkg.exe" /silent

Aber wenigstens fehlt dann das "t" am Ende nicht mehr.

Schön dass solche Hersteller noch Aufwand in die QA stecken...

LDAPS Anmeldeprobleme nach Upgrade JRE auf 1.8u51

Beim Upgrade einer Atlassian Stash Testumgebung auf 3.11.1 habe ich gleichzeitig die benötigte JRE von 1.8u25 auf 1.8u51 aktualisiert.

Stash ist mit Active-Directory Anbindung auf SSL eingerichtet. Damit prüft das darunter liegende Java die Zertifikate der Domain Controller. Hierzu wurde das Root CA Zertifikat der Enterprise-PKI in den cacerts Store der JRE importiert.

Das funktionierte bei 1.8u25 problemlos.

Jetzt kam aber folgende Fehlermeldung:

"The remote authentication server is not available. Please try again later."

Logmeldung:

Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names matching IP address 192.168.0.1 found

Nach https://www.java.com/de/download/faq/release_changes.xml wurde ein Reverselookup bei der Zertifikatsprüfung entfernt. 

In Stash selbst ist der Hostname und keine IP konfiguriert.

Trotzdem scheint es bei der Übergabe des Hostnamens auf die weiter unten liegenden Module zwischendurch eine Namensauflösung zu geben. Damit scheint die Funktion, die am Ende prüft ob der Hostname mit dem Zertifikat übereinstimmt, diesen Hostnamen nicht zu haben und bis u51 einen Backresolve im DNS zu machen.

Mit "-Djdk.tls.trustNameService=true" kann man das Verhalten vor u51 wiederhestellen. Damit geht dann die Anmeldung.

Sauber erscheint mir das Vorgehen trotzdem nicht. Muss wohl jemand mal die Funktionen in der Kette überarbeiten.