2
Selbes Passwort bei verschiedenen Usern in der ADS verhindern
Hallo,
wir haben folgendes Problem in der Firma, dass manche Abteilungen das komplett selbige Passwort verwenden, um den Zugriff auf alle User für alle User in der Abteilung zu gewähren, was eigentlich nicht sein sollte.
Nun hier meine Frage,
kann ich in der ADS mit irgendwelchen Boardmitteln oder Tools verhindern, dass die User das selbes Passwort verwenden können?
Grüße
DuckY
wir haben folgendes Problem in der Firma, dass manche Abteilungen das komplett selbige Passwort verwenden, um den Zugriff auf alle User für alle User in der Abteilung zu gewähren, was eigentlich nicht sein sollte.
Nun hier meine Frage,
kann ich in der ADS mit irgendwelchen Boardmitteln oder Tools verhindern, dass die User das selbes Passwort verwenden können?
Grüße
DuckY
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: 83566
Url: https://administrator.de/contentid/83566
Printed on: April 25, 2024 at 20:04 o'clock
2 Comments
Latest comment
Hallo !
Mit Windows Boardmitteln kann sowas nicht verhindert werden. Es macht eigentlich auch wenig Sinn, denn
a) ist es für die User sehr unkomfortabel, wenn sie plötzlich ein eigentlich geeignetes Kennwort nich verwenden können, wenn es (unbeabsichtigt) identisch ist mit dem irgendeines anderen Users.
Stell Dir ml vor, Dein Netzwerk wächst auf 200 User oder mehr an.
b) ist es ein Sicherheitsrisiko, wenn ich als Anwender über diesen Weg darüber benachrichtigt werde, dass es jemanden anderes im AD gibt, der dasselbe Kennwort verwendet. Dann brauche ich ja nur noch die einzelnen Usernamen mit dem Kennwort durchzuprobieren, um an einen fremden Account heranzukommen.
Man könnte sicherlich ein Script entwerfen, welches auf das AD zugreift und die dort gespeicherten Hashes miteinander vergleicht - und dann diejenigen benachrichtigt, die identische Kennwörter haben - oder diese Accounts einfach auf "Kennwort bei der nächsten Anmeldung ändern" setzt.
Um aber im Moment der Passwort-Änderung einen Abgleich zu starten und in Echtzeit den Anwender ggf. darauf hinzuweisen, dass er dieses Kennwort nicht verwenden kann, müsste man die ganze Windows-Passwort-Änderungs-Routine umschreiben. Denn wie gesagt: Mit Bordmitteln geht das nicht.
Alternative:
Mach den Leuten einfach mal klar, welches Risiko es für sie darstellt, wenn andere ihr Kennwort kennen. Es kann immer mal jemanden geben, der sauer auf einen ist. Und wenn der dann einfach eine Mail unter meinem Account schreiben kann - z.B. mit unflätigen Beschimpungen an die Geschäftsleitung - wie soll ich dann beweisen, dass die Mail nicht von mir kommt ? Da ist ratz-fatz der eigene Job weg.
Oder mache der Geschäftsleitung klar, welche Risiken bestehen, wenn die Mitarbeiter ihre Kennwörter an andere weitergeben - und lasse die Geschäftsleitung eine entsprechende Arbeitsanweisung herausgeben - mit entsprechender Androhung von Abmahnungen.
Und Du musst den Anwendern der einzelnen Abteilungen Mittel und Wege an die Hand geben, mit denen sie im Krankheits- oder Urlaubsfall problemlos die Vertretung für andere Kollegen übernehmen können - d.h. Abteilungsbezogene Datenablage mit gemeinsamen Zugriff und Vertretungsfunktionen im E-Mail etc.
Gruß teejay
Mit Windows Boardmitteln kann sowas nicht verhindert werden. Es macht eigentlich auch wenig Sinn, denn
a) ist es für die User sehr unkomfortabel, wenn sie plötzlich ein eigentlich geeignetes Kennwort nich verwenden können, wenn es (unbeabsichtigt) identisch ist mit dem irgendeines anderen Users.
Stell Dir ml vor, Dein Netzwerk wächst auf 200 User oder mehr an.
b) ist es ein Sicherheitsrisiko, wenn ich als Anwender über diesen Weg darüber benachrichtigt werde, dass es jemanden anderes im AD gibt, der dasselbe Kennwort verwendet. Dann brauche ich ja nur noch die einzelnen Usernamen mit dem Kennwort durchzuprobieren, um an einen fremden Account heranzukommen.
Man könnte sicherlich ein Script entwerfen, welches auf das AD zugreift und die dort gespeicherten Hashes miteinander vergleicht - und dann diejenigen benachrichtigt, die identische Kennwörter haben - oder diese Accounts einfach auf "Kennwort bei der nächsten Anmeldung ändern" setzt.
Um aber im Moment der Passwort-Änderung einen Abgleich zu starten und in Echtzeit den Anwender ggf. darauf hinzuweisen, dass er dieses Kennwort nicht verwenden kann, müsste man die ganze Windows-Passwort-Änderungs-Routine umschreiben. Denn wie gesagt: Mit Bordmitteln geht das nicht.
Alternative:
Mach den Leuten einfach mal klar, welches Risiko es für sie darstellt, wenn andere ihr Kennwort kennen. Es kann immer mal jemanden geben, der sauer auf einen ist. Und wenn der dann einfach eine Mail unter meinem Account schreiben kann - z.B. mit unflätigen Beschimpungen an die Geschäftsleitung - wie soll ich dann beweisen, dass die Mail nicht von mir kommt ? Da ist ratz-fatz der eigene Job weg.
Oder mache der Geschäftsleitung klar, welche Risiken bestehen, wenn die Mitarbeiter ihre Kennwörter an andere weitergeben - und lasse die Geschäftsleitung eine entsprechende Arbeitsanweisung herausgeben - mit entsprechender Androhung von Abmahnungen.
Und Du musst den Anwendern der einzelnen Abteilungen Mittel und Wege an die Hand geben, mit denen sie im Krankheits- oder Urlaubsfall problemlos die Vertretung für andere Kollegen übernehmen können - d.h. Abteilungsbezogene Datenablage mit gemeinsamen Zugriff und Vertretungsfunktionen im E-Mail etc.
Gruß teejay
Diese Sicherheitslücke wäre mir bewusst, aber die wahrscheinlich dass jemand das gleiche PW verwendet ist sehr gering, da mit den Komplexitätsanforderungen dies fast unmöglich.
Schade, aber die User sehen es mehr als Schikane der IT an.... Müssen wir vielleicht mit IT-Sicherheitsrichtlinien klar machen, dass man Ihnen bei dem selbigen Verstoß eine Mahnung zukommen lassen kann.
Danke & Grüße
DuckY
Schade, aber die User sehen es mehr als Schikane der IT an.... Müssen wir vielleicht mit IT-Sicherheitsrichtlinien klar machen, dass man Ihnen bei dem selbigen Verstoß eine Mahnung zukommen lassen kann.
Danke & Grüße
DuckY
