LDAPS mit Access Gateway Enterprise

Standardmäßig ist auf einem Windows Server 2008 LDAPS aktiviert, allerdings ist kein entsprechendes Zertifikat im System hinterlegt, was dazu führt, dass gültige Anmeldeversuche abgewiesen werden, sobald man den Security Type des Authentication Servers auf TLS oder SSL stellt.

Bei der Verwendung von PLAINTEXT ist der Login für Benutzer zwar möglich, sollte das Kennwort des Benutzers jedoch abgelaufen oder zurückgesetzt worden sein, stellt der Benutzer bei der nächsten Anmeldung am CAGEE fest, dass er sein Kennwort nicht ändern kann, obwohl er die Abfragen zum Ändern seines Kennworts richtig beantwortet. Zur erfolgreichen Änderung des Kennworts ist die Verwendung von LDAPS zwingend erforderlich.

Um die Kennwortänderung über das Webinterface des CAGEE zu ermöglichen müssen folgende Bedingungen erfüllt sein:

  • LDAP Server muss Anfragen über SSL akzeptieren (LDAPS)
  • Der Authentication Server des CAG muss Passwortänderungen erlauben und LDAPS nutzen

Für die Konfiguration von LDAPS wird in diesem Beispiel ein selbstsigniertes Zertifikat verwendet, die Zertifikatserstellung erfolgt nicht mit den Active Directory Certificate Services, sondern wird lokal auf der Windows Maschine durchgeführt.

 

Erstellen eines selbstsignierten Zertifikats:

Das Zertifikat wird auf dem Domain Controller erstellt der später LDAPS anbieten soll. Prinzipiell kann das Zertifikat auch mit OpenSSL erstellt werden, allerdings finden sich dann bei jedem Login über das CAG Warnmeldungen (Ereignis-ID: 36886) im Eventlog des Domain Controllers, da bestimmte Zertifikatserweiterungen (x.509 Extensions) fehlen.

Zur Erstellung des Request wird das Kommandozeilentool certreq verwendet, welches nach Übergabe einer .inf Datei alle benötigten Dateien anlegt. Wir benötigen also die Datei request.inf mit folgendem Inhalt:

;—————– request.inf —————–
[Version]
Signature=“$Windows NT$
[NewRequest]
Subject = „CN=server.domain.zz“ ; replace with the FQDN of the DC
KeySpec = 1
KeyLength = 2048
; Can be 1024, 2048, 4096, 8192, or 16384.
; Larger key sizes are more secure, but have
; a greater impact on performance.
Exportable = TRUE
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = „Microsoft RSA SChannel Cryptographic Provider“
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ; this is for Server Authentication
;———————————————–

Nachdem die Datei angelegt ist, wird das Kommando certreq -new request.inf request.req mit Administratorberechtigungen ausgeführt. Um an die benötigten Dateien (Zertifikat und Private Key) zu kommen öffnen wir nun die mmc.exe und fügen das Snap-In Zertifikate für das Computerkonto „lokalen Computer“ hinzu. In der Baumansicht an der linken Seite Zertifikatsregistrierungsanforderungen -> Zertifikate erweitern. An dieser Stelle sollte ein Eintrag mit unseren Daten (server.domain.zz) zu finden sein. Ein Doppelklick auf den Eintrag öffnet das Zertifikat welches über den Karteireiter Details -> In Datei Kopieren… gespeichert wird. Nun noch einen Rechtsklick auf den Eintrag Alle Aufgaben -> Exportieren… und dem Dialog folgen.

  • Ja, privaten Schlüssel exportieren
  • Privater Informationsaustausch – PKCS#12
  • Alle erweiterten Eigenschaften exportieren
  • Kennwort eingeben
  • Speicherort auswählen und Fertigstellen

Nachdem die beiden Dateien gespeichert sind, wechseln wir in der Baumansicht zu den eigenen Zertifikaten und importieren die PKCS#12 Datei (Rechtsklick -> Alle Aufgaben -> Importieren..). Anschließend muss noch das gespeicherte Zertifikat, in die Vertrauenswürdigen Stammzertifizierungsstellen importiert werden. Sobald diese Schritte abgeschlossen sind, bekommen wir Antworten vom LDAP-Dienst über SSL.

Ob die Funktionalität tatsächlich bereit steht, kann mit dem Tool ldp.exe getestet werden. Das Tool über Ausführen ldp.exe starten und im Fenster Remotedesktopverbindung -> Verbinden die Adresse des Domain Controllers welcher LDAPS bereitstellt eingeben, SSL anhaken, Port 636 eingeben und mit OK bestätigen.

Wenn die Verbindung funktioniert erfolgt eine längere Ausgabe mit dem Inhalt

[…]
Established connection to server.domain.zz.
Retrieving base DSA information…
Getting 1 entries:
Dn: (RootDSE)
[…]

andernfalls wird eine Fehlermeldung angezeigt.

Anpassen der Einstellungen auf dem CAGEE:

Die Einrichtung im Bereich Windows ist an dieser Stelle abgeschlossen. Damit LDAPS vom CAGEE genutzt werden kann, müssen nun noch zwei Einstellungen am Authentication Server angepasst werden. Im Dialog des Authentication Server muss der Radiobutton Security Type auf SSL (Port 636) eingestellt werden und zusätzlich zu den bisherigen Einstellungen sollte die Checkbox Allow Password Change aktiviert werden.

Im Anschluss an diese Änderungen kommuniziert das CAGEE SSL gesichert mit dem LDAP-Backend und Benutzer sind in der Lage ihr Passwort über die Weboberfläche zu ändern.

iOS „Bewegungsprofile“

Nachdem das Thema gestern Abend sogar in der Tagesschau umfangreich behandelt wurde, sei der eine oder andere wichtiger Hinweis gestattet:

  • Es existiert keinerlei Beweis oder auch nur Indiz, dass Apple diese Daten sammelt – lediglich das einzelne Gerät erfasst und speichert sie. Zahlreiche Kommunikationsanalysen konnten keinen Transfer dieser Daten in Richtung Apple belegen oder Anhaltspunkte dafür liefern.
  • Die Erkenntnis, dass Geo-Location-Daten erfasst werden, ist nicht neu.
  • Die Erkenntnis, dass die Geo-Location-Daten auch gespeichert werden, ist ebenfalls nicht neu. Es existieren ebenfalls Werkzeuge (Software) und sogar ein Buch, die ein gutes halbes Jahr und mehr alt sind, die sich mit diesen Daten beschäftigen. Die beiden Kollegen von O’Reilly hätten diese Tatsachen zumindest erwähnen müssen, statt das alles jetzt als revolutionäre Entdeckung darzustellen.

Eine deutsche Adaption des oben referenzierten Artikels von Alex Levinson gibt es übrigens auch seit ein paar Minuten bei FAZ.net.

SP1 für Server 2008 R2 und Windows 7 ist RTM

Das Servicepack 1 für Server 2008 R2 und Windows 7 ist seit dem 09.02.2011 RTM (Release to Manufacture).

Für TechNet-Abonnenten und Volume Licensing-Kunden wird es ab dem 16.02. verfügbar sein, am 22.02. findet es sich dann auch in Windows Update und dem Microsoft Download Center.

Das Service Pack bringt eine Zusammenfassung der Updates seit dem Release der Betriebssysteme, neue Features bekommt nur der Server spendiert: RemoteFX und DynamicMemory.

DynamicMemory für Hyper-V ist Microsofts Antwort auf die VMware ESX und Citrix XenServer Lösungen einen Memory Overcommit zu ermöglichen, also den VMs insgesamt mehr virtuellen RAM zur Verfügung zu stellen als physikalisch vorhanden ist.

Dabei wird der Arbeitsspeicher dynamisch verteilt statt in Pagefiles zu schreiben. Die VM teilt dem Hypervisor mit, wie viel RAM sie effektiv belegt und bekommt diesen zugeteilt. Dadurch stehen Speicherbereiche, die sonst reserviert wären, zur Verfügung und können von weiteren VMs genutzt werden. Wird mehr RAM benötigt als physisch vorhanden ist, nutzt der Hypervisor wie zuvor Pagefiles.

Dank dieser Technik lässt sich die Auslastung des physischen Speichers verbessern und es können mehr Systeme bereitgestellt werden, so lange die Auslastung innerhalb der virtuellen Maschinen sich unterhalb des maximal zugeteilten Wertes bewegt.

RemoteFX ist eine Erweiterung des RDP-Protokolls von Microsoft. Diese ermöglicht es, anspruchsvolle grafische Inhalte wie Flash, Silverlight oder 3D-Anwendungen von der GPU beschleunigen zu lassen.

Ist im Client eine entsprechende Grafikkarte verbaut, werden die Inhalte auf dem Clientsystem berechnet. Werden hingegen ThinClients oder ähnliche Systeme ohne entsprechende Hardware genutzt, kann der Server diese Aufgabe übernehmen. Voraussetzung ist natürlich, dass er eine entsprechend leistungsfähige Grafikkarte verbaut hat.

Die Serverhersteller arbeiten bereits an entsprechenden Systemen mit der nötigen Hardwarebasis, da die aktuell verwendeten Grafikkarten selten zu den leistungsfähigen am Markt zählen. Die Nutzbarkeit beschränkt sich aufgrund gestiegener Bandbreitenanforderungen hingegen auf das lokale Netzwerk (LAN). Für Verbindungen über das WAN empfehlen sich wie bisher die Mehrwertlösungen von Citrix (XenApp, XenDesktop), die das hochoptimierte HDX-Protokoll verwenden.

Durch diese beiden Features werden alleine mit Windows Bordmitteln aber neue Möglichkeiten der Bereitstellung von VDI Umgebungen gegeben. So lassen sich mehr Clientsysteme auf weniger physischen Hosts bereitstellen und nutzen als dies bisher möglich war.

Chrome Instant – Fluch oder Segen?

Vor Kurzem erschien die neuste Version von Googles Hausbrowser „Chrome“. In diesem wurde ein neues Feature implementiert, das sich „Chrome Instant“ nennt. Womöglich kennen Sie „Google Instant“, eine Funktion, die Ihnen bereits die Suchergebnisse beim Tippen anzeigt. „Chrome Instant“ überträgt diese Technik in die Adressleiste des Browsers: Noch während Sie tippen, wird die vermutete Zielseite geladen – ohne, dass Sie etwas dafür tun müssen.

So komfortabel diese Funktion auch ist, sie hat diverse Nachteile: Wird eine Webseite geladen, noch während der Anwender tippt, ist nicht vollständig sichergestellt, dass der Anwender auch diese Seite tatsächlich besuchen möchte. So wird bei der Eingabe von „stern“ vermutlich die Webseite „stern.de“ geladen, erst im weiteren Verlauf fügt der Anwender ein „-tv.de“ hinzu, um die Adresse zu komplettieren: „stern-tv.de“. Durch den unnötigen Aufruf von stern.de wurde selbstverständlich Bandbreite in Anspruch genommen, die womöglich anderen Verbindungen zur Verfügung hätte stehen können. Je größer das Unternehmen, desto kritischer wird das ständige Vorausladen „auf gut Glück“.

Auch Administratoren von Webservern werden die Hände über dem Kopf zusammenschlagen: Ihre Zugriffs-Logs werden in Zukunft häufiger von 404-Fehlern übersät sein, da die gewünschte Adresse vom Anwender noch nicht komplett eingegeben wurde und so ein Zugriffsfehler provoziert wurde. Auch hier gilt: Jeder Aufruf einer Webseite, sei es mit echten Inhalten oder einer Fehlerseite, beansprucht Bandbreite des Webservers, was bei hochfrequentierten Seiten zu Performance-Problemen führen kann.

Die Marketing-Abteilung wird das neue Feature des Browsers besonders kritisch beäugen: Das gut ausgeklügelte System zur Optimierung der Webseite bricht in sich zusammen, wenn die Statistiken über Besucherherkunft, Besucherbewegung auf der Webseite und Klickstrecken mit Datenmüll durch ungewollte Aufrufe unbrauchbar werden. Es ist zudem kein Verlass mehr auf die Page Impressions, da man nicht sicher sagen kann, ob eine Seite tatsächlich aufgerufen und gelesen wurde oder ob die Page Impression ein Produkt von „Chrome Instant“ ist.

Zuletzt ist es wieder ein Schritt Richtung Kontrollverlust des Anwenders über sein Arbeitsgerät. Immerhin muss „Chrome Instant“ (noch) vom Anwender aktiviert werden. Aktuell hat Google Chrome eine Verbreitung von bis zu 20% (laut w3schools.com), doch der Browser konnte in den vergangenen Monaten in großen Schritten zu Konkurrenten wie Firefox und Internet Explorer aufschließen. Es ist also nur eine Frage der Zeit, bis man sich Methoden überlegen muss, wie man mit dem wohl gut gemeinten, aber schwer kontrollierbaren Feature umgehen wird.