9
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
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: 296424
Url: https://administrator.de/contentid/296424
Printed on: April 19, 2024 at 21:04 o'clock
9 Comments
Latest comment
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
Tja, aber selbst wenn ich es signiert hätte, würde deine Domäne das Zertifikat nicht akzeptieren. Außer ich würde mir eins kaufen.
Aber der "Execution Policy" Schutz ist sowieso gebrochen in meinen Augen: https://blog.netspi.com/15-ways-to-bypass-the-powershell-execution-polic ...
Falls es dir dabei besser geht, es gibt ja auch folgende Wege:
1. Du holst dir selbst ein Zertifikat von deiner PKI, von meiner währe das sowieso sinnlos.
2. Du startest das ganze über cmd mit dem Befehl:
3. Nach dem Benutzen weider ein "Set-ExecutionPolicy RemoteSigned" ausführen
Wo soll das jetzt Sicherheit liefern?
Außerdem bin ich eigentlich davon ausgegangen, dass wenn ich hier so etwas schreibe sich die verwendeten mit Powershell zumindest soweit auskennen, das Skript zu verstehen. Wer führt denn Programme/Skripte einer unbekannten Person die er selbst nicht versteht auf seinem Domain Controller aus???
Aber trotzdem danke für die Links zum signieren der Skripte, werde ich in Erwägung ziehen, falls ich mir irgendwann ein Code Signing Certificate holen sollte.
@psannz: Als ich mir das genauer angesehen habe, fand ich das hier: https://gallery.technet.microsoft.com/scriptcenter/Powershell-ISE-Add-on ... dadurch wird ein Menüpunkt im ISE hinzugefügt um die Signierung zu erleichtern. Getestet hab ich es jedoch nicht.
Aber der "Execution Policy" Schutz ist sowieso gebrochen in meinen Augen: https://blog.netspi.com/15-ways-to-bypass-the-powershell-execution-polic ...
Falls es dir dabei besser geht, es gibt ja auch folgende Wege:
1. Du holst dir selbst ein Zertifikat von deiner PKI, von meiner währe das sowieso sinnlos.
2. Du startest das ganze über cmd mit dem Befehl:
powershell -ExecutionPolicy Unrestricted -command .\ForcePaswordChange.ps1Wo soll das jetzt Sicherheit liefern?
Außerdem bin ich eigentlich davon ausgegangen, dass wenn ich hier so etwas schreibe sich die verwendeten mit Powershell zumindest soweit auskennen, das Skript zu verstehen. Wer führt denn Programme/Skripte einer unbekannten Person die er selbst nicht versteht auf seinem Domain Controller aus???
Aber trotzdem danke für die Links zum signieren der Skripte, werde ich in Erwägung ziehen, falls ich mir irgendwann ein Code Signing Certificate holen sollte.
@psannz: Als ich mir das genauer angesehen habe, fand ich das hier: https://gallery.technet.microsoft.com/scriptcenter/Powershell-ISE-Add-on ... dadurch wird ein Menüpunkt im ISE hinzugefügt um die Signierung zu erleichtern. Getestet hab ich es jedoch nicht.
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.
Es handelt sich um ein Assistenz Skript für die Implementierung einer Passwortpolicy, deshalb der Titel.
Ok, und der Bug?
- Wenn der PC gesperrt ist und das Passwort abläuft, kann der PC nicht mehr entsperrt werden.
- Wenn der Benutzer angemeldet ist und das Passwort abläuft, fliegt die Verbindung mit den Netzlaufwerken weg
- ...
- Wenn der Benutzer angemeldet ist und das Passwort abläuft, fliegt die Verbindung mit den Netzlaufwerken weg
- ...
Wenn der PC gesperrt ist und das Passwort abläuft, kann der PC nicht mehr entsperrt werden.
Blödsinn 
Das probier bitte mal aus, es stimmt nicht.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.
Also das tritt bei uns definitiv so auf, eventuell ist hier aber auch eine andere Einstellung verbogen um das auszulösen, würde mich jedenfalls nicht mehr groß wundern...
