Jump to content

Bulk Password Resets


cwilson

Recommended Posts

Hi Community,

I have read through several forum posts and the available documentation but I am still unclear on how to achieve what I am after. We are trying to setup a process to automatically change the local administrator password on all of our workstations on a scheduled basis (4600 workstations). I have created a password list specific for this purpose, but when I select a Windows Account as the target account type, I am required to select a hostname. Obviously if choosing an AD account, I can specify the domain, but I am not suspect this applies to a specific host. My question is, how I can apply this password reset policy to all workstations in our environment?  I am probably missing something simple.

I have already scanned our AD, created a folder under Hosts for Workstations and imported all workstations into this folder. Next is figuring out how to apply this policy in bulk to all workstations.

The last step to this is in ensuring there is a retry mechanism that can capture workstations that were offline during the initial run. IE. Run several times / day, every day until all workstations are updated - assuming there is the intelligence to track each successful workstation and skip it for future runs until the next scheduled password reset date.

Any help that can be provided would be great.

Link to comment
Share on other sites

Hello,

 

You can either set this up manually, but that would be an enormous amount of work that many workstations, or you can use one of our Discovery Jobs for this, which can automate the whole thing.

 

If you go to the Tools menu, and then Account Discovery, you will see you can add a Discovery Job called 'Windows Local Admin Accounts'. The screen should hopefully be self explanatory, but please let us know if you have any questions about the settings and filtering options.

 

Also, you can enable Simulation Mode initially if you just want an email report of what it finds, and also consider the requirements for this in the following document - https://www.clickstudios.com.au/downloads/version8/Password_Discovery_Reset_and_Validation_Requirements.pdf - basically you will need PowerShell Remoting enabled on all Workstations, and the documentation also shows how to do this via group policy if required.

 

Regards

Click Studios

Link to comment
Share on other sites

Supports method is the best method for your situation.
Just be sure to set the parent OU containing all the computer objects in your AD environment carefully so that it only searches within OUs with computers in them, and not servers. (Since I'm assuming you don't want to reset local admin password on the servers).

 

5 hours ago, cwilson said:

The last step to this is in ensuring there is a retry mechanism that can capture workstations that were offline during the initial run.

I'm not sure if Passwordstate does this, I've never had to care since I only reset server passwords, however I'd assume it does.

The security item in the password list won't change until it's been successfully reset, however the expiry date would have still passed - so it'd be a safe bet that it would try again the next day on the hour/minute you've specified for resets to take place (Which is a password list setting which inherits downwards to the security items)

If it doesn't, then it would be easy enough to achieve via the API.

Link to comment
Share on other sites

Sarge is correct:) 

 

If you have a failed reset, in the event the server is turned off for example, the Expiry date will not change and the Passwordstate Windows Service will retry the reset again the following day at the same time.  It will do this every day until the reset is successful, at which point it will then recalculate the Expiry date for another 90 days (or what ever you have it set at).

 

Hope this helps:)

Support.

 

Link to comment
Share on other sites

Thank you, this is very helpful. I was able to follow your guidance and verify the appropriate configuration steps in Account Discovery under the Tools menu options. I did fail to mention this earlier, so at least I was on the right track.

Sarge made the suggestion in ensuring the parent search OU was specified to contain only those computers to be targeted for account discovery. Could someone tell me where to set this value so I can be sure it is applying only to the workstations OU I am concerned about? I did not see this option within the Account Discovery context, and current the root of my domain is specified within the Active Directory Domains option under Administration.


Thank you!

 

Link to comment
Share on other sites

26 minutes ago, cwilson said:

Sarge made the suggestion in ensuring the parent search OU was specified to contain only those computers to be targeted for account discovery. Could someone tell me where to set this value so I can be sure it is applying only to the workstations OU I am concerned about? I did not see this option within the Account Discovery context, and current the root of my domain is specified within the Active Directory Domains option under Administration.

 

Actually, that setting is not part of the account discovery configuration. It's part of the host discovery config. The account discovery will simply login to all found hosts and try to find local administrator accounts.

 

If you feel iffy about having PasswordState run the account discovery for you, you could also create the user+password objects through the API. It's pretty darn wonderful! Assuming that you have some way of generating a list of hostnames from your CMDB (or other registration), it's a simple matter of a ForEach loop to create the required host and password objects. That's exactly what I'm doing right now for a few hundred IOT devices.

Link to comment
Share on other sites

Thank you Buckit. So if I understand correctly, under the Account and Host Discovery screen I should have two jobs. One should be a hosts discovery job for my workstations, in which I have specified a target OU. Then I should have a second job which is the local admin password reset job, which will query and take action against the items discovered in the host discovery job?

I have attached a screenshot of my current Account and Host Discovery page. I am hoping someone can confirm I am on the right track. Should the discovery process really take so long?

2017-12-08 08_57_05-Active Directory Users and Computers.jpg

Link to comment
Share on other sites

Hi,

 

Yes, that is correct. You can do Host filtering in your Account Discovery Job, but with 4600 workstations to interrogate, it will take some time - especially if some are turned off, as the script first needs to timeout before it moves on to the next Host.

 

Regards

Click Studios

Link to comment
Share on other sites

  • 4 weeks later...

Hi All,

I am coming back to this post after the holidays, as I would like to ensure I taking the correct steps and am a bit uncertain that I am.

I have created the Windows Local Admins Account discovery job and that seems to be functioning properly. I have also created a hosts discovery job and targeted a specific *test* OU with several *test* workstations. To this point I have been running both jobs in simulation mode and am ready to begin live testing.

My concern is the following. How do I ensure that when I actually run the password reset job, that it is running only against the hosts in the predefined *test* OU specified in the Hosts discovery job? The reason I ask is because under the Hosts tab, I have created two folders. Servers and Workstations. My discovery job is not auto-populating the workstation folder that I have defined filters for Windows 7, 8, and 10. However if I choose to add an inventory item to the Workstations folder I created under Hosts, every device in my domain is listed (4876 devices). I can add a filtered list of systems manually to the Workstations folder I created, but I would like this automated if possible so that newly added systems are always captured.

I only want to apply this local admin password reset job against the small isolated test OU and test workstations, but I see no indication that this targeted group is the only group the job will apply to. I cannot apply a local password change to all systems within the domain as different workstations have different local admin password policies depending on department and organization and I am not ready for that yet.

I am hoping someone can confirm and provide the necessary clarity.

Many thanks.

Link to comment
Share on other sites

Hi cwilson,

 

On the discovery job, there are multiple options for filtering on which hosts will be interrogated. By default, there is an option on the Host Discovery job called 'Populate the Host's Tag field with the Organizational Unit (OU) it belongs to', and on the Account Discovery job, you can filter on the Tag field.

This should give you what you need.

Regards

Click Studios

Link to comment
Share on other sites

That is what I was looking for and that did the trick! Thank you. 

You can take it for what it is worth, but I had a time figuring this out on my own even after read through the existing documentation. I am not sure if there are resources and or/perceived value for future customers, but it might be worth adding a similar type scenario example to your future documentation. It might at least provide a more clear jumping off point for those like me who unfortunately do not have a lot of time to experiment with trial and error. That said, I am really enjoying the product and the bang for the buck when compared with competitive solutions. Keep up the quality work and cost to feature ratio!

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...