Blog moved

Hi!

Obwohl ich das ja schon vor längerer Zeit geschrieben habe, hier nochmal der Hinweis, dass der Blog umgezogen ist:

http://ralfwigand.wordpress.com/

Außerdem habe ich noch seit kurzem einen TechNet-Blog unter:

http://blogs.techNet.com/b/ralfwi

Hier also nix Neues mehr!

Ralf.

Veröffentlicht unter Uncategorized | Kommentar hinterlassen

Wofür braucht es eigentlich diesen SPN?

Der SPN, oder ausgeschrieben „Service Principal Name“, ist essentiell für Kerberos Authentifizierungen notwendig. Die Profis mögen mir eine stellenweise drastische Vereinfachung in der kommenden Beschreibung verzeihen, mir geht es um das Verständnis…

Meldet sich ein Benutzer an einer Domäne an, dann bekommt er (wenn er sich erfolgreich authentifizieren konnte) vom Domain Controller ein sogenanntes TGT, ein „Ticket Granting Ticket“. Im realen Leben wäre das etwa vergleichbar mit dem Personalausweis (nach Vorlage einer Geburtsurkunde). Will der Benutzer jetzt auf eine Freigabe auf dem Server „file1“ zugreifen, so wendet er sich erneut vertrauensvoll an den DC und erbittet (unter Vorlage seines TGT) ein Session Ticket für den Dienst „CIFS“ auf Server „file1“. Der DC durchsucht seine – jetzt kommt’s – Liste der SPNs nach etwas wie „cifs/file1“ oder „host/file1“. Diese Liste entsteht zum Beispiel bei Aufnahme von Servern in die Domäne und wird von den DCs im Active Directory gepflegt. Zu diesen SPNs gehören dann Schlüssel und weitere Attribute, die der DC verwendet, um dem anfragenden Client eine Zutrittsgenehmigung, ein Session Ticket, ausstellen zu können.

Findet der DC einen passenden SPN, dann gibt er dem Benutzer ein Ticket mit, das dieser dann wiederum beim „file1“ vorlegen kann. Klingt kompliziert, isses auch. Der Vorteil davon? Nun, der Benutzer kann sich ohne erneutes Passwort an „file1“ anmelden, und „file1“ weiß auch, dass alles korrekt ist, ohne ein Kennwort zu überprüfen oder beim DC nachfragen zu müssen. Im Vergleich zum realen Leben: Für meinen Firmenausweis musste ich meinen Personalausweis vorlegen (nicht meine Geburtsurkunde!). Mit dieser Firmenkarte komm ich in alle Bereiche, in die ich rein darf, und in die anderen eben nicht. Trotzdem muss der Pförtner bzw. die Türkontrolle nicht jedes Mal beim Einwohnermeldeamt nachfragen. Alles klar? Ok.

Was passiert, wenn der DC keinen SPN findet? Und wie kann es dazu kommen? Vielleicht mal mit der zweiten Frage angefangen: Das passiert zum Beispiel ganz häufig, wenn mit CNAMEs, also DNS-Aliasen, gearbeitet wird. Klassisches Beispiel: Der Server „file1“ ist gleichzeitig auch noch Webserver. Ein Benutzer öffnet seinen Internet Explorer und verbindet sich mit http://file1/. Wenn der Webserver auf „Integrierte Windows Authentifizierung“ eingestellt ist, dann fordert der Client im Hintergrund für den Benutzer ein Service Ticket an für den Server „file1“ und den Dienst „http“. Der DC schaut in der Liste der SPNs und stellt das Session Ticket aus, der Client reicht es den „file1“, et voila, Zugriff klappt. Damit die URL etwas eingängiger wird, kommt jetzt jemand auf die Idee und vergibt einen CNAME für den „file1“, sagen wir mal „intranet“. Gleiches Spiel wie eben, Client beantragt ein Session Ticket, DC sucht nach „intranet“ und „http“ und findet – nichts! Netterweise (?) probiert Windows dann noch ein paar andere Authentifizierungsmöglichkeiten durch (je nach Einstellungen) und meistens klappt es dann trotzdem – aber Kerberos ist das nicht mehr.

Abhilfe? Klar. Man kann jederzeit weitere SPNs definieren und einem Host zuordnet. Der magische Befehl dazu heißt „setspn“. Hier ein paar Beispiele:

setspn -L file1   zeigt alle SPNs, die für den Server file1 registriert sind

setspn -L intranet   zeigt erst mal nichts

setspn -A host/intranet file1 registriert einen weiteren SPN für den Namen „intranet“ auf den Host „file1“. Damit wird der DC im oben genannten Beispiel dann ein Session Ticket für „file1“ ausstellen und die Integrierte Windows Authentifizierung klappt.

setspn -?  zeigt übrigens alle Optionen

Wichtig in diesem Zusammenhang: auch noch einen SPN auf den FQDN, den vollständigen Namen, registrieren, und niemals vom System generierte SPNs überschreiben. Wenn der SPN da sein sollte und er ist es nicht, dann ist das ein Fehler, dessen Ursache man finden muss, ein Anlegen „von Hand“ hilft nur bedingt.

Generell gilt hier (wie auch sonst im AD): Know what you are doing!

Veröffentlicht unter Active Directory, Uncategorized, Windows Server | Kommentar hinterlassen

A duplicate name exists – oder auch nicht!

Schon mal passiert? Man versucht, sich mit einem Share zu verbinden, also sowas wie \\server\share, und Windows meldet:

„You are not connected because a duplicate name exists on the network“ oder auch mal gerne „System error 52 has occured. A duplicate name exists on the network“.

Es gibt aber definitiv keinen anderen Server mit dem gleichen Namen. Woher kommt also diese Fehlermeldung? Weiterlesen

Veröffentlicht unter Uncategorized | Kommentar hinterlassen

minimales Passwort-Alter

Manchmal denkt man, eine Funktion verstanden zu haben, und steht dann völlig ratlos da, wenn etwas nicht wie vorhergesagt funktioniert. So ging es mir mit der Einstellung „Minimales Kennwortalter“ in den Windows GPOs. Wie gesagt ist die Funktion eigentlich klar:

Ein Kennwort muss x Tage alt sein, bevor ein Benutzer es das nächste Mal ändern darf!

Aber was passiert, wenn der Benutzer sein Kennwort vergessen hat und der Helpdesk oder der Admin das Kennwort zurücksetzt? Da entstehen ein paar Fragen, und ich bin gespannt, ob jemand alle davon richtig beantworten kann:

  1. Darf der Helpdesk bzw. Admin auch vor Ablauf der Kennwortalter-Frist das Kennwort zurücksetzen?
  2. Wie oft darf der Helpdesk bzw. Admin das Kennwort innerhalb der Kennwortalter-Frist ändern?
  3. Muss der Benutzer dann einen Tag warten, bevor er es selbst wieder ändern kann?
  4. Kann der Helpdesk ein beliebiges Kennwort setzen?
  5. Muss ein Benutzer auf die Kennwort-Historie achten?

Und hier die Antworten:

1) Der Helpdesk oder der Admin kann das Kennwort jederzeit zurücksetzen, die Frist gilt hier nicht.

2) Der Helpdesk oder der Admin darf das Kennwort beliebig oft hintereinander setzen, auch hier gilt keine Frist.

3) Und hier scheitern die meisten… Der Benutzer darf sein Kennwort nämlich tatsächlich erst am nächsten Tag wieder ändern. Davor bekommt er eine (wenig hilfreiche) Fehlermeldung bzgl. Komplexitätsanforderungen etc.

Erst wenn der Helpdesk oder der Administrator zusätzlich noch den Haken „Benutzer muss sein Kennwort beim nächsten Anmelden ändern“ setzt, dann gilt die Frist nicht und er darf es selbst und am gleichen Tag noch ändern. Nach dieser einen Änderung gilt aber wieder die eingestellte Frist bis zur nächsten Änderung (Ausnahmen siehe 1. und 2.). Übrigens ist auch dieser Text etwas verwirrend, denn „…beim nächsten Anmelden“ ist nicht korrekt, der Benutzer kann es vielmehr sofort danach ändern, zum Beispiel über Strg-Alt-Entf.

4. Jain, der Helpdesk kann zwar ein beliebiges Kennwort verwenden, allerdings muss es den Komplexitätsanforderungen hinsichtlich Länge und Sonderzeichen entsprechen. Der Helpdesk kann allerdings ein Passwort verwenden, das der Benutzer schon einmal in Verwendung hatte, d. h. die Passwort-Historie des Benutzers wird nicht überprüft. Der Helpdesk kann also auch ein Standard-Initial-Passwort mehrfach bei einem Benutzer verwenden.

5. Der Benutzer muss beim Ändern des Passwortes die Historie beachten, er darf also keines der letzten x Passwörter erneut verwenden (abhängig von der Einstellung in der Default Domain Policy). Allerdings gibt es einen interessanten Fall, wo die Historie nicht berücksichtigt wird: Beim Login. Wird die Policy verwendet, dass ein Account nach einer bestimmten Anzahl von Fehlversuchen automatisch gesperrt wird (Account Lockout Policy), dann zählen Fehlversuche mit alten Passwörtern nicht! Hat ein Benutzer also vergessen,d ass er sein Passwort geändert hat, oder wurde es vom Helpdesk (ohne Wissen des Benutzers) geändert, dann wird der Benutzer weiterhin versuchen, sich mit dem alten Passwort anzumelden. Und das darf er beliebig oft versuchen, ohne dass die Lockout Policy zuschlägt.

Na, alles gewusst?

Veröffentlicht unter Active Directory, GPO, Windows Server | 1 Kommentar

eventlog nach syslog

Während die meisten Devices im Netz die Möglichkeit haben, per syslog Ereignisse an einen anderen Server zu senden, fehlt dies bei Windows. Auf Clients mag man noch darauf verzichten können, aber in einer gemischten Serverlandschaft hätte das durchaus Vorteile.

  • Die Auswertung der Logfiles aller Komponenten (Windows, Linux, Switche etc) kann an einer zentralen Stelle erfolgen
  • Die Logfiles werden dupliziert auf einen anderen Server und stehen auch nach einem Systemausfall zur Auswertung zur Verfügung
  • Ein Hacker müßte bei einem Angriff in einen weiteren Server eindringen, um seine Spuren zu verwischen. Handelt es sich bei diesem anderen Server gar um eine andere Plattform (zum Beispiel beim Weiterleiten von Events von Windows per syslog auf einen Linux-Server), wird das zusätzlich erschwert.

Ein Mini-Tool, das alle Eventlog-Einträge per UDP an einen Syslog-Server sendet, habe ich vor kurzem mal wieder ausprobiert und bin nach wie vor sehr zufrieden damit. Es nennt sich (sehr spektakulär) „Eventlog to Syslog„, stammt von Sherwin Faria, und liegt in der Version v4.4.3 vom März 2011 kostenlos zum Download bereit unter:

http://code.google.com/p/eventlog-to-syslog/

Nach dem Auspacken der 32bit- oder 64bit-Version kopiert man die evtsys.exe und evtsys.dll in das Windows-Systemverzeichnis (wie in der prima Anleitung beschrieben), wechselt da rein und startet das Tool. Je nach Parameter installiert es sich als Service oder läuft einfach mal nur auf der Kommandozeile (Debug-Modus). Möchte man zum Beispiel einfach alles weiterleiten und den Service installieren, dann reicht ein einmaliges:

evtsys.exe -i -h <logserver.mydomain.com>

Optional kann man weitere Logserver angeben, auch den Port verändern, und noch ein paar andere Dinge. Die 8 Registry-Werte, die der Service anlegt, sind in der Anleitung aufgeführt. Auch ein Uninstall funktioniert sehr einfach. Fehlt noch ein

net start evtsys

und schon werden munter Events an den Logserver gesendet. Die Konfiguration dort hängt natürlich vom verwendeten Logserver ab. Ich habe das mit dem „Kiwi Syslog Service Manager“ auf einem anderen Windows-Server probiert, aber auch schon mal mit syslog-ng auf Linux getestet.

Auch auf Agent-Seite gibt es mehrere Applikationen, die in Frage kommen könnten, zum Beispiel den Correlog-Agent, aber mir reicht der EVTSYS vollständig.

Übrigens gibt es unter Windows Server 2008 natürlich auch die Möglichkeit, Eventlogs von anderen Windows 2008 Servern bzw. Windows 7 Clients zu sammeln (mittels WinRM), aber über verschiedste Plattformen hinweg eben nicht.

Viel Spaß!

Veröffentlicht unter Uncategorized | Kommentar hinterlassen

Technet- und MSDN-Hilfeseiten offline

Hatte schon vor einiger Zeit ein Tool auf CodePlex gefunden, mit dem man Teilbäume von den TechNet- und MSDN-Hilfeseiten herunterladen und offline als CHM abspeichern kann. Das hatte damals noch etwas Probleme mit Bildern, das ist aber in der neuen Version (1.3.4) wohl behoben. Das Tool heißt Package This! und ist ganz einfach zu bedienen.

Starten (als Administrator), dann die gewünschte Sprache auswählen. Auf der linken Seite erscheint der komplette Baum von Hilfethemen in TechNet und läßt sich wie gewohnt erweitern. Ein Haken vor dem Thema wählt die Seite aus zum späteren Verarbeiten, ein Rechtsklick erlaubt, den kompletten Teilbaum zu selektieren.

Package This 1.3.4 Screenshot

Das war es eigentlich auch schon. Export nach Chm oder HxS wählen, Datei angeben, und los gehts. Die Hilfeseiten sind untereinander richtig verlinkt und die Bilder sind ebenfalls eingebettet. Damit sind diese Hilfeseiten auch auf Servern verfügbar, die keinen direkten Internet-Zugang haben.

Viel Spaß damit!

Veröffentlicht unter Windows Server | Kommentar hinterlassen

IPv6 deaktivieren

Wer kein IPv6 braucht, der kann auf folgende Art alle Komponenten deaktivieren (gilt für Windows Server 2008, 2008 R2, Vista und Windows 7):

  • Registry-Editor starten (regedit)
  • Navigieren zu HKEY_LOCAL_MACHINE / SYSTEM / CurrentControlSet / Services / Tcpip6 / Parameters
  • Im rechten Teil einen Rechtsklick, und ein DWORD erzeugen mit dem Namen „DisabledComponents
  • Diesem einen Wert zuweisen (doppelklick) von „ffffffff“ (das ist 8mal das f) in Hex oder „4294967295“ in Dezimal
  • Reboot

Fertig

Veröffentlicht unter Uncategorized | Kommentar hinterlassen

How to (un)destroy your Active Directory

Ist zwar schon ein paar Monate her, aber grade hab ich gemerkt, dass ich die Aufzeichnungen der Demos hier nirgendwo verlinkt habe….

Auf der TechEd 2010 in Berlin habe ich eine Session gehalten mit dem Titel: „How to (un)destroy your Active Directory“. Darin habe ich 10 Fehlerzustände eines ADs gezeigt und deren Behebung vorgeführt. Die Aufzeichung der Demo ist (in 5 Teilen) auf YouTube zu finden. Suchen nach „SIA403“ oder direkt hier zur ersten Demo

Die Session selbst und die PPTs gibt es natürlich auch!

Veröffentlicht unter Active Directory, Windows Server | Verschlagwortet mit | 1 Kommentar

Vorsicht, Falle! Vererbung im AD

Im Active Directory kann man ja, wie allseits bekannt, auf OUs etc. auch Rechte vergeben. Und natürlich lassen sich diese Rechte auch vererben an darunter liegende Objekte. Dass diese Vererbung nicht immer ganz einleuchtend ist, zeigt folgendes Beispiel:

Eine OU=Deutschland, darunter eine OU=Bayern und darunter eine OU=Franken. Dazu noch eine Gruppe CN=Bayrisch,OU=Deutschland und eine Gruppe CN=Hessisch,OU=Deutschland. Alles klar? Wir haben also zwei Gruppen, „Bayrisch” und “Hessisch”, und eine OU Bayern mit einer Unter-OU Franken.

Aufgabenstellung: In der OU Bayern sollen nur Mitglieder der Gruppe “Bayrisch” lesen dürfen. Weiterlesen

Veröffentlicht unter Active Directory, LDAP | Verschlagwortet mit | Kommentar hinterlassen

Gelöschte AD-Objekte von Hand wiederherstellen

Neben all den Tools, die es mittlerweile gibt (Lazarus, RecycleBin), mag es manchmal nötig sein, eben schnell von Hand mit (fast) Bordmitteln ein Objekt wieder zum Leben zu erwecken. Here we go…

Weiterlesen

Veröffentlicht unter Active Directory, Windows Server | Verschlagwortet mit | Kommentar hinterlassen