Lokales User Passwort ändern

[Mike-Sbg 10]

Hallo Leute,

 

ich habe folgendes Problem:

Eine Workstation in einer Windows NT/Samba-Domain. Darauf ist ein "normaler" User angemeldet.

 

Ich möchte jetzt ein Script schreiben, mit dem das Kennwort dieses Users geändert wird.

 

Wenn ich es nur auf dem Domain-Controller mache, führt das leider zu Problemen. Ich möchte also jene API nutzen, die auch hinter dem STRG+ALT+ENTF - Kennwort Ändern Dialog steckt.

 

Kann mir da jemand weiterhelfen ... weil z.B. mit PSPASSWD.EXE kann man nur das Kennwort eine lokalen Users z.B. Administrator ändern.

[XP-Fan 151]

Hallo Mike-Sbg,

 

schau mal in der cmd nach" net user /? ".

Sollte dir weiterhelfen können.

[blub 115]

http://www.microsoft.com/technet/technetmag/issues/2007/04/HeyScriptingGuy/default.aspx?rss=http://www.microsoft.com/technet/technetmag/issues/2007/04/HeyScriptingGuy&loc=de

 

da ist ein bischen mehr dabei, aber im letzten Skript steht das Essentielle (Set objUser = GetObject(“WinNT:// ....)

 

cu

blub

[Mike-Sbg 10]

Danke für die Tipps. nur leider ergeben sich genau die 2 Probleme:

 

Mit Net User kann ich (mit den richtigen Berechtiigungen) ein User-Kennwort auf dem Domain-Controller zurücksetzen ... das wirkt sich aber nicht sofort auf den Client aus. In dier Zeit bis zum Reboot - so meine Erfahrungen - funktioniert der Client dann sehr komisch, sodaß er z.B. auf gewisse File-Server sich nicht mehr verbinden darf.

 

Das Script hilft mir nur bei der Änderung von lokalen Usern weiter, nicht jedoch bei Usern der Domain. Wenn ich versuche auf einen lokal gecacheten User zuzugreifen, bekommen die Scripts alle den Fehler, daß sie den User nicht finden können, was mache ich da falsch?

 

Was ich bräuchte, sind genau die Routinen, die sich hinter dem STRG+ALT+ENTF + Kennwort verbergen

[blub 115]

ahh, jetzt hab ichs auch verstanden..

Ich bin mir fast sicher, dass man STRG-ALT-Entf nicht einfach nachprogrammieren und schon gar nicht skripten kann. Da steckt ein Schutzmechanismus gegen Trojaner dahinter, der garantieren soll, dass man sein Password nur dem Winlogon-Prozess übergibt.

 

Vielleicht kannst du das Domänenpasswort ändern, den Client neu starten und den User wieder über den autologonuser-Mechanismus automatisch anmelden lassen. Die notwendingen Registrykeys kannst du vor dem Neustart setzen und nach dem Boot wieder löschen

 

cu

blub

[Zearom 10]

mmh ich kann dem Problem hier nicht ganz folgen.

 

Um das Passwort einen AD-Users zu ändern nutzt man normalerweise das ADSI-Interface, welches einem bei einem User-Object die Funktion "changePassword" zur verfügung stellt. Als Parameter gibt man dem User das alte Password und das neue Password mit. Aufrufen kann dann diese Funktion jeder User für sein eigenes Userobject. Probleme nach dem PW-Change darf es eigentlich nicht geben, da eine Authentifizierung mit dem Password danach nicht mehr erfolgt, weil der User bereits Authentifiziert ist und sein Anmeldetoken besitzt. Das neue Passwort wird halt erst bei der nächsten Authentifizierung benötigt. Ich hab hier auch mehrere Jobs die Passwörter ändern können, und ich hatte nie das Problem da sich jemals mit irgendeinem anderen System Fehler bekommen hab, nachdem ich das PW gewechselt hab.

 

Der STRG-ALT-ENTF Mechanismus, macht ja auch nicht mehr als über das ADSI-Interface das PW zu wechseln. lässt sich doch alles relatitv simpel über vbs-Scripts lösen, im Scripting Center findet man dazu garantiert auch beispiele.

 

Bitte die ChangePassword Funktion nicht mit der "SetPassword" funktion verwechseln, letztes ist quasi das "Passwort zurücksetzen" und benötigt rechte des Kontooperators (oder wie die gruppe genau heist)

[blub 115]

Das Kerberos TGT Ticket ist ein Problem. Dieses Ticket wird nach 10 Stunden erneuert, was nicht funktioniert wenn domainpasswort und Clientpasswort unterschiedlich sind.

 

cu

blub

[Mike-Sbg 10]

@Blub: Danke, zwar arbeitet unsere NT-Domain ohne Kerberos sondern noch mit NTLM V2 aber nichts desto trotz, läuft man dort in das selbe Probleme hinein.

 

Der STRG+ALT+ENTF-Dialog macht da offensichtlich mehr, wie am Domain-Controller das Kennwort zu setzen .... und da war es wieder mein Problem :rolleyes:

[Zearom 10]

Okay, ich hatte da wohl eine Wissenslücke. Aber das heist ja fürmich das Windows das User-Pw im Speicher halten muss. Mmmh ich werd dazu nochmal die DOkus wälzen, weil das interessiert mich ja nun.