Hallo Leutz,
am Wochenende hatte ich im Rahmen eines ASWE mit meinem Freund und Kollegen Holger Voges die Gelegenheit, ein NVGRE Gateway mit Hyper-V 2012 R2 und SCVMM 2012 R2 einzurichten.
Orientiert haben wir uns an der sehr guten Anleitung: http://gallery.technet.microsoft.com/Hybrid-Cloud-with-NVGRE-aa6e1e9a
Daraus ist dann folgendes Bilderbuch entstanden:http://www.it-training-grote.de/download/NVGRE-SCVMM2012R2.pdf
Gruss Marc
Hallo Leutz,
im Rahmen einer Exchange 2007 zu 2013 Migration mussten wir den Forefront TMG Server anpassen, dass Outlook Web Access Benutzer sowohl auf Exchange 2007 als auch Exchange 2013 Mailboxen zugreifen koennen.
Dazu wurden in der Exchange Server Umgebung die entsprechenden internen/externen URL / SCP angepasst.
Nach der Anpassung hatten OWA User aus dem Internet aber das Problem, dass ein Exchange 2007 User nicht korrekt ueber die Legacy URL redirected wurde und sich in einer Endlosschleife befand. Im Forefront TMG kam die Meldung “302 Moved Temporarily”.
Wie man das Problem loesen kann, steht in diesem Bilderbuch:
http://www.it-training-grote.de/download/EX2013-Migration-LegacyURL-TMG.pdf
Gruss Marc
Hallo Leutz,
bei einem Kunden wurden fuer die Exchange Server Zertifikate von Entrust verwendet. Seit einigen Tagen haeufen sich bei diversen Clients die Fehlermeldungen, dass die Outlook Web App Seite nicht mehr per HTTPS erreicht werden kann. Es erscheint die Meldung “Die Webseite kann nicht angezeigt werden”, welche auf den ersten Blick vermuten laesst, der IIS stellt kein Socket mehr auf Port 443 zur Verfuegung, was aber nicht der Fall ist, da das Problem nur an vereinzelten Clients auftaucht. Nach einiger Recherchen habe ich festgestellt, dass Entrust (Comodo) die Ausstellung von RSA Schluesseln kleiner als 2.048 Bit fuer eigene Zertifizierungsstellen (Root und Intermediate) gesperrt hat. Wie man die Ursache des Problems ermitteln und eine Loesung schaffen kann, steht in folgendem Bilderbuch:
http://www.it-training-grote.de/download/Entrust-RootCA.pdf
Gruss Marc
Hallo Leutz,
Bei einem Kunden wurden Sharepoint Server 2013 implementiert und spezielle Applikationen eingerichtet, welche die anspruchsbasierte (Claims based Authentication) verwenden. Die Administratoren haben festgestellt, dass man in der Sharepoint Applikation nur Benutzer, aber keine Benutzergruppen berechtigen kann. Wenn statt Benutzer eine Benutzergruppe verwendet wird, erscheint eine Fehlermeldung, dass die entsprechende Anwendung / Funktion nicht aufgerufen werden kann. Ursache fuer das Problem sind neue SID in Windows Server 2012 Domaenen Controller Anmeldetoken mit denen die Sharepoint Applikation nicht klar kommt.
Wie wir das Problem geloest haben, steht in folgendem Bilderbuch:
http://www.it-training-grote.de/download/Sharepoint-2013-Group-SID.pdf
Gruss Marc
Hallo Leutz,
das folgende Bilderbuch zeigt die Konfiguration des Work Folder Features in WS 2012 R2 mit einem Windows 8.1 Client:
http://www.it-training-grote.de/download/WorkFolders-WS2012R2.pdf
Gruss Marc
Hallo Leutz,
das folgende Bilderbuch zeigt das OWA Publishing von Exchange Server 2013 mit dem Web Application Proxy in WS 2012 R2 mit ADFS Preauthentication:
http://www.it-training-grote.de/download/WebApplicationProxy-EX2013.pdf
Gruss Marc
Hallo Leutz,
nach Teil I-III:
http://www.it-training-grote.de/blog/?p=5434
http://www.it-training-grote.de/blog/?p=5452
http://www.it-training-grote.de/blog/?p=5628
http://blog.forefront-tmg.de/?p=1076
jetzt eine weitere Ankuendigung:
http://www.sophos.com/de-de/products/unified/utm/tmg-replacement.aspx
Gruss Marc
Hallo Leutz,
der System Center 2012 R2 Endpoint Protection Client (SCEP) laeuft auch auf Windows Server 2012 R2. Bisher konnte ich den Client auf zahlreichen Systemen ohne Probleme installieren. Nur auf einem Server kam die Meldung: “System Center Endpoint Protection cannot be installed on your operating system”. Der Error Code ist 0x8004FF71 und die Event ID 100 im Application Log.
Wie man den SCEP Client trotzdem installieren kann steht in diesem Bilderbuch:
http://www.it-training-grote.de/download/SCEP-WS2012R2.pdf
Gruss Marc
Hallo Leutz,
Microsoft hat in dem Blogeintrag http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx heute (12.11.2013) angekuendigt, mit SHA1 ausgestellte SSL und CodeSigning Zertifikate in zeitlich festgelegten Stufen aus Sicherheitsgruenden nicht mehr zu unterstuetzen. Das wesentliche in Kuerze:
Juli 2015 – Microsoft wird in diesem Zeitraum neue Informationen / Richtlinien veroeffentlichen, wie mit der SHA1 Abloesung durch SHA2 umzugehen ist
01.01.2016 – CA Anbieter, welche Mitglied im Windows Root CA Programm sind, muessen ab diesem Zeitpunkt SHA2 Zertifikate ausstellen
01.01.2016 – Windows akzeptiert keine Code Signing Zertifikate mehr, welche auf SHA1 basieren und KEINEN Zeitstempel besitzen. Code Signing Zertifikate mit Zeitstempel vor 01.01.2016 werden weiterhin akzeptiert bis Microsoft entscheidet, dass diese Zertifikate angreifbar fuer “Pre-Image-Attacken” sind
01.01.2017 – Windows akzeptiert ab diesem Zeitpunkt keine SSL-Zertifikate mit SHA1
01.01.2017 – Webserver Administratoren / CA Administratoren muessen neue Zertifikate fuer alle ausgestellten SSL und Code Signing Zertifikate mit SHA1 ausstellen und sicherstellen das SHA2 verwendet wird.
Fuer PKI-Administratoren / Webserver-Administratoren bedeutet dass:
1) Zeitnah alle Anwendungen und Dienste zu evaluieren, welche SSL und CodeSigning Zertifikate mit SHA1 verwenden und pruefen, ob diese durch SHA2 Zertifikate ausgetauscht werden koennen
2) Neue PKI Implementierungen gleich mit SHA2 (CNG) Support etablieren, wobei auch hier vorher die Auswirkungen auf die IT Infrastruktur zu beruecksichtigen sind
3) Migrationswege zur “Migration” vorhandener CA auszuarbeiten, welche noch nicht zur Verwendung von CNG Algorithmen konfiguriert sind. Je nach verwendetem CSP (z. B. Microsoft Strong Cryptographic Provider) kann es sehr aufwaendig werden, eine existierende CA auf CNG umzustellen (z. B.: http://www.it-training-grote.de/download/WindowsCA-SHA1-SHA256.pdf)
Gruss Marc
Hallo Leutz,
bei einem Kunden startete die Windows Server 2008 R2 RootCA nicht mehr mit der Fehlermeldung: WsResetMetadata 0xd00000bb (-805306181).
Schuld war ein fehlender Registry Key (siehe Bilderbuch). Wer oder was die Ursache des Problems war, konnte ich bisher nicht ermitteln:
http://www.it-training-grote.de/download/RootCA-WSResetMetaData.pdf
Gruss Marc