Griller Geschrieben 11. November 2014 Teilen Geschrieben 11. November 2014 Hi, wir ändern zurzeit unsere Kennwörter bei den Usern. Das ganze habe ich etwas automatisiert, indem ich mir im Netz einige Powershell-Scripte angesehen habe. Dabei ist folgendes herausgekommen: Import-Module ActiveDirectory #HENSELAD importieren Import-Csv "PassChange.csv" | Foreach { #PassChange.csv importieren (name=Username, pw=Neues Kennwort) $user = $_.name #Variable user setzen $pw = $_.pw #Variable Kennwort setzen try { Set-ADAccountPassword -Identity $user -NewPassword (ConvertTo-SecureString -AsPlainText $pw -force) -Reset #Neues Kennwort setzen Write-Output "$user,Success" #Success bei Erfolg ausgeben } catch { Write-Output "$user,Error" #Error bei Fehler ausgeben } } | Out-File PassChange.log Es wird also aus der CSV Datei username und Kennwort ausgelesen. Klappt auch fast immer aber bei einigen muss man das Kennwort manuell neu setzen. Es wird trotzdem in der Logdatei ein Success ausgegeben. Ich vermute, dass dies an den Kennwörter liegt. Es handelt sich dabei um ein Wort, drei Zahlen und ein Sonderzeichen. Das Sonderzeichen variiert immer, deshalb liegt die Vermutung nahe, dass es da Probleme gibt. Zum Beispiel macht das §-Zeichen große Probleme, aber bei anderen Zeichen tritt das Problem genauso auf. Handelt es sich hier in irgendeiner Art und Weise um eine Escape-Sequenz oder etwas ähnliches? LG Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Griller Geschrieben 11. November 2014 Autor Teilen Geschrieben 11. November 2014 Habe das gerade mal mit einem Testnutzer provoziert. Bis auf das §-Zeichen waren alle Sonderzeichen, die sich auf den Zahlen 1-0 befinden erfolgreich Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
orioon Geschrieben 11. November 2014 Teilen Geschrieben 11. November 2014 Für was braucht ihr da ein Script? Einfach im AD setzen, dass der Nutzer beim nächsten Login ein neues Passwort wählen muss und gut ist?! Oder gibt es den begründeten Verdacht, dass Accounts kompromittiert wurden? So sperrt ihr doch die Nutzer aus, weil sie das neue Kennwort nicht kennen. Erschließt sich mir nicht... Tippe ebenfalls auf eine Escapesequenz. Schau dir das mal an: C# verbatim strings vs. PowerShell here-strings | John D. Cook Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Griller Geschrieben 11. November 2014 Autor Teilen Geschrieben 11. November 2014 Weil wir aufgrund der besseren Administrierbarkeit die Kennwörter kennen sollen. Über Sinn und Unsinn möchte ich aber eigentlich nicht diskutieren, weil das nicht in meiner Entscheidungsgewalt lag (sonst wäre es vermutlich so gemacht worden, wie du geschrieben hast). Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Heikooo Geschrieben 12. November 2014 Teilen Geschrieben 12. November 2014 "Zur besseren Administrierbarkeit" hihi.... Was macht ihr denn wenn ein User sein Passwort im Nachgang wieder ändert? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Griller Geschrieben 12. November 2014 Autor Teilen Geschrieben 12. November 2014 Das darf der nicht. Ist aber auch wirklich nicht nötig zu besprechen. Ist sowohl vom chef als vom Betriebsrat abgesegnet Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Maniska Geschrieben 12. November 2014 Teilen Geschrieben 12. November 2014 Weil wir aufgrund der besseren Administrierbarkeit die Kennwörter kennen sollen Aufgrund der sehr guten Administrierbarkeit ist es mir egal welches Kennwort ein User hat: Brauche ich dringen Zugriff auf sein Konto und er ist nicht da, wird das Kennwort zurückgesetzt und gut ist. Hat den Vorteil, dass der User dafür verantwortlich gemacht werden kann wenn in seinem Namen etwas angestellt wird, da nur er sein Kennwort kennen darf. Wenn es nicht über zurücksetzen geht, muss er halt hier antraben. Es gibt keinen Grund warum irgendjemand, und schon gar nicht die IT, fremde Kennwörter kennen muss, und ich würde auch den Teufel tun und so arbeiten. Datenschutzrechtlich extrem bedenklich und keinerlei Möglichkeit von Seiten der IT zu sagen "wir haben nix gemacht". Bei euch kann der Anwender hergehen und soweit seine Rechte reichen den Fileserver löschen oder anderen Quatsch machen (gibt auch einige sehr schöne Dinge für die man nur User Rechte braucht). Niemand kann beweisen dass es dieser User war. Meiner Meinung nach liegt euer Problem nicht in dem Script sondern in einer absolut bescheuerten Kennwortpolitik. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Griller Geschrieben 12. November 2014 Autor Teilen Geschrieben 12. November 2014 Lieg aber wie gesagt als azubi nicht in meiner Entscheidungsgewalt Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
orioon Geschrieben 12. November 2014 Teilen Geschrieben 12. November 2014 (bearbeitet) Ich habe dir bereits einen Link gepostet gehabt, hast du dir das mal angesehen? C# verbatim strings vs. PowerShell here-strings | John D. Cook Die Entscheidung ist aber dennoch hirnrissig von eurem Unternehmen. Haben wir hier einen Datenschützer im Forum? Wenn das mit deutschem Recht nicht vereinbar ist, seht ihr bei der nächsten Prüfung ganz alt aus. Betriebsrat hin oder her, die kochen auch nur mit Wasser... Ein Arbeitnehmer wird vor Gericht mit relativ hoher Wahrscheinlichkeit gewinnen, wenn ihr ihm nahelegt Daten entwendet zu haben. Den meisten Möglichkeiten des Nachweises beraubt ihr euch gerade selber. Sorry, aber da fehlen mir echt die Worte... Bearbeitet 12. November 2014 von orioon Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Griller Geschrieben 12. November 2014 Autor Teilen Geschrieben 12. November 2014 Topic: Ich habe es mir bereits angesehen. Da es bei Kennwörtern mit § aber andere Probleme gibt (Batch Dateien, etc) wird das §-Zeichen nun ersetzt.. Offtopic: Mein Chef kennt die Argumente, aber da habe ich nunmal nichts zu sagen. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.