PWDMan Update

I’ve updated my Password Manager utility. If you haven’t seen this, I wrote about it in my Mr. Roboto column. This tool will scan computers and report the age of the local administrator password. If you’ve renamed the account you can change the account name to check. When finished, you’ll have a nice report showing how old the administrator account password is on all computers. You can print the report or export it to a CSV.

The utility also will change the password on all your computers as well.

The latest version (v1.4) adds support for searching Active Directory, including recursing through all child containers. If you have a small network this should be ok. But be careful as you might end up trying to check computers that no longer exist. There is a ping option you can select to verify the computer is up and running before attempting an password tasks.

Other changes:

    • Added code to support multiple computernames separated by commas.
    • Added an Age Limit alarm so that password ages equal to or greater than this number will be highlighted in red.
    • Added Report Last Run footer.

You can download the latest version, read more as well as see some short videos of the tool in action at http://www.jdhitsolutions.com/pwdman

Technorati tags: ADSI, , , , MrRoboto


del.icio.us tags: , , , ,

4 thoughts on “PWDMan Update

  1. i have tried the pwdman i works for few systems, but for many PCs it is showing Error 46 permission denied or error 48 permission denied

    any other paramaters should i need to follow

    kindly guide me

  2. The errors are pretty clear that you don’t have admin permissions on those remote servers. I’ve also found problems when I run this from a desktop that isn’t part of the domain I am querying, but it sounds like some machines work and some don’t so that is likely not the case. You might need to verify the account you are using is still a member of the administrators group on those trouble machines. There may also be a problem with those machines in regards to their trust relationship with the domain. You can use NETDOM.EXE to verify the trust relationship. Finally, you may have to look at the event log on the problem machines to see if you can get any other tidbits of information that might explain why you are getting denied.

  3. hai jeffery

    first off all we are not having a domain environment. we have 450 thin client in workgroup environment. i want to change the local admin password for the 450 thin clients. also i have used the correct username and password.

    does PWDMAN does not support workgroup environment ?

    Regards
    Balaji

  4. It might work in theory for that type of environment but there are many gotchas. You have to have an account with admin rights for every machine. Then, you’d have to make sure you could use passthrough authentication. That is, the account name and password you are using to run PWDMAN must be the same as the admin account on all the machines. There’s no provision for you to specify an account like XP0123\administrator.

    The other work around is to already have a secure channel to the remote machine such as mapping a drive to the remote C$ or Admin$ shares using an alternate credential. ADSI should then use that connection. But with 450 you can’t map that many drives in advance. You could do this in smaller batches and map drives ahead of time, or take the code from the HTA and write your own script that maps a drive with the credentials then does the ADSI stuff. I have to say that given this type of environment, I think any tool is going to have these types of issues.

Comments are closed.