Eine der größeren Herausforderungen, wenn man sich in einer Mischumgebung bewegt, in der nicht alle Client mit Windows 2000 SP4/Windows XP oder Windows 2003 ausgestattet sind. In meinem HowTo "DOS/9x/*nix Clients mit 2003 DC verbinden" habe ich schon einen Teil der Lösung hinterlegt, aber da es nicht zur zu einfachen Kommunikationsproblemen führen kann, bei denen sich ein "alter" oder "nicht-MS" Rechner weigert mit dem Server zu sprechen, sondern auch zu Zugriffsproblemen führt ist ein "Bestpraxis-Szenario" hier zur Pflicht geworden.

Ich möchte dieses HowTo nicht als "Bestpraxis" verstanden sehen, in der Form, dass jetzt jeder sein Netzwerk so einzustellen hat, damit es überhaupt funktioniert, sondern ich möchte vielmehr einen Weg zeigen in dem es in Mischumgebungen oder bei Problemen des Zugriffs auf das SYSVOL, die Richtlinien und Replikationsproblemen mit den folgenden aufgeführten Einstellungen auf jeden Fall gehen muss.

Digitale Signierung (SMB Signing) für Server Message Block (SMB) Pakete dienen als Schutz vor "Man-in-the-Middle" Attaken, auch als Bucket Brigade-Angriff bezeichnet. Eine Deaktivierung der Funktion führt zu einem Sicherheitsrisiko. Da die Pakete nicht länger mit einem Zeitstempel versehen werden und sich damit in einem Szenario Reply-Attacken ergeben können.

Noch ein paar grundsätzliche Gedanken, damit meine Beispielkonfiguration verstanden werden kann:

In einigen FAQs findet man immer wieder die Empfehlung das "SMB Signing - Kom. digital signieren" zu deaktivieren. Sei es aus Performance Gründen motiviert oder auch durch Probleme verursacht, die sich ergeben haben. Aus Sicherheitsgründen kann ich die komplette Deaktivierung des SMB Signings nicht empfehlen.

Fehler ergeben sich immer in Konstellationen, in denen das SMB Signing widersprüchlich konfiguriert ist. Also, wo das Client, bzw. Serververhalten mit unterschiedlichen, sich widerspechenden Einstellungen konfiguriert ist. In diesem Fall kann es zu Fehlern in der Replikation zwischen den Domänen Controllern kommen, Gruppenrichtlinien werden nicht mehr angewendet, da nicht drauf zugegriffen werden kann, Anmeldeprozesse scheitern komplett, die Datei Zugriffe sind nicht mehr möglich usw.

Beliebte Fehlermeldungen, die u.A. am widersprüchlichen SMB Signing liegen können:

Gehen wir mal davon aus, das wir nicht mit der Deaktivierung arbeiten wollen, sondern besser einen Mittelweg wählen, der abgesehen vom Sicherheitsaspekt der mit signierten SMB Paketen verfolgt wurde, für einen reibungslosen Einsatz sorgt.

Wer mit nicht 2K/XP/2003 Clients/Servern arbeitet kann den Weg gehen, SMB Signing für Linux, Mac, 98 und auch NT zu integrieren. Jedes dieser OS bietet die Möglichkeit dazu.

Hier noch mal ein paar Links:
"How to enable Windows 98/ME/NT clients to logon to Windows 2003 based Domains"
http://support.microsoft.com/?kbid=555038

Linux/Samba: "client signing"
http://www.samba.org/samba/docs/man/smb.conf.5.html


An ein paar einfachen Fragen kann man schnell die Verwirrung feststellen die in diesem Bereich immer wieder auftaucht:
- Ist mit Server immer nur der Server gemeint?
- Kann ein Client nur ein Clientbetriebsystem sein?
- Ist der Server nicht auch mal ein Client?
- Kann nicht auch der Client Serverdienste anbieten?

Die letzten beiden Fragen muss man mit JA beantworten, die ersten beiden sind ein klares Nein.
Ein Server agiert als Client, wenn er eine Anfrage an einen anderen Rechner stellt. Ein Client ist in dem Moment Server, wenn man auf ihn zugreift und er die Daten liefert.

Die Einstellungen der auf den DCs und Computer angewendeten Sicherheitsrichtlinien dürfen sich auf keinen Fall widersprechen!

Clients und Server müssen mit denselben Werten konfiguriert sein und diesmal meine ich die "Computers" und "Domänen Controller", wenn ich von Clients und Server spreche. Das Problem ist, daß auf den Container der Domain Controller einen andere Richtlinie wirkt als auf den Container der Computers.


Gehen wir vom Normalverhalten aus, daß nur folgende zuletzt auf dem Objekt angewendete Richtlinien existieren:

Default Domain Policy: Computer:

Default Domain Controllers Policy: Domänen Controller: (Achtung nicht nachstellen, nur beispielhaft)

Als eine von vielen Fehlkonfigurationen kann jetzt folgende Situation auftreten:
Am Client Computer steht die lokale Richtlinie auf "Microsoft-Netzwerk (Client/Server): Kommunikation digital signieren (immer): Aktiviert" aber am Server ist sowohl die erzwungene Konfiguration (immer) als auch die optionale (wenn X zustimmt) grundsätzlich abgeschaltet. Der Client akzeptiert jetzt aber nur noch signierte Pakete, die der Server nicht versendet ... Das Resultat: Die Kommunikation wird nicht stattfinden.

Ob ich digital signierte Pakete immer erzwinge, oder ob ich sie optional einstelle, ist völlig egal, was die reine Funktion angeht und ich das Thema Sicherheit ausser Acht lasse. Es geht nur darum, daß ich auf dem Sender (Client Einstellung) und dem Ziel (Server Einstellung) immer mit den gleichen Werten arbeite.   


Bestpraxis: Default Domain Policy + Default Domain Controllers Policy

Die gerade genannten Einstellungen als fertige Sicherheitsvorlage, die dann importiert werden kann:

----- bestpraxis-smb.inf -----
[Unicode]
Unicode=yes
[Version]
signature="$CHICAGO$"
Revision=1
[Registry Values]
MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters\EnableSecuritySignature=4,1
MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters\RequireSecuritySignature=4,0
MACHINE\System\CurrentControlSet\Services\LanmanWorkstation\Parameters\EnableSecuritySignature=4,1
MACHINE\System\CurrentControlSet\Services\LanmanWorkstation\Parameters\RequireSecuritySignature=4,0

----- bestpraxis-smb.inf -----


Konfiguration des SMB Signings, wenn auf die GPO nicht mehr zugegriffen werden kann:
Die Lösung steht praktisch schon im oben genannten Artikel http://support.microsoft.com/kb/839499/EN-US/ und im bestpraxis-smb.inf File, denn dort sind die Registry Werte schon hinterlegt.
In diesem Moment muss man die Konfiguration kurzfristig in der Registry anpassen, aber direkt danach in der GPO konfigurieren, wenn der Zugriff wieder möglich ist, da der per Hand eingetragene Wert in der Registry nach ca. 5 Minuten durch den Wert in der GPO überstimmt werden kann. Aus dem Grunde ist eine manuelle Anpassung in der Registry für Werte aus dem Bereich der Sicherheitsvorlagen fast immer aussichtslos. Sie werden halt einfach wieder überschreiben.

Der Ordnung halber noch mal als Tabelle:

(c) 2003 - heute, Mark Heitbrink, weitere Informationen unter WebSite-Info\Copyright