SAN Zertifikate mit der Microsoft CA

Auch mit der Microsoft CA (Certificate Authority) ist es möglich SAN Zertifikate über das Webenrollment (auch bekannt als „certsrv“ bekannt) auszustellen.

Hierzu muss jedoch vorher einmalig über die CMD folgender Befehl (mit anschließendem Neustart des Services) auf dem Host mit der PKI Rolle ausgeführt werden.

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc

Das Attribut für einen AltName kann direkt beim einreichen des Requests im Webinterface über das dafür vorhergesehene Feld angegeben werden. Der Syntax ist dabei wie folgt.

Microsoft CA - SAN Zertifikat

san:dns=name1.example.com[&dns=name2.example.com]

Ohne den vorherigen CMD Befehl wird der Parameter für einen AltName komplett ignoriert.

AWX – Ansible Tower wird OpenSource

Im Jahr 2015 hat RedHat das Unternehmen Ansible für rund 150 Millionen US Dollar übernommen, das seinerzeit die schlanke Automatisierungslösung Ansible ins Leben gerufen hat.

Anfang September wurde nun der Quellcode von der „Zentrale“ Ansible Tower als Projekt AWX (Ansible Works) unter die Apache License gestellt und auf GitHub gestellt. AWX dient fortan als Upstream für das weiterhin kostenpflichte Ansible Tower, wobei das Produkt nun den Namen gewechselt hat und jetzt als „Ansible Engine“ vermarktet wird.

Wie bei anderen RedHat Produkten (Satellite/Katello, OpenShift) wird die primäre, schnelle Entwicklung im Upstream liegen. Zu gegebener Zeit wird aus dem Code dann eine „stabile“ Version von Ansible veröffentlicht. Ansible Tower bleibt weiterhin kostenpflichtig, womit man sich aber auch den Support seitens RedHat einkaufen kann.

Das GitHub Repository von AWX befindet sich hier. Die Installation selbst ist natürlich auch via Ansible gescriptet. AWX lässt sich entweder in ein OpenShift Cluster oder auf einem einem Standalone Docker Host installieren.

Critical Citrix NetScaler Security Issue

Derzeit sind bei Citrix alle Firmware Downloads für den Citrix NetScaler Offline geschaltet. Hintergrund ist eine größere Sicherheitslücke, über die derzeit noch nicht viel bekannt ist.
Citrix hat bereits den Artikel CTX227893 veröffentlicht und alle Kunden via E-Mail informiert.

Due to an issue found in the builds, NetScaler 10.1, 10.5, 11.0, 11.1 and 12.0 builds are not available for download temporarily. Currently, we are testing replacement builds, which we expect to release in the coming days.

In the meantime, our guidance is to make sure your NetScaler is configured following our best practices guides found at https://support.citrix.com/article/CTX121149 and https://docs.citrix.com/content/dam/docs/en-us/netscaler/media/secure-deployment-guide/NetScaler-Secure-Deployment-Guide.pdf.

Aus dem Artikel lässt sich entnehmen das die Lücke wohl nur ausgenutzt werden kann wenn Zugriff auf eine NSIP oder SNIP (dann mit aktiviertem Management) besteht.

Betroffen sind alle bisher veröffentlichten NetScaler Versionen ab Version 10.1. Der Patch für die Lücke sollte hoffentlich noch in dieser Woche erscheinen.

Update vom 25.09.2017: der CTX-Artikel CTX227928 wurde veröffentlicht. Es handelt sich um ein Sicherheitsproblem, das einen Authentication Bypass auf das NetScaler Management ermöglicht (CVE-2017-14602).

Treat your documents like code

Präsentationen und Dokumentationen zu erstellen ist nicht immer ein leichtes Thema. Mit diesem Beitrag möchte ich meine Erfahrungen teilen und zeigen, wie ich aktuell meine Dokumentationen und Präsentationen erstelle. Mittlerweile behandle ich meine Dokumentationen wie meinen Code und schreibe diese in Asciidoc – revisioniert via Git.

Um die Grundprobleme zu verstehen möchte ich erst einmal darauf eingehen, welche Anforderungen meist an Dokumentationen innerhalb von Projekten bestehen.

  • In großen Projekten werden Teilbereiche meist durch unterschiedliche Kollegen realisiert. Diese erstellen die Dokumentation für Ihren Teilbereich, der jedoch später in einer Gesamtdokumentation zusammen laufen sollte.
  • Kollegen sollten sich nicht gegenseitig blockieren und auch gleichzeitig am Dokument arbeiten können, möglichst ohne den Aufwand, die Arbeiten später wieder zusammenzuführen.
  • Der Kunde möchte in der Regel über den aktuellen Stand der Dokumentation informiert sein. Eventuelles Feedback sollte natürlich in das Dokument einfließen.
  • Dahingehend wird auch eine komplette Änderungshistorie benötigt.
  • Um möglichst jeden Kunden glücklich zu machen sollte das Zielformat flexibel bleiben.

Meist werden Dokumentationen aber einfach in Microsoft Office oder einem vergleichbarem Tool erstellt. Welche Probleme ergeben sich dadurch?

  • Durch das Format ist man an ein proprietäres Tool gebunden.
  • Durch zusätzlichen Verschiedene Versionen (die auch tatsächlich noch bei Kunden im Einsatz sind), wird die Zusammenarbeit zusätzlich erschwert (2003, 2007, 2010, 2013, LibreOffice)
  • Die Speicherung des Dokuments wird meist auf einem zentralen CIFS-Share durchgeführt. Durch das Filelocking ist es nicht möglich das mehrere Personen das Dokument gleichzeitig bearbeiten.
  • Durch diese Tatsache werden meist Teildokumente erstellt, die später manuell zusammengeführt werden.
  • Vorabversionen werden meist manuell per E-Mail an den Kunden gesendet.
  • Korrekturvorschläge und Verbesserungen werden in der Vorabversion farblich markiert und müssen im Nachgang wieder manuell in das Hauptdokument eingearbeitet werden.
  • Eine wirkliche Änderungshistorie existiert meist gar nicht.

Ich erstelle meine Dokumentationen in dem rein textbasierten Format Asciidoc in Verbindung mit einer Revisionierung mit Git. Bearbeitet werden bei mir nur noch die Daten bzw. der tatsächliche Inhalt, nicht das tatsächliche Zielformat.

Der Ansatz ist sicherlich nicht neu – und viele werden bereits von LaTeX oder Docbook gehört haben. Der große Vorteil in Asciidoc liegt jedoch in der einfachen Syntax, die anders als XML basierte Alternativen, auch im Quellformat lesbar bleibt. Der Syntax ist etwas an Markdown angelehnt, bietet jedoch deutlich mehr Funktionen, die bei größeren Dokumenten sehr hilfreich sein könnten. Als Beispiel seien hier eine Include Funktion (zur Aufteilung von großen Dokumenten in einzelne Dateien) oder ein automatisch generiertes Inhaltsverzeichnis genannt. Hier beispielhaftes ein kleines Dokument in Asciidoc.

= Titel des Dokuments
Simon Lauger <author@example.com>

== Überschrift H1
=== Überschrift H2

Normaler Text

  * Listenpunkt 1
  * Listenpunkt 2

*Fetter Text*, _kursiver Text_, ...

Mögliche Ausgabeformate sind unter anderem HTML5, PDF, Docbook oder Präsentationen via deck.js. Das Design kann für jedes Format via CSS komplett an die eigenen Bedürfnisse angepasst werden. Durch die komplette Trennung von Design und Content ist es später ein leichtes etwa ein neues Firmenlogo in alle vorhandenen Dokumente zu integrieren.

Um den Text von Asciidoc nach HTML5 zu konvertieren genügt ein einfacher Befehl. Asciidoctor basiert auf Ruby und kann meist direkt über den verfügbaren Paketmanager oder rubygems.org installiert werden.

asciidoctor example.adoc

Das anschließende Resultat sieht wie folgt aus.

Beispielausgabe von Asciidoctor in HTML5

Beispielausgabe von Asciidoctor in HTML5

Durch das Zusammenspiel des rein textbasierten Quellformates in Verbindung mit Git ergeben sich folgende Vorteile.

  • Komplette Versionsverwaltung mit allen weiteren Vorteilen von Git (z.B. Branches, Versionstags usw.).
  • Jeder Kollege kann seinen Teil der Dokumentation Offline bearbeiten und später in das zentrale Repository pushen.
  • Bei Bedarf können Git Mechanismen genutzt werden um Konflikte bei einem Merge zu beheben.
  • Dem Kunden kann auf Wunsch direkt Zugriff auf das Repository gegeben werden. Verbesserungsvorschläge können via Pull-Requests vorgeschlagen werden.
  • Die Vorschau der fertigen Dokumentation wird meist sogar in der GUI des Git-Servers angezeigt (Bitbucket, GitLab, GitHub).

Für Entwickler entfällt zudem der lästige und zeitaufwändige Wechsel zwischen Entwicklungsumgebung (IDE) und Office Programm. Das sorgt dafür das Änderungen ohne viel Aufwand schnell „nachdokumentiert“ werden können. Einfache Texteditoren haben zudem den Vorteil das man sich auf das wesentliche (den Content) konzentrieren kann, statt von den vielen, teils unnötigen Features und Farben, erschlagen zu werden.

Viele IDEs und Editoren (etwa Atom oder IntelliJ) bieten zudem eine komplette Live Preview auf das fertige Dokument.

Hier noch einige relevante Links für den ersten Schritte mit Asciidoctor.

Wie sich die Dokumentation via Asciidoctor sauber in einen Entwicklungsworkflow integrieren lassen zeige ich in einem nachfolgendem Beitrag.

NetScaler Gateway: Login with sAMAccountName in Multitenancy Deployment

Ich hatte diese Woche einen Kunden der sein bestehendes NetScaler Gateway Deployment mit einer zusätzlichen Active Directory Domain ausgestattet haben wollte. Bisher lief die Authentifizierung via LDAP (Primary) und RADIUS (Secondary) via SMS Passcode.

Um die Policies zu entschlacken und etwas Komplexität aus dem Setup zu nehmen haben wir das ganze auf RADIUS only (via SMS Passcode) umgestellt. Dadurch muss beim späteren hinzufügen einer weiteren Domain keine weitere LDAP Policy hinzugefügt werden. Der RADIUS bzw. SMS Passcode ist an mehreren Domänen angebunden und übernimmt zudem noch die Password Validation.

Problematisch war jedoch das der Login mit sAMAccountName weiterhin möglich sein sollte. SMS Passcode (bzw. der Windows NPS) akzeptiert zwar den Login sowohl via sAMAccountName als auch via UserPrincipalName, auf dem NetScaler kann dann aber nicht mehr zugeordnet werden in welcher Domäne der Benutzer zugeordnet wurde. In der RADIUS Antwort des NPS ist die Domain des Users nicht enthalten. Auch gibt es sonst keine Möglichkeit ohne ein zusätzlich Group Extraction via LDAP an die Domain des Users zu kommen.

Bei einem NetScaler Gateway SSO zu Citrix Storefront wird die Domäne jedoch immer benötigt. Andernfalls bedeutet funktioniert zwar der Login am NetScaler selbst, der „NetScaler Gateway SSO“ an Storefront schlägt aber fehlt und es erscheint ein weiteres Login Prompt (bei dem im Regelfall aber kein manueller Login möglich ist).

Eine einfache Lösung sind an dieser Stelle Traffic Policies, mit denen man auch die Möglichkeit hat einen Rewrite des Benutzernamens auszuführen. Diese werden bei jedem Request (und damit nach der Authentifizierung) evaluiert. Via Conditions können diese sogar auf bestimmte URLs/Pfade (z.B. /Citrix/Store) beschränkt werden.

Die Standard SSO Domain in der Session Policy bleibt leer. Stattdessen legt man für jede Kundendomain eine eigene Traffic Policy an.

# SSO Traffic Policies
add vpn trafficAction prof_traffic_tentant1_sso_domain http -SSO ON -userExpression "HTTP.REQ.USER.LOGIN_NAME + \"@tentant1.local\""
add vpn trafficAction prof_traffic_tentant2_sso_domain http -SSO ON -userExpression "HTTP.REQ.USER.LOGIN_NAME + \"@tentant2.local\""
add vpn trafficPolicy pol_traffic_tentant1_sso_domain ns_true prof_traffic_tentant1_sso_domain
add vpn trafficPolicy pol_traffic_tentant2_sso_domain ns_true prof_traffic_tentant2_sso_domain

Diese Traffic Policies können nun an Gruppen aus dem Active Directory gebunden werden. Wichtig ist lediglich das man eine Gruppe verwendet die eindeutig ist und in dieser Schreibweise nur in einer Domain vorhanden ist.

# Bind Traffic Policies to AAA Groups
bind aaa group Tentant1_Users -policy pol_traffic_tentant1_sso_domain -priority 100
bind aaa group Tentant2_Users -policy pol_traffic_tentant2_sso_domain -priority 200

Optional bietet es sich noch an den Rewrite des Benutzernamens nur dann durchzuführen, wenn nicht bereits ein „\“ (TENTANT\user1) oder ein „@“ (user1@tentant.local) enthalten ist.

Dieses Problem besteht lediglich in Szenarien in denen ausschließlich via RADIUS authentifiziert wird. Bei LDAP gibt es die Möglichkeit das SSO Feld unabhängig vom Login Feld anzupassen (z.B. dann eben auf den UserPrincipalName).