Tag Archives: Active Directory

Gross-/Kleinschreibung bei Active Directory Authentication

Comment

Wenn Firewall-Regeln auf Basis einer Active Directory Gruppenmitgliedschaft oder eines Active Directory Username geschrieben werden, muss der Name der Gruppe oder des Users auf der WatchGuard zuerst einmal “bekannt gemacht” werden: Setup > Authentication > Authorized Users/Groups. Als “Name” MUSS genau die gleiche Schreibweise bezüglichGroß-/Kleinschreibung verwendet werden mit der die Gruppe bzw. der User im Active Directory angelegt ist (sAMAccountName):


Anderenfalls ist zwar unter Umständen die User Authentication an für sich erfolgreich, jedoch werden dabei nicht die passenden Gruppenmitgliedschaften ausgelesen – entsprechende Firewall-Regeln laufen daher ins Leere. Im Traffic Monitor wird der Traffic zwar als dem User zugehörig angezeigt, aber u.U. eben trotzdem als Unhandled Packet und daher als denied.

RMA Fälle der letzten Zeit

Comment

Ich hatte in den letzten Wochen drei Fälle, in denen WatchGuard die Hardware Appliance im Zuge eines Support Incidents ausgetauscht hat:

  • Defekte XTM 505: nachdem die Ersteinrichtung (incl. Aufspielen des Feature Key) einwandfrei geklappt hatte, blieb beim nächsten Boot-Vorgang das LCD-Display komplett leer (Hintergrundbeleuchtung an), die Box “kam nicht hoch” und auch die Lüfter liefen nach wie vor auf 100% (reduziert sich normalerweise nach ca. 20-30 Sekunden auf eine geringe Drehzahl).

  • Defekte X10e: trotz korrekter Ausführung eines “Factory Reset” (für mehr als 1 Minute gedrückter RESET-Buttons während Power On) startete die Box nicht in die Maintenance-Partition SYS-B (Safe Mode) – stattdessen war wieder die reguläre Partition SYS-A und die reguläre Konfigurationsdatei aktiv…

  • Defekte SSL100: Probleme mit User Authentication (Microsoft ActiveSync gegenüber Active Directory für den SSL-Zugriff von Apple iPhone auf Microsoft Exchange Server)

Begrenzter Zeichensatz bei Active Directory Authentication

Comment

Puuuuh, nach mehr als einem halben Jahr komme ich endlich mal wieder dazu, hier einen Beitrag zu schreiben. Ich will nicht klagen, es waren einfach sehr viele und anspruchsvolle Projekte in den letzten Monaten. In den nächsten Wochen hoffe ich nun, hier wieder einige hilfreiche Postings schreiben zu können.

Ich fange mit einem “alten Schuh” an, allerdings in einer etwas anderen Ausprägung. Ich habe bereits ja empfohlen, sich in der WatchGuard XML Konfigurationsdatei, und insbesondere bei Passwörtern, Pre-Shared Keys etc. auf den Zeichensatz US-ASCII 7 zu beschränken, d.h. also insbesondere auf die Verwendung von äöüß und Sonderzeichen zu verzichten. Ich empfehle sogar, Kennwörter etc. gänzlich nur aus den klassischen Buchstaben A-Z, a-z und den Ziffern 0-9 zu bilden. Ganz ohne Sonderzeichen, lieber ein paar Stellen mehr…

Wenn nun User Authentication gegenüber Active Directory im Spiel ist, sollte diese Grundregel auch beherzigt werden, wenn die User ihre AD/Windows-Kennwörter festlegen. Ein Kunde berichtete von MUVPN-Einwahl-Problemen bei einem bestimmten User. Dieser hatte ein €-Zeichen in seinem Windows-Kennwort. Die Einwahl schlug fehl. Nach Änderung des AD/Windows-Kennworts (ohne €-Zeichen) war die Einwahl erfolgreich!

Der Kunde hat mir freundlicherweise eine Liste von Zeichen geschickt, die in einem AD/Windows-Kennwort vorkommen dürfen, damit eine MUVPN-Einwahl / User Authentication erfolgreich ist:

!#$%&()*+,-.0123456789:;<=>@ABCDEFGHIJKLMNOPQRSTUVWXYZ[]_abcdefghijklmnopqrstuvwxyz{} und das “Leerzeichen”…

Diese Einschränkung dürfte dann auch gelten, wenn die Einwahl bzw. Authentication per PPTP-VPN (i.V. mit RADIUS), SSL-VPN (AD oder RADIUS) und auch in Verbindung mit Two-Factor Authentication Systemen wie VASCO oder RSA gegenüber AD erfolgt!

XTM 11.4: mehr Details zu den neuen Features

Comment

Die Fireware XTM v11.4 befindet sich kurz vor dem Beta-Stadium. Das endgültige Release ist noch für 2010 angekündigt (Dezember). Hier eine aktuelle Zusammenfassung der neuen Features und Produkt-Verbesserungen. Bitte beachten Sie, dass einige Neuerungen NUR für die neuen XTM Hardware Appliances bereitgestellt werden – NICHT jedoch für die bisherigen Produktreihen X Edge e-series, X Core e-series und X Peak e-series…

Application Control: Diese bahnbrechende Funktion ermöglicht, dass speziell der Zugriff auf Web 2.0 Anwendungen wie Facebook, Skype, YouTube, Twitter, Gmail, BitTorrent, MSN, Yahoo Messenger, WebEx, Teamviewer, weitere Instant Messaging und über 1.500 weitere Web Anwendungen wesentlich genauer reglementiert werden kann als bisher. Application Control gibt den Admins also wieder die tatsächliche Kontrolle über die Nutzung ihrer Internet-Bandbreite zurück.

Intrusion Prevention Service: Die Kooperation mit einem neuen Signatur-Anbieter ermöglicht eine eine einfachere Konfiguration, die auch alle Ports und Protokolle scannen kann.

Configuration History und Rollback: Bei Verwendung des WatchGuard Management Servers kann nun auch automatisiert eine gewisse Histore von Konfigurationsdateien verwaltet werden.

In gemanagten Umgebungen (WatchGuard Management Server) können nun wesentlich mehr Features innerhalb von Policy Templates genutzt werden: sowohl globale Einstellungen als auch lokale Einstellungen (z.B. lokale SNAT-Regeln für lokale Mailserver).

Verbessertes Reporting: z.B. Überblick über Application Control und DHCP Leases. Reports können nun bei Bedarf mit einer Zeitsteuerung versehen werden. Auch können Admins per SMTP über die Bereitstellung von neuen Reports informiert werden.

Terminal Services Authentication: Auch dieses Feature ist bahnbrechend! Mit Version 11.4 wird ein neuer Agent bereit gestellt, der auf einem Terminalserver installiert werden kann. Der WatchGuard Firewall werden dann die angemeldeten User und deren Gruppen-Mitgliedschaften gemeldet, so dass session-basiert unterschiedliche Berechtigungsebenen auf dem gleichen Terminalserver realisiert werden können.

Als neues Feature wird die parallele Nutzung von Active Directory-basiertem Single Sign-On und manueller Anmeldung angepriesen, wenn z.B. neben Windows-Maschinen auch Apple Mac und Linux Systeme eingesetzt werden. Dies ist jedoch auch jetzt bereits bei den aktuellen Versionen 11.3.x möglich… Neu ist jedoch, dass auf EINER WatchGuard Firebox auch MEHRERE Active Directory Domains für die User Anmeldung unterstützt werden – und dass für die Abfrage nicht nur klassisches LDAP, sondern aus Sicherheitsgründen auch LDAP-SSL unterstützt wird.

XTM 2 Wireless Appliances bekommen die Möglichkeit, nicht autorisierte (Rogue) WLAN Access Points zu erkennen und zu reporten.

Das WebUI wird erweitert, so dass auch Application Proxy Settings über das Webinterface bearbeitet werden können.

Als weniger wichtig schätze ich ein, dass künfig der “Drop-In-Mode” auch auf Active/Passive Cluster Konfigurationen unterstützt wird – und dass neue XTM Appliances (“out of the box”) auch über den Quick Setup Wizard registriert werden können, wenn dort Benutzername/Kennwort für den WatchGuard LiveSecurity Account eingegeben werden können.

XTM: SSO Exceptions jetzt auch als Host Range und Network IP

Comment

Bei einer WatchGuard Firebox oder XTM hat Single Sign On (SSO) in Verbindung mit Active Directory die Aufgabe, automatisch zu erkennen, welcher Windows-User an einem PC angemeldet ist und dies an die WatchGuard Firebox zu melden, damit Firewall-Regeln angewendet werden, die auf einer Gruppenmitgliedschaft oder einem Usernamen basieren. Wie beim händischen Ausfüllen der Authentication Page (Port 4100) lernt die WatchGuard mit Hilfe des SSO Agent (und des optionalen SSO Client) dabei, welcher User sich hinter einer bestimmten IP “verbirgt” und in welchen Active Directory Gruppen dieser User Mitglied ist.

Die automatische Erkennung per SSO macht jedoch nur Sinn bei Standalone-PCs, die Mitglied einer Windows-AD-Domäne sind – und an denen jeweils nur ein User gleichzeitig angemeldet ist. In der Regel ist es empfehlenswert, Maschinen, die kein AD-Domänenmitglied sind oder kein Windows-Betriebssystem haben (z.B. Apple Mac, Linux oder Windows Mobile Clients) sowie Windows-Server von der automatischen User-Erkennung per SSO auszuschließen.

Bislang konnte die Liste der so genannten “SSO Exceptions” nur relativ umständlich befüllt werden. Jede dementsprechende IP-Adresse musste einzeln eingetippt werden. Mit dem aktuellen WatchGuard System Manager (WSM) und Fireware XTM 11.3.2 lassen sich nun auch die von normalen Firewall-Regeln her bekannten Auswahlen Host Range, Network IP und Host Name (DNS lookup) verwenden, was das Befüllen der SSO Exception List in vielen Umgebungen sicher deutlich vereinfachen wird:

Gross-/Kleinschreibung bei Active Directory Authentication

Comment

Wenn Firewall-Regeln auf Basis einer Active Directory Gruppenmitgliedschaft oder eines Active Directory Username geschrieben werden, muss der Name der Gruppe oder des Users auf der WatchGuard zuerst einmal “bekannt gemacht” werden: Setup > Authentication > Authorized Users/Groups. Als “Name” MUSS genau die gleiche Schreibweise bezüglich Groß-/Kleinschreibung verwendet werden mit der die Gruppe bzw. der User im Active Directory angelegt ist (sAMAccountName):


Anderenfalls ist zwar unter Umständen die User Authentication an für sich erfolgreich, jedoch werden dabei nicht die passenden Gruppenmitgliedschaften ausgelesen – entsprechende Firewall-Regeln laufen daher ins Leere. Im Traffic Monitor wird der Traffic zwar als dem User zugehörig angezeigt, aber u.U. eben trotzdem als Unhandled Packet und daher als denied.

Fireware XTM: Reihenfolge der Anmelde-Domänen auf der Anmeldeseite

1 Comment

In Verbindung mit User Authentication wird meist die manuelle Anmeldeseite der WatchGuard Firewall Appliance verwendet:
https://[IP-der-Firebox]:4100.
Die Authentication kann entweder gegenüber der lokalen Benutzer-Datenbank der Firebox selbst erfolgen (Firebox-DB), alternativ gegenüber externen Benutzer-Datenbanken unter Verwendung von RADIUS, SecureID/VASCO, LDAP oder Active Directory. Selbst wenn in der Firebox-DB gar keine lokalen User vorhanden sind, weil z.B. generell mit Active Directory gearbeitet wird, sieht die Anmeldeseite BEIM ERSTEN AUFRUF erst einmal so aus, d.h. standardmäßig wird “Firebox-DB” als Anmelde-Domäne angezeigt:

Die User müssen also in diesem Fall nicht nur geschult werden, dort ihren Windows-Benutzernamen und ihr Windows-Kennwort einzugeben, sondern auch noch in dem Pulldown-Menü darunter MANUELL von “Firebox-DB” auf “Active Directory” umzustellen. Das gestaltet sich manchmal etwas schwierig……… Besser wäre es natürlich, wenn die Anmeldeseite auch schon beim ersten Aufruf standardmäßig “Active Directory” als Anmelde-Domäne zeigen würde:

Die Reihenfolge der Anmelde-Domänen in dem Pulldown-Menü lässt sich durch einen manuellen Eingriff in die XML-Konfigurationsdatei beinflussen.
Erzeugen Sie als Backup zunächst eine Kopie Ihrer aktuellen XML-Konfigurationsdatei. Öffnen Sie die XML-Datei dann mit einem entsprechenden Editor. WordPad reicht schon. Suchen Sie nach dem Tag “auth-domain-list”. Sie werden erkennen, dass dort die von Ihnen verwendeten Anmelde-Domänen als “auth-domain” aufgelistet sind. An erster Stelle werden Sie “Firebox-DB” finden. Sie können nun die Anzeige-Reihenfolge festlegen, indem sie die jeweils vollständigen “auth-domain”-Tags per Cut&Paste in der gewünschten Reihenfolge anordnen. Speichern Sie die geänderte XML-Datei, öffnen Sie diese über den Policy Manager und laden Sie sie per “Save to Firebox” auf die WatchGuard hoch.
ACHTUNG: Wie immer ist in einem solchen Fall natürlich sehr sorgfältiges Vorgehen angesagt!!!

SSL 100: One Time Password per SMS

1 Comment

Die einfachste Form der User Authentication an einer WatchGuard SSL 100 ist die Kombination aus Benutzername und Kennwort, WatchGuard SSL Password. Die User und Kennwörter können auf der SSL100 selbst gepflegt werden oder es erfolgt ein Mapping zu einer externen Benutzerdatenbank, z.B. einem Active Directory. Damit nicht die unbefugte Weitergabe der Zugangsdaten an Dritte die Sicherheit der internen Daten und Programme gefährdet, kann eine zweite Komponente die Sicherheit erhöhen: eine Two-Factor Authentication, also die Kombination aus Wissen und Besitz oder Biometrie). Neben der Kenntnis von Benutzername und Kennwort ist auch noch eine zweite Komponente erforderlich, z.B. ein OTP Token als Schlüsselanhänger, der zeitgesteuert z.B. alle 60 Sekunden eine neue 6-stellige Zahl anzeigt, die bei der Anmeldung zusätzlich abgefragt wird. Hersteller sind u.a. RSA und VASCO. Alternativ ist es auch möglich, das Einmal-Kennwort per E-Mail (z.B. an BlackBerry Handhelds, iPhone oder andere Mobile E-Mail Devices) zu versenden – oder per SMS auf ein beliebiges Mobiltelefon.
Wenn das One Time Password (OTP) per SMS versendet werden soll, bedient man sich in der Regel eines SMS-Providers, bei dem man ein gewisses Kontingent an SMS einkauft. Ein möglicher Anbieter ist Clickatell. Nach der Aktivierung eines Accounts und dem Kauf eines SMS-Kontingents (hier 400 SMS für 17,60 EUR = 4,4 ct pro SMS) bekommt man von Clickatell drei Zugangsinformationen zugewiesen: USERNAME, PASSWORD und API_ID. Diese drei Angaben ersetzen die Platzhalter in folgender URL: https://api.clickatell.com/http/sendmsg?user=USER&password=PASSWORD&api_id=API&to=[$user-mobile]&text=[$message].
In der Konfiguration der WatchGuard SSL100 wird diese URL an folgender Stelle eingetragen: Manage System > Notification Settings > SMS Channel > Add SMS Channel > Plugin = HTTP-Plugin > URL > Save > Save (!!!) > Publish (!!!)
Außerdem muss sichergestellt sein, dass WatchGuard SSL Mobile Text generell als Authentication Methode enabled ist und auch in den entsprechenden Userkonten, die dieses Verfahren nutzen sollen. Dort muss ebenfalls die Mobilfunknummer eingetragen werden, an die die SMS geschickt werden soll (hier im Format 49171xxxxxxx). Die Nutzung des SMS-OTP macht natürlich nur dann Sinn, wenn in den betreffenden User-Accounts die Anmeldemethode WatchGuard SSL Password disabled wird, denn sonst wäre ja nach wie vor die einfache Anmeldung nur mit Benutzername und Kennwort möglich. Beim Aufruf der Anmeldeseite wählt der User also WatchGuard SSL Mobile Text aus und meldet sich zunächst mit seinem regulären Benutzernamen und Kennwort an:

Dadurch wird die Erzeugung des SMS-OTP angestoßen und wenige Sekunden später kommt eine SMS an. Als Absender der SMS tritt bei Clickatell eine +44 Nummer in Erscheinung, da das Gateway wohl in Großbritannien betrieben wird. Der Standard-Text der SMS lautet: Your OTP is xxxxxx. Enter it to login with Mobile Text. Anschließend steht die gewohnte Portaloberfläche mit den freigegebenen Icons zur Verfügung.

Fireware XTM v11 und Windows 2000 Active Directory User Authentication

3 Comments

Die Release Notes von WSM und Fireware XTM v11 enthalten den lapidaren Satz “We no longer support Microsoft Windows 2000”. Eine damit zusammenhängende Erscheinung hat mir die Tage etwas Kopfzerbrechen beschert: User Authentication gegenüber einer nativen Windows 2000 Domäne. Nach dem Upgrade von WSM/Fireware 10.2.7 auf 11.2.1 funktionierte sowohl die Web Authentication über Port 4100 nicht mehr (“user name or password invalid”) als auch die MUVPN-Einwahl über den IPSec-Client (“admd ADM auth Firewall user [xxxxx@Active Directory] Error, Reason – Generic error id=”1100-0012” bzw. “wgcgi Firewall user xxxxx@Active Directory from [IP] rejected – all other error”).
Das liegt daran, dass eine Firebox mit Fireware XTM v11 “anders” in das Active Directory abfragt als die bisherige Fireware 10. Zum Auslesen von Gruppenmitgliedschaften werden jetzt tokenGroups_get Abfragen ins AD gestellt. Damit kann ein natives Windows 2000 Active Directory aber noch nichts anfangen. Erst ein Windows 2003 Domänencontroller kommt damit zurecht. Natürlich sollte heutzutage die AD-Migration kein Problem mehr sein, will aber natürlich trotzdem gut vorbereitet sein. Für die Übergangszeit kann daher mit einem Trick gearbeitet werden, der zwar nicht offiziell supported wird, aber trotzdem funktioniert: anstelle der direkten Active Directory Authentication auf LDAP umstellen – mit ansonsten identischen Einstellungen:

In der Pulldown-Liste von Login Attribute findet sich bei LDAP jedoch nicht das klassische Windows-Attribut sAMAccountName. Dies kann dort aber händisch über die Tastatur eingegeben werden… Natürlich müssen dann ggfs. noch die in Firewallregeln verwendeten Gruppennamen unter Setup > Authentication > Authorized Users and Groups nachgezogen werden. Und unter VPN > Mobile VPN muss auch an den entsprechenden Stellen von Active Directory auf LDAP umgestellt werden.

Probleme mit self-signed Zertifikaten beim Update auf 11.2

Comment

Mir ist es heute zum zweiten Mal passiert, dass nach dem Update einer Firebox X Core bzw. X Peak von Fireware (Pro) 10.2.x auf Fireware XTM v11.2 zwar die Firewall/VPN-Funktionalität da war, die Box jedoch über den WatchGuard System Manager (WSM) nicht mehr ansprechbar war.

In beiden Fällen führe ich das Problem auf das Vorhandensein bzw. die Nutzung eines selbst generierten 3rd Party Zertifikats für die SSL-geschützte Web Authentication Page (Port 4100) zurück. Die Zertifikate waren jeweils von einer eigenen Active Directory-integrierten Zertifizierungsstelle erzeugt worden, damit beim Laden der Firewall-Anmeldeseite auf den Domänen-Mitglieds-PCs die Warnmeldung des Browsers nicht angezeigt wird. Unter Fireware (Pro) 10.2.x hatte dies auch die ganze Zeit problemlos funktioniert.

Beim ersten Fall vor ca. 2 Wochen stand ich sehr unter Zeitdruck (Downtime…) und habe zur schnellen Problemlösung die Brachialmethode gewählt: Factory Default Reset über das Command Line Interface (CLI) [PuTTY/SSH auf Port 4118 der Firebox, Anmeldung als User “admin” mit der Configuration Passphrase (dem “schreibenden Kennwort”)] und Eingabe des Kommandozeilen-Befehls “restore factory-default”. Hierdurch werden u.a. die Firewall-Kennwörter auf die Fireware XTM v11.x Defaults “readwrite” (für den User “admin” bzw. die Configuration Passphrase) und “readonly” (für den User “status” bzw. die Status Passphrase) zurückgesetzt… Anschließend dann das übliche Spiel: Durchklicken des Quick Setup Wizard, Verbinden per WSM, Öffnen des Policy Managers, Laden der letzten funktionierenden Konfigurationsdatei, Ändern der Einstellungen für das Web Server Certificate und “Save to Firebox”…

Heute konnte ich ein paar Minuten Zeit mehr investieren und habe dabei herausgefunden, dass es offenbar auch ausreicht, auf Kommandozeilenebene die Befehle “configure” und “web-server-cert default” auszuführen – also anstelle des 3rd Party Zertifikats das eingebaute Original-WatchGuard-Zertifikat auszuwählen. Anschließend konnte ich auch sofort wieder per WSM auf die Box zugreifen… Interessanterweise konnte ich anschließend im Policy Manager sogar wieder das 3rd Party Zertifikat auswählen und problemlos wieder aktivieren… Das Problem tritt also offenbar nur genau im Moment des Software Upgrades von 10.2.x auf 11.2 auf. Ich werde mir also angewöhnen, bei Migrationen künftig vorsorglich über Setup > Authentication > Web Server Certificate zunächst das Original-WatchGuard-Zertifikat auszuwählen und erst nach der Migration wieder das 3rd Party Zertifikat zu aktivieren…