9
AD User Password aus anderer Domain ändern
Ich brauche Eure Hilfe um ein verzwicktes Problem zu lösen.
Wir migrieren unsere Desktops und Notebooks incl. Fileserver zu unserern Mutterkonzern.
Die Benutzeranmeldung wird folglich zukünftig auch in deren AD erfolgen.
Da einige Applikationsserver nicht migriert werden können/sollen, wird das bisherige AD beibehalten.
Die zwei Domainenstämme bekommen kein Vertrauensverhältnis, so dass die User für Zugriffe zu Applikationen/Dateien in der bisherigen Domaine sich anmelden müssen.
Ich könnte die Accounts natürlich so einstellen, dass das Passwort nicht mehr abläuft, aber das ist mit zu unsicher.
Nun meine Frage an Euch:
Kennt ihr eine Lösung / ein Webtool oder ähnliches um den Usern aus Domain A zu erlauben bei den Account in Domain B das Passwort zu ändern.
=> Sprich die Funktion [Strg] + [Alt] + [Entf] => Passwort ändern für eine Fremddomain => idealerweise eine WebApplikation
Ich danke Euch schon mal im Voraus für Eure Hilfe
Michel2000
Die Benutzeranmeldung wird folglich zukünftig auch in deren AD erfolgen.
Da einige Applikationsserver nicht migriert werden können/sollen, wird das bisherige AD beibehalten.
Die zwei Domainenstämme bekommen kein Vertrauensverhältnis, so dass die User für Zugriffe zu Applikationen/Dateien in der bisherigen Domaine sich anmelden müssen.
Ich könnte die Accounts natürlich so einstellen, dass das Passwort nicht mehr abläuft, aber das ist mit zu unsicher.
Nun meine Frage an Euch:
Kennt ihr eine Lösung / ein Webtool oder ähnliches um den Usern aus Domain A zu erlauben bei den Account in Domain B das Passwort zu ändern.
=> Sprich die Funktion [Strg] + [Alt] + [Entf] => Passwort ändern für eine Fremddomain => idealerweise eine WebApplikation
Ich danke Euch schon mal im Voraus für Eure Hilfe
Michel2000
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 154592
Url: https://administrator.de/contentid/154592
Printed on: April 19, 2024 at 11:04 o'clock
9 Comments
Latest comment
Hallo,
Eigentlich hast du die Frage schon selbst beantwortet. Ohne Vertrauensstellung kein Zugriff auf Objekte oder sonstiges der fremden Domain.
Wie soll das also realisiert werden??
Wieso migriert ihr nicht komplett alle Server? Auch wenns teilweise sehr zeitaufwendig ist -> Es lässt sich grundsätzlich alles migrieren.
Es muss nur richtig geplant und umgesetzt werden. Lieber einmal den schweren Weg gehen und in einer konsolidierten Umgebung arbeiten.
Gruß
Eigentlich hast du die Frage schon selbst beantwortet. Ohne Vertrauensstellung kein Zugriff auf Objekte oder sonstiges der fremden Domain.
Wie soll das also realisiert werden??
Wieso migriert ihr nicht komplett alle Server? Auch wenns teilweise sehr zeitaufwendig ist -> Es lässt sich grundsätzlich alles migrieren.
Es muss nur richtig geplant und umgesetzt werden. Lieber einmal den schweren Weg gehen und in einer konsolidierten Umgebung arbeiten.
Gruß
Das ist von der Gruppe nicht gewollt oder erwünscht.
Das Netzwerk ist durch 2 VLAN getrennt
Die Umstellung der rund 30 Server incl. Applikationen und Datenbanken wäre ein zu großer Aufwand - zudem ist zum Überfluß eine Ablösung einiger Applikationen wie ERP usw. durch SAP geplant - es wird also noch umfangreicher und verzwickter
Ich hatte so eine Lösung schon mal gesehen - das war eine WebApp, bei der Du Dich mit Domain\Username angemeldet hattest und anschließend das Passwort ändern konntest - genau das wäre ideal.
Gruß
Das Netzwerk ist durch 2 VLAN getrennt
Die Umstellung der rund 30 Server incl. Applikationen und Datenbanken wäre ein zu großer Aufwand - zudem ist zum Überfluß eine Ablösung einiger Applikationen wie ERP usw. durch SAP geplant - es wird also noch umfangreicher und verzwickter
Ich hatte so eine Lösung schon mal gesehen - das war eine WebApp, bei der Du Dich mit Domain\Username angemeldet hattest und anschließend das Passwort ändern konntest - genau das wäre ideal.
Gruß
Auch dir keine Zeile des Grußes...
naja das Projekt hört sich doch vernünftig von einem frisch von der Schulbank kommenden Studifizierten an
Gruß
naja das Projekt hört sich doch vernünftig von einem frisch von der Schulbank kommenden Studifizierten an
- Ist OWA oder ne andere IIS Schüssel geplant?
Gruß
Hallo,
die Bereitstellung eines Portals ist ja gut und schön. Nur: wer wird das Nutzen? Wenn du passwortablauf deaktivierst: niemand. Wenn du Passwortablauf aktiviert lässt gibt es zwei Möglichkeiten: 1. Die Anwendungen kennen sich mit AD aus und erkennen, dass das Passwort abgelaufen ist. Dann sind sie ziemlich sicher auch so gut, eine Änderung anzubieten. Oder 2. Die Änderungen kennen sich nicht mit AD aus und melden nur "Login nicht erfolgreich" wenn das Kennwort abgelaufen ist. Dann bekommst du haufenweise Tickets, dass die Applikation nicht geht. Natürlich sagt dann der ServiceDesk "Probieren sie erstmal das Kennwort über die Website zu ändern" - aber bis dahin hat der Nutzer schon 10mal versucht, die Applikation mit den alten Daten zu starten, und der Account ist gelockt.
Lösung: Einrichten einer Passwort-Synchronisation vom neuen Forest in den alten. Kostenfreies MS-Produkt (okay, man benötigt, wenn das nicht mittlerweile geändert wurde Win Enterprise & SQL Enterprise) dazu ist der Identity Lifecycle Manager. Und nein Mike.ekiM: man benötigt dazu _keine_ Trust. Wie das dann funktioniert? Über LDAP. ADMT ist vielleicht etwas einfacher zu handhaben, das aber benötigt den Trust.
Gruß
Filipp
die Bereitstellung eines Portals ist ja gut und schön. Nur: wer wird das Nutzen? Wenn du passwortablauf deaktivierst: niemand. Wenn du Passwortablauf aktiviert lässt gibt es zwei Möglichkeiten: 1. Die Anwendungen kennen sich mit AD aus und erkennen, dass das Passwort abgelaufen ist. Dann sind sie ziemlich sicher auch so gut, eine Änderung anzubieten. Oder 2. Die Änderungen kennen sich nicht mit AD aus und melden nur "Login nicht erfolgreich" wenn das Kennwort abgelaufen ist. Dann bekommst du haufenweise Tickets, dass die Applikation nicht geht. Natürlich sagt dann der ServiceDesk "Probieren sie erstmal das Kennwort über die Website zu ändern" - aber bis dahin hat der Nutzer schon 10mal versucht, die Applikation mit den alten Daten zu starten, und der Account ist gelockt.
Lösung: Einrichten einer Passwort-Synchronisation vom neuen Forest in den alten. Kostenfreies MS-Produkt (okay, man benötigt, wenn das nicht mittlerweile geändert wurde Win Enterprise & SQL Enterprise) dazu ist der Identity Lifecycle Manager. Und nein Mike.ekiM: man benötigt dazu _keine_ Trust. Wie das dann funktioniert? Über LDAP. ADMT ist vielleicht etwas einfacher zu handhaben, das aber benötigt den Trust.
Gruß
Filipp
Technisch ist das auch ohne Vertrauensstellung kein Problem.
Einkaufsliste:
Wie man das dann zusammenbaut kann sich denken
Dass ILM kostenlos ist wäre mir völlig neu.
Das ist noch mit eins der teuersten M$-Produkte für die CALs.
Das Spiel hatte ich mit M$ nämlich schonmal für ein Projekt durch und da MS mir nicht mal eine funktionierende Demo einräumen wollte, damit auch eingestampft.
Einkaufsliste:
- Ein Server in der alten Domain
- PHP mit LDAP
- IP-Connectivity zur neuen Domain
- Identische Benutzernamen oder eine Möglichkeit die gegeneinander aufzulösen
- Ein Benutzerkonto, was alle Passwörter ändern kann
Wie man das dann zusammenbaut kann sich denken
Dass ILM kostenlos ist wäre mir völlig neu.
Das ist noch mit eins der teuersten M$-Produkte für die CALs.
Das Spiel hatte ich mit M$ nämlich schonmal für ein Projekt durch und da MS mir nicht mal eine funktionierende Demo einräumen wollte, damit auch eingestampft.
Hallo,
Ich muss aber zugeben, etwas weiteres nicht bedacht zu haben: Für die Passwort-Synchronisiation muss im Source-Forest auf jedem DC der PCNS (Password Change Notification Service) installiert werden, evtl. hat die Muttergesellschaft da etwas dagegen.
Der Aussage, dass es kein Problem ist, eine Website einzurichten, über die man Kennwörter ändern kann, schließe ich mich an.
Gruß
Filipp
Dass ILM kostenlos ist wäre mir völlig neu.
Mea culpa! ILM ist der Nachfolger des MIIS, sprich der kostenpflichtigen Schiene. Der letzte Abkömmling der kostenfreien Sippschaft ist das IIFP (Identity Integration Feature Pack). Nicht mehr ganz taufrisch, aber sehr gut funktionierend.Ich muss aber zugeben, etwas weiteres nicht bedacht zu haben: Für die Passwort-Synchronisiation muss im Source-Forest auf jedem DC der PCNS (Password Change Notification Service) installiert werden, evtl. hat die Muttergesellschaft da etwas dagegen.
Der Aussage, dass es kein Problem ist, eine Website einzurichten, über die man Kennwörter ändern kann, schließe ich mich an.
Gruß
Filipp
Hi TimoBeol
das Problem sind nicht die Studienabgänger sondern die Nationalität
Bei US-Firmen ist immer eine Übersicherung alles Dinge ein MUSS...
Mail Services sind NATÜRLICH längst zentralisiert und daher ausgelagert - also auch hier keine Chance.
Cheers
Michel2000
das Problem sind nicht die Studienabgänger sondern die Nationalität
Bei US-Firmen ist immer eine Übersicherung alles Dinge ein MUSS...
Mail Services sind NATÜRLICH längst zentralisiert und daher ausgelagert - also auch hier keine Chance.
Cheers
Michel2000
Hi filippg,
erst mal DANKE auch an die anderen HELFER.
Ich werde mal IIFP ausprobierern. Es ist sehr schwierig hier weiter zu kommen, wenn man so abgekapselt wird. Die Technische Domain (so konnte man sie wohl nennen) bleibt voll in unserer Hand - aber wie gesagt - leider komplett abgekapselt *FRUST*
Danke noch mal - habt mir viel geholfen!!
Michel2000
erst mal DANKE auch an die anderen HELFER.
Ich werde mal IIFP ausprobierern. Es ist sehr schwierig hier weiter zu kommen, wenn man so abgekapselt wird. Die Technische Domain (so konnte man sie wohl nennen) bleibt voll in unserer Hand - aber wie gesagt - leider komplett abgekapselt *FRUST*
Danke noch mal - habt mir viel geholfen!!
Michel2000
Hallo,
Gruß
Filipp
Ich werde mal IIFP ausprobierern. Es ist sehr schwierig hier weiter zu kommen, wenn man so abgekapselt wird. Die Technische Domain
(so konnte man sie wohl nennen) bleibt voll in unserer Hand - aber wie gesagt - leider komplett abgekapselt *FRUST*
nee, das war ja leider das, was ich nicht beachtet habe. Du musst den PCNS auf den Domaincontrollern der Domain installieren, an der sich die Nutzer anmelden (da sie auch dort ihr Kennwort ändern). Der PCNS greift eingehende Requests zur Passwortänderung ab und schickt sie an den IIFP. Dieser wiederum setzt das Kennwort dann in der Zieldomain (also eurer bisherigen). Notwendig ist der PCNS, da nur zum Zeitpunkt der Kennwortänderung dieses überhaupt unverschlüsselt (bzw mit einer entschlüsselbaren Verschlüsselung) am DC vorliegt (Alternative: Man kann "Store Password with reversible Encryption" setzen, dann könnte man statt dem PCNS wohl auch irgendeine Schedule-basierte Lösung entwickeln).(so konnte man sie wohl nennen) bleibt voll in unserer Hand - aber wie gesagt - leider komplett abgekapselt *FRUST*
Gruß
Filipp
