Lets say we have around 300 Windows XP machines on our ActiveDirectory domain that are used for processing something. Each has an account which is patterned on the machines name. As these are treated as normal domain accounts, they are subject to the monthly password change requirements.

We have techs who go through and change the passwords each month, but this is tedious, error-prone, and time consuming. In an effort to make it better, I am going to start changing the passwords on the 300+ accounts programatically.

This, however, presents a problem. The machines are logged on as the user accounts we are changing, and by default do not update the cached credentials, which eventually will lock the account out when it tries accessing locations on the network.

Is there any way to update the cached credentials on a machine without locking/logging? Perhaps a Policy setting?

  • I suppose that configuring auto-logon (with new credentials), rebooting, then disabling auto-logon, is out of the question. – jscott Sep 27 '11 at 0:06
  • If, after doing that, I change the password a month later, is there the likely hood that I will have to do it again, or that I will be presented with the "Window needs your new credentials" or whatever? If so, then it wont work for me. Really I am looking for a way to change passwords on 300 plus accounts that are currently logged in without having anyone do anything besides myself running the password change program I have written. – CodeWarrior Sep 27 '11 at 0:57
  • 4
    You'll hit the "Window needs your new credentials" any time you don't logon/lock-unlock after the user's password changes. I was thinking, if the users-to-XP-machines is a 1:1 mapping, a portion of the "password change" process could incorporate an auto-logon/reboot using the new credentials. This wouldn't involve any hands-on work, just additional scripting. – jscott Sep 27 '11 at 1:10
  • What you basically need is an answer to the question on how to change the user's own password from within the user's context by script. I've bountied the question, let's see if something comes up in the end. – the-wabbit Sep 27 '11 at 8:11
  • Yeah. I have worked with ActiveDirectory objects quite a bit in .NET, but that doesn't really touch the workstation's cached credentials, except inasmuch that the account in AD no longer matches the workstations... Never messed around much with Windows scripting or anything like that. This will be a bit of a learning experience. – CodeWarrior Sep 27 '11 at 13:46

If the XP boxes have been joined to the domain then there is already a machine account for each one. It is maintained by Windows and AD without you having to do anything special. It never expires and works after reboot and without anyone having to log in.

Rather than creating an account per machine matching the machine name why not just rig your job to run as "NT Authority\NetworkService" (FireDaemon works great when you need to turn a program into a service) and let it take care of itself? All you need to do is permit those machines on the other end by adding accounts in the form DOMAIN\MACHINENAME$.

  • I am not the domain admin, and their reasons are their own. This may have to do with the fact that all of these accounts need access to several hundred databases or any of thousands of network filesystem locations, I don't know. I am just the developer who is being asked to figure out a way to do this. The account name is not exactly the name of the machine, but has the numeric portion of the machine name in it... – CodeWarrior Sep 29 '11 at 19:22
  • After re-reading your post I realize now that you are talking about an AD account for the machine. All I know at this point is that this is how we have it set up, and it is unlikely that I will be able to do anything to change it... – CodeWarrior Sep 29 '11 at 20:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.