Implementierung einer Passwortpolicy
Sollte jemand von euch auch das Problem haben, dass es sehr viele Benutzer gibt, die nicht wissen wie man das Kennwort bei der Aufforderung ändert, hier ein kleines Skript.
Dadurch kann man das AD nach allen Usern durchsuchen, welche vor X Jahren, Monaten, Tagen geändert haben und einfach per Klick diese zum ändern beim nächsten Login auffordern.
Außerdem umgehen wir so den bug, dass ein abgelaufenes Kennwort nicht mehr geändert werden kann (Policy Maximales Kennwortalter 42 Tage)...
Alternative wäre ein , welchem die User "bestimmt" auch alle nachgekommen wären...
https://github.com/agowa338/ForcePasswordChanges
Verwendung:
Remote Server Administration Tools installieren oder an einem Domain Controller ausführen.
Powershell Execution policy mittels "Set-ExecutionPolicy -ExecutionPolicy Unrestricted" in einem Powershell Command Prompt.
Anschließend im Konfigurationsbereich des Skripts den LDAP Pfad der zu durchsuchenden OU und die Zeit (z. B. AddYears(-5) vor über 5 Jahren) angeben.
Freue mich über Rückmeldungen
Dadurch kann man das AD nach allen Usern durchsuchen, welche vor X Jahren, Monaten, Tagen geändert haben und einfach per Klick diese zum ändern beim nächsten Login auffordern.
Außerdem umgehen wir so den bug, dass ein abgelaufenes Kennwort nicht mehr geändert werden kann (Policy Maximales Kennwortalter 42 Tage)...
Alternative wäre ein , welchem die User "bestimmt" auch alle nachgekommen wären...
https://github.com/agowa338/ForcePasswordChanges
Verwendung:
Remote Server Administration Tools installieren oder an einem Domain Controller ausführen.
Powershell Execution policy mittels "Set-ExecutionPolicy -ExecutionPolicy Unrestricted" in einem Powershell Command Prompt.
Anschließend im Konfigurationsbereich des Skripts den LDAP Pfad der zu durchsuchenden OU und die Zeit (z. B. AddYears(-5) vor über 5 Jahren) angeben.
Freue mich über Rückmeldungen
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 296424
Url: https://administrator.de/knowledge/implementierung-einer-passwortpolicy-296424.html
Ausgedruckt am: 02.04.2025 um 17:04 Uhr
9 Kommentare
Neuester Kommentar
Sers,
Unabhängig von Nutzen und Funktion deines Skriptes:
Das ist grob fahrlässig!
Es kann jetzt nu wirklich kein Aufwand sein, fix ein Code Signing Certificate an der Unternehmens-PKI raus zu lassen, und das Skript damit zu signieren. Und wenn man einen passenden Time Stamp Server in den Signing Vorgang einbindet, dann bleibt das Signatur auch nach Ablauf des Zertifikats gültig.
Und die Execution Policy bleibt schön auf "AllSigned" und sicher.
Technet: Hey, Scripting Guy! How Can I Sign Windows PowerShell Scripts with an Enterprise Windows PKI? (Part 1 of 2)
Technet: Hey, Scripting Guy! How Can I Sign Windows PowerShell Scripts with an Enterprise Windows PKI? (Part 2 of 2)
Grüße,
Philip
Unabhängig von Nutzen und Funktion deines Skriptes:
Zitat von @agowa338:
Verwendung:
Remote Server Administration Tools installieren oder an einem Domain Controller ausführen.
Powershell Execution policy mittels "Set-ExecutionPolicy -ExecutionPolicy Unrestricted" in einem Powershell Command Prompt.
Verwendung:
Remote Server Administration Tools installieren oder an einem Domain Controller ausführen.
Powershell Execution policy mittels "Set-ExecutionPolicy -ExecutionPolicy Unrestricted" in einem Powershell Command Prompt.
Das ist grob fahrlässig!
Es kann jetzt nu wirklich kein Aufwand sein, fix ein Code Signing Certificate an der Unternehmens-PKI raus zu lassen, und das Skript damit zu signieren. Und wenn man einen passenden Time Stamp Server in den Signing Vorgang einbindet, dann bleibt das Signatur auch nach Ablauf des Zertifikats gültig.
Und die Execution Policy bleibt schön auf "AllSigned" und sicher.
Technet: Hey, Scripting Guy! How Can I Sign Windows PowerShell Scripts with an Enterprise Windows PKI? (Part 1 of 2)
Technet: Hey, Scripting Guy! How Can I Sign Windows PowerShell Scripts with an Enterprise Windows PKI? (Part 2 of 2)
Grüße,
Philip
Dass das Skript für die eigene PKI/Domäne signiert sein muss, und nicht von dir signiert werden kann, das dürfte wohl logisch sein.
Abgesehen davon dass bei einer "Vor-Signierung" deinerseits - selbst wenn du ein Code Signing Certificate e.g. von Thawte oder Symantec hättest - man selbst keinerlei Anpassungen mehr am Skript vornehmen könnte, ohne dass die Signierung aufgrund der Inhaltsänderung wertlos wird.
Was mich an der Anleitung einfach störte ist das Aufreissen der allgemeinen Execution Policy auf den Systemen. Auch wenn es der einfachste Weg ist PS Skripte zur Ausführung zuzulassen.
Selbst wenn es Mittel und Wege um die Policy gibt (die oftmals mehr Basisrechte erfordern als man sonst zum Starten des Skriptes bräuchte), man muss es den Angreifern nicht allzu einfach machen.
Bitte vergiss nicht, dass die Anleitungen hier regelmäßig als einzige Wahrheit gesehen werden, und stur abgebetet wird was da steht.
Abgesehen davon dass bei einer "Vor-Signierung" deinerseits - selbst wenn du ein Code Signing Certificate e.g. von Thawte oder Symantec hättest - man selbst keinerlei Anpassungen mehr am Skript vornehmen könnte, ohne dass die Signierung aufgrund der Inhaltsänderung wertlos wird.
Was mich an der Anleitung einfach störte ist das Aufreissen der allgemeinen Execution Policy auf den Systemen. Auch wenn es der einfachste Weg ist PS Skripte zur Ausführung zuzulassen.
Selbst wenn es Mittel und Wege um die Policy gibt (die oftmals mehr Basisrechte erfordern als man sonst zum Starten des Skriptes bräuchte), man muss es den Angreifern nicht allzu einfach machen.
Bitte vergiss nicht, dass die Anleitungen hier regelmäßig als einzige Wahrheit gesehen werden, und stur abgebetet wird was da steht.
Hi.
Ein nettes Skript, keine Frage.
Fragen habe ich dennoch:
Was hat der Titel mit dem Skript zu tun? Dies ist doch keine "Implementierung einer Passwortpolicy".
Was für ein Bug ist mit "bug, dass ein abgelaufenes Kennwort nicht mehr geändert werden kann" gemeint? Ich sehe da keinen.
Die Executionpolicy braucht man auch nicht zu ändern, wenn man es einfach in die ISE schreibt. Und unrestricted wäre eh die falsche Wahl, remote-signed tut es völlig, aber sei's drum. Dauerhaft verändert man jedenfalls keine Executionpolicy auf unrestricted, denn dann fällt der Schutz gegen "shoot oneself in the foot" (Zitat aus Deinem Link) nämlich flach. Nein, mit Sicherheit hat das zunächst mal nichts zu tun (steht auch in Deinem Link), es ist lediglich Schutz vor eigener Torheit.
Ein nettes Skript, keine Frage.
Fragen habe ich dennoch:
Was hat der Titel mit dem Skript zu tun? Dies ist doch keine "Implementierung einer Passwortpolicy".
Was für ein Bug ist mit "bug, dass ein abgelaufenes Kennwort nicht mehr geändert werden kann" gemeint? Ich sehe da keinen.
Die Executionpolicy braucht man auch nicht zu ändern, wenn man es einfach in die ISE schreibt. Und unrestricted wäre eh die falsche Wahl, remote-signed tut es völlig, aber sei's drum. Dauerhaft verändert man jedenfalls keine Executionpolicy auf unrestricted, denn dann fällt der Schutz gegen "shoot oneself in the foot" (Zitat aus Deinem Link) nämlich flach. Nein, mit Sicherheit hat das zunächst mal nichts zu tun (steht auch in Deinem Link), es ist lediglich Schutz vor eigener Torheit.
Wenn der PC gesperrt ist und das Passwort abläuft, kann der PC nicht mehr entsperrt werden.
Blödsinn Wenn der Benutzer angemeldet ist und das Passwort abläuft, fliegt die Verbindung mit den Netzlaufwerken weg
Auch das stimmt so nicht, und vor allem ist das kein Bug.