credential manager - Expires question

[ChrisRider]

I am using Blue Prism 6.2.1.  I have recently started using Credential Manager to manager credentials for the projects I'm working on.  One of my credentials has its password expire every 90 days.   I notice there is an option in Credential Details screen called "Expires" (selectable by a check box, and you define a calendar date.) . Maybe a stupid question - but what does this actually do?  Not sure if I overlooked documentation on this topic? I ticked the box for today's date as an experiment.  I did not notice any differences in behavior with Blue Prism.  Is there a way to have it alert our IT department that the password is expiring?  It would be best if we can change the password before it expires so we do not have lose of functionality.  

[John__Carter]

Setting an expiry date is optional, and if the date has passed, the credential will become inaccessible to the process.

[ryanamiller]

We set up an automation that runs every day and loops through the credentials that check if there are any that are expired, near expiration, or have no expiration set.  It then sends an email to our Bot Controlling team to action on.

[ChrisRider]

Thanks for the feedback.  I am checking with our IT team to see if they are using other tools to manage expiring accounts.  If not, I could see the need for creating an automation like Ryan describes.

[SajitValloli]

Hi Ryan,

Could you please provide more information about this automation? i would like to implement the same in my work as well. Please help.

Thanks,
Sajit

------------------------------
Sajit Valloli
------------------------------

[david.l.morris]

If you do end up making an automation to handle credentials, there are a couple things I want to suggest. I've made several versions of Password Management processes, and there is some interesting behavior in BP.

1. As John said, the credential becomes inaccessible to the processes if a credential expires. I typically do not use the Expires feature in credentials for that reason because the processes can no longer retrieve the old password.
2. in the Credentials internal business object, there's an action called 'List' which will list out all the credentials in Credential Manager. The interesting thing here is that it outputs the Description of the Credential as well. This means that you could effectively add your own fields. I currently have extra fields in the Credentials like {ChangePassword=True} to let the automation know whether or not that credential should have a password changed by the Login Agent VBO etc. Anyway, if the Expires feature doesn't work quite how you want, you could always create your own field in the Description like {Expires:2/25/2020} or formatted however you like and then have the automation extract that date at runtime to determine if IT or Support or whoever should be notified.
3. The Additional Properties seem like they have so much potential as an alternative to #2 above, but the problem is that the value is always masked like ****, so it's hard to determine what is currently in the value when viewing the credential.
4. You may have already done this, but consider determining a naming convention for Credentials so that your automation can assume each credential's purpose or whatever based on the naming convention of it. As an example, consider the 'Windows login: machineName' convention that Blue Prism already uses for login credentials. We use a convention like "ROBOT:Username" which we use for various purposes.
5. This may not be exactly related, but I figured I'd suggest anyway. Consider never hardcoding a Credential Name in processes because this limits your ability to rename all Credentials according to naming conventions. I find it best to have Environment Variables that represent the names of the Credentials. This way it can be managed and changed separate from Process logic/code changes. Keep in mind that Environment Variables access may be granted to people who do not also have access to Credentials. So there's that as far as security is concerned.

I'll stop there so I don't write a novel today. 😃
​

------------------------------
Dave Morris
3Ci @ Southern Company
Atlanta, GA
------------------------------

[jessiebrooks]

Have you worked with a Password Management tool like LastPass before? Are there any tips on syncing passwords in an external password manager and the credential manager in BluePrism?

Thanks

------------------------------
Jessie Brooks
------------------------------

[david.l.morris]

We currently use CyberArk as a secondary storage location for passwords so that authorized support personnel can go view the passwords if they need to do something manually as a Virtual User.

What I found is that it really depends on the Secrets Manager. I haven't used LastPass. I'm assuming it has an API. Honestly, there's a hundred ways syncing passwords can be handled, but what it comes down to for me is how reliable you think the Secrets Manager is as well as how reliable the team is who supports that app. In our case, we decided to rely primarily on Blue Prism's ability to change passwords and then to only use CyberArk as a secondary password repository.

So, I think you'd have to decide whether you intend for that secrets manager to change the passwords for you or just sync your Credential Manager's credentials with that external tool. This is the way I prefer it as it reduces the likelihood of RPA being entirely halted because the external system isn't functioning or the API Endpoint is down or something like that.

As far as tips for syncing, I'd say to be sure you use a work queue with status updates and that your password management process is capable of continuing from where it left off. This way, Blue Prism can change passwords and update Credential Manager but is not dependent on the sync happening immediately. But typically I'd see it happening like (1) Blue Prism changes the password for a User, (2) BP updates any associated credentials in Credential Manager, (3) BP attempts to push the new password(s) to the external secrets manager with retries around that just in case, and then as I always do (4) a final report table at the end for support personnel to review to ensure that all the credentials were managed properly.

------------------------------
Dave Morris
3Ci @ Southern Company
Atlanta, GA
------------------------------

[HakanEngman]

Dave, as you are already using CyberArk, did you ever consider or test the other way around, having CyberArk as primary vault and BP Vault as fallback? 
Combined with a process the repetedly fetch the password from CyberArk and write it to BP Vault. 

In normal conditions, credentials are fetched from CyberArk and the in the quite rare situation where CyberArk is unavailable to BP, then hopefully the password is alredy in BP.. 

Br,
Håkan

------------------------------
Hakan Engman
Automation engineer
Teliacompany.com
Europe/Stockholm
------------------------------

[david.l.morris]

I haven't done this primarily because I trust Blue Prism more than I trust CyberArk. I've never seen Blue Prism Credential Manager not work, whereas I have seen CyberArk be down. I think retrieving credentials from CyberArk primarily and at runtime is a fine model and would likely work well. As far as storing it also into Blue Prism, I think that is a good backup, however there's a further aspect to this that would affect such a design. If an organization wanted to ensure that no one could ever retrieve passwords from the Blue Prism Production environment at all, the only real way to accomplish this is by storing the passwords in CyberArk. Don't misunderstand. Blue Prism Credential Manager is secure, but it is not intended to keep passwords from people who have admin or other high level access to the environment.

For us, the only reason we use CyberArk at all is that Credential Manager does not have a 'Show Password' feature because we do want authorized users to be able to retrieve the passwords sometimes, such as when a profile on a VM needs to be logged into manually in order to troubleshoot an issue. With CyberArk, someone who is authorized to can log into CyberArk and use either the RDP feature in CyberArk or retrieve the password and then manually RDP into the machine. (Yes we use RDP to remote into machines. It works fine if you log out at the end of using it. It does not work for the middle of a session run).

If you're considering using CyberArk for the primary credential storage/retrieval, that tells me you have a very different reason for using it than I do. But as far as functionality, yeah the way you describe it should work well.


------------------------------
Dave Morris
3Ci @ Southern Company
Atlanta, GA
------------------------------