RODC Kennwortreplikation

[tokra 10]

Hallo zusammen,

 

ich habe eine kleine Verständnisfrage zum Thema RODCs.

 

Nehmen wir folgendes Szenario an:

Zwischen einem RODC und einem beschreibbaren Domänencontroller wurde die Replikation konfiguriert. Darüber hinaus wurde eine Kennwortreplikationsrichtlinie für bestimmte Benutzer konfiguriert, deren Kennwort auf dem RODC gespeichert werden darf. Mittels "Kennwörter auffüllen" werden die Kennwörter dann schon vorab auf dem RODC gespeichert.

 

Was passiert, wenn nun das Kennwort eines Benutzers (welches auf dem RODC gecached ist) auf einem beschreibbaren Domänencontroller geändert wird?

 

Ich könnte mir folgende Möglichkeiten vorstellen:

 

1. Der beschreibbare Domänencontroller repliziert das aktuelle Kennwort beim nächsten Replikationsintervall auf den RODC; der RODC ersetzt sein cached Passwort für diesen Benutzer

 

2. Der beschreibbare Domänenconroller repliziert das geänderte / aktuelle Kennwort nicht auf den RODC; authentifiziert sich ein Client am RODC, wird er an einen beschreibbaren Domänencontroller weitergeleitet. Erst danach wird das aktuelle Kennwort im Password Cache des RODC aktualisiertt.

 

Wer weiß welcher Fall (oder ein anderer) eintritt?

[olc 18]

Hi tokra,

 

schau einmal hier hinein für den Anfang:

 

Read-only Domänencontroller und Passwörter ? Teil 1 - Aktives Verzeichnis Blog - Site Home - TechNet Blogs

 

Read-only Domänencontroller und Passwörter ? Teil 2 - Aktives Verzeichnis Blog - Site Home - TechNet Blogs

 

Viele Grüße

olc

[tokra 10]

Hallo und danke für den Link,

 

wie es aussieht, speichert der RODC also kein Kennwort mehr, sobald es geändert wird. Ich überlege gerade, ob es sinnvoll ist, einen RODC in die vorliegenden Umgebung zu stellen (gewisse Extranetapplikationen benötigen zwingend LDAP-Zugriff für Authentifizierungen).

 

Ich wollte aber keinen Zugriff von der DMZ in das LAN, respketive auf einen beschreibbaren DC im LAN, gestatten, was ja in diesem Fall nötig wäre, damit der RODC Kennwörter abfragen kann (spätestens, wenn sie geändert wurden).

 

Ich bin mir auch immer noch sehr unsicher, ob der RODC hier eine geeignete Maßnahme darstellt, da es ja primär für Zweigstellenszenarien entwickelt wurde. Andererseits gibt es ja nicht umsonst einen "Deploying RODC in perimeter networks" Guide von Microsoft.

 

Prinzipiell würde es natürlich Sinn ergeben, auf dem RODC überhaupt keine Kennwörter zu speichern, so dass der RODC nur als Proxy für LDAP-Anfragen der DMZ agiert.

[dmetzger 10]

Ich bin mir auch immer noch sehr unsicher, ob der RODC hier eine geeignete Maßnahme darstellt, da es ja primär für Zweigstellenszenarien entwickelt wurde. Andererseits gibt es ja nicht umsonst einen "Deploying RODC in perimeter networks" Guide von Microsoft.

 

Darüber wurde kürzlich hier im Forum bereits diskutiert:

 

http://www.mcseboard.de/active-directory-forum-79/rodc-dmz-171509.html

 

Vielleicht findest Du darin den einen oder anderen Gedanken als Entscheidungshilfe.

[olc 18]

Hi zusammen,

 

wie es aussieht, speichert der RODC also kein Kennwort mehr, sobald es geändert wird.

 

Der RODC wird bei aktivierter Kennwortreplikation für den Benutzer das Kennwort von einem RWDC wieder replizieren. Von daher speichert der RODC das Kennwort auch nach einer Änderung oder wie genau meinst Du das?

 

Ich bin mir auch immer noch sehr unsicher, ob der RODC hier eine geeignete Maßnahme darstellt, da es ja primär für Zweigstellenszenarien entwickelt wurde. Andererseits gibt es ja nicht umsonst einen "Deploying RODC in perimeter networks" Guide von Microsoft.

 

Der Guide hat nichts damit zu tun, ob es eine "Empfehlung" oder ein "gängiges Szenario" ist. Vielmehr geht es eher darum, wie man die Firewall konfigurieren muß, was Vor- und Nachteile dieses Szenarios sind usw. D.h. der Guide ist kein Indiz dafür, daß es ein "sinnvolles" Anwendungsbeispiel ist.

 

Prinzipiell würde es natürlich Sinn ergeben, auf dem RODC überhaupt keine Kennwörter zu speichern, so dass der RODC nur als Proxy für LDAP-Anfragen der DMZ agiert.

 

Dann kannst Du auch auf AD LDS in Verbindung mit Proxy-Objekten setzen, siehe dazu auch den Hinweis von "demtzger".

 

Vielleicht findest Du darin den einen oder anderen Gedanken als Entscheidungshilfe.

 

Guter Thread - ich würde in dem Szenario ebenfalls eher auf AD LDS setzen, da scheinbar ausschließlich LDAP binds notwendig sind. Dabei sollte ein SSL bind eingesetzt werden. Mit ADAMsync können auch Proxy Objekte automatisch beim synchronisieren erzeugt werden, das vereinfacht das ganze ungemein.

 

Viele Grüße

olc

[dmetzger 10]

Zur Synchronisierung von AD LDS mit AD DS gibt es nachstehend weitere Informationen:

 

Checklist: Synchronize Data from AD DS to AD LDS

Synchronize with Active Directory Domain Services

Schritt 3: Verwenden von AD LDS-Verwaltungsprogrammen (Übungen)

 

Als Nebenanwendung an dieser Stelle erwähnt ist das Testen von AD-Schemaerweiterungen mittels AD LDS. Hierzu wird zuerst das in der Produktivumgebung vorhandene AD-Schema mittels ADSchemaAnalyzer importiert und anschliessend die geplante Schemaerweiterung eingespielt. Innerhalb 30 Minuten kann man auf diese Weise feststellen, ob eine Erweiterung ggf. zu Konflikten führt oder ob man zuversichtlich das Schema der produktiven AD-Umgebung erweitern kann.

[olc 18]

Genau. :)

[tokra 10]

Hallo zusammen und danke für eure Rückmeldungen,

 

Der RODC wird bei aktivierter Kennwortreplikation für den Benutzer das Kennwort von einem RWDC wieder replizieren. Von daher speichert der RODC das Kennwort auch nach einer Änderung oder wie genau meinst Du das?

 

Eben, er wird sie WIEDER replizieren, aber erst wenn eine Authentifizierung stattfindet und dann muss der RODC Kontakt zu einem RWDC aufnehmen -> DMZ->LAN-Kommunikation nötig

 

Wenn ich alles in eine AD-LDS Instanz synchronisiere, liegen wiederrum alle Kennwörter in der DMZ. Ich frage mich gerade was das geringere Übel ist:

 

Szenario 1:

Egal ob durch RODC mit cached Passwords oder durch eine AD-LDS Instanz: Die Kennwörter liegen auf einem Server in der DMZ

 

Szenario 2:

Eine Art LDAP-Proxy (z.B. RODC ohne cached Passwords) fragt jedes mal bei einem RWDC im LAN nach -> Firewall muss von der DMZ ins LAN geöffnet werden

[olc 18]

Hi,

 

AD LDS synchronisiert die Kennwörter nicht, bzw. kann ADAMsync das nicht. Dafür würdest Du eine eigene Sync Lösung benötigen, so zum Beispiel "FIM".

 

In jedem Fall benötigst Du Kommunikation zwischen den Systemen. Ohne geht es nicht, es sei denn Du baust in der DMZ ein eigenes Directory auf.

 

Wovor genau willst Du Dich eigentlich schützen?

 

Viele Grüße

olc

[tokra 10]

Hi,

 

es ist angedacht, die Struktur später mit AD-FS auf ein zweites AD auszudehnen, was sich in der DMZ befinden wird.

 

Ich müsste jetzt schauen, ob die AD-LDS mit den AD-FS kombiniert werden können, aber momentan sehe ich bei den AD-LDS im Gegensatz zu einem RODC keinen Vorteil.

 

Wenn eine Kommunikation aus der DMZ ins LAN so oder so nötig ist, halte ich es für den sinnvollsten Weg, die Kennwörter gar nicht erst in der DMZ zu speichern. Demnach würde die AD-LDS Instanz oder ein RODC in der Standardkonfiguration (speichert keine Kennwörter) in Frage kommen.

[olc 18]

Hi,

 

es ist im Kern doch "egal", ob die Kennwörter (oder besser: Die Hashes, die ja zusätzlich "abgesichert" sind) in der DMZ liegen oder ob man sich von dort ins produktive Netz verbinden kann.

 

Also noch einmal die Frage: Was genau möchtest Du eigentlich mit der DMZ absichern und wovor möchtest Du Dich schützen? Um welche Angriffszenarien geht es Dir?

 

Eine DMZ "nur so " aufzubauen ist nicht sinnvoll. Zuallererst steht die Schutzdefinition, Schutzbedürfnis und die Defintion möglicher Angriffsszenarien.

 

BTW: AD LDS benötigt keine Infrastrukturdienste wie DNS oder ähnliches und ist daher leichter zu warten und zu betreiben. Es gibt einige zusätzliche Unterschiede, die jedoch erst nach Betrachtung der Anforderungen sinnvoll zu betrachten sind.

 

Viele Grüße

olc

[tokra 10]

Nehmen wir an ein Angreifer kompromittiert den RODC.

 

Jetzt gibt es zwei Möglichkeiten:

 

1. Er kann die cached Password Hashes auslesen und versuchen diese zu knacken

 

2. Er kann zunächst keine Passwort Hashes auslesen

 

-> Da so oder so eine Kommunikation vom RODC zu einem beschreibbaren DC im LAN notwendig ist, halte ich es für einen Sicherheitsgewinn, die Hashes nicht in der DMZ zu speichern

 

Weiteres Angriffsszenario:

Ein Angreifer kompromittiert den RODC und findet eine Sicherheitslücke, Daten auf einen beschreibbaren DC zu injizieren. Die Eintrittswahrscheinlichkeit dieses Risikos halte ich für gering, wodurch ein RODC in der DMZ durchaus in Frage kommt.

[dmetzger 10]

Ein Angreifer kompromittiert den RODC und findet eine Sicherheitslücke, Daten auf einen beschreibbaren DC zu injizieren. Die Eintrittswahrscheinlichkeit dieses Risikos halte ich für gering, wodurch ein RODC in der DMZ durchaus in Frage kommt.

 

Da wir endlich bei den Hypothesen angekommen sind: Nehmen wir an, ein Angreifer schafft es sich, sich erfolgreich als Domänen-Admin an einem RODC in der DMZ anzumelden. Nun spielt er ein bisschen mit den AD- und DNS-Konsolen. Welchen Fokus haben diese? :shock:

 

Ist natürlich nur rein hypothetisch.

[tokra 10]

Wenn er Domänen-Admin-Rechte hat, kann er auch gleich Verbindung mit dem beschreibbaren DC im LAN aufnehmen.

 

Alternativ könnte er die ADDS neu installieren und diesmal nicht als RODC.

[dmetzger 10]

Wenn er Domänen-Admin-Rechte hat, kann er auch gleich Verbindung mit dem beschreibbaren DC im LAN aufnehmen.

 

Alternativ könnte er die ADDS neu installieren und diesmal nicht als RODC.

 

Ist beides nicht nötig. Er hat ja die Konsolen.