istike2
Goto Top

AD-Account - Anmeldungen prüfen

Hallo Zusammen,

wir haben im AD einen technischen Benutzer, wo das Passwort aus Sicherheitsgründen geändert werden sollte.
Um das PW ändern zu können, müssten wir wissen, welche Systeme sich mit diesen User am LDAP anmelden (JIRA, Confluence, Bitbucket usw. möglicherweise Dutzende anderer Systeme wie Drucker oder ReverseProxy).

Gibt es Möglichkeiten dies aus dem AD abzufragen, welches System und wann sich mit dem Account angemeldet hat?

Wie würdet ihr so eine Passwortänderungen angehen?
Ich habe aktuell ca. 30 verdächtige Systeme ggfs. mit Hunderten von Configdateien.

Falls jemand eine sinnvoller Idee hat als alle Configs manuell zu prüfen, bedanke ich mich für den Vorschlag?

Gr. I.

Content-Key: 7602381911

Url: https://administrator.de/contentid/7602381911

Printed on: April 27, 2024 at 06:04 o'clock

Member: mayho33
mayho33 Jun 21, 2023 at 08:01:04 (UTC)
Goto Top
Hi,

Ihr habt also einen "Service-Account" bei dem ist das PW ändern wollt und nun sucht ihr nach eine Möglichkeit abzusehen wo es crashen wird, weil es ein wenig undokumentierten Wildwuchs gibt?

Dann sollte das helfen:

https://theitbros.com/windows-user-login-history/

Grüße!
Member: DerMaddin
DerMaddin Jun 21, 2023 at 08:01:17 (UTC)
Goto Top
Auf einem DC im Eventlog Einträge mit der ID 4624 und Typ Logon durchsuchen nach dem betreffendem AD-User.
Generell aber empfehle ich pro Dienst ein Service-Account zu nutzen, damit im Falle von Änderungen/Löschung nicht andere betroffen sind.
Member: istike2
istike2 Jun 21, 2023 at 08:05:15 (UTC)
Goto Top
Quote from @mayho33:
Ihr habt also einen "Service-Account" bei dem ist das PW ändern wollt und nun sucht ihr nach eine Möglichkeit abzusehen wo es crashen wird, weil es ein wenig undokumentierten Wildwuchs gibt?

Genau. face-smile
Member: istike2
istike2 Jun 21, 2023 at 08:06:10 (UTC)
Goto Top
Quote from @DerMaddin:
Generell aber empfehle ich pro Dienst ein Service-Account zu nutzen, damit im Falle von Änderungen/Löschung nicht andere betroffen sind.

Vielen Dank, ja, wir haben es inzw. auch kapiert, dass es nicht gerade "best practice" war ...