Selbstsignierte Zertifikate ohne Hostnamen und Windows 7/8

Hallo Leutz,

bei einem Kunden hatte ich heute ein interessantes, reproduzierbares Problem mit selbstsignierten Zertifikaten ohne Hostname mit lediglich dem Domaenennamen als Aufruf. Ich sollte bei einem Kunden einen ISA Server 2006 troubleshooten wo seit ueber einem Jahr Outlook Anywhere nicht mehr funktioniert. Der Kunde nutzt Exchange Active Sync so dass das Outlook Anywhere Problem nicht so relevant war.
Nachdem ich als erstes auf dem ISA Server die Konfiguration geprueft hatte und der Exchange Umgebung einen Health Check unterzogen hatte und keinen Fehler feststellen konnte schauten wir uns den Client an und der bekam den klassischen Mehrfach Prompt zur Kennworteingabe.
Wir prueften also als erstes das Zertifikat auf dem ISA Server. Das Zertifikat ist selbst signiert und ausgestellt lediglich auf einen Domaenennamen und nicht klassisch auf einen FQDN!. Erst mal ja kein Problem, da das self signed Zertifikat schon seit 2 Jahren im ISA Zertifikatspeicher liegt und Outlook Anywhere ja mal funktioniert hat. Der Client hatte das Zertifikat im Zertifikatspeicher der vertrauenswuerdigen Stammzertifizierungsstellen des lokalen Computers. Also alles prima – dachte ich 🙁
Wenn man die durch ISA Server veroeffentlichte Webseite im Browser aufruft kommt aber die Meldung, dass das Zertifikat nicht zu einer vertrauenswuerdigen Zertifizierungsstelle verifiziert werden kann. Wenn man im Zertifikatspeicher das Zertifikat auswaehlt ist der Trust aber validiert. Die Clients waren alle Windows 7 / 8 und auch mein Windows Server 2012 Notebook brachte die gleiche Fehlermeldung. Als Gegentest hatte ich dann die Idee Outlook Anywhere auf einem Windows XP Client zu testen und siehe da, kein Exchange und ISA Problem, Outlook Anywhere funktioniert einwandfrei!
Zusammenfassend das reproduzierbare Ergebnis:
Windows 7 / 8 / Server 2012:
Selbstsigniertes Zertifikat nur mit Domaenennamen – Untrusted
Selbstsigniertes Zertifikat mit FQDN – Trusted
Windows XP:
Selbstsigniertes Zertifikat nur mit Domaenennamen – Trusted
Selbstsigniertes Zertifikat mit FQDN – Trusted

Microsoft scheint also das Verhalten der Cryto API oder aktuellen IE Versionen geaendert zu haben, dass self signed Zertifikate mit nur einem Domaenennamen ohne FQDN nicht mehr als Trusted erkannt werden (was sicherlich auch kein alltaegliches Szenario ist) auch wenn sich das Zertifikat im korrekten Zertifikatspeicher befindet. Bei den gaengigen Suchmaschinen im Internet konnte ich noch nichts finden wie man das Problem loesen kann. Mein Kunde erstellt jetzt einen

Windows Server 2008 R2 CA Migration – Exchange 2010 CRL

Hallo Leutz,

bei einem Kunden habe ich diese Woche eine CA von einem Server auf einen anderen migriert. Im Rahmen der Migration wollten wir auch auf den Exchange Servern das Zertifikat erneuern (u. a. wegen des neuen CDP). Nach der Zertifikatanforderung erschien immer die Meldung in der Exchange Konsole dass der Sperrstatus nicht geprueft werden konnte. Trotz CRL Cache loeschen konnte der Sperrstatus nicht validiert werden, das PKI Health Utility auf der CA brachte keine Fehler. Schlussendlich war der Exchange Server Schuld (dank sei dem CAPI2 Logging). Wie das Problem geloest werden konnte steht in folgendem Bilderbuch:
http://www.it-training-grote.de/download/CA-Migrate-Exchange-CRL.pdf

Gruss Marc

Exchange 2013 Fehlermeldung: „Database is mandatory on UserMailbox“

Hallo Leutz,

der Titel des Blogposting ist Programm. Vor einigen Monaten habe ich in meiner Windows Server 2012 Umgebung Exchange 2013 Beta installiert. Seit einigen Wochen ist Exchange 2013 RTM und ich installierte bei RTM-Veroeffentlichung meinen ersten Exchange 2013 RTM Server. Vorher deinstallierte ich den Exchange Server 2013 Beta. Bei der Installation gab es keine Probleme.
Letztes Wochenende entschied ich mich noch einen weiteren Exchange Server 2013 RTM zu installieren. Die Installation der Mailbox-Rolle schlug zuerst fehl, aber duch die bekannten “Probleme” mit falschen HomeMTA und HomeMDB Attributen fuer die System (Arbitration) Mailboxen konnte ich schliesslich Exchange 2013 installieren. Nach der Installation konnte ich mit der Powershell und EAC aber keinen Benutzer editieren, auch neuangelegte Exchange Empfaenger brachten die Meldung „Database is mandatory on UserMailbox“. Typische Aussagen im Internet sind das die System Mailboxen (Federated-E-Mail, System Mailbox etc.) ein fehlendes / falsche HomeMDB / HomeMTA Attribut besitzen:
http://support.microsoft.com/kb/978776/en-us
Alle Tipps die Systemmailboxen zu deaktivieren, zu loeschen, erneut zu aktivieren oder Setup / Adprep oder / Domainprep auszufuehren oder ADSIEDIT zu verwenden fuehrten zu keiner Verbesserung. Ich erstellte alle Systemmailboxen neu (auch die neuen in Exchange 2013 wie die Migration oder Health Mailbox).?

Nach stundelangen abendlichen Recherchen gab ich die Suche erst mal auf bis ich heute Abend durch Zufall mal wieder mit ADSIEDIT auf Spurensuche war und in der AD Domaenen-Partition im AD Objekte mit dem Namen PF01 – PF4 gefunden habe und da war mir klar, dass die Probleme von einer dieser Mailboxen stammen musste. Exchange Server 2013 fuehrt ein neues Konzept fuer die Public Folder ein, bei der die PF nicht mehr in einer PF-DB liegen sondern in PF-Postfaechern:
http://technet.microsoft.com/en-us/library/jj552408.aspx
Die komplette Problemdarstellung und Problemloesung steht in fogendem Bilderbuch: http://www.it-training-grote.de/download/Exchange-2013-MBX-error.pdf

Gruss Marc

Windows 7/8 RDP 8.0 und Forefront UAG

Hallo Leutz,

RDP 8.0 in Windows 8 / 2012 funktioniert derzeit noch nicht mit den RDP/RDG/RemoteApp-Publishing-Moeglichkeiten von Forefront UAG, da Microsoft einige Aenderungen in das RDP-Protokoll eingebaut hat, welche Forefront UAG noch nicht verstehen kann. Microsoft arbeitet an einem zukuenftigen Service Pack fuer UAG, der Veroeffentlichungstermin ist aber noch nicht bekannt.
Aufpassen muss man auch wenn man das Update http://support.microsoft.com/kb/2592687 einspielt. Dieses Update bringt RDP 8.0 fuer Windows 7 SP1 und Windows Server 2008 R2 SP1. Nach Einspielen des Hotfix ist dann auch kein RDP Zugriff durch gepublishte Applikationen ueber Forefront UAG moeglich:
http://blogs.technet.com/b/ben/archive/2012/11/20/remote-desktop-publishing-on-uag-fails-to-work-on-windows-7-clients-following-an-update-in-november-2012.aspx

Gruss Marc

Forefront UAG Session Manager Service terminated unexceptedly

Hallo Leutz,

bei einem Kunden hatte ich heute das Problem, dass auf einem Forefront UAG Server in einem UAG-Array der Forefront UAG Session Manager Dienst nach der Installation von UAG Service Pack 2 nicht mehr starten wollte. Nach laengerer Recherche stellten wir fest, dass andere Dienste / Applikationen den Default Port 6001 / 6002 blockten. Wie wir das Problem loesen konnten steht in folgendem Bilderbuch:
http://www.it-training-grote.de/download/UAG-SessionManager-Service.pdf

Gruss Marc

Important changes to Forefront Product Roadmaps – Teil III – Laengeres Leben fuer TMG?

Hallo Leutz,

nach der Abkuendigung von Forefront TMG durch Microsoft:
http://www.it-training-grote.de/blog/?p=5434
hat die Firma SecureGUARD angekuendigt, dem Produkt noch einen laengeren Lebenszyklus einzuhauchen:
http://www.it-training-grote.de/blog/?p=5452
Seit dem 13.11.2012 hat auch die Firma Celestix angekuendigt ihre MSA Appliances mit Forefront TMG bis 2023 verfuegbar zu machen:
http://www.celestix.com/celestix_announces_tmg_availability.html. Den Vertrieb in Europa uebernimmt wie immer die Firma Wick Hill (http://www.wickhill.de)

Gruss Marc