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.

Citrix acquires Cloud.com

Citrix geht massiv den Cloud-Weg: Sie sind Gründungsmitglied der OpenStack-Initiative, haben auf der diesjährigen Synergy das daraus entspringende „Project Olympus“ vorgestellt und kaufen mit Cloud.com jetzt einen Hersteller/Provider eines Cloud Stacks (Produktname: CloudStack), der die strategische Ausrichtung auf Offenheit und Cloud weiter verdeutlicht.

Alle Details auf der gemeinsamen Landing Page von Citrix und Cloud.com.

Gartner Magic Quadrant for x86 Server Virtualization Infrastructure

Mit Datum vom 30.06.2011 ist der neue Gartner Magic Quadrant for x86 Server Virtualization Infrastructure erschienen. Es gibt nur Marktteilnehmer in zwei Quadranten – Leaders (VMware, Microsoft, Citrix) und Niche Players (Oracle, Parallels, Red Hat).

Die Ausführungen und Einschätzungen der Analysten sind wie immer interessant, aber auch nicht als ultimative Weis- oder Wahrheit anzusehen.

Netscaler AAA Cookies killen

Authenticate, Authorize, Audit. Nach dem Authentifizieren hat der Browser ein Cookie bekommen, mit dem er sich fortan ausweist und mit dem weitere Requests durchgelassen werden, solange das Session Timeout nicht erreicht oder der Browser geschlossen wurde (Session Cookie, d.h. gültig bis zum Schließen der Browser Session – das sind ALLE Fenster eines Browsers).

Will man nun eine AAA Session gezielt beenden, etwa durch einen „Logout“ Button in der Anwendung, so müsste ja eigentlich einfach nur das Session Cookie gelöscht werden. Wie aber löscht man ein Cookie? Gar nicht, das tut der Browser, wenn es nicht mehr gültig ist (invalid). Wie also macht man ein Cookie ungültig? Indem man den Browser schließt – schließlich ist es ja ein Session Cookie. Es ist aber oftmals unzumutbar, dem Anwender zu sagen „um dich abzumelden, schließe einfach alle deine Browser Fenster“.

Lösungsansatz 1: Javascript auf einer Logout-Seite, das mittels document.cookie das Cookie manipuliert, genauer gesagt sein Ablaufdatum in die Vergangenheit setzt.

Problem 1: Abhängigkeit von einem Webserver, auf dem diese Logout Seite liegt, evtl. Probleme beim Zugriff auf das Cookie (Seite muss innerhalb der Authentication Domain liegen und die Authentication Domain muss beim Manipulieren des Cookies angegeben werden). Ist aber passend zum Invalidieren von Session Cookies der Anwendung, was man ja im selben Schritt vielleicht auch machen möchte – jeder killt seine Cookies selbst, siehe Ansatz 2.

Lösungsansatz 2: An den VServer des Netscalers wird eine Rewrite (Response) Policy gebunden, die auf eine passende Bedingung matcht, z.B. den Aufruf einer bestimmten Seite (ausgelöst durch den Klick auf „Logout“). Die dadurch ausgelöste Action ist vom Typ INSERT_HTTP_HEADER und setzt einen Header namens „Set-Cookie“ mit dem Inhalt:

„NSC_TMAA=nothing;expires=Thursday, 1 Jan 1970 00:00:00 GMT;path=/;domain=Authdomain.aus.dem.AAA.VServer“

Da die Policy am selben VServer hängt, ist der Zugriff auf die Cookie Domain sichergestellt. Die Bedingungen bleiben die gleichen – so kümmert sich der Netscaler aber selbst um das von ihm gesetzte Cookie. Das existiert nämlich bereits mit genau diesen Parametern in dieser Domain, nur ohne Ablaufdatum. Durch das Set-Cookie wird dieses überschrieben, damit ist das Cookie ungültig und wird vom Browser verworfen. Die in dieser Response ausgelieferte Seite wird noch dargestellt, der nächste Request aber wird wieder auf den AAA Server umgeleitet.

Kudos an die Kollegen der Hellmann Worldwide Logistics für die Zusammenarbeit! 😉

Citrix stampft Essentials for Hyper-V ein

Recht kurz angebunden informiert Citrix darüber, dass die Essentials für Hyper-V ein angekündigtes End-of-Life haben. Kunden mit gültiger Subscription Advantage können ihre Lizenzen zu XenServer oder XenDesktop konvertieren.

Interessant ist dieser Schritt vor allem, weil noch vor Jahresfrist Spekulationen im Raum standen, Citrix könne XenServer auslaufen lassen und sich auf die Essentials for Hyper-V konzentrieren, da diese schneller neue Versionen und Features bekamen als ihr XenServer Pendant. Diese Frage sollte ja nun beantwortet sein.

Morgen ist World IPv6 Day

Am morgigen Mittwoch, 08.06.2011, ist „World IPv6 Day„: Unter anderem werden große Spieler wie Google, Facebook, Akamai und Limelight ihre Inhalte für 24 Stunden per IPv6 bereitstellen. Auch ohne eigene IPv6-Anbindung sind keine Probleme beim Zugriff auf diese Dienste während des Tests zu erwarten.

Aber die Richtung ist klar, eigentlich schon lange: Get ready for IPv6. Zumindest der Dual-Stack-Betrieb, also gleichzeitige Unterstützung von IPv4 und IPv6 steht als kurzfristiges Ziel im Fokus. Heise.de zum Beispiel ist seit einem ähnlichen Testflug im September 2010 im Dual-Stack-Betrieb am Netz.

„IPv6 ready“ prangt daher auch schon seit längerem auf immer mehr IT-Produkten, insbesondere natürlich solchen, die das Netzwerk nicht nur nutzen, sondern auch gestalten. Der Citrix Netscaler etwa kann auch die Transition und den Kombi-Betrieb unterstützen durch INAT (oder auch Destination NAT) in alle Übersetzungsrichtungen (IPv4 in IPv6 oder IPv6 in IPv4 und natürlich IPv4 in IPv4, IPv6 in IPv6) und auch durch die Möglichkeit, dass die VIP eines VServers nicht mit der IP-Version der Backends übereinstimmen muss. D.h. VServer können per IPv6 ansprechbar sein und im Backend auf IPv4 Adressen verteilen und umgekehrt. So können Netzwerksegmente schrittweise umgestellt werden, ohne gleich in Probleme mit der Verbindung untereinander zu laufen.

Netscaler AAA und OpenLimit eID, neuer Perso

Ein Enterprise Feature des Citrix Netscalers ist AAA, was nicht für „Access All Areas“ steht, sondern für „Authenticate, Authorize, Audit“. Vor jedwede Web-Anwendung kann eine entsprechende Instanz des Netscalers geschaltet werden, die den Benutzer authentifiziert (gegen die verschiedensten Backends wie LDAP/AD, Radius uvm.), seine Berechtigungen prüft und seine Zugriffe natürlich auch auditierbar protokolliert.

Wichtiger Kniff dabei: das ganze läuft über Browser-Redirects und Cookies, die einerseits den Client zur Anmeldung dirigieren, solange er sich nicht erfolgreich ausgewiesen hat und ausreichend berechtigt ist, und andererseits diese erfolgreiche Autorisierung in gesicherter Form transportieren. Damit diese Cookies den Sprung vom AAA Virtual Server zum eigentlichen Service schaffen, müssen diese beiden VServer unter der selben DNS Domain angesprochen werden (Cookie Domain).

Ein interessantes Beispiel für den Einsatz dieser Funktionalität ist im Bereich des nPA (neuer Personalausweis) die Zusammenarbeit mit dem eID-Server von OpenLimit. Der eID-Server agiert als Bindeglied zwischen AusweisApp/Bürgerclient und den Web-Anwendungen von Behörden oder anderen Service-Anbietern. Er führt die Online-Authentisierung per eID durch, sorgt für das sichere und authentische Auslesen der Daten vom nPA und verwaltet die gesamte Zertifikats-Magie, die dazu nötig ist. Einsatzort ist die gesicherte Umgebung des Service-Anbieters, da der eID-Server mit diversen internen, teils hochsicheren Instanzen kommunizieren muss.

Als sicherer Kontaktpunkt zwischen Client/Bürger, Anwendung und eID-Server bietet sich natürlich der Netscaler an. Ein entsprechender AAA VServer nutzt also den OpenLimit eID-Server als Authentifizierungs-Backend, gegen das Benutzer angemeldet und autorisiert werden.

HP P4000 stolpert über Umlaute in Volume Beschreibung

Ein Freitextfeld zur „Beschreibung“ eines Volumes. Welche Relevanz kann das für den Betrieb, die Arbeit mit dem Storage Cluster insgesamt haben? Wie ein Kollege sowie der HP Support gemeinsam feststellen mussten, eine deutlich größere als man vermuten sollte:

Volume X hat eine Beschreibung, die einen Umlaut enthält. Volume Y soll auf einem Server neu verbunden werden (DSM deinstalliert, Sessions müssen neu hergestellt werden). Die Sessions verschwinden aber einfach nicht. Beim manuellen Session Reset über die CLI bekommt man eine Fehlermeldung, die irgendwas zum Thema Encoding und UTF-8 moniert. Ohne den Umlaut in der Beschreibung des Volumes, das überhaupt nichts mit diesem Vorgang zu tun hat (auch nicht mit dem Server verbunden ist), klappt es dann.

Stick to English. Oder programmiert eure Software so, dass sie vollständige Plausibilitätsprüfungen durchführt.

Linux Kernel 3.0 am Horizont – Xen Dom0 ready!

Ich hätte nicht gedacht, dass ich mal auf eine Oracle Seite verlinken würde, aber nun tue ich es: Wim Coekaerts hat eine schöne Zusammenfassung der Geschichte geschrieben, wie die Unterstützung für die verschiedenen Teile zum Betrieb als DomU und nun auch Dom0 in den Linux Kernel gewandert ist. Seit kurzem ist nun tatsächlich ALLES im Mainline Kernel Tree enthalten – und dieser Kernel Tree wurde soeben von Linus Torvalds als Version 3.0-rc1 im GIT eingestellt:

I decided to just bite the bullet, and call the next version 3.0. It will get released close enough to the 20-year mark, which is excuse enough for me, although honestly, the real reason is just that I can no longer comfortably count as high as 40.

Nach 2.6.39 kommt also 3.0 – das nächste Release des Linux Kernels beginnt eine neue Ära der Versionsnummerierung, und der wesentliche Grund dafür ist, dass es an der Zeit ist. Es gibt keine massiven, weltbewegenden, die Community umstürzenden Neuerungen oder Änderungen – nur eben die Versionsnummer, ansonsten könnte es auch einfach 2.6.40 sein.

Die Tatsache mit der vollständigen Xen-Unterstützung allerdings führt zu großer Freude bei denen, die auf diesen Hypervisor als Basis ihrer Virtualisierungslösungen setzen, allen voran also Citrix und Oracle. Denn für die wird es in Zukunft viel einfacher, ihre Produkte zu supporten und zügig zu entwickeln, ohne dabei ständig Kernel-Patches und Portierungen von Neuerungen pflegen zu müssen. Red Hat schwenkte ja vor einiger Zeit von Xen auf KVM als Hypervisor, weil der einfach nativ im Linux Kernel beheimatet ist und entwickelt wird – hier wird also endlich nachgezogen. Das etwa im August erwartete Release von XenServer 6.0 (Project Boston, derzeit Beta) wird aber sicher noch keinen Kernel 3.0 enthalten – aber mal sehen, wie lange das auf sich warten lässt.

Infos und Torvalds Post auf der Linux Kernel Mailinglist siehe http://www.phoronix.com/scan.php?page=news_item&px=OTUwMg.

Netscaler 9.3 – Stichworte

Das neue Release ist seit ein paar Wochen draußen – nicht nur deshalb bleibt kaum Zeit für Beiträge hier. 😉

Was gibt es Neues? Revolutionäres?

Stichwort Database Load Balancing – ehrlich gesagt nur für wenige Situationen interessant, bisher, weil vor allem auch nur für MySQL (und „umgehend“ auch für MSSQL) verfügbar. Die Sache an sich ist aber schon einzigartig: quasi Content Switching mit (T)SQL Intelligenz und all den schönen Möglichkeiten des Netscalers, was die Einflussnahme auf die Kommunikation angeht.

Stichwort TCP Rewriting – jedweder Schweinkram, den man sich vorstellen kann, nur ein paar Kommandos (oder Klicks) entfernt. Was wir für HTTP Kommunikation kennen und lieben gelernt haben (Sie haben die Macht!), jetzt auf TCP-Ebene. Aber Vorsicht…

Stichwort AppFlow – Sammeln und Weitergeben von Traffic-Daten an Kollektoren wie Solarwinds. Je Virtual Server, je Applikation aktivierbar.

Darüber hinaus weiter verbessertes onboard Reporting und Monitoring (hübscher, direkter) und einige tiefgründige Verbesserungen im Bereich Networking/Routing, die neue aberwitzige Konstellationen ermöglichen, die umliegenden Endpunkte an der Nase herum zu führen.

Und natürlich die neuen Open Cloud Komponenten OCB und OCA (Bridge und Access) – die Bridge ist ein L2-VPN, für dessen transparente Funktion neue Features Einzug gehalten haben, hinter Open Cloud Access steckt die Idee, für SaaS Anwendungen einen transparenten Single Sign On mit einmaliger Benutzerverwaltung im eigenen Directory zu realisieren. Da SaaS wie Salesforce & Co. hierzulande wenig Relevanz hat, eher ein USA-lastiges Thema bisher, außerdem extra zu lizensieren.

Weiteres bei Zeiten an dieser Stelle.