How to Brand OOB Password Reset and Password Enrollment UI Pages

debmcdaniel · ‎01-09-2017

We are about to deploy ServiceNow Password Reset and Password Change for Active Directory.

Is there a way to brand the UI pages associated with these applications? As they are today OOB, there is no corporate logo or any other identifying details - just a link to a "generic" web page.

To a self-service user, the password enrollment page and password reset page might appear as phishing pages (with no corporate branding). I know as an end-user I certainly would not be inclined to enroll or reset my password from what appears to be a very non-descriptive "generic" web page.

I've read where others in the community asked questions about branding using an iFrame since the pages are locked down. Unfortunately there were no answers provided. If someone knows how to brand using Bootstrap, I'm open to this idea as well.

Any suggestions/tips/hints/tricks?

Thanks in advance,

Deb

Carl Murray · ‎02-10-2017

Deb,

We had the same question, so we went to the HI portal and asked as well. After several back an forth items, here is how we accomplished it:

Under UI Pages, you will want to copy the information and code from inside the $pwd_reset pages. Then start a new page and paste it in. Do not do an Insert and Stay with $pwd_reset, as it copies the Protection Policy as well.

Then in the HTML code, there is this line:

Right after this line, we inserted the following code: (this is using our branding practices)

<tr>

</td>

<td width="50%"><font face="Segoe UI" size="5" color="#FFFFFF"><b>Password Manager</b></font>

</td>

</td>

</tr>

</table>

Within the code, it also changes from $pwd_reset to $pwd_verify, then to $pwd_new.

When we created each of our new pages, we had to go back into the client script area and update the code so it would go to the newer form. Example:

function PwdAjaxIdentityParse(response) {

//Let's handle security

handleSecurityFrom(response);

var answer = response.responseXML.documentElement.getAttribute("answer");

if (answer == "ok") {

wasSubmitted = false;

submitWithOK('$pwd_verify.do'); ---> change to $pwd_verify_custom.do instead

}

else if (answer == "block") {

wasSubmitted = false;

submitWithBlock('$pwd_error.do',answer);

Then you will also want to update the Client Script URL Suffix onChange so it can update you password processes:

function onChange(control, oldValue, newValue, isLoading, isTemplate) {

// Update the public url if the url suffix changes:

if (newValue == 'default') {

g_form.setValue('public_url', '/$pwd_reset_custom.do');

} else {

g_form.setValue('public_url', '/$pwd_reset_custom.do?sysparm_url=' + newValue);

}

This will allow the branding to be done throughout the pages. It is tedious, but ends up working in the end.

Thanks,

Carl

View solution in original post

debmcdaniel · ‎02-13-2017

Hi Carl,

We seem to have it all working. I think we may have to do through and create a custom page for each of the $pwd_ pages -- uggghhh!

One last question - how do I update the Public URL that shows in the Process definition? As you can see, my public url still points to the OOB $pwd_reset page.

Carl Murray · ‎02-13-2017

Deb,

Near the bottom of my answer, there is a piece that will help with this change: (You will need to search for the client script that is referenced. â˜º )

Then you will also want to update the Client Script URL Suffix onChange so it can update your password processes:

function onChange(control, oldValue, newValue, isLoading, isTemplate) {

// Update the public url if the url suffix changes:

if (newValue == 'default') {

g_form.setValue('public_url', '/$pwd_reset_custom.do');

} else {

g_form.setValue('public_url', '/$pwd_reset_custom.do?sysparm_url=' + newValue);

}

Once you change the above code, you should be able to go into your Password process and make a small change then save it, and the code will update the page automatically.

Here is what ours ended up looking like:

Thanks,

CARL MURRAY

Enterprise Support Operations and Systems Analyst

debmcdaniel · ‎02-13-2017

Perfect! I totally missed that one I was so excited to be able to get this to work! Will test and if we have any more issues, will advise.

debmcdaniel · ‎02-13-2017

Quick question - are you using SSO?

We are and I think in order for this to work, I actually have to make the $pwd_reset_custom pages public (System Definition > Public Pages). This will keep ServiceNow/SSO from requiring the user to be logged in order to access the $pwd_reset_custom pages.

Carl Murray · ‎02-13-2017

Yes, we are using SSO. We are using Okta.

CARL MURRAY

Enterprise Support Operations and Systems Analyst