Unser Skript “Bert” verbindet sich per WMI (Windows Management Instrumentation) mit einem Windows-System und liest die wichtigen Eckdaten der IP-Konfiguration aus. Diese zeigt er als separierte Liste auf der Kommandozeile an. Leitet man diese Ausgabe in eine zentrale Datei auf einem Server um, so entsteht eine CSV-Datei, aus der man etwa mit Excel die IP-Konfigurationen direkt verarbeiten kann. Das Skript funktioniert lokal und über das Netzwerk.

Syntax und Verwendung

Die Grundsyntax von Bert sieht folgendermaßen aus:

cscript //nologo Bert.vbs [Rechner] /header:[yes|no]

Es handelt sich um ein Konsolenskript, daher muss es mit cscript aufgerufen werden. Der Schalter “//nologo” unterdrückt die Ausgabe der WSH-Informationen, sodass nur die eigentliche Ausgabe des Skripts erscheint. Mit dem Schalter “/header” gibt man an, ob die Spaltenüberschriften in der Ausgabe erscheinen sollen. Lässt man diese nur beim ersten Rechner ausgeben und unterdrückt sie bei allen anderen, so kann man die Ausgabe in einer einzigen Datei sammeln, die dann einmalig mit den Spaltenüberschriften beginnt.

Das Skript erfasst folgende Daten:

• Computername
• Adaptername
• MAC-Adresse
• DHCP-Nutzung
• IP-Adressen
• DNS-Server

Gibt man keinen Rechnernamen an, so wertet Bert die IP-Konfiguration des lokalen Rechners aus. Wenn man einen entfernten Rechner über das Netzwerk auswerten möchte, benötigt man dort Administratorrechte (das ist bei lokaler Ausführung nicht nötig), oder man muss die WMI-Berechtigungen auf dem Remote-System bearbeiten. Außerdem darf keine Firewall die WMI-Schnittstelle blockieren.

Eine zentrale Sammlung der Konfigurationen in der Datei “IP-Daten.txt” in einer Dateifreigabe zeigt folgendes Beispiel:

cscript //nologo C:\Pfad\Bert.vbs DC01 /header:yes > \\SERVER007\IPData$\IP-Daten.txt
cscript //nologo C:\Pfad\Bert.vbs EX01 /header:no >> \\SERVER007\IPData$\IP-Daten.txt
cscript //nologo C:\Pfad\Bert.vbs SQL01 /header:no >> \\SERVER007\IPData$\IP-Daten.txt

Um die Einschränkungen bei der Remote-Auswertung zu umgehen, kann man Bert auch aus einem Start- oder Logonskript aufrufen. Da normale Anwender die WMI-Schnittstelle lokal aufrufen dürfen, sind hierzu keine besonderen Benutzerrechte nötig. In diesem Fall muss man darauf achten, dass für die Anwender (bei Logonskripts) bzw. für die Computerkonten (bei Startskripts) Schreibrechte auf die Sammel-Datei bestehen.

Um beim Einsatz per Logonskript Schreibkonflikte durch gleichzeitigen Zugriff auf die Zieldatei zu vermeiden, kann man z.B. über folgendes Batch die Daten des lokalen Rechners in jeweils eine eigene Datei schreiben:

@echo off
rem Schreibt die IP-Grundkonfiguration des Rechners in eine Textdatei

SET Target=\\SERVER\IPData$\Clients\%computername%.txt
SET Bert=\\SERVER\IPData$\Bert.vbs

COPY %Bert% "%userprofile%"

cscript //nologo "%userprofile%\Bert.vbs" /header:no > %Target%

DEL "%userprofile%\Bert.vbs"

Dieses Batch kopiert zunächst die Skriptdatei ins lokale Userprofil, damit es keine Berechtigungsfehler beim Aufruf von einem Share aus gibt. Das Ergebnis der Ausführung landet dann in einer Textdatei auf einer Dateifreigabe, die den Namen des lokalen Rechners trägt. Am ende entfernt das Batch die Skriptdatei wieder vom System.

In der Freigabe liegen dann zahlreiche Dateien – eine pro Rechner. Um sie nachträglich zu einer Datei zusammenzufassen, eignet sich dieses Kommando, das man in einem CMD-Fenster aus dem Ordner ausführt, wo die Dateien liegen:

for /F "usebackq" %i in (`dir /b`) do @type %i | find /i ";" >> "IP-Konfigs Clients.txt"

Keine verwandten Beiträge.

Diese Daten speichern wir nicht bei uns (naja, zumindest nicht extra – sie stehen natürlich in den Server-Logs, die wir aber alle paar Tage anonymisieren und löschen), sondern zeigen sie dir nur an. Das mag in manchen Situationen nützlich sein.

Der Kurzlink dorthin:

http://faq-o-matic.net/werbinich

Keine verwandten Beiträge.

Die neue Funktion erlaubt es, einen einheitlichen DHCP-Adressbereich gleichzeitig und vollständig auf zwei Servern bereitzuhalten. Eine Aufteilung auf beide Server ist nicht notwendig, denn die Partner gleichen ihren Adresspool und die Leases untereinander ab. Das vermeidet eine Reihe von Einschränkungen, die im klassischen “Split Scope”-Verfahren vorliegen. Das Failover-Feature setzt genau zwei Server voraus, größere Verbünde lassen sich damit nicht aufbauen.

Die Einrichtung erfolgt assistentengesteuert oder per PowerShell. Zwischen den beteiligten DHCP-Servern erzeugt die Administratorin eine Failover-Partnerschaft, die sich auf einen, mehrere oder alle IP-Adressbereiche  bezieht, die per DHCP verteilt werden. Für jeden Bereich kann man dabei aus zwei Optionen wählen:

1. Load Balancing: Neben dem Failover im Fall eines Serverfehlers arbeiten beide DHCP-Server im Normalbetrieb parallel und versorgen Clients mit IP-Konfigurationen. Dadurch entsteht eine Aktiv-/Aktiv-Partnerschaft.
2. Hot Standby: Die einfachere Konfiguration arbeitet mit einem primären und einem Standby-Server. Nur wenn der primäre Server einen Scope nicht mehr bedient, springt der Standby-Server ein. Hierfür lässt sich vorab ein Teil der Adressen reservieren.

Die Einrichtung der neuen Funktion ist recht einfach und weitgehend selbsterklärend.

Neben dieser Funktion wird der neue DHCP-Server auch ein “Policy-based Assignment” unterstützen, mit dem verschiedene Adressbereiche und Konfigurationen auf Basis selbst definierter Richtlinien an DHCP-Clients ausgegeben werden. Das erlaubt eine gezielte Segmentierung des Netzwerks nach logischen Kriterien bei vergleichsweise einfacher Administration.

Verwandte Beiträge:

1. Wie kann man einen DHCP-Server unter Windows ausfallsicher gestalten?
   Der erste Gedanke zielt an dieser Stelle meist in Richtung...
2. DHCP-Server autorisieren ohne Organisations-Admin-Rechte
   Um in einer Active-Directory-Umgebung einen auf Windows 2000/2003 basierenden DHCP-Server...
3. Dynamische DNS-Updates seit Vista nicht mehr per DHCP-Client
   Gerade machte Yusuf Dikmenoglu auf ein Detail aufmerksam, das ich...

Erweiterte Grundfunktionen

Einige Netzwerk-Neuerungen haben direkt ins Betriebssystem Einzug gefunden und sind keine Spezialität von Hyper-V. Dazu zählt vor allem das Teaming von Netzwerkkarten – auch dies durchaus eine Sensation, denn bislang (also auch bei Windows Server 2008 R2) hat Microsoft diese Technik vollständig auf die Hersteller der Netzwerkkarten abgeschoben. Zwar empfehlen die Redmonder auch heute (mit Windows Server 2008 R2) den Einsatz des Teaming, sie unterstützen es aber nicht selbst. Gibt es damit also Probleme, so muss der Treiber-Hersteller diese lösen.

Mit dem neuen Server-Windows scheint das nun anders zu werden. Zukünftig wird Windows Teams auch über Karten verschiedener Hersteller bilden können, und es dürfen mehr als zwei Karten beteiligt sein. Das Team dient dann sowohl für Failoverzwecke (beim Ausfall einer Karte bzw. einer Netzwerkverbindung läuft der Traffic über die andere Verbindung weiter) als auch für den Lastenausgleich (im Normalbetrieb nutzt Windows alle Verbindungen gleichzeitig und verteilt den Traffic darüber). Daher verwendet Microsoft den Ausdruck “LBFO” (“Load Balancing and Fail-over”). Es ist dabei nicht einmal notwendig, dass die physischen Switches “hinter” dem Server das Teaming direkt unterstützen, denn es gibt einen “Switch Independent Mode”, den man bei Bedarf auswählen kann. Interessant dabei: Das Teaming soll auch remote verwaltbar sein.

WLAN soll mit Hyper-V 3.0 auch im VM-Gast nutzbar sein. Bislang waren dafür immer einige (nicht supportete) Workarounds nötig, weil Microsoft auf dem Host nur LAN-Adapter zur Virtualisierung vorgesehen hatte.

Derzeit anscheinend noch nicht nutzbar ist die “Guest IP Address Injection”, mit der eine VM (wahrscheinlich) eine bestimmte IP-Konfiguration gewissermaßen “von außen” erhält. Was es damit genau auf sich hat, ist noch unklar, denn der einzige Hinweis auf diese Funktion stammt aus einer neuen BPA-Regel (Best Practices Analyzer), die noch nicht angewandt wird.

Hardwarebeschleunigung

In der neuen Fassung wird Hyper-V gleich mehrere Techniken zur Hardwarebeschleunigung von Netzwerkverbindungen enthalten. Neben der eher speziellen Möglichkeit, die Netzwerkverschlüsselung per IPSec von der Netzwerkkarte erledigen lässt, sind hierbei VMQ (Virtual Machine Queue) und SR-IOV relevant. Beide erfordern spezielle Netzwerkkarten im Host.

• VMQ ist bereits in Windows Server 2008 R2 verfügbar. Damit ist es möglich, die Verarbeitung des Netzwerktraffics durch mehrere Host-CPUs erledigen zu lassen. Ohne VMQ nutzt der Host immer nur eine einzige seiner CPUs für das Netzwerk. Durch VMQ kann man den Netzwerkverkehr in mehrere interne Queues aufteilen, die von mehreren CPUs abgearbeitet werden. In 2008 R2 weist man dazu statisch mehrere CPUs zu.
  Hyper-V 3.0 ermöglicht die dynamische CPU-Zuweisung abhängig von der aktuellen Last. Gibt es viel Netzwerkverkehr, so kann Hyper-V mehrere CPUs zur Verarbeitung einbinden. Ist wenig los, dann reduziert der Hypervisor die verarbeitenden CPUs.
• SR-IOV ist eine neue Technik, mit der sich leistungsfähige Netzwerkkarten in mehrere logische Karten (VF, Virtual Function) partitionieren lassen. Die Ansprache dieser VFs geschieht dann direkt durch die VM oder VMs, die einen vSwitch nutzen, der auf einer solchen VF beruht. Dadurch ist die Netzwerkansprache direkter und muss nicht mehr durch die Parent Partition laufen. In Hyper-V 3.0 ist es dazu nötig, dass die Zuweisung eines vSwitch zu einer VF beim Erzeugen des vSwitch geschieht. Im Fall einer Live Migration auf einen Host ohne SR-IOV kann die betreffende VM auf einen “konventionellen” vSwitch umschalten.

Switch-Logik

Dramatisch erweitert hat Microsoft die Logik innerhalb der vSwitches. Das neue Switch-Modell arbeitet als “Extensible vSwitch” und bringt schon einige Ergänzungen mit. Besonders interessant ist aber das darunterliegende API, das auch von Drittanbietern zur Erweiterung der Switch-Funktionen genutzt werden kann.

Direkt integriert sind ein paar Schutzfunktionen:

• DHCP Guard: Der vSwitch kann so konfiguriert werden, dass er DHCP-Serverinformationen nur von bestimmten VMs durchlässt, die als DHCP-Server vorgesehen sind. Falls eine VM eigentlich kein DHCP-Server sein soll, aber aufgrund einer Fehlkonfiguration doch DHCP-Serverpakete verschickt, so unterdrückt der vSwitch diese Pakete.
• Router Guard: Diese Funktion ist sehr ähnlich, unterdrückt aber Router-Informationen von VMs, die nicht als Router arbeiten sollen.
• Netzwerk-ACLs: Ein vSwitch kann so konfiguriert werden, dass er nur Verkehr für VMs mit bestimmten IP- oder MAC-Adressen weiterleitet. Damit lässt sich steuern, welche VM mit welchem anderen System kommunizieren darf. Derzeit scheint man dies nur per PowerShell konfigurieren zu können.
• Bandbreitensteuerung: Eine QoS-Funktion (Quality of Service) kann man nun pro VM einrichten. Damit legt man fest, welche minimale oder maximale Netzwerk-Bandbreite eine VM nutzen kann.
  

Das Kernkonzept sind aber die “Switch Extensions”, die man pro vSwitch einrichten und je nach Anbieter detailliert konfigurieren kann. Das Extension-Modell unterstützt mehrere Kategorien von Erweiterungen, etwa zum Filtern des Verkehrs (die Funktionen ähneln dann einer Firewall), zum Überwachen (für Monitoring-Zwecke) oder für die Verwaltung von Switches. Das Konzept folgt einem Plug-in-Ansatz, sodass mehrere Erweiterungen parallel nutzbar sind und jede Erweiterung sich nur um ihre eigene Funktion kümmern muss. Jede Erweiterung kann im laufenden Betrieb ein- und ausgeschaltet werden. Dabei sind die Konfigurationen der Erweiterungen bei einer Live Migration auch auf andere Hosts übertragbar. Eingebaut sind zwei rudimentäre Erweiterungen für WPF-basierte Filter (Windows Filtering Platform) und für das Monitoring (NDIS-Monitor). Damit lässt sich bereits der Verkehr eines vSwitches zu einer VM an ein anderes System für die Auswertung weiterleiten.

In einem Build-Video zeigen einige externe Anbieter interessante Zusatzfunktionen für die Extensible Switches:

• Firewall-Funktionen
• Monitoring
• Einheitliche Verwaltung von physischen und virtuellen Switches

[Extending the Hyper-V switch | BUILD2011 | Channel 9]
http://channel9.msdn.com/Events/BUILD/BUILD2011/SAC-559T

Verwandte Beiträge:

1. Hyper-V 3.0: Was (wahrscheinlich) kommt, Teil 3
   Dies ist der dritte Teil unserer kleinen Artikelserie zu den...
2. Hyper-V 3.0: Was (wahrscheinlich) kommt, Teil 1
   Eine der Funktionen, die Microsoft im kommenden Windows Server “8”...
3. Hyper-V 3.0: Was (wahrscheinlich) kommt, Teil 4
   Hier als letzter Teil unserer kleinen Artikelserie zu Hyper-V 3.0...

Diejenigen die sich schon einmal intensiv mit Windows Updates und dem Windows Server Updates Services (WSUS) beschäftigt haben, kennen vermutlich den BITS (Background Intelligent Transfer Service) – zu Deutsch: Intelligenter Hintergrundübertragungsdienst. Doch was macht diesen Dienst nun intelligent und wofür kann ich ihn eventuell selber nutzen?

Es kommt bei meiner Arbeit nicht selten vor, dass ich eine größere Installation auf einem entfernten Kundensystem plane, für die zuvor einige Dateien (ISO-Abbilder, Installationspakete etc.) heruntergeladen werden müssen. Bevor ich nun gebrannte DVDs via Post versende oder die Dateien direkt herunterlade und so die Internetverbindung des Kunden “belaste”, nutze ich lieber eine bereits im Betriebssystem enthaltene Funktion: den BITS.

Funktionsweise

Der intelligente Hintergrundübertragungsdienst (BITS) verwaltet auf einem Standardsystem unter Windows typischerweise Downloads von Windows Update (auch WSUS). Dazu misst er während der Download-Vorgänge ständig die verfügbare Bandbreite des Systems – benötigen andere Anwendungen oder Dienste die volle Bandbreite, so pausiert BITS seine Download-Jobs. Dabei überträgt BITS die Daten im Hintergrund über HTTP oder auch HTTPS als Systemdienst. Jeder Download-Auftrag besteht wenigstens aus einer Quell-Datei (URL) und einem Ziel (Pfad).

How-To oder wie nutze ich BITS für meine Downloads?

Typischerweise nutze ich für meine Hintergrund-Downloads auf entfernten Systemen die folgenden Komponenten – vorausgesetzt der Intelligente Hintergrundübertragungsdienst (BITS) und das .NET Framework 2.0 sind installiert (beides ist unter Windows Server 2008 der Fall):

• Gruppenrichtlinien-Einstellung (für die Begrenzung der genutzten Bandbreite)
• NetSpeedMonitor (zur Kontrolle der Download-Rate)
• BITS Download Manager (für das Anlegen von Download-Aufträgen)

Vor dem ersten Download sollte man mit Hilfe der Gruppenrichtlinien (entweder bei einer Domäne zentral administriert oder via gpedit.msc für die lokale Richtlinie) eine maximale Bandbreitenbeschränkung definieren, um die Bandbreite der Internetverbindung (die auch andere Benutzer verwenden) nicht zu blockieren. Dies geschieht in der Computerkonfiguration der Richtlinie im Zweig Administrative Vorlagen, Netzwerk, Intelligenter Hintergrundübertragungsdienst (BITS):

Die Einstellung Maximale Netzwerkbandbreite für BITS-Übertragungen im Hintergrund begrenzen sorgt nun dafür, dass die verwendete Bandbreite für Haupt- und Nebengeschäftszeiten limitiert werden kann – im folgenden Beispiel von 8.00 Uhr bis 17.00 Uhr auf 100 kBit/s in der übrigen Zeit auf 100.000 kBit/s:

Wer dieser Einstellung nicht traut, kann selbige mit Hilfe des (überaus nützlichen) Tools NetSpeedMonitor von Florian Gilles kontrollieren. Dieses Programm (verfügbar als 32 Bit- und 64 Bit-Version, ab Windows Server 2003) bietet nach der Installation eine eigene Symbolleiste in der Taskleiste, auf der die aktuellen Download- und Uploadwerte für eine gewählte Netzwerkverbindung angezeigt werden und ist zudem kompakt und granular konfigurierbar:

Nach dem Download und der Installation des (schon etwas betagten) BITS Download Managers können nun URLs zum Download hinzugefügt werden. Die Downloads starten anschließend automatisch und können auch manuell pausiert, gestoppt oder gelöscht werden:

Wie schon erwähnt, kann das Programm nach dem Hinzufügen und während der Ausführung eines Auftrages geschlossen werden, die Download-Rate wird automatisch durch die Gruppenrichtlinie Uhrzeit-bedingt angepasst wird. Eine feine Sache, wie ich finde.

Bei der Erstellung eines Download-Auftrages erstellt der BITS im Zielverzeichnis eine temporäre Datei (BITxxxx.tmp) mit der Größe der Quelldatei, die dann “gefüllt” wird – somit wird der vollständige Speicherplatz im Vorfeld reserviert.

Alternativ kann man zum BITS Download Manager auch das BITSAdmin Tool von Microsoft verwenden, es ist in den Support Tools des Betriebssystems enthalten (ab Windows Server 2003 SP1). Seit Windows Server 2008 ist dieses Programm zwar bereits nach der Installation verfügbar, es wird aber empfohlen, die BITS Powershell CmdLets zu nutzen, die innerhalb der Powershell einmalig importiert werden müssen:

Import-Module BitsTransfer

Allerdings muss bei diesen Tools auf eine grafische Oberfläche verzichtet und mit der Kommandozeile vorlieb genommen werden – die Funktionsweise ist die gleiche.

Problem der Download-Pausierung bei Abmeldung

Hat man einen BITS-Job (und eine Datei) angelegt, so ist man automatisch Eigentümer (Owner) dieses Auftrags. Dies lässt sich leicht mit Hilfe des Befehls

bitsadmin /list /allusers /verbose

kontrollieren. Meldet sich nun der Benutzer vom betreffenden System ab, wird auch der Download pausiert (der Status wechselt von TRANSFERRING in QUEUED). Dieses Verhalten lässt sich aber durch einen kleinen Trick umgehen:

Zunächst benötigen wir die GUID des BITS-Jobs, die man mit Hilfe des zuvor beschriebenen Befehls erhält. Des weiteren benötigt man das Tool psexec von Sysinternals um im Anschluss den Eigentümer des Jobs zu ändern:

psexec -s bitsadmin /takeownership {GUID}

Durch die Option -s führt PsExec den Folgebefehl als Systemkonto aus – dadurch wird der Owner des Jobs in NT-AUTORITÄT\SYSTEM geändert. Meldet man sich nun von dem Server ab, so kann man leicht von einem anderen System mit dem Befehl

psexec -s \\<Server> bitsadmin /getbytestransferred {GUID}

den Fortschritt des entsprechenden Jobs prüfen. Somit muss man für einen eigenen Download mit BITS nicht am System angemeldet bleiben. Einziger Nachteil ist, dass der BITS Download Manager nun die Jobs nicht mehr anzeigt (da der Eigentümer geändert wurde), dies muss man nun mit dem bitsadmin-Tool oder den Powershell-Befehlen erledigen.

Fazit

Wer ab und zu größere Downloads im Hintergrund auf Servern durchführen will, ohne dabei die Internetverbindung zu Hauptgeschäftszeiten zu blockieren bzw. zu beeinflussen – für den ist die Nutzung des BITS eine gute und praktikable Lösung. Downloads werden bei Unterbrechung automatisch fortgesetzt, die zu nutzende Bandbreite ist limitiert. Mit Hilfe des BITS Download Managers kann man sich schnell einen Fortschritts-Überblick verschaffen oder Aufträge hinzufügen oder abbrechen.

Mit Hilfe des beschriebenen Workarounds kann man sich auch vom System abmelden und die Downloads werden im Hintergrund heruntergeladen.

Verwandte Beiträge:

1. Intelligent Message Filter aktualisieren
   Nachdem der IMF (Intelligent Message Filter) mit SP2 für Exchange...
2. Eigene Patches über WSUS ausrollen
   Die Windows Server Update Services (WSUS) verteilen in vielen Unternehmen...
3. Downloads
   Unsere Downloads gruppieren sich derzeit in folgende Kategorien: Dokumente: Das...

Und: Natürlich ist die Software kostenlos.

[NetworkTrayTool - Quick access to your Network Connections]
http://www.gruppenrichtlinien.de/tools/Networktraytool.htm

Verwandte Beiträge:

1. BGInfo per Gruppenrichtlinien ausrollen
   BGInfo ist ein sehr nützliches kleines Werkzeug von Sysinternals, das...
2. Gruppenrichtlinien per Skript lesen und schreiben
   ReadPol.vbs liest und schreibt (!) registry.pol-Dateien, die in Gruppenrichtlinien verwendet...
3. Windows 7 und Watchguard-VPN
   Ich stehe kurz davor, Windows 7 (RC) in den Produktionsbetrieb...

Das folgende Skript hilft: Es deaktiviert die Netzwerkverbindung und schaltet sie wieder an. Das Skript muss man mit Administrator-Rechten ausführen. Wem es so geht wie mir, kann sich eine Verknüpfung zu dem Batch auf den Desktop legen und dort aktivieren, dass es als Administrator ausgeführt werden soll. Dann reicht ein Doppelklick und die UAC-Abfrage.

WLAN-ein-aus.bat

@echo off
netsh interface set interface "Drahtlosnetzwerkverbindung" disable
pause
netsh interface set interface "Drahtlosnetzwerkverbindung" enable

Verwandte Beiträge:

1. Watchguard-VPN verbindet nach Ruhezustand nicht
   Auf meinem Notebook ist unter Windows 7 der Watchguard-VPN-Client installiert....
2. Drucker, WLAN und Strom
   So, habe gerade per Fernwartung bei einem Kunden einen Drucker...
3. Exchange 2007: Dienste starten nicht nach Rollup Update 5
   Mit dem Rollup Update 5 für den Exchange Server 2007...

In einem Technik-Video stellen wir das Konzept genauer vor.

Atmo: Was nach der Wolke kommt von faq-o-matic.net auf Vimeo.

Atmo ist ein völlig neues Konzept für Computing, Netzwerke und Datenzugriff. Unser Video stellt die Idee, die Technik, die Erfinder und den aktuellen Entwicklungsstand vor.

Verwandte Beiträge:

1. Hyper-V 3.0: Was (wahrscheinlich) kommt, Teil 2
   Diese zweite Folge unserer Artikelserie zu Hyper-V 3.0 konzentriert sich...
2. Watchguard-VPN verbindet nach Ruhezustand nicht
   Auf meinem Notebook ist unter Windows 7 der Watchguard-VPN-Client installiert....
3. WLAN nach Standby neu starten
   Der WLAN-Treiber meines Notebooks unter Windows 7 mag nach dem...

[A More Beautiful Web Launches on March 14th]
http://windowsteamblog.com/ie/b/ie/archive/2011/03/09/a-more-beautiful-web-launches-on-march-14th.aspx

Verwandte Beiträge:

1. WebDAV: Dateien sicher übers Internet übertragen
   Viele Admins stehen vor der Aufgabe, mobilen Mitarbeitern den Zugriff auf...
2. Vista SP1 kommt doch früher
   Nachdem in der letzten Woche die Nachricht die Runde machte,...
3. Windows 7: Der RC kommt! Nee – doch?!
   Kurz vor dem Release eines neuen Kernprodukts wird es ja...

Kürzlich habe ich in unserem Unternehmen ein sicheres WLAN aufgebaut – eigentlich zu Evaluierungszwecken gedacht, hat sich die Lösung doch recht schnell zu einer praktikablen und sicheren Variante zur Nutzung für unsere Mitarbeiter etabliert. Bei der Übertragung von Daten steht nach wie vor das Thema Sicherheit im Vordergrund – gerade was das Thema WLAN angeht, sollte die Sensibilität für sichere Verbindungen vorhanden sein. Der folgende Artikel beschreibt, wie ich das Thema umgesetzt habe, stellt aber ganz sicher nicht die praktikabelste Lösung für alle denkbaren Einsatzzwecke dar. Allein die Tatsache, dass mit Hilfe von Windows-Bordmitteln die Umsetzung einen relativ geringen Aufwand verursachte, macht diese Möglichkeit meiner Meinung nach sehr interessant.

Anforderungen an Funknetzwerke

Bevor man sich an die Umsetzung eines WLANs macht, sollte man sich im Vorfeld mit den gängigen, möglichen Sicherheitsstandards vertraut machen. Auch für Betreiber eines bereits eingerichteten Funknetzwerkes sollte die regelmäßige Prüfung der Konfiguration in Bezug auf Sicherheit und Stabilität in gewissen Abständen kontrolliert und ggf. angepasst werden. Da ein offenes Funknetz für den Betreiber ein rechtliches Risiko darstellt, sollte eine sichere Authentifizierung und Verschlüsslung des Datenverkehrs hohe Priorität besitzen.

Die Entscheidung für das im Titel genannte Verfahren fiel auf Grund der in einer Evaluation untersuchten Möglichkeit, Funk-Verbindungen für Benutzer mit individuellen Zugangsdaten zu ermöglichen, deren Zugriffe nicht nur verschlüsselt, sondern auch hinreichend protokolliert werden sollten. Diese Anforderungen lassen sich sehr gut mit der Funktion WPA2-Enterprise umsetzen. Da ich hier nicht die vollständige Funktionsweise des Authentifizierungsverfahrens 802.1X erläutern will, verweise ich für Interessierte an dieser Stelle auf den sehr guten Artikel von Stefan Krecher bei heise Netze: WLAN und LAN sichern mit IEEE 802.1X und Radius.

Sicherheit

Grundsätzlich wird bei 802.1X das Extensible Authentication Protocol (EAP) verwendet, welches im OSI-Modell auf Ebene 2 arbeitet und dabei lediglich Authentifizierungs-Anfragen und Antworten überträgt. Da diese Daten teilweise unverschlüsselt übertragen werden, gibt es verschiedene Varianten, die die Sicherheit von EAP erhöhen.

Im folgenden Beispiel beziehe ich mich auf den Einsatz des Protected EAP (EAP-MSCHAP-v2). Diese Methode ist relativ leicht zu konfigurieren und stellt ein Mittelmaß an Aufwand und Sicherheit dar. Wer absolute Sicherheit verlangt, muss sich zwangsläufig mit der Methode PEAP mit Zertifikaten (EAP-TLS) auseinandersetzen, der Aufwand für die Einrichtung ist allerdings sehr groß. Da sich bei meiner Umsetzung die WLAN-Endgeräte (sowie der DHCP-Server für die IP-Adressvergabe) in einem abgetrennten, durch eine Firewall geschützten, Netzwerkabschnitt befinden, ist die Methode EAP-MSCHAP-v2 für uns ausreichend sicher.

Voraussetzungen

Hardware

Um ein WLAN aufzubauen, benötigt man selbstverständlich die entsprechenden Hardwarekomponenten. Im einfachsten Fall – eine vorhandene Netzwerkinfrastruktur vorausgesetzt – genügt hierfür bereits ein einzelner Access Point, abhängig von der Abdeckung des zu versorgenden Bereichs. Das Gerät sollte WPA2 beherrschen, die Konfiguration sollte auf das verkabelte Netzwerk beschränkbar und durch eine Authentifizierung schützbar sein. Die Clientgeräte müssen natürlich ebenfalls den verwendeten Standard WPA2 unterstützen – dazu aber später mehr.

Windows Server: Softwarekomponenten

Ich war erstaunt, was mit Hilfe der im Windows Server integrierten Komponenten, ohne Zukauf bzw. Einsatz von weiteren Produkten, realisierbar ist. In folgenden Beispiel gehe ich von der "kleinsten" Umgebung aus, sowohl was die Betriebssystemversion als auch die Edition betrifft. Benötigt wird:

• eine Domäne mit mindestens Windows Server 2003, Standard Edition
• eine eingerichtete Microsoft Stammzertifizierungsstelle (Root Certificate Authority)
• einen Microsoft DHCP Server
• einen Microsoft Internet Authentication Server (IAS), der RADIUS Server

Es ist durchaus denk- und machbar, die drei letzteren Rollen auf dem Domänencontroller zu installieren, in größeren Umgebungen sollte man diese aber auf eigenen Servern installieren. Die Lösung ist auch unter Windows Server 2008 (R2) umsetzbar, lediglich der Name der Rolle des IAS hat sich in Network Policy Server (NPS) geändert. Selbiger bietet in Verbindung mit NAP (Network Access Protection) eine Fülle von neuen Funktionen, die allerdings nur bei reiner Nutzung von Windows Clientgeräten wirklich sinnvoll ist. In der Standard Edition von Windows Server werden vom IAS maximal 50 Clientgeräte und 2 Remote-RADIUS-Servergruppen unterstützt, was für die meisten, kleineren Umgebungen ausreichend sein sollte, mit der Enterprise Version ist diese Limitierung aufgehoben.

Einrichtung

Access Point

Abhängig vom Hersteller weicht die Konfiguration des Gerätes in der Menüführung ab. Unabhängig davon gibt es aber für die Umsetzung der Lösung folgende zu konfigurierende Werte:

• Netzwerkkonfiguration des Access Points: IP Adresse, DNS Server, NTP Server und Default Gateway
• SSID (Service Set Identifier): Bezeichner bzw. Name des Funknetzwerkes
  (die Möglichkeit die SSID "unsichtbar" zu machen ist trotz oftmals gegenteiliger Behauptung weitgehend nutzlos: Artikel bei heise.de)
• Funkkanal: abhängig von bereits existierenden Netzwerken sollte hier möglichst ein unbenutzter, freier Kanal genutzt werden, um Störquellen auszuschließen
• Sicherheitsmodus: hier ist WPA2-Enterprise auszuwählen (auch WPA2-802.1.X oder WPA2-1X genannt)
• RADIUS Server: IP Adresse oder DNS-Name des Internet Authentication Servers (IAS)
• RADIUS Server Port: im Standard 1812, bei Änderung auch im IAS einzustellen
• Verschlüsselung: sollte bei WPA2 automatisch auf AES eingestellt sein
• Shared Secret: Passwort für die verschlüsselte Kommunikation zwischen Access Point und IAS

Es existieren außerdem noch viele weitere Einstellmöglichkeiten, die sich aber fast ausschließlich auf die Qualität der Funkverbindungen beziehen.

Zertifikat durch interne Zertifizierungsstelle

Damit der IAS später eine sichere, verschlüsselte Verbindung zur Authentifizierung des WLAN Clients aufbauen kann, benötigt dieser beim Verfahren Geschütztes EAP (PEAP) ein Computerzertifikat (Zweck: Serverauthentfizierung). Ist noch keine interne, private Zertifizierungsstelle vorhanden, muss diese zuvor installiert werden (entweder auf einem Domänencontroller oder Domänenmitgliedserver, über Windows-Komponenten).

Auf dem späteren IAS-Server muss das Computerzertifikat nun beantragt werden. Der einfachste Weg (wenn nur ein Zertifikat benötigt wird), stellt die Anforderung eines neuen Zertifikates auf dem IAS Server im MMC Zertifikate (Snap-In hinzufügen, Hinzufügen, Zertifikate für lokalen Computer) dar.

Wesentlich eleganter – da hier bei Ablauf des Zertifikates selbiges automatisch erneuert wird – ist die Ausstellung von Zertifikaten über Gruppenrichtlinien. Dafür sind innerhalb der Gruppenrichtlinie die folgenden Einstellungen zu treffen:

Unter Computerkonfiguration, Windows-Einstellungen, Sicherheitseinstellungen, Richtlinien öffentlicher Schlüssel kann die Einstellung der automatischen Zertifikatsregistrierung vorgenommen werden. In der Einstellung für die automatische Anforderung des Zertifikats muss nun noch eine neue Vorlage für den Typ Computer hinzugefügt werden:

Danach muss noch das Zertifikat der Zertifizierungsstelle unter dem Punkt Vertrauenswürdige Stammzertifizierungsstellen importiert werden, damit alle von ihr ausgestellten Zertifikate auf den von der GPO betroffenen Computern als vertrauenswürdig behandelt werden:

Wird die Gruppenrichtlinie nun auf den IAS Server angewendet, erhält dieser automatisch ein Computerzertifikat, welches bei Ablauf auch erneuert wird. Damit sind Voraussetzungen für den IAS Server geschaffen, eine verschlüsselte Verbindung für die Authentifizierungsmethode PEAP herzustellen.

Internet Authentication Server (IAS) – RADIUS Server

Wird der IAS auf einem eigenständigen Server installiert, so muss dieser Mitglied der Domäne sein (Grund: Computerzertifikat und lokale Authentifizierung – siehe unten). Unter Windows Server 2003 wird der Internetauthentifizierungsdienst als Netzwerkdienst der Windows-Komponenten installiert:

Seit Windows Server 2008 (R2) heißt diese Option nun Network Policy Server (Netzwerk-Richtlinien-Server) und lässt sich als Rolle nachträglich hinzufügen – der Funktionsumfang ist zwar wesentlich erweitert wurden, es handelt sich aber auch hier um einen RADIUS Server zur Authentifizierung und Kontoführung.

Nach der Installation kann der IAS über die MMC Internetauthentifizierungsdienst administriert werden.

In den Einstellungen des IAS können außer der Beschreibung des Servers und der im Ereignisprotokoll einzutragenden Authentifizierungsanforderungen auch die Ports für Authentifizierung und Kontoführung geändert werden:

Hier ist der gleiche Port (wie im Access Point definiert) zu verwenden (siehe RADIUS Server Port). Anschließend kann im Bereich RADIUS-Clients ein neuer Eintrag erstellt werden:

Neben dem Anzeige-Namen wird hier die IP-Adresse (bzw. DNS-Name) des Access Points eingetragen. Für die sichere, verschlüsselte Kommunikation zwischen RADIUS-Client (Access Point) und IAS muss das Shared Secret verwendet werden, welches ebenfalls zuvor im Access Point hinterlegt wurde.

Im nächsten Schritt kann eine neue Verbindungsanforderungsrichtlinie erstellt werden. Diese Richtlinie definiert, ob der IAS eine Authentifizierungs-Anforderung (Request) lokal (in der Domäne in der sich der IAS befindet) authentifiziert oder ob er als Proxy diese Anfrage an einen Remote-RADIUS-Server (bspw. an einen IAS in einer anderen Domäne) weiterleiten soll. In meinem Beispiel soll der IAS lokal in der selben Domäne authentifizieren, weswegen der IAS im Active Directory zunächst registriert wird (Server muss Domänenmitglied sein):

Durch diese Einstellung erhält der IAS das Recht, die RAS-Eigenschaften der Benutzerkonten innerhalb der Domäne zu lesen. Befindet sich der IAS in einer anderen Domäne als in der, die die Benutzerkonten für die Authentifizierung enthält, so kann die Registrierung über den folgenden Befehl auf der Kommandozeile umgesetzt werden (Beispiel: Der IAS befindet sich in der Root-Domäne der Gesamtstruktur, die Benutzerkonten in einer Sub-Domäne.):

netsh ras add registeredserver Domäne IASServer

Anschließend wird nun eine neue Verbindungsanforderungsrichtlinie erstellt:

Wie im obigen Beispiel erkennbar, kann durch die Konfiguration der Bedingungen (hier Client-IP und Name des Access Points) festgelegt werden, welche Anforderungen durch diese Richtlinie verarbeitet werden sollen. Im Profil dieser Richtlinie wird wiederum eingestellt, wo die Anforderungen authentifiziert werden sollen – im meinem Beispiel lokal innerhalb der Domäne:

Nun muss im IAS noch definiert werden, wer sich wann und wie einwählen darf.

Dies geschieht über die Definition einer neuen RAS-Richtlinie:

Im obigen Beispiel wird die Einwahl nur für Mitglieder einer bestimmte Sicherheitsgruppe erlaubt, die sich über IEEE 802.11 (also WLAN) einwählen und authentifizieren sollen. Die Sicherheitsgruppe muss selbstverständlich innerhalb der Domäne existieren. Deren Mitglieder (Benutzerkonten) werden später auf den Clientgeräten für die Authentifizierung verwendet.

Wichtig: Diese Richtlinie nur beachtet, wenn auch die Bedingungen der Verbindungsanforderungsrichtlinie zutreffen.

Im Profil der RAS-Richtlinie können nun weitere granulare Einstellungen für den Zugriff der WLAN Teilnehmer getroffen werden:

Ist im Netzwerk des Access Points ein DHCP-Server vorhanden, kann durch die obige Einstellung erlaubt werden, dass dieser dem WLAN-Client eine IP-Adresse zuweist. Im Reiter Authentifizierung kann nun (auf Basis des zuvor erstellten Computerzertifikats) die Einstellung für das Verfahren PEAP (Protected EAP) getroffen werden:

In den Einwähleinschränkungen der RAS-Richtlinie kann der Zugriff für die W-LAN Teilnehmer weiter eingegrenzt und gesichert werden. Über den NAS-Porttyp (Network Access Server, RADIUS Attribut 61) wird der Zugriff auf das Medium WLAN beschränkt :

Außerdem lässt sich in diesem Reiter auch die Uhrzeit für den Zugriff einstellen.

Achtung: Doch aufgepasst, Microsoft hat (bei der Deutschen Version) einen Fehler im Fenster für die Auswahl der Einwählzeiten "versteckt". Möchte man beispielsweise den Zugriff nur an Wochentagen (Montag bis Freitag) in den Zeiten von 7:00 Uhr bis 22:00 Uhr zulassen und wählt diese Felder aus, so werden die Tage als Sonntag bis Donnerstag gespeichert. Um die richtigen Wochentage einzustellen, sind folgende Felder (Dienstag bis Samstag) zu markieren:

Nach Abschluss dieser Einstellungen ist der IAS Server bereit, W-LAN Clientbenutzer über 802.1X mit PEAP zu authentifizieren.

Konfiguration der Clientgeräte

Abschließend fehlt noch die Konfiguration der entsprechenden Clientgeräte, die abhängig von dem verwendeten Betriebssystem entsprechend durchgeführt werden muss. Für das oben beschriebene Authentifizierungs- und Verschlüsselungsverfahren konnte ich in meinen Tests mit den folgenden Clients (die allesamt WPA2 beherrschen) erfolgreich eine Verbindung herstellen:

• HTC Desire (Android 2.2, Android 1.6 unterstützt noch kein WPA2-Enterprise)
• Apple iPhone 3G und 4G
• Apple iPad
• Ubuntu (Desktop Edition 10.10)
• Windows XP (ab Service Pack 2)
• Windows 7

Da die Einstellung für Windows 7 am aufwändigsten war, möchte ich die dort notwendigen Einstellungen hier noch dokumentieren. Es ist sinnvoll, die neue Drahtlosnetzwerk-Konfiguration manuell durchzuführen, da der Wizard von Windows 7 sonst zu viele automatische Einstellungen vornimmt:

In den Eigenschaften dieser Verbindung sind im Reiter Sicherheit die folgenden Einstellungen vorzunehmen:

Die folgenden Einstellungen für die Authentifizierungsmethode sind zu wählen:

Besitzt der Client das Zertifikat für die interne Stammzertifizierungsstelle noch nicht in seinem Speicher für die vertrauenswürdigen Stammzertifizierungsstellen, so muss dieses zuvor importiert werden. Im Anschluss ist die Authentifizierungsmethode EAP-MSCHAP-v2 auszuwählen und zu konfigurieren:

Der Haken, welcher hier standardmäßig gesetzt ist, muss dann zwingend entfernt werden, wenn die lokale Anmeldung am Clientcomputer nicht dem Benutzerkonto der Sicherheitsgruppe in der Domäne entspricht, die in der RAS-Richtlinie auf dem IAS Server hinterlegt ist. Andernfalls schlägt die Authentifizierung fehl.

In den erweiterten Einstellungen innerhalb der Sicherheitskonfiguration sollte man noch als Authentifizierungsmodus die Benutzerauthentifizierung auswählen, da Windows sonst ebenfalls versucht, das Computerkonto zu verwenden:

Wird das Drahtlosnetzwerk im Anschluss gestartet, so wird man zur Eingabe seiner Authentifizierungsdaten (Benutzername und Kennwort) aufgefordert, welche in den Formen (Username@FQDN oder NETBIOS-Domain-Name\Username) eingeben kann.

Selbstverständlich kann die WLAN Konfiguration auch über Gruppenrichtlinien auf Windows-Clients verteilt werden (Computerkonfiguration, Windows-Einstellungen, Sicherheitseinstellungen, Drahtlosnetzwerkrichtlinien (802.1X)). Mit dieser Gruppenrichtlinie könnte bspw. auch das Zertifikat der Stammzertifizierungsstelle automatisch auf die Clients verteilt werden. In meinem Fall handelt es vorwiegend um Smartphones und einige wenige Notebooks, weswegen ich hier auf eine eigene Anleitung verzichte.

Ablauf der Verbindungsherstellung bei 802.1X

Der Verbindungsaufbau einer authentifizierten, verschlüsselten WLAN-Verbindung ist auf Grund der beschriebenen, vielschichtigen Konfiguration relativ komplex. Ich möchte deshalb an dieser Stelle auf den guten TechNet-Artikel von Microsoft verweisen, in dem der Ablauf beschrieben wird: Grundlegendes zur 802.1X-Authentifizierung für drahtlose Netzwerke.

Protokollierung der Verbindungen

Schon aus Gründen des Nachweises als auch zu Analysezwecken bei eventuell auftauchenden Problemen empfiehlt es sich, die Verbindungs- und Authentifizierungsversuche zu protokollieren. Der IAS Server schreibt im Standard diese Informationen automatisch in sein eigenes Protokoll (Konfiguration unter RAS-Protokollierung), wenn konfiguriert (Eigenschaften des IAS) aber auch im Ereignisprotokoll des IAS Servers:

Das Standard-Protokoll ist umständlich auszuwerten, zumal es keine Beschreibungen sondern nur Werte enthält. Gerade zur Fehleranalyse ist es sinnvoll, das Ereignisprotokoll zu verwenden. Diese Einträge haben das folgende Aussehen (Ausschnitt):

Bei einer ungültigen Authentifizierung hat der Administrator aber auch hier schlechte Karten, da als Ursache für einen Fehler lediglich Fehlercodes protokolliert werden. Erst mit der Tabelle des folgenden TechNet-Artikels von Microsoft Analysieren von Protokolldateien im IAS-Format kann man den Fehler eingrenzen und mit der Behebung beginnen.

Zusätzlich bietet der IAS Server die Möglichkeit alle Informationen über eine ODBC-Verbindung in einer Microsoft SQL Datenbank abzulegen. Dafür muss die entsprechende Datenbank existieren und die Verbindungsdaten konfiguriert werden. Allerdings legt der IAS keinerlei Datenstrukturen automatisch innerhalb der Datenbank an, weswegen alle Versuche einen Eintrag zu schreiben fehlschlagen und alle Verbindungen abgelehnt werden. Microsoft bietet aber zum Download ein Dokument an welches nicht nur das Verfahren detailliert beschreibt, sondern auch alle SQL Befehle für die Erstellung der notwendigen Datenbankstruktur enthält. Danach funktionierte bei mir die Protokollierung einwandfrei. Vorteil dieser Lösung ist, dass man zu Auswertungszwecken relativ schnell Berichte (bspw. über Report-Services des SQL Server) erzeugen kann.

Fazit

Nachdem ich den Artikel noch einmal überflogen habe, muss ich feststellen, dass er ganz schön umfangreich ist – und das liegt klar an der Komplexität des Themas. Allerdings zeigt der Artikel auch, dass mit beherrschbarem Aufwand eine relativ sichere Möglichkeit geschaffen werden kann, um WLAN-Endgeräten den Zugriff auf ein internes Netzwerk zu ermöglichen. Mittlerweile sind mit den Funktionen von Windows Server 2008 (R2) dank Network Protection Server und Network Access Control noch wesentlich mehr Einstellungen möglich, das grundsätzliche Verfahren bleibt jedoch das Gleiche.

Verwandte Beiträge:

1. Wie kann ich sicher prüfen, ob ein Benutzer Mitglied einer bestimmten Gruppe ist?
   Neben der Möglichkeit, für den gerade angemeldeten Benutzer mit dem...
2. Webcast: “Windows 7 und Windows Server 2008 R2: Reif fürs Unternehmen?”
   Am 20. Oktober werde ich einen Webcast zu Windows 7...
3. Windows 7/Server 2008 R2 Service Pack 1: Troubleshooting
   Leider gibt es mit dem Service Pack 1 für Windows...