Machine Account Password +RODC

[exchangekoala 1]

Hallo zusammen, 

 

Durch die aktuelle Corona Nummer haben wir alle Mitarbeiter ins Homeoffice verfrachtet. 

Mir ist nun aber siedend heiß eingefallen, das die Machine Account Password Richtlinie nur auf 30 Tage steht und ich aufgrund der aktuellen Lage damit rechnen muss, dass nach mir Ostern mit ziemlicher Sicherheit alle Vertrauensstellungen um die Ohren fliegen. Mea Culpa!

Ich habe nun den Gedanken, alle mit einer VPN auszustatten, überlege aber ob ein RODC hierfür ausreichend ist. 

Kann mir jemand mit der Frage weiterhelfen ? 

 

Gruß

Exchangekoala

[Dukel 454]

Wieso sollen die Vertrauensstellungen um die Ohren fliegen?

[exchangekoala 1]

Wenn der Client nicht alle 30 Tage sein Computer Kennwort mit dem DC abgleicht bzw. erneuert, kickt er sich selbst aus der AD und ein Rejoin oder Powershell Befehl ist notwendig. 

 

[NilsK 2.940]

Moin,

 

Computerkennwörter laufen nicht einfach ab. Wenn der Wechsel eines Computerkennworts ansteht, dann ist es der Client, der dies auslöst und durchführt, nicht der DC. Ist also ein Client lange Zeit ohne direkten Kontakt zur Domäne, dann steht er nicht plötzlich vor einem abgelaufenen Konto.

 

Ich zitiere den guten Fabian, von dem ich schon zu lange nichts mehr gehört habe:

 

[Wann läuft ein Maschinenaccount / Computerkonto ab? Gar nicht! | Microsoft Docs]
https://docs.microsoft.com/de-de/archive/blogs/deds/wann-luft-ein-maschinenaccount-computerkonto-ab-gar-nicht
 

EDIT: exchangekoala, du müsstest den Thread, den du zitierst, auch bitte ganz lesen.

 

Gruß, Nils

 

bearbeitet 2. April 2020 von NilsK

[exchangekoala 1]

Hey Nils, 

 

Danke für den Link. Ich habe den Nachtrag von daabm zu Norberts Aussage falsch aufgenommen. 

Sprich der Client behält solange sein Passwort, bis er es dem DC mitteilen konnte und keiner sollte seine Vertrauensstellung verlieren.

Dann wäre ich hier erst einmal beruhigt. Danke! 

 

Unabhängig davon, wäre es deiner Meinung nach sinnvoll einen RODC zu nutzen um die Außendienst Mitarbeiter zu versorgen? 

 

[tesso 375]

vor 9 Minuten schrieb exchangekoala:

Unabhängig davon, wäre es deiner Meinung nach sinnvoll einen RODC zu nutzen um die Außendienst Mitarbeiter zu versorgen? 

Das verstehe ich nicht. Willst du jedem Außdendienstler einen RODC ins Homeoffice stellen?

 

An einem RODC kann der CLient auch kein Kennwort änder, deshalb heißt der RODC Read-Only.

[exchangekoala 1]

vor 6 Minuten schrieb tesso:

Das verstehe ich nicht. Willst du jedem Außdendienstler einen RODC ins Homeoffice stellen?

 

An einem RODC kann der CLient auch kein Kennwort änder, deshalb heißt der RODC Read-Only.

 Natürlich will ich nicht einen RODC ins Homeoffice stellen. Was ist das für eine Frage? 

Einen RODC statt einem regulären DC per VPN zu Verfügung stellen, dieser fungiert als "Proxy" für Passwortänderungen der User.

Das kann dieser sehr wohl, er benötigt selbst nur eine Verbindung zum DC.

[NilsK 2.940]

Moin,

 

ich halte einen RODC fast nie für sinnvoll. Genau betrachtet, habe ich noch nicht ein einziges Mal ein Szenario beschrieben bekommen, in dem ich einen RODC für passend gehalten hätte.

Warum würdest du denn meinen, sowas zu brauchen?

 

Gruß, Nils

 

[NorbertFe 2.050]

vor 3 Minuten schrieb NilsK:

Warum würdest du denn meinen, sowas zu brauchen?

 

OT: Weil... wegen Gründen. :)

[tesso 375]

vor 7 Minuten schrieb exchangekoala:

 Natürlich will ich nicht einen RODC ins Homeoffice stellen. Was ist das für eine Frage? 

Einen RODC statt einem regulären DC per VPN zu Verfügung stellen, dieser fungiert als "Proxy" für Passwortänderungen der User.

Das kann dieser sehr wohl, er benötigt selbst nur eine Verbindung zum DC.

Das funktioniert nicht. Wie willst du den Client genau diesen RODC zuweisen?

Ein RODC kann kein Kennwort ändern. Er reicht die Anforderungen weiter an einen RWDC, der ändert das Kennwort, Dieses wird dann wieder auf der RODC repliziert.

 

Ich warte mal auf den Grund, warum du glaubst sowas zu brauchen.

bearbeitet 2. April 2020 von tesso

[exchangekoala 1]

vor 26 Minuten schrieb NorbertFe:

OT: Weil... wegen Gründen. :)

Ich schätze eure Hilfe sehr, aber warum muss es immer direkt abwertend werden?

Muss den jeder Admin immer ein Experte auf jedem Gebiet sein und darf nicht mal eine Frage in den Raum stellen ohne direkt belächelt zu werden? 

Gerade wenn man sich mit zusätzlichen Sicherheitsgedanken befasst?

 

Mein Grundgedanke war einen RODC statt einem RWDC für Außendienst und Homeoffice zur Verfügung zu stellen.

Dieser hat wie der Name bereits sagt eine RO AD- Datenbank und ein RO DNS. Weiterhin eine unidirektionale Verbindung mit dem RWDC.

Dazu kommt das er die Credentials cached und auch mit einem RWDC aktualisieren kann. @tesso Habe ich doch oben mit Proxy beschrieben? 

Weiterhin würde ich nur diesen RODC den VPN Clients zur Verfügung stellen. Damit diese nur mit ihm sprechen können. 

Ich muss in der Firewall nur den RODC freigeben und keinerlei interne RWDCs. Plus ich kann nur definierte Gruppen zum Caching freigeben und biete keine Angriffsfläche für alle Gruppen.

 

Wenn dies insgesamt keine gute Idee sein sollte, bin ich gerne offen für Kritik. Aber sagt mir doch warum ich keinen nehmen sollte, sondern einen vollwertigen? 

Microsoft hat das Ding ursprünglich für Branch Offices entwickelt, warum nicht auch für AD oder HO Mitarbeiter? 

Klar die selben Mitarbeiter fallen auch in der Firma rum, aber einen Zugriff von extern kann ich weniger überwachen, bzw. nicht ausschließend das sich jemand Zugriff verschaffen möchte. z.B. nach Verlust oder Diebstahl. 

 

bearbeitet 2. April 2020 von exchangekoala

[NilsK 2.940]

Moin,

 

ein RODC würde in dem Szenario doch gar keinen Sicherheitsvorteil ergeben. Die User melden sich, wie du sagst, per VPN an. Das VPN ist also deine Sicherheitsgrenze. Ab da sind die User im Netzwerk. Ob sie also auf einen RODC oder einen echten DC zugreifen, macht keinen Unterschied. Danach greifen sie ja ohnehin vermutlich auf "alle" Ressourcen zu.

 

RODCs wurden ursprünglich für genau einen Zweck entworfen: kleine Niederlassungen, die physisch nicht ausreichend gesichert sind, aber einen lokalen DC haben sollen. Der RODC steht dann also physisch in dieser Niederlassung. Wenn dort der DC gestohlen wird, soll nicht gleich das ganze Unternehmen kompromittiert sein.

 

Außerhalb dieses einen Szenarios gibt es - nach meiner Ansicht - keinen sinnvollen Einsatzzweck für einen RODC. Verschiedentlich wird ein RODC für andere Zwecke in Konzepten genannt, aber wenn man sich das genauer ansieht, passt es eigentlich nie. Es gibt keinen Sicherheitsvorteil, es werden praxisferne Annahmen getroffen oder jemand hat das einfach nicht verstanden.

 

Kein Angriff beabsichtigt, nur die Darstellung der Dinge aus meiner Sicht.

 

Gruß, Nils

 

bearbeitet 2. April 2020 von NilsK

[NorbertFe 2.050]

vor einer Stunde schrieb exchangekoala:

Ich schätze eure Hilfe sehr, aber warum muss es immer direkt abwertend werden?

 

War nicht abwertend gemeint, sondern ist üblicherweise die Antwort in solchen Szenarien. Die Absicht eine Lösung zu entwickeln, ohne die entsprechenden Kenntnisse zu besitzen ist eben dann nur halbgar. Warum das Verwenden eines RODC in deinem Szenario nicht zielführend ist, hat dir Nils technisch dargelegt. Also nix für ungut. 

 

Bye

Norbert

[exchangekoala 1]

Hey Nils, 

 

Danke für deine konstruktive Antwort. 

Natürlich ist das VPN erst einmal eine Grenze zu unserem internen Netzwerk. Allerdings haben wir bis auf einen kleinen Teil alle Apps in die Cloud ausgelagert.

Die restlichen Apps werden von extern nur per RDS Gateway über die VPN zugänglich gemacht. Ansonsten erfolgt keinerlei Zugriff auf das interne Netzwerk. 

Ich benötige meine DC's also nur noch für stumpfe Authentifzierungs-, DNS, und GPO Aufgaben.

 

Um diesen letzten Punkt noch sicherer zu gestalten war mein Gedanke dann der RODC. Dieser wäre natürlich auch in ein eigenes VLAN etc. gekommen.

Aber gut, wenn der Sicherheitsvorteil nicht merklich den Aufwand überwiegt, werde ich das noch einmal überdenken müssen. 

 

Danke trotzdem für deine technische Ausführung und Hilfe!

bearbeitet 2. April 2020 von exchangekoala