11
Benutzerveränderungen im AD überwachen
Hallo Freunde,
ich muss ein Programm schreiben, welches die Benutzer in unserem AD über eine API mit einer externen DB synct.
Ich wollte mal fragen welche Konzepte es da grundsätzlich gibt. Folgende spontane Ideen kommen mir da:
1. Das Programm in der Nacht laufen lassen. Bei 10K Benutzern sehr Arbeitslastig und ich würde die API dauernd fluten, weil ich ja bei jedem Benutzer fragen müsste: existiert der Benutzer schon, hat sich was verändert, etc... Ausserdem ist diese Methode dann nicht live.
2. AD Auditing: Habe dazu diese Anleitung gefunden: https://www.windowspro.de/wolfgang-sommergut/auditing-administratoren-ac .... Ich stelle mir das gerade schwierig vor. Ich sehe Schwierigkeiten darin alle Events auch wirklich zu erwischen.
Änderungen an einem Benutzer die mich interessieren sind : Änderungen an einzelnen Eigenschaften / Aktivieren eines Benutzers / Deaktivieren eines Benutzers / Löschen eines Benutzers
Kennt ihr unter Umständen noch andere Konzepte?
Vielen lieben Dank und mit freundlichen Grüßen
ich muss ein Programm schreiben, welches die Benutzer in unserem AD über eine API mit einer externen DB synct.
Ich wollte mal fragen welche Konzepte es da grundsätzlich gibt. Folgende spontane Ideen kommen mir da:
1. Das Programm in der Nacht laufen lassen. Bei 10K Benutzern sehr Arbeitslastig und ich würde die API dauernd fluten, weil ich ja bei jedem Benutzer fragen müsste: existiert der Benutzer schon, hat sich was verändert, etc... Ausserdem ist diese Methode dann nicht live.
2. AD Auditing: Habe dazu diese Anleitung gefunden: https://www.windowspro.de/wolfgang-sommergut/auditing-administratoren-ac .... Ich stelle mir das gerade schwierig vor. Ich sehe Schwierigkeiten darin alle Events auch wirklich zu erwischen.
Änderungen an einem Benutzer die mich interessieren sind : Änderungen an einzelnen Eigenschaften / Aktivieren eines Benutzers / Deaktivieren eines Benutzers / Löschen eines Benutzers
Kennt ihr unter Umständen noch andere Konzepte?
Vielen lieben Dank und mit freundlichen Grüßen
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: 1023564851
Url: https://administrator.de/contentid/1023564851
Printed on: April 28, 2024 at 05:04 o'clock
11 Comments
Latest comment
Hi.
Ein paar Tipps:
Trotzdem klingt das zunächst nach "zu ambitioniert" bzw. "am falschen Ende angepackt", da das AD selbst ja auch direkt ausgewertet werden könnte.
Ein paar Tipps:
- Es wäre weitaus schöner, wenn das System, was die Daten nutzen soll, keine gesyncte DB braucht, sondern das AD selbst nutzt - warum ist das nicht möglich?
- Du schreibst, dass angestrebt wird, die Daten möglichst "live" zu bekommen, sprich: ohne Zeitverzug. Aber ist das wirklich wichtig? Ich könnte mir vorstellen, dass ein Versatz von einer Stunde kaum stören wird und somit möglicherweise ein stündlicher kompletter Dump, also kein Syncing, am einfachsten wäre.
- Nun zu den Tasks und dem Auditing: da man sehr einfach einstellen kann, was pro OU (oder gar pro Domain) überwacht werden soll, ist der Ansatz, das Eventlog zu nutzen, natürlich in Ordnung. Du könntest nun geplante Tasks etablieren, die von den bestimmten Ereignissen getriggert würden, so dass Du keine Sorgen hättest, etwas nicht zu erwischen. Man kann sich hierzu Filter erstellen, die nicht nur auf bestimmte EventIDs anspringen, sondern zusätzlich die Eventmessage ansehen und entsprechend handeln könnten.
Trotzdem klingt das zunächst nach "zu ambitioniert" bzw. "am falschen Ende angepackt", da das AD selbst ja auch direkt ausgewertet werden könnte.
Hallo DWW,
1. Das ist auch vorgesehen. Wir arbeiten an einer SAML Lösung. Dauert aber bis die andere Seite bereit ist. Und ich brauche eine Lösung in der Übergangszeit.
2. Ja, das ist korrekt. 1 Stunde wäre auch noch akzeptabel. Ich sehe das Problem aber eigentlich auch eher bei der Kommunikation mit der API, als jetzt mit dem AD. Das auslesen aller Benutzer dauert etwa 5 bis 10 Sekunden.
3. Den Task planer hatte ich nicht auf dem Schirm. Ich fuchs mich mal da rein wie das geht um die Events so auszulesen. Ich denke das wird die Lösung sein.
Vielen Dank für deinen Input.
Ein schönes WE.
1. Das ist auch vorgesehen. Wir arbeiten an einer SAML Lösung. Dauert aber bis die andere Seite bereit ist. Und ich brauche eine Lösung in der Übergangszeit.
2. Ja, das ist korrekt. 1 Stunde wäre auch noch akzeptabel. Ich sehe das Problem aber eigentlich auch eher bei der Kommunikation mit der API, als jetzt mit dem AD. Das auslesen aller Benutzer dauert etwa 5 bis 10 Sekunden.
3. Den Task planer hatte ich nicht auf dem Schirm. Ich fuchs mich mal da rein wie das geht um die Events so auszulesen. Ich denke das wird die Lösung sein.
Vielen Dank für deinen Input.
Ein schönes WE.
Hi,
ist das besagte Programm von euch?
Wäre es nicht sinnvoll bei einer solchen Größe den Hersteller zu fragen ob es in dem "Programm" eine LDAP Schnittstelle gibt? Hier hast du dann keine Fehlerquelle welche Mal nicht läuft... Und die Daten sind immer Aktuell bei der Abfrage.
Fehler kann dann nur noch ein nicht verfügbares AD sein was aber dann nicht so schlimm ist wenn das Programm nicht läuft denn dann hast du bestimmt anderes zu tun.
Grüße
ist das besagte Programm von euch?
Wäre es nicht sinnvoll bei einer solchen Größe den Hersteller zu fragen ob es in dem "Programm" eine LDAP Schnittstelle gibt? Hier hast du dann keine Fehlerquelle welche Mal nicht läuft... Und die Daten sind immer Aktuell bei der Abfrage.
Fehler kann dann nur noch ein nicht verfügbares AD sein was aber dann nicht so schlimm ist wenn das Programm nicht läuft denn dann hast du bestimmt anderes zu tun.
Grüße
Hallo Fabezz,
also das Programm oder den Dienst (service) muss ich ja erst selbst programmieren. Ich habe natürlich intern Zugriff auf das AD. Die benötigten Daten der Benutzer lese ich hier aus und schicke sie dann an den externen Dienstleister.
Das AD selbst ist hier nicht unbedingt das Nadelohr. Die Benutzer auszulesen dauert in etwa 5 bis 10 Sekunden. Aber wenn du 10K user über eine Web API synchronisieren möchtest ist das schon heavy. Weil pro Benutzer auch eventuell mehrere Abfragen nötig sind. (Z.b: Abfrage 1: Existiert benutzer xyz? / Abfrage 2: Dann modifiziere oder lege an). Wären also etwa pro Durchlauf 20K abfragen. Das ist natürlich für ne Web API ne Hausnummer. Und wenn das stündlich käme, dann gäbe es sicherlich haue vom Dienstleister ;)
Danke
also das Programm oder den Dienst (service) muss ich ja erst selbst programmieren. Ich habe natürlich intern Zugriff auf das AD. Die benötigten Daten der Benutzer lese ich hier aus und schicke sie dann an den externen Dienstleister.
Das AD selbst ist hier nicht unbedingt das Nadelohr. Die Benutzer auszulesen dauert in etwa 5 bis 10 Sekunden. Aber wenn du 10K user über eine Web API synchronisieren möchtest ist das schon heavy. Weil pro Benutzer auch eventuell mehrere Abfragen nötig sind. (Z.b: Abfrage 1: Existiert benutzer xyz? / Abfrage 2: Dann modifiziere oder lege an). Wären also etwa pro Durchlauf 20K abfragen. Das ist natürlich für ne Web API ne Hausnummer. Und wenn das stündlich käme, dann gäbe es sicherlich haue vom Dienstleister ;)
Danke
Hi,
ja kann der DL vielleicht LDAP?
Dann brauchst den Zwischenschritt nicht.
ja kann der DL vielleicht LDAP?
Dann brauchst den Zwischenschritt nicht.
Ich werde ja auf keinem Fall dem Zugriff auf unser AD geben.
Dat kommt ja net in de Tütte ;)
mfG
Dat kommt ja net in de Tütte ;)
mfG
Lesender Zugriff?
Ist es ein Unterschied ob du eine DB mit den Daten zur Verfügung stellst oder ein reglementierten Zugriff auf das LDAP?
Ist es ein Unterschied ob du eine DB mit den Daten zur Verfügung stellst oder ein reglementierten Zugriff auf das LDAP?
Selbstverständlich ist da ein Unterschied. Ich entscheide, welche Informationen rausgehen. Und nicht welche Informationen er sich von Innen heraus nimmt.
mfG
mfG
Ist wieder Ansichtssache. Du entscheidest welche Daten er ziehen kann. (Reine Konfiguration)
Du hast ja mehrere Optionen hier... Das kommt nur auf den Aufwand an den du reinstecken willst. Du kannst ja z.B. auch mit ner simplen Datenbank arbeiten:
1) Du liest ein Objekt aus dem AD raus
2) Du machst eine Checksumme über alle Felder die für dich relevant sind und packst die zusammen mit der SSID in die DB
3) Du vergleichst:
a)Ist die Checksumme bereits in der DB und identisch -> keine änderung
b) Ist die Checksumme bereits in der DB aber unterschiedlich, SSID existiert -> update
c) Ist die Checksumme nicht in der DB, SSID existiert nicht: Neuer Eintrag
4) Ich würde noch ein Datumswert einfügen bei jedem Durchlauf wird das Datum auch aktuell gesetzt. Ist ein Datumswert z.B. älter als X Stunden (z.B. 2 oder 3 durchläufe): Der Benutzer wurde gelöscht...
Schon brauchst du nur wenige Abfragen an die Web-Api zu machen weil du ja bereits weisst welche Einträge sich geändert haben.
Allerdings musst du natürlich in dem Fall auch die ganze Fehlerbehandlung sauber machen -> was passiert wenn dein AD-Server grad nicht erreichbar ist? Was passiert wenn die Web-Api nen Fehler wirft? Wie kannst du prüfen ob der Wert auf dem Zielsystem wirklich eingetragen wurde?
Ich würde daher auch eher dazu tendieren zu schauen das ich den Zugriff für den DL so anpasse wie es nötig ist statt das selbst zu programmieren. Denn wenn du es auch nur halbwegs sauber haben willst müsstest du ja auch sauber testen, in der Grössenordnung können das auch mal einige Wochen sein. Weil ja eben ggf. auch div. Spezialfälle berücksichtigt werden müssen:
- Umlaute im Namen (und ggf. sogar Namen mit Nicht-Europäischen Zeichensatz)
- Lange bzw. Kurze Namen
- Titel bzw. "Mittel-Namen" (inkl. möglicher Experten die z.B. den Titel ins Namensfeld packen - dabei aber vergessen das es Dr. Müller ist - aber Prinz Charles....)
- ...
Und das nur bei dem Namen, da gibts aber ja noch zig Checks die ggf. relevant sein können...
1) Du liest ein Objekt aus dem AD raus
2) Du machst eine Checksumme über alle Felder die für dich relevant sind und packst die zusammen mit der SSID in die DB
3) Du vergleichst:
a)Ist die Checksumme bereits in der DB und identisch -> keine änderung
b) Ist die Checksumme bereits in der DB aber unterschiedlich, SSID existiert -> update
c) Ist die Checksumme nicht in der DB, SSID existiert nicht: Neuer Eintrag
4) Ich würde noch ein Datumswert einfügen bei jedem Durchlauf wird das Datum auch aktuell gesetzt. Ist ein Datumswert z.B. älter als X Stunden (z.B. 2 oder 3 durchläufe): Der Benutzer wurde gelöscht...
Schon brauchst du nur wenige Abfragen an die Web-Api zu machen weil du ja bereits weisst welche Einträge sich geändert haben.
Allerdings musst du natürlich in dem Fall auch die ganze Fehlerbehandlung sauber machen -> was passiert wenn dein AD-Server grad nicht erreichbar ist? Was passiert wenn die Web-Api nen Fehler wirft? Wie kannst du prüfen ob der Wert auf dem Zielsystem wirklich eingetragen wurde?
Ich würde daher auch eher dazu tendieren zu schauen das ich den Zugriff für den DL so anpasse wie es nötig ist statt das selbst zu programmieren. Denn wenn du es auch nur halbwegs sauber haben willst müsstest du ja auch sauber testen, in der Grössenordnung können das auch mal einige Wochen sein. Weil ja eben ggf. auch div. Spezialfälle berücksichtigt werden müssen:
- Umlaute im Namen (und ggf. sogar Namen mit Nicht-Europäischen Zeichensatz)
- Lange bzw. Kurze Namen
- Titel bzw. "Mittel-Namen" (inkl. möglicher Experten die z.B. den Titel ins Namensfeld packen - dabei aber vergessen das es Dr. Müller ist - aber Prinz Charles....)
- ...
Und das nur bei dem Namen, da gibts aber ja noch zig Checks die ggf. relevant sein können...
Hallo Maretz,
ja, wie weit ich gehe muss ich mal schauen. Vor allem weil es ja auch nur eine Übergangslösung sein wird.
Aber die Idee mit der Zwischendatenbank ist nice. Werde das mal durchplanen.
Vielen Dank.
ja, wie weit ich gehe muss ich mal schauen. Vor allem weil es ja auch nur eine Übergangslösung sein wird.
Aber die Idee mit der Zwischendatenbank ist nice. Werde das mal durchplanen.
Vielen Dank.
