10
Account Provisioning über mehrere Domänen
Ersteinmal hallo an alle und vielen Dank das es euch gibt.
Ich habe mich nach Monaten des stillen mitlesens hier auch endlich registriert und denke das war ein vernünftiger Schritt in Richtung Zukunft.
Ebenso freue ich mich auch die Zeit die wir wohl in den nächsten Jahren und Jahrzehnten miteinander verbringen werden
und über die Möglichkeit erlangtes Wissen teilen und erweitern zu können.
Etwas über mich:
Derzeit bin ich noch in einer Überbetrieblichen Umschulung zum FiSi tätig und absolviere gerade mein zweites Praktikum im Betrieb.
Innerhalb dieser Praktikumszeit werde ich meine praktische Projektarbeit durchführen.
Das ganze mache ich derzeit bei einem mittelständischen Systemhaus. Aufgrund der derzeitigen Projektlage und Auslastung des Projektteams
habe ich bis jetzt leider noch keine passende Aufgabe für mich finden können.
Demnach habe ich auf Grund einer Thematik folgenden Vorschlag beim Teamleiter eingebracht:
Eine übergreifende Account Provisioning Lösung für unsere Administratoren in den Active Directory's der Kunden.
Sprich ich möchte eine Möglichkeit schaffen, womit das Entry- und Exit-Management in sämtlichen Active Directorys aller Geschäftskunden
zu handhaben ist. Wenn wir in der Firma einen neuen Mitarbeiter bekommen oder bestehende Mitarbeiter ausscheiden (was im Moment der Fall ist)
bedeutet das eine Menge administrativen Aufwand für den Abteilungsleiter und die Verwaltung, wenn man für besagte Mitarbeiter einen personalisierten Domänen Administrator Account einrichten oder suspenden möchte.
Da die Mitarbeiter logischerweise alle einen Zugriff auf sämtliche, von uns konzeptionierte oder verwalteten Infrastrukturen,
einschließlich der dort laufenden Diensten, benötigen um entsprechend arbeiten zu können ist demnach unerlässlich.
Nach etwas Recherche bin ich auf die Idee gekommen Azure bzw die Azure Domain Services dafür zu benutzen.
Nun stelle ich mir die Frage ob das überhaupt so zu realisieren ist oder welche Alternativen es für so ein Vorhaben noch gibt
und ob jemand von euch schon einmal mit solch einem Projekt zutun hatte. Dementsprechend würde ich mich über ein Feedback oder einigen Tipps hierzu sehr freuen.
Im Endeffekt werden es bestimmt 50-100 unterschiedliche Kunden mit eigenen Infrastrukturen sein die damit integriert werden sollen.
Demzufolge müsse man jede der AD's über einen zentralen Punkt verwalten können und die Möglichkeit haben unsere OU Struktur in diesem Ausmaß zu erstellen.
Grüße,
seal
Ich habe mich nach Monaten des stillen mitlesens hier auch endlich registriert und denke das war ein vernünftiger Schritt in Richtung Zukunft.
Ebenso freue ich mich auch die Zeit die wir wohl in den nächsten Jahren und Jahrzehnten miteinander verbringen werden
und über die Möglichkeit erlangtes Wissen teilen und erweitern zu können.
Etwas über mich:
Derzeit bin ich noch in einer Überbetrieblichen Umschulung zum FiSi tätig und absolviere gerade mein zweites Praktikum im Betrieb.
Innerhalb dieser Praktikumszeit werde ich meine praktische Projektarbeit durchführen.
Das ganze mache ich derzeit bei einem mittelständischen Systemhaus. Aufgrund der derzeitigen Projektlage und Auslastung des Projektteams
habe ich bis jetzt leider noch keine passende Aufgabe für mich finden können.
Demnach habe ich auf Grund einer Thematik folgenden Vorschlag beim Teamleiter eingebracht:
Eine übergreifende Account Provisioning Lösung für unsere Administratoren in den Active Directory's der Kunden.
Sprich ich möchte eine Möglichkeit schaffen, womit das Entry- und Exit-Management in sämtlichen Active Directorys aller Geschäftskunden
zu handhaben ist. Wenn wir in der Firma einen neuen Mitarbeiter bekommen oder bestehende Mitarbeiter ausscheiden (was im Moment der Fall ist)
bedeutet das eine Menge administrativen Aufwand für den Abteilungsleiter und die Verwaltung, wenn man für besagte Mitarbeiter einen personalisierten Domänen Administrator Account einrichten oder suspenden möchte.
Da die Mitarbeiter logischerweise alle einen Zugriff auf sämtliche, von uns konzeptionierte oder verwalteten Infrastrukturen,
einschließlich der dort laufenden Diensten, benötigen um entsprechend arbeiten zu können ist demnach unerlässlich.
Nach etwas Recherche bin ich auf die Idee gekommen Azure bzw die Azure Domain Services dafür zu benutzen.
Nun stelle ich mir die Frage ob das überhaupt so zu realisieren ist oder welche Alternativen es für so ein Vorhaben noch gibt
und ob jemand von euch schon einmal mit solch einem Projekt zutun hatte. Dementsprechend würde ich mich über ein Feedback oder einigen Tipps hierzu sehr freuen.
Im Endeffekt werden es bestimmt 50-100 unterschiedliche Kunden mit eigenen Infrastrukturen sein die damit integriert werden sollen.
Demzufolge müsse man jede der AD's über einen zentralen Punkt verwalten können und die Möglichkeit haben unsere OU Struktur in diesem Ausmaß zu erstellen.
Grüße,
seal
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: 483048
Url: https://administrator.de/contentid/483048
Ausgedruckt am: 25.11.2024 um 12:11 Uhr
10 Kommentare
Neuester Kommentar
Guten Morgen seal,
du sprichst hier von einem Identity Manamgent System (IDM). Damit lassen sich Ein- und Austritte, sowie die Vergabe und Veränderung von Nutzerberechtigungen realisieren. Aber weder die Einführung, noch die Betreuung von einem IDM sind trivial. Schon gar nicht, wenn das System auch noch Organisationsübergreifend funktionieren soll. Du brauchst die entsprechenden Schnittstellen. Welche HR-Systeme kommen zum Einsatz? Sind die Daten darin verlässlich? Ist schon ein vernünftiges Berechtigungs- und/oder Rollenkonzept vorhanden? Sind überhaupt möglichst alle Anwendungen bereits ans AD angedockt? Ich spreche jetzt nicht nur von technischen, sondern ganz besonders auch von organisatorischen Herausforderungen. Meiner Meinung nach defintiv nichts für ein Praktikumsarbeit.
Wie groß ist denn eure Umgebung und die eurer Kunden?
Vielleicht noch als alternativer Ansatz: Warum nicht einfach pro Kunde ein Skript erstellen (PowerShell?), dass beim Aufrufen die Stammdaten abfragt und entsprechend den User anlegt und zumindest schonmal zu den jeweiligen Basisgruppen hinzufügt.
Viele Grüße
Daniel
du sprichst hier von einem Identity Manamgent System (IDM). Damit lassen sich Ein- und Austritte, sowie die Vergabe und Veränderung von Nutzerberechtigungen realisieren. Aber weder die Einführung, noch die Betreuung von einem IDM sind trivial. Schon gar nicht, wenn das System auch noch Organisationsübergreifend funktionieren soll. Du brauchst die entsprechenden Schnittstellen. Welche HR-Systeme kommen zum Einsatz? Sind die Daten darin verlässlich? Ist schon ein vernünftiges Berechtigungs- und/oder Rollenkonzept vorhanden? Sind überhaupt möglichst alle Anwendungen bereits ans AD angedockt? Ich spreche jetzt nicht nur von technischen, sondern ganz besonders auch von organisatorischen Herausforderungen. Meiner Meinung nach defintiv nichts für ein Praktikumsarbeit.
Wie groß ist denn eure Umgebung und die eurer Kunden?
Vielleicht noch als alternativer Ansatz: Warum nicht einfach pro Kunde ein Skript erstellen (PowerShell?), dass beim Aufrufen die Stammdaten abfragt und entsprechend den User anlegt und zumindest schonmal zu den jeweiligen Basisgruppen hinzufügt.
Viele Grüße
Daniel
Hallo Daniel, dir auch einen guten Morgen.
Ja ich weiß, das geht in Richtung eines IMS.
Welche HR Systeme wir hier verwenden werde ich jetzt gleich recherchieren. Nichtsdestotrotz denke ich aber, dass diese Information nicht wirklich wichtig ist bzw es nicht essenziell ist, ob die Daten darin "verlässlich" sind oder nicht. Da es sich ja nur um einzelne, individuelle Erstellungen handelt. Ich möchte ja nur unsere neuen oder alten Mitarbeiter damit in den Infrastrukturen der Kunden adden oder bei Bedarf suspenden bzw. nach einiger Zeit löschen. Sprich ich will in jeder AD (was meinen Schätzungen zwischen 50 und 100 Stück sind) einen neuen Administrator anlegen.
Beispiel: Bei uns kommt Hans in die Firma und Franz scheidet aus.
Jetzt müssten wir uns als Systemhaus natürlich bei jedem ADDC des gesamten Kundenstamms über RDP einloggen und dort einen Admin Account für Hans einpflegen und den Account vom Franz dementsprechend suspenden. Wenn das jetzt nur 4-5 Kunden wären die jeweils ein paar Server haben würden, wäre das ja überhaupt kein Problem. Allerdings sind es wesentlich mehr. Deshalb dieses Projekt.
Ich hoffe ich drücke mich nicht zum umständlich oder zu verwirrend aus. ^^
Ja ich weiß, das geht in Richtung eines IMS.
Welche HR Systeme wir hier verwenden werde ich jetzt gleich recherchieren. Nichtsdestotrotz denke ich aber, dass diese Information nicht wirklich wichtig ist bzw es nicht essenziell ist, ob die Daten darin "verlässlich" sind oder nicht. Da es sich ja nur um einzelne, individuelle Erstellungen handelt. Ich möchte ja nur unsere neuen oder alten Mitarbeiter damit in den Infrastrukturen der Kunden adden oder bei Bedarf suspenden bzw. nach einiger Zeit löschen. Sprich ich will in jeder AD (was meinen Schätzungen zwischen 50 und 100 Stück sind) einen neuen Administrator anlegen.
Beispiel: Bei uns kommt Hans in die Firma und Franz scheidet aus.
Jetzt müssten wir uns als Systemhaus natürlich bei jedem ADDC des gesamten Kundenstamms über RDP einloggen und dort einen Admin Account für Hans einpflegen und den Account vom Franz dementsprechend suspenden. Wenn das jetzt nur 4-5 Kunden wären die jeweils ein paar Server haben würden, wäre das ja überhaupt kein Problem. Allerdings sind es wesentlich mehr. Deshalb dieses Projekt.
Ich hoffe ich drücke mich nicht zum umständlich oder zu verwirrend aus. ^^
Guten Morgen,
ah - ich hatte das so aufgefasst, dass du das bei dir in der Firma und für eure Kunden anbieten willst. Es geht darum, dass du einen neuen Account in mehreren ADs anlegen kannst? Hast du direkten Zugriff auf das Active Directory eurer Kunden? Gibt es einen Site2Site VPN? Dann solltest du ein Script schreiben können, das unter wechselenden Identitäten neue Accounts anlegt. Sicherheitstechnisch sollte das dann aber nochmal sorgfältig durchdacht werden.
Innerhalb einer Unternehmensgruppe könnte man auch darüber nachdenken, zwischen den einzelnen Domänen eine Vertrauensstellung aufzubauen, so kann ein Account über mehrere Domänen (im selben Forest) hinweg genutzt werden. Bei Systemhaus / Kundeninstallationen ist mir das aber noch nie untergekommen und wird auch sicher nicht gewünscht.
Grüße
Daniel
ah - ich hatte das so aufgefasst, dass du das bei dir in der Firma und für eure Kunden anbieten willst. Es geht darum, dass du einen neuen Account in mehreren ADs anlegen kannst? Hast du direkten Zugriff auf das Active Directory eurer Kunden? Gibt es einen Site2Site VPN? Dann solltest du ein Script schreiben können, das unter wechselenden Identitäten neue Accounts anlegt. Sicherheitstechnisch sollte das dann aber nochmal sorgfältig durchdacht werden.
Innerhalb einer Unternehmensgruppe könnte man auch darüber nachdenken, zwischen den einzelnen Domänen eine Vertrauensstellung aufzubauen, so kann ein Account über mehrere Domänen (im selben Forest) hinweg genutzt werden. Bei Systemhaus / Kundeninstallationen ist mir das aber noch nie untergekommen und wird auch sicher nicht gewünscht.
Grüße
Daniel
Hallo seal,
Das koennte man ueber Active Directory Trusts (zwingend ueber Site2Site VPN) realisieren.
Allerdings fände ich das als Kunde nicht so toll wenn mein Dienstleister dies tut. Auch aus der Sicht des Datenschutzes / der Datensicherheit wuerde ich dir hier einen Riegel vor schieben. Wer garantiert mir dass alles konform eingerichtet ist? Ein falscher Klick und du hast einen zweiseitigen Trust eingerichtet... im schlimmsten Fall (Firewall und VPN falsch konfiguriert) kommt Kunde A in das Netz von Kunde C oder Kunde XY...
Hier muss wie bereits von Daniel erwaehnt auch eine ganze Menge organisatorisches geregelt sein... du musst die Kunden informieren was du vor hast... Eure eigenen Prozesse muessen passen.....
Überleg dir lieber genau ob du so was machen willst...
Gruss
Das koennte man ueber Active Directory Trusts (zwingend ueber Site2Site VPN) realisieren.
Allerdings fände ich das als Kunde nicht so toll wenn mein Dienstleister dies tut. Auch aus der Sicht des Datenschutzes / der Datensicherheit wuerde ich dir hier einen Riegel vor schieben. Wer garantiert mir dass alles konform eingerichtet ist? Ein falscher Klick und du hast einen zweiseitigen Trust eingerichtet... im schlimmsten Fall (Firewall und VPN falsch konfiguriert) kommt Kunde A in das Netz von Kunde C oder Kunde XY...
Hier muss wie bereits von Daniel erwaehnt auch eine ganze Menge organisatorisches geregelt sein... du musst die Kunden informieren was du vor hast... Eure eigenen Prozesse muessen passen.....
Überleg dir lieber genau ob du so was machen willst...
Gruss
Genau ein Account der in zig ADs angelegt werden soll.
Ich selbst habe natürlich keinen direkten Zugriff auf all die Kunden AD's (Sicherheitsrisiko Eyerolls) aber würde das natürlich hier in der Firma auf mehreren Servern ersteinmal realisieren und wenn das ganze so machbar ist dann kann das PRojekt mit dem Projektteam zusammen ausgerollt werden.
Für jeden Kunden gibt es natürlich einen S2S VPN Tunnel der in der Firewall dementsprechend hinterlegt ist.
Ansonsten könnten wir deren Infrastruktur ja auch nicht administrieren oder überwachen.
Zum Thema Script: Der Gedanke kam mir zu allererst allerdings bin ich zu dem Entschluss gekommen, dass sowas wohl ein sicherheitsrelevanter Supergau ist. Stell dir vor: 1 Terminalserver wo sämtliche AD Domänen Admin Logins stored werden. Ai Ai Ai.. Wenn da was passiert kannste den Laden zusperren und die Wohnung kündigen. Das will wirklich keiner.
Ich selbst habe natürlich keinen direkten Zugriff auf all die Kunden AD's (Sicherheitsrisiko Eyerolls) aber würde das natürlich hier in der Firma auf mehreren Servern ersteinmal realisieren und wenn das ganze so machbar ist dann kann das PRojekt mit dem Projektteam zusammen ausgerollt werden.
Für jeden Kunden gibt es natürlich einen S2S VPN Tunnel der in der Firewall dementsprechend hinterlegt ist.
Ansonsten könnten wir deren Infrastruktur ja auch nicht administrieren oder überwachen.
Zum Thema Script: Der Gedanke kam mir zu allererst allerdings bin ich zu dem Entschluss gekommen, dass sowas wohl ein sicherheitsrelevanter Supergau ist. Stell dir vor: 1 Terminalserver wo sämtliche AD Domänen Admin Logins stored werden. Ai Ai Ai.. Wenn da was passiert kannste den Laden zusperren und die Wohnung kündigen. Das will wirklich keiner.
Du kannst dir auch überlegen statt mit einem Push-Prinzip mit einem Pull-Prinzip zu arbeiten. Du stellst im internen Netzwerk (und für die Kundensysteme erreichbar) eine Informationsquelle (bspw. CSV) zur Verfügung. In regelmäßigen Abständen läuft auf einem Kundensystem ein Scheduled Task und greift auf die Informaitionsquelle zu und falls dort ein neuer Eintrag enstanden ist, wird ein neuer Benutzer angelegt, in die entsprechenden Gruppen aufgenommen und ein zufällig generiertes Passwort wird per E-Mail an den neuen Admin geschickt. Der ändert dann baldmöglichst überall sein Passwort. Das wäre sicherheitstechnisch etwas weniger heikel.
Das klingt nach einem sehr guten Ansatz.
Ich werde mir jetzt nen Kaffee ziuehen und mal etwas brainstromen und recherchieren.
Danke!
Ich werde mir jetzt nen Kaffee ziuehen und mal etwas brainstromen und recherchieren.
Danke!
Also ich habe mir nun etwas Gedanken zu dem was Daniel geschrieben hat gemacht.
Wenn ich anstelle des Push-Prinzips ein Pull-Prinzip anstrebe dann würde ich so vorgehen:
1. Server bei uns aufsetzen und dort nen Drive mit einer "newuser.csv" und "olduser.csv" anlegen.
2. Side to Side VPN Verbindung einrichten
3. den DC's das neue Drive mit den CLV's mappen
4. Scheduled Task auf den DC's schreiben welches im 30 Minuten Abstand checked, ob sich eine der CLV's geändert hat oder ob dort eine CLV ist, wenn eine "newuser.csv" vorhanden ist > mein Newuser Powershell Script durchlaufen lassen. Wenn es eine neue "olduser.csv" gibt > mein Olduser Powershell Script durchlaufen lassen.
5. Ereignis in eine Logfile ausgeben.
Wenn das wirklich doch auf so leichtem Wege realisierbar ist, dann wird das allerdings als Abschlussprojekt wegfallen.
Hm schade.
Wenn ich anstelle des Push-Prinzips ein Pull-Prinzip anstrebe dann würde ich so vorgehen:
1. Server bei uns aufsetzen und dort nen Drive mit einer "newuser.csv" und "olduser.csv" anlegen.
2. Side to Side VPN Verbindung einrichten
3. den DC's das neue Drive mit den CLV's mappen
4. Scheduled Task auf den DC's schreiben welches im 30 Minuten Abstand checked, ob sich eine der CLV's geändert hat oder ob dort eine CLV ist, wenn eine "newuser.csv" vorhanden ist > mein Newuser Powershell Script durchlaufen lassen. Wenn es eine neue "olduser.csv" gibt > mein Olduser Powershell Script durchlaufen lassen.
5. Ereignis in eine Logfile ausgeben.
Wenn das wirklich doch auf so leichtem Wege realisierbar ist, dann wird das allerdings als Abschlussprojekt wegfallen.
Hm schade.
Moin,
Sehe ich nicht so.
Das doing selbst ist zwar auf den ersten Blick recht dünn, aber:
Ich habe auf das System eures Kunden zugriff erhalten, finde zufällig solch eine csv, erstelle selbst eine und schon habe ich meinen eigene User mit administrativen Rechten...
Als "Ex-Mitarbeiter" kenne ich das 30Minuten zeitfenster: Ausreichend Zeit mir einen neuen User anzulegen und zuvor auf dem Kundensystem eine Client2Site-VPN-Verbindung angelegt und ich kann bequem auch nach dem Ausscheiden agieren....
Worauf ich hinaus will: das Einrichten des PS-Scripts sowie das Umsetzen scheint recht trivial, das stimmt. Du musst/ kannst in der Abschlussarbeit aber die ganzen organisatorischen Dinge einfließen lassen, wie IT-Security, Datenschutz, Transparenz für den Kunden, ggf. noch andere Möglichkeiten betrachten und mitteilen, warum du dich dafür entschieden hast..
Auch, was du gedenkst zu tun, wenn 3/4 eurer Kunden nicht mit ziehen wollen (würde ich im übrigen auch nicht wollen)
Oder wie du es absichern willst, dass ich als "böser Bub" eine "Create-User-csv" ablege, danach ein PS-script ausführe, welches dann an allen Kundensystemen Schadcode ausführt...
Also genug Futter hast du links und rechts vom eigentlichen Doing
Gruß
em-pie
Zitat von @sealhunter:
Wenn das wirklich doch auf so leichtem Wege realisierbar ist, dann wird das allerdings als Abschlussprojekt wegfallen.
Hm schade.
Wenn das wirklich doch auf so leichtem Wege realisierbar ist, dann wird das allerdings als Abschlussprojekt wegfallen.
Hm schade.
Sehe ich nicht so.
Das doing selbst ist zwar auf den ersten Blick recht dünn, aber:
Ich habe auf das System eures Kunden zugriff erhalten, finde zufällig solch eine csv, erstelle selbst eine und schon habe ich meinen eigene User mit administrativen Rechten...
Als "Ex-Mitarbeiter" kenne ich das 30Minuten zeitfenster: Ausreichend Zeit mir einen neuen User anzulegen und zuvor auf dem Kundensystem eine Client2Site-VPN-Verbindung angelegt und ich kann bequem auch nach dem Ausscheiden agieren....
Worauf ich hinaus will: das Einrichten des PS-Scripts sowie das Umsetzen scheint recht trivial, das stimmt. Du musst/ kannst in der Abschlussarbeit aber die ganzen organisatorischen Dinge einfließen lassen, wie IT-Security, Datenschutz, Transparenz für den Kunden, ggf. noch andere Möglichkeiten betrachten und mitteilen, warum du dich dafür entschieden hast..
Auch, was du gedenkst zu tun, wenn 3/4 eurer Kunden nicht mit ziehen wollen (würde ich im übrigen auch nicht wollen)
Oder wie du es absichern willst, dass ich als "böser Bub" eine "Create-User-csv" ablege, danach ein PS-script ausführe, welches dann an allen Kundensystemen Schadcode ausführt...
Also genug Futter hast du links und rechts vom eigentlichen Doing
Gruß
em-pie
Hallo seal,
em-pie hat Recht. Deine Abschlussarbeit wird viele organisatorische Dinge berücksichtigen müssen, um ein stimmiges Gesamtwerk abzugeben. Ich möchte dir zusätzlich noch ein paar Gedanken für die Umsetzung mit auf dem Weg geben:
Nur ein paar Sachen, die mir spontan eingefallen sind.
Grüße
Daniel
em-pie hat Recht. Deine Abschlussarbeit wird viele organisatorische Dinge berücksichtigen müssen, um ein stimmiges Gesamtwerk abzugeben. Ich möchte dir zusätzlich noch ein paar Gedanken für die Umsetzung mit auf dem Weg geben:
- Warum brauchst du eine NewUsers.csv und eine OldUsers.csv? Wie wäre es, wenn du nur eine Datenquelle hättest (Users) und nur wer darin ist, bekommt auf den Kundensystemen ein Account. Accounts, die in den Kundensystemen in der Admingruppe sind, aber namentlich nicht in deiner Datenquelle auftauchen werden deaktiviert?
- Der Share mit der CSV sollte natürlich nur Read-Only gemappt werden. Aber brauche ich dann überhaupt einen Share? Und eine CSV? Was spricht gegen einen anderen technologischen Ansatz? Du stellst die Daten über einen Webserver intern zur Verfügung. Im Skript machst du ein Invoke-Webrequest, um die aktuellen Daten abzurufen. Hat den Vorteil, dass du bei der Verbindung auf funktionierendes TLS setzen kannst. Und du kannst ganz spezifische Datenprüfungen auf beiden Seiten aufbauen, um Manipulation zu verhindern.
- Wie sieht das Logging aus? Was wird geloggt und wo wird es geloggt?
Nur ein paar Sachen, die mir spontan eingefallen sind.
Grüße
Daniel
