New Set Password feature on User form lay-out (San Diego)

Thanks Mark, we were also surprised by the change - a great explanation.

Issue with this is that you have to accept the generated password and have no option to overwrite it to one you choose, or have pre-agreed (from what I could see).

This is an issue for service accounts where a password has been pre-agreed between parties prior to the change window, especially where it is not easily changed in the other system, or where a password is changed by mistake and needs to be set back. I get the desire to improve password security, but a bit more flexibility is required.

Having to disable/customise an OOB client script doesn't seem an elegant workaround to the problem. Why not just hide the field normally and have the admin choose to expose it in the usual method if they need it, or allow the SN generated one to be overridden manually in the model box like most password managers do? I hope this is updated before launch.

Have a look at:

"glide.password.policy..generate.password.field.disabled
Disables the Password field on the set password pop-up on the sys_user form."

Kind regards,
Mark

Hi Mark,

Do you know if there is a way to control the complexity of the password being generated? Based on limited testing, it doesn't appear to follow our custom password policy.

Thanks,

Cyn

There is a UI page called "generate_copy_password" that handles this whole feature end-to-end. Within this page it calls a script include called "PasswordPolicyUtil" that is used to determine the password policy that is used. Out of the box it is configured to utilise the "Default" password policy. This script include is read only - so if you wanted it to use your custom Password Policy - perhaps you could alter the default policy to match your custom policy? 

Seems like a bit of an oversight to not allow people to edit this script include - or even to add an extension point

Thanks for the information.

I notice that while the new "Set Password" UI Action is visible on both sys_user and customer_contact, the  new"hide password field" script only runs on sys_user. This seem inconsistent, so I'm inclined to apply the script to the customer_contact table. Can you suggest any reasons we might need to leave customer_contact showing both the UI Action and the field?

This whole thing seems pretty half baked....

Being all-or-nothing (property based) doesn't make any sense at all. It's a platform feature that you can mix auth methods and this makes it more difficult for "No Code" admin types set passwords for system / service accounts. (There will be a TON of conversations in IT departments about how that's not supported anymore, so many places I've worked with would just stop there and never go looking at the docs for an esoteric system property, OR even if the ServiceNow teams do find it, asking for the "Customization" opens up a completely different can of worms...)

Also, why is it a client script running client side Glide Record? That's a bad precedent to be setting on a form that a lot of ServiceNow newbies will look to for examples of "how to do stuff in ServiceNow"

Editing the password from list view still works. 

Great article, @Mark Roethof , thank you!
Just some additional info if you get "password generation failed." error:
https://community.servicenow.com/community?id=community_article&sys_id=ed8faf3fdb3f8914457ae6be139619ff

As always, great job/work @Mark Roethof !

Just wanted to add, without making any of the changes, you can still set the password via list edit 🙂

I wish ServiceNow has the option to let the "Set Password" button invisible.

I believe that is available. As an admin user, navigate to sys_user.config, select the UI Actions tab, and mark the "Set Password" action as inactive.

If you do that, you may also want to restore the visibility of the password field on the form. For this, there are two options. It seems the preferred way would be to navigate to sys_properties.list, search for glide.user.show.password.field, and change the value to true. Alternatively, one could also disable the Client Script on sys_user called 'hide password field'.

Thanks so much for explaining this.

I was just able to use this on my developer instance and it's not quite as bad as I originally thought.  Very complex password is generated AND the 'Password needs reset' is also checked.  The second part begins to make this feature more useful because we generate enough (one is too many) password resets for our clients and now the new password and the Password needs reset are all done in one click.   Each user's password is unique and the user can change it to something more familiar on the first login.    This will be a time saver for us.

Mark, please don't take the following as criticism on your article, it was very informative. Thank you for the time you put in to dive into this feature and figure out all of the details. My comments below are more about the time ServiceNow spent on it rather than other things that people have been asking for.

I may be wrong but, how useful is this really, don't most companies use SSO?

If so, they don't want users changing the ServiceNow password and then needing to remember it, and wouldn't it get overridden when the next AD update comes through?

I would appreciate any correction to my thinking.

Thanks!

"don't most companies use SSO"

Still see companies without 🙂 Though hope most have something similar indeed.
And what about accounts to which SSO does not apply?

Do agree, that you can question how useful the feature is, and perhaps if that effort could have been spent on something else.

Kind regards,
Mark

I do not understand why there are two Properties to be set for this.

In my opinion, setting glide.user.show.password.field should be sufficient.

(Also calling a property ...disabled is very bad UX).

Hi,

How about setting password via script? From time to time we need to create new accounts for 5 to 20 users in SNOW. We've been using script for this, but after upgrade to San Diego script cannot set initial password for them. Below seems to stop working properly:

user.user_password.setDisplayValue('examplePassword')

 Should I set glide.user.show.password.field to true? Will that be enough or should I also change something in other properties?