Jump to content
Buckit

Bug report: password dependencies

Recommended Posts

Hey guys,

 

I'm still running an older version in my DEV environment, 8180. After defining a dependency for one of my password objects, I discover that I cannot edit the created dep. I can only add a new one and remove the existing one. That feels really sloppy. Was this fixed in a newer version, or is this a "FIXME" for a future release?

 

EDIT:

Here's another one! Instead of asking us to select both a script AND a dependency type, could you please make this an implicit action? Either you choose the "Reset Scheduled Task Password" script, or you choose the "Scheduled Task" dependency type. It's too easy to forget to change one of these and it leads to messy situations. Especially if you can't edit defined dependencies :)

 

EDIT 2:

Could you also consider renaming the "Reset Scheduled Task Password" script to "Reset Windows Scheduled Task Password"? Similar for the IIS app pool and the COM+ components. That will neatly group the four related scripts together in the pulldown menus.

 

Cheers,

 

 

Thomas

Share this post


Link to post
Share on other sites

Hi Thomas,

 

Firstly, can you rename your forum post to "By design: password dependencies" :):):)

 

We've released build 8284 today, and included changes for Edit and Edit 2 - we haven't renamed IIS and COM+ yet, as we did need to get the build out today.

For the editing of Dependencies, this is not currently possible as we haven't come across a requirement for this yet - until now. Until we can work on this, you will need to delete your dependency and then add it back - or if you are using our Discovery Jobs for this, it will add it back automatically.

 

Regards

Click Studios

Share this post


Link to post
Share on other sites
Quote

For the editing of Dependencies, this is not currently possible as we haven't come across a requirement for this yet - until now.

Personally, I'd expect one to be able to edit anything one has added :) Nothing's set in stone.

 

Quote

Until we can work on this, you will need to delete your dependency and then add it back - or if you are using our Discovery Jobs for this, it will add it back automatically.

Wait what? O_o

 

Time to hit the manuals again! You mean to say that I don't have to manually add 150+ dependencies for that task that runs on all my boxen? NICE!

 

Share this post


Link to post
Share on other sites

Whelp, looking back I realize that this would also be a wonderfully easy way to kill a lot of services in one fell swoop :D Especially when the target password list that accounts are added to adds auto-expiry to the passwords. Wouldn't it suck for your prod applications to restart in the middle of the day, because PState had a scheduled password reset? <_<

 

Let's tread carefully.

Share this post


Link to post
Share on other sites

Hi Thomas,

 

I'd need to double check the code when I'm back in the office, but newly discovered accounts should get the "Default Password Reset Schedule" from the Password List the accounts are dropped into - so  if these are for Windows Services, etc, then yes they should be scheduled outside of business hours.

Regards

Click Studios

Share this post


Link to post
Share on other sites

Yeah that was exactly my point :) Discovery puts an account in a list you've indicated and if that list has a default sched, it'll apply. That could lead to all manner of fun.

Share this post


Link to post
Share on other sites

Hey guys,

 

Here's another feature request: add an option for existing dependencies to manually re-sync the password in the dependent task/service.

 

I've just discovered one account that has 20 dependencies. Expiring the password went fine and for 17 out of 20 deps the password was updated on the dependent side. For 3 of them however, the change failed with cause "Unknown error". This means that I'll have to visit the boxen in question and manually update the password. For 3 services that's doable, for 30 that's gonna suck. But I also don't want to re-expire the password, because that means I'll be restarting the 17 services that -were- okay to begin with.

 

So, please add a command to re-apply the current password to a dependent service.

Share this post


Link to post
Share on other sites

Hi Thomas,

 

Are you asking to re-apply the previous password value to these 3 failed resets? If so, won't that cause issues because the password for the AD account is different?

 

Regards

Click Studios

Share this post


Link to post
Share on other sites

ACK! That's absolutely my point. 

 

Because every time that you change the password object itself, it will restart every single dependent service. You really do NOT want that. So, in my example of 3/20 failures, I only want to re-sync the password to the three failed dependencies. And because we're moving into troubleshooting-country I'd like to be able to do it on an individual basis, one dep at a time. 

Share this post


Link to post
Share on other sites

Here's another feature that I would love, related to this topic.

 

Currently if you change a service account's password, it'll show up green/OK if the account change worked on the AD-side. However, there are zero indicators that adjusting the password on the dependency-side failed, unless you actually open up the object's dep-list. It would be much, much appreciated if there was a way to indicate that deps had failed resets.

Share this post


Link to post
Share on other sites

Ahhh, another useful tidbit: it happens that a dependent service has been disabled. The password change will then report a failure for this particular dep, even if it isn't one: the service is not intended to be (re)started. Would be good if there's a check for that before/while restarting.

Share this post


Link to post
Share on other sites

Hi Buckit,

 

Thanks for your suggestions. For now, you could possible create yourself a scheduled report to let you know of any failures, and then you won't even have to go looking in Passwordstate for them.

 

Regards

Click Studios

Share this post


Link to post
Share on other sites

Hi Buckit,

 

I've made some changes to this Windows Service Reset Script today:

  • It will only try and stop the service if it's currently running
  • It will only try and restart the Service, if the Startup Type is set to one of the 'Auto' options

I've just emailed you a copy of this new script, and this version will be included in the next release - due later this week.

Regards

Click Studios

Share this post


Link to post
Share on other sites

Hi Buckit,

 

We've also made another small change to this script for the official release. Instead of only restarting the Service if the Startup Type is set to one of the 'Auto' options, we instead only restart the Service is if was started perform the reset occurred i.e. Auto or Manual Startup Type.

Regards

Click Studios

Share this post


Link to post
Share on other sites

Hey Buckit,

 

Just a quick message to say we've released a new build which includes a fix or the issue you identified in this forum post.  We've also added in another 30 or so changes and the full change of can be found here:  https://www.clickstudios.com.au/passwordstate-changelog.aspx

 

Thanks very much for your contributions, and have a nice weekend.  We hope you like the new build!

 

Regards,

Support.

Share this post


Link to post
Share on other sites
6 hours ago, support said:

We've also added in another 30 or so changes and the full change of can be found here:

I saw that, big update guys, nice work!

Time to update my instance at home!

Share this post


Link to post
Share on other sites

×
×
  • Create New...