Hallo Leutz,
bei einem Kunden mit einem SCVMM 2012 erscheinen bei verschiedenen SCVMM Aktionen (P2V, ISO Mount) WINRM und BITS-Fehlermeldungen, welche auf falsche Zertifikate hin deuten. Wie man den Fehler beheben kann steht in diesem Bilderbuch:
http://www.it-training-grote.de/download/SCVMM-2012-WINRM-BITS.pdf
Gruss Marc
Hallo Leutz,
das Backup einer Enterprise SubCA mit der Backup GUI der CA-Verwaltungskonsole oder Certutil schlaegt fehl mit der Meldung “ungueltiger Algorithmus angegeben”. Grund ist eine falsche/fehlende Zuordnung des Microsoft Software Crpyto Provider zu dem SubCA Zertifikat im lokalen Crypto Store. Wie man diesen Fehler beheben kann steht in folgendem Bilderbuch:
http://www.it-training-grote.de/download/Windows-CA-Backup-Error.pdf
Gruss Marc
Hallo Leutz,
standardmaessig stellt eine CA fuer fast alle Zertifikatanfragen Zertifikate automatisch aus (Ausnahme zum Bsp. KRA Template). Wie man die CA oder Certificate Templates so konfigurieren kann das eine CA Manager Genehmigung erforderlich ist und wie man dann Zertifikate anfordern kann steht in diesem Bilderbuch:
http://www.it-training-grote.de/download/CA-Cert-request.pdf
Gruss Marc
Hallo Leutz,
bei einem Kunden bin ich diese Woche dabei eine zweistufige PKI Hierarchie mit einer Offline Root CA und einer Enterprise Subordinate CA einzurichten. Bei dem heutigen Versuch Certificate Templates fuer EV-Zertifikate (http://www.it-training-grote.de/blog/?p=5190) ausgestellt von der SubCA zu konfigurieren schlug fehl. Schuld war eine fehlende CAPOLICY.INF auf der SubCA und der Tatsache das eine SubCA zwar zum Ausstellen von “Allen Anwendungsrichtlinien” aber nicht zur Ausstellung von “Allen Ausgegebenen Richtlinien” konfiguriert ist. Wie man der SubCA beibringen kann auch bestimmte oder alle Issurance Policies zu akzeptieren steht in diesem Bilderbuch:
http://www.it-training-grote.de/download/Issuance-Policies-SubCA.pdf
Gruss Marc
Hallo Leutz,
eine kleine wichtige Information zu Forefront UAG NLB Arrays bei der Verwendung von Software/Hardware welche eine MAC Adress Authentifizierung / -Suche im LAN durchfuehrt und nur erlaubten MAC-Adressen Zugang zum LAN erteilt:
Bei einem Kunden bin ich diese Woche dabei ein Forefront UAG NLB Array einzurichten und bei der Aktivierung des NLB-Array im Unicast Modus hatten wir massive Probleme das NLB-”Cluster” zum Laufen zu bringen. Die Admins hatten zwar in der ARP Guard (das Produkt) Konfiguration die Unicast MAC Adresse der Clusterknoten als erlaubte MAC-Adressen hinterlegt aber irgendwie hat das nicht funktioniert, da ARP Guard immer noch die MAC-Adresse als Intrusion erkannt hat. Wir vermuten das das Problem dadurch ausgeloest wurde das die Unicast MAC-Adresse ja an allen vier Switch Ports der internen LAN-Adapter auftaucht und ARP Guard dieses als Bedrohung erkannt hat. Eine Umstellung auf Multicast NLB war aufgrund der Switch-Einschraenkungen nicht moeglich. Die Loesung des Problems war dann ganz einfach an alle Switch-Ports wo die UAG Array Member angeschlossen waren den ARP Guard zu deaktivieren und anschlissend funktioniert auch das Windows NLB in Verbindung mit Forefront UAG
Gruss Marc
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
Hallo Leutz,
das neue Unified Remote Access 2012 Buch von Erez Ben-Ari ist veroeffentlicht worden:
http://blogs.technet.com/b/ben/archive/2012/12/27/the-new-book-about-unified-remote-access-2012-is-finally-out.aspx
Hier kann man es kaufen:
http://www.packtpub.com/windows-server-2012-unified-remote-access-planning-and-deployment/book
Es beschaeftigt sich mit den neuen Direct Access Funktionen von Windows Server 2012 und ist was ich bisher gelesen habe eine Bereicherung fuer jeden der sich mit dem Direct Access Nachfolger von Forefront UAG beschaeftigen will:
http://www.it-training-grote.de/download/Windows8-DirectAccess.pdf
Gruss Marc
Hallo Leutz,
fuer die Januar 2013 Ausgabe der Print Ausgabe des IT Administrator habe ich einen Artikel zum Thema Client Security mit Bordmitteln in Windows 8 geschrieben. Weitere Informationen findet man hier: http://www.it-administrator.de
Gruss Marc
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
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