Archiv » Juni, 2013 «

29 | 06 | 2013

Server 2012/IIS8: Bei Root-Zertifikaten aufpassen!

Geschrieben von um 13:15 Uhr

Vor einiger Zeit musste ich innerhalb einer SCCM 2012-Installation einen Web Based Management Point einrichten. Enterprise PKI hatte der Kunde schon am Start, ein Paar Zertifikatsvorlagen udn Autoenrollment-Einstellungen mussten angepasst werden, das war aber nicht weiter wild. Nun mochte aber der Management Point, sobald man ihn auf HTTPS umstellen, sich nicht initialisieren.

Hintergrund: Der MP läuft im IIS. Nach der Grundinstallation versucht er – unter zertifikatsbasierter Authentifizierung – zum sich selbst zu verbinden und eine Liste der Management Points abzufragen. An dieser Stelle bereits loggte der IIS den Fehler 403.16 mit dem erweiterten Fehlercode 2148204809 (in hex 0x800b0109), was soviel bedeutet wie CERT_E_UNTRUSTEDROOT. Sowohl das Server- als auch das Client-Zertifikat sind von der gleichen Issuing CA ausgestellt, somit ist die RCA ebenfalls die gleiche, sie ist per GPO eingetragen, alle Test laufen ohne Beanstandungen durch – was ist also das Problem?

Nun, die Lösung war einfach, auch wenn die Ursache eher als „Bug“ denn als „Feature“ einzustufen ist. Im „Trusted Roots“ des Servers (wie auch jeder anderen Maschine in diesem AD, da die PKI-GPO ganz oben gelinkt ist) befand sich ein Zertifikat von Thawte, welches zwar für eine „Thawte Primary Root CA“ ausgestellt war, jedoch nicht von ihr selber signiert, sondern von einer „Thawte Primary Server CA“. Insofern ist diese Root CA genaugenommen keine Root CA, und das Zertifikat hätte woanders rein gemusst. Man sollte aber meinen, das betrifft uns nicht, da wir ja nur mit Zertifikaten aus der internen PKI hantieren. Bis IIS 7.5 würde das auch stimmen. IIS 8 hingegen verzeiht einem Derartiges nicht und legt das oben beschriebene Verhalten an den Tag. Dazu gibt es auch einen Fast Publish-Artikel: http://support.microsoft.com/kb/2802568.

Entdeckt wurde das Verhalten anscheinend im Zusammenhang mit Lync 2013. Welch Wunder 😉

Tags » , , , , , «

+

27 | 06 | 2013

Windows Cluster, iSCSI IQN und SCSI-3 Reservation

Geschrieben von um 11:05 Uhr

Bei der Validierung einer Windows Failover Cluster-Konfiguration (2 Knoten, EqualLogic SAN, Server 2012, Software-Initiator) kam die gefürchtete Fehlermeldung „SCSI-3 Permanent Reservation Error“. Da es speziell mit der EqualLogic auch in der Vergangenheit schon sehr anstrengend war, dieses Fehlerbild zu entstören, hatte ich mich moralisch schon auf eine lange Fehlersuche eingestellt. Zum Glück war das Problem in diesem Fall einfach gelagert:

Die beiden Clusterknoten hießen (geändert) sap-db-01-node1 und sap-db-01-node2. Bei der Generierung der iSCSI-IQNs hat anscheinend Server 2012 die Ziffer am Schluss abgeschnitten, womit die IQNs der beiden Knoten identisch waren! Da klappt es natürlich nicht mit dem Nachbarn 😉

Tags » , , , «

+