Problem with Password encryption logic when migrating from development PC to production robot

When migrating from a studio development PC to a robot the following error occurs…

Fidelity Signon ALPSFUNDS 1 has thrown an exception

Source: Get password

Message: Key not valid for use in specified state.

Exception Type: CryptographicException

System.Security.Cryptography.CryptographicException: Key not valid for use in specified state.

at UiPath.Core.Activities.ScopeActivity.OnFaulted(NativeActivityFaultContext faultContext, Exception propagatedException, ActivityInstance propagatedFrom)
at System.Activities.Runtime.FaultCallbackWrapper.Invoke(NativeActivityFaultContext faultContext, Exception propagatedException, ActivityInstance propagatedFrom)
at System.Activities.Runtime.FaultCallbackWrapper.FaultWorkItem.Execute(ActivityExecutor executor, BookmarkManager bookmarkManager

Is there something not loaded correctly on the robot?

From all the other Forum information I can find it sounds like Get Password only works on the development machine it was defined on. Since this is a standard design feature added by checking the box on a type into operation, why isn’t this portable.?

This is from my understanding

Get Password encrypts your password to a store only found on that machine and user profile. And, if you try to encrypt it on another machine the encryption code changes so it stops working on the other machine and user.

It’s really only useful to use for personal or testing use, not for a shared RPA network.

For that you would want to use Orchestrator Assets (with Get Credential activity) or another credential store that can be communicated within a network like CyberArk for example.

2 Likes

Thanks Clayton, I know your correct. From a product design point of view maybe UI path should add logic to assist in the use of other credential store as well as Get Password. Hence my confusion.

The division of the company I work for is still ramping up the use of UI path, and haven’t added Orchestrator to our suite, currently we are sharing it with another division who has yet to implement it but they hold the license. My team are still in a startup POC mode, but moving quickly to get automation in production, scheduling, servers, licensing, all are tied up in executive approval red tape, etc. We will at some point have unattended bots running on a bot server and use Orchestrator to facilitate that, I guess I’ll deal with the credentials issue at that point. I’ve found a workaround until then.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.