23
Passwortänderung an RODC möglich?
Hallo,
ich habe einen RODC, auf welchen ich über ldaps (Web-Seite mit php7) Passwortänderungen durchführen möchte. Ist das grundsätzlich möglich, auf einen RODC Passwortänderungen zu senden? Ich bekomme dabei nämlich immer LDAP - Modify password error 10 (Referral). Wenn ich die Passwortänderung an den schreibbaren Domain-Controller sende, würde es funktionieren (was ich aber nicht will).
LG, Dextha
ich habe einen RODC, auf welchen ich über ldaps (Web-Seite mit php7) Passwortänderungen durchführen möchte. Ist das grundsätzlich möglich, auf einen RODC Passwortänderungen zu senden? Ich bekomme dabei nämlich immer LDAP - Modify password error 10 (Referral). Wenn ich die Passwortänderung an den schreibbaren Domain-Controller sende, würde es funktionieren (was ich aber nicht will).
LG, Dextha
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 453807
Url: https://administrator.de/contentid/453807
Ausgedruckt am: 21.11.2024 um 22:11 Uhr
23 Kommentare
Neuester Kommentar
Zitat von @Dextha:
Hallo,
ich habe einen RODC, auf welchen ich über ldaps (Web-Seite mit php7) Passwortänderungen durchführen möchte. Ist das grundsätzlich möglich, auf einen RODC Passwortänderungen zu senden? Ich bekomme dabei nämlich immer LDAP - Modify password error 10 (Referral). Wenn ich die Passwortänderung an den schreibbaren Domain-Controller sende, würde es funktionieren (was ich aber nicht will).
Du weißt aber schon, dass ein RODC, wie der Name schon sagt, nur read-only ist?Hallo,
ich habe einen RODC, auf welchen ich über ldaps (Web-Seite mit php7) Passwortänderungen durchführen möchte. Ist das grundsätzlich möglich, auf einen RODC Passwortänderungen zu senden? Ich bekomme dabei nämlich immer LDAP - Modify password error 10 (Referral). Wenn ich die Passwortänderung an den schreibbaren Domain-Controller sende, würde es funktionieren (was ich aber nicht will).
Da ist nichts mit schreiben, das hast du ja gemerkt
Nur lesen geht.
LG, Dextha
tomolpi
Moin,
Gruß,
Dani
Ist das grundsätzlich möglich, auf einen RODC Passwortänderungen zu senden?
Nein.Wenn ich die Passwortänderung an den schreibbaren Domain-Controller sende, würde es funktionieren (was ich aber nicht will).
Klingt nach einem Henne-Ei Problem. Du hast einen RODC willst dort das Passwort ändern. Dafür bräuchst du einen WRDC an der Stelle. Was du aber widerrum nicht willst.Gruß,
Dani
Hi,
das sollte funktionieren. Voraussetzung, der RODC kann einen schreibbaren DC erreichen und an diesen die Änderung delegieren.
Change User Account Password Against an RODC - Client Application
E.
das sollte funktionieren. Voraussetzung, der RODC kann einen schreibbaren DC erreichen und an diesen die Änderung delegieren.
Change User Account Password Against an RODC - Client Application
E.
Da wird man alt wie eine Kuh und lernt dann immer noch dazu. Da kann man mal sehen was man alles nicht weiß.
Zitat von @emeriks:
Hi,
das sollte funktionieren. Voraussetzung, der RODC kann einen schreibbaren DC erreichen und an diesen die Änderung delegieren.
Change User Account Password Against an RODC - Client Application
Ich schließe mich den Lernenden an und stauneHi,
das sollte funktionieren. Voraussetzung, der RODC kann einen schreibbaren DC erreichen und an diesen die Änderung delegieren.
Change User Account Password Against an RODC - Client Application
E.
OK, und dann kannst im Endeffekt auch gleich wieder einen "normalen" DC implementieren, weil du ja doch wieder auf dem RODC schreibst. mh...War wohl jemand bei Microsoft am Freitag am Arbeiten?!
Grüße...
Grüße...
Zitat von @certifiedit.net:
OK, und dann kannst im Endeffekt auch gleich wieder einen "normalen" DC implementieren, weil du ja doch wieder auf dem RODC schreibst. mh...War wohl jemand bei Microsoft am Freitag am Arbeiten?!
Nein, wieso?OK, und dann kannst im Endeffekt auch gleich wieder einen "normalen" DC implementieren, weil du ja doch wieder auf dem RODC schreibst. mh...War wohl jemand bei Microsoft am Freitag am Arbeiten?!
Der Sinn eines RODC liegt doch nur darin, dass dieser nicht offline (ausgeschaltet) manipuliert werden kann und diese Manipulationen dann nicht zu den anderen repliziert, wenn er wieder online ist.
Die Passwortänderung nimmt er erstmal an. Dann sendet er diese an einen schreibbaren DC, vorzugsweise an den PDC-Emulator. Erst wenn dieser DC die Änderung bestätigt, dann gilt diese. Wo soll da das Problem sein?
Der RODC stellt einen vollwertigen Domain Controller dar. Allerdings kann von dem Controllertyp nur gelesen werden. Schreibende Zugriffe auf die Active Directory DS-Datenbank werden unterbunden.[1]
Daraus lese ich eine Unsinnigkeit, denn ich betrachtete einen solchen rein als "Proxy ggf. Cache" fürs AD. Wenn er aber nun auch Schreibanweisungen annimmt...
Kann man natürlich wie du verargumentieren, aber das ist so ein Sicherheitskonzept wie, die einzige Sicherheitsbarriere am Server ist eine Abschottung der Platten durch Verschlüsselung, wenn er aus ist - und sonst alles offen wie ein Scheunentor.
Vielleicht auch nur philosophisch zu ergründen.
???
Ein Proxy leitet Daten weiter. Das ist vollkommen korrekt so. Sinn der Sache.
Der RODC ist beides: Proxy und Cache.
Auch eine Verschlüsselung kann man knacken. Doch selbst dann kannst Du mit den Daten dieses RODC nicht viel anfangen, wenn dort keine Passwörter gespeichert sind.
Ein Proxy leitet Daten weiter. Das ist vollkommen korrekt so. Sinn der Sache.
Der RODC ist beides: Proxy und Cache.
Kann man natürlich wie du verargumentieren, aber das ist so ein Sicherheitskonzept wie, die einzige Sicherheitsbarriere am Server ist eine Abschottung der Platten durch Verschlüsselung, wenn er aus ist - und sonst alles offen wie ein Scheunentor.
Auch eine Verschlüsselung kann man knacken. Doch selbst dann kannst Du mit den Daten dieses RODC nicht viel anfangen, wenn dort keine Passwörter gespeichert sind.
Wir drehen uns im Kreis und ich glaub, du willst gar nicht auf den eigentlich Punkt "Mehrwert" des RODC im laufenden Betrieb eingehen.
Von daher, lassen wir das.
Von daher, lassen wir das.
@emeriks
Gruß,
Dani
das sollte funktionieren. Voraussetzung, der RODC kann einen schreibbaren DC erreichen und an diesen die Änderung delegieren.
Bei einem normalen Vorgang has du Recht. Aber der Fragesteller gibt in seinem Skript wohl fix den Namen/IP des RODC an. Somit wird der obengenannte Fehler erzeugt, weil das Passwort nicht geändert werden kann.Gruß,
Dani
Hallo Emeriks,
danke für die Info! Genau sowas suche ich. Hast du da zufällig noch wo ein howto dafür?
LG, Dextha
danke für die Info! Genau sowas suche ich. Hast du da zufällig noch wo ein howto dafür?
LG, Dextha
In dem von mir genannten Link steht doch alles drin.
Versuchst Du tatsächlich eine Änderung des Passworts oder ein Reset dessen?
Bei einer Änderung muss man auch das alte Passwort angeben. Beim Reset nicht, braucht aber entsprechende Rechte dafür.
Reset über RODC geht meines Wissens nicht.
Ändern schon.
Da PHP nicht mein Ding ist, kann ich Dir jetzt auch nicht sagen, wie man das damit anstellen muss. Aber ich kann Dir ein Beispiel für VBS nennen, mit welchem Du die Funktionalität prinzipiell testen kannst.
Dieses auf einem Windows Domain Member ausführen.
test.vbs
Versuchst Du tatsächlich eine Änderung des Passworts oder ein Reset dessen?
Bei einer Änderung muss man auch das alte Passwort angeben. Beim Reset nicht, braucht aber entsprechende Rechte dafür.
Reset über RODC geht meines Wissens nicht.
Ändern schon.
Da PHP nicht mein Ding ist, kann ich Dir jetzt auch nicht sagen, wie man das damit anstellen muss. Aber ich kann Dir ein Beispiel für VBS nennen, mit welchem Du die Funktionalität prinzipiell testen kannst.
Dieses auf einem Windows Domain Member ausführen.
test.vbs
Dim UserDN
UserDN = "distinguishedName-des-Benutzerkontos"
' Bsp.: UserDN = "CN=Müller\, Peter,OU=Benutzerkonten,DC=domain,DC=tld"
Dim RODC
RODC = "FQDN-des-RODC"
' Bsp.: RODC = "rodc1.domain.tld"
Dim UserObject
Set UserObject = GetObject("LDAP://" & RODC & "/" & UserDN)
UserObject.ChangePassword "altes-Passwort", "neues-Passwort" Zitat von @certifiedit.net:
ich glaub, du willst gar nicht auf den eigentlich Punkt "Mehrwert" des RODC im laufenden Betrieb eingehen
Oha!ich glaub, du willst gar nicht auf den eigentlich Punkt "Mehrwert" des RODC im laufenden Betrieb eingehen
Zitat von @certifiedit.net:
Wir drehen uns im Kreis und ich glaub, du willst gar nicht auf den eigentlich Punkt "Mehrwert" des RODC im laufenden Betrieb eingehen.
Wir drehen uns im Kreis und ich glaub, du willst gar nicht auf den eigentlich Punkt "Mehrwert" des RODC im laufenden Betrieb eingehen.
Der dürfte doch auf der Hand liegen, du hast in der ungesicherten Filiale einen DC mit beschnittenen Möglichkeiten liegen, falls dir jemand deinen Container aufbricht und den Server klaut kann er nicht allzu viel damit anfangen.
Für die beschriebene Anwendung macht das aber wenig Sinn, denn entweder erlaube ich das schreiben oder nicht, der RODC ist hier nur ein Umweg.
Würde jemand die Website hacken, wäre das keine Absicherung, da die Schreibvorgänge ja trotzdem autorisiert sind.
Der dürfte doch auf der Hand liegen, du hast in der ungesicherten Filiale einen DC mit beschnittenen Möglichkeiten liegen, falls dir jemand deinen Container aufbricht und den Server klaut kann er nicht allzu viel damit anfangen.
Containerbeispiel, absolut deiner Meinung.
Für die beschriebene Anwendung macht das aber wenig Sinn, denn entweder erlaube ich das schreiben oder nicht, der RODC ist hier nur ein Umweg.
und genau darauf wollte ich hinaus.
Der RODC ist hier kein Umweg sondern einfach ein Sicherheitskanal. Quasi ein Reverse Proxy. Ein Reverse Proxy für eine Website z.B. verliert ja auch nicht seinen Sinn, wenn man darüber Passwörter ändern oder sonstige Daten hochladen kann.
Den grundsätzlichen Sinn vielleicht nicht, aber ich denke Dextha will dadurch die Sicherheit seiner Webanwendung erhöhen, was der RODC in dem Fall aber nicht hergibt, weil er für die Passwortänderung gar nicht zuständig ist.
Dextha?
Der Grundgedanke lag darin, dass keine Zugangsdaten in dem Netz liegen, wo auch der Web-Server steht. Leider haben sich die Anforderungen dahingehend geändert, dass sich die User (die ausschließlich Zugriff auf das Web-Portal haben) auch die Zugangsdaten ändern wollen, oder auch einen Self-Service mit Passwort vergessen brauchen. Daher wollte ich den wenigsten Aufwand betreiben und den RODC dahingehend aufbohren, dass dieser zusätzlich diese Funktionen unterstützt.
Die Frage ist jetzt nur, wie ich das am besten umsetze....
Die Frage ist jetzt nur, wie ich das am besten umsetze....
Moin,
nach deiner Beschreibung wäre eine Umsetzung mit Hilfe von SAML oder oAuth über AD FS und WAP der richtige Ansatz. Somit werden keinerlei Zugangsdaten zwischen gespeichert und die Kommunikation mit dem WRDC erfolgt über AD FS (HTTPs). Besser geht es dann eigentlich kaum mehr...
Gruß,
Dani
nach deiner Beschreibung wäre eine Umsetzung mit Hilfe von SAML oder oAuth über AD FS und WAP der richtige Ansatz. Somit werden keinerlei Zugangsdaten zwischen gespeichert und die Kommunikation mit dem WRDC erfolgt über AD FS (HTTPs). Besser geht es dann eigentlich kaum mehr...
Gruß,
Dani
Ja vermutlich... dann werd mich mich mal auf die Suche nach einer guten Beschreibung von AD FS machen 
Danke euch allen!
Danke euch allen!
Moin,
Gruß,
Dani
Ja vermutlich... dann werd mich mich mal auf die Suche nach einer guten Beschreibung von AD FS machen
Microsoft Docs sind eine gute Anlaufstelle. Je nachdem wie gut du mit Deutsch/Englisch klar kommst. Ansonsten ist dazu auch vieles in meinen Kopf abgelegt. Aber mich kannst du nicht "suchen". Gruß,
Dani
