BeyondTrust Password Safe

[jdt-ab]

Hello,
We recently implemented BeyondTrust Password Safe but have had some buy-in resistance because most of our IT users use ASG-RD to manage their remote desktop sessions. One thing that makes this difficult out of the box is that to connect to a server, the server name has to be included in the username. For example, if I want to connect to SERVERA, I have to RDP to BEYONDTRUST with the username of DOMAIN\USER+DOMAIN\ACCOUNT+SERVERA, meaning I'd need a unique Credential for each server. 

I upgraded ASG to 2019 (from 2017) and was glad to see several password vault integrations, but BeyondTrust was not one of them. Is there any chance this could be included in a future release, or does anyone have any suggestions for a workaround? BeyondTrust does provide an API. I would more than happy to test any beta releases. 

Thanks!

[DevOma]

We will check that - which products of BeyondTrust do you use? Only PasswordSafe or also RemoteAccess Security or anything else? Just to know what we should do :-)

[jdt-ab]

We will check that - which products of BeyondTrust do you use? Only PasswordSafe or also RemoteAccess Security or anything else? Just to know what we should do :-)

Just Password Safe.

[assassindk]

Any ETA on a solution for BeyondTrust / Password Safe?

[DevOma]

Sorry, it's on hold - we never got a test environment that was running well - so we stopped it - we can try to reactivate...

[assassindk]

We are currently rolling out Password Safe and have been using ASG for a long time, so the internal IT staff are used to it and it would be great if we could continue with using ASG after the shift to Password Safe

[assassindk]

Anything new on this?

[DevOma]

Was planned for this week to get a test environment - but I have to ask again...

[DevOma]

We have a working test environment - and can read the data from Beyond Password Safe - but as we do not use it really it is not easy to see which data we need - I can see that getting passwords must be "Requested" for each system? And there are some categories like ManagedAccounts and FunctionalAccounts that I do not understand the difference - if you can tell me what do you expect to be synced it would help

You can answer here or send your suggestions to asg.rd@asg.com

Thanks

[jdt-ab]

We have a working test environment - and can read the data from Beyond Password Safe - but as we do not use it really it is not easy to see which data we need - I can see that getting passwords must be "Requested" for each system? And there are some categories like ManagedAccounts and FunctionalAccounts that I do not understand the difference - if you can tell me what do you expect to be synced it would help

You can answer here or send your suggestions to asg.rd@asg.com

Thanks

Functional Accounts are the service accounts that BeyondTrust uses to change the passwords for Managed Accounts. For ASG, Managed Accounts are the ones we'd be concerned with. They would match up to the Credentials in ASG. In BeyondTrust, I have a regular account (call it "USER") that I use to login to BeyondTrust, then I request access to a Managed Account (call it "MA-USER") that has admin access on the systems. I know the password to USER, but BeyondTrust is the only one that knows the password to MA-USER, and it changes the MA-USER password when I am finished with the account. While some orgs may require approval to use an account, we just auto-approve all requests. 

Within ASG, we'd want to have connections in our list where we could choose Connect as and choose the MA-USER account, then it would interact with BeyondTrust to get the appropriate password for the MA-USER account to connect to the connection.

[DevOma]

Ok thanks - we will try to implement

[DevOma]

Back at BeyondTrust implementation - and I'm thinking about how it would be the best to implement... Because the structure of Beyond PS

In Beyond PasswordSafe there are accounts for each system - sure we can read all accounts and remove duplicate ones - and then show it as Credentials - but if you connect using an account that is not assigned to a system it won't work (I guess) because BT PS needs a request tfor system/account combination to retrieve the password data - and perhaps not all users have access to all credentials?!? So don't know if that really is a good solution?!?

So another idea is - Choose your system (in ASGRD-Navigation) => Connect As => Beyond Credentials - popup is displayed (or the next sub menu is opened) and ASGRD reads all available accounts for that system? Of course the system names must match and you always have to choose an account to use - but that would be the way BeyondTrust is working as I understand... After account was chosen by the user we Request the creds and connect to the system with the retrieved credentials


Just tell me what you think :-) We don't want to implement something that nobody can use...

[jdt-ab]

Back at BeyondTrust implementation - and I'm thinking about how it would be the best to implement... Because the structure of Beyond PS

In Beyond PasswordSafe there are accounts for each system - sure we can read all accounts and remove duplicate ones - and then show it as Credentials - but if you connect using an account that is not assigned to a system it won't work (I guess) because BT PS needs a request tfor system/account combination to retrieve the password data - and perhaps not all users have access to all credentials?!? So don't know if that really is a good solution?!?

So another idea is - Choose your system (in ASGRD-Navigation) => Connect As => Beyond Credentials - popup is displayed (or the next sub menu is opened) and ASGRD reads all available accounts for that system? Of course the system names must match and you always have to choose an account to use - but that would be the way BeyondTrust is working as I understand... After account was chosen by the user we Request the creds and connect to the system with the retrieved credentials


Just tell me what you think :-) We don't want to implement something that nobody can use...

Thanks for looking into it, Oliver. You are correct that the managed user (Credential) has to be assigned to the managed system (Connection) for BeyondTrust to allow that account to login to that system. While other orgs may be different, for our implementation of BeyondTrust, it would not make sense to pull a list of managed accounts associated to managed systems. A managed system may have several managed accounts that could access it, and each managed account is generally assigned to a human user, so I wouldn't want our IT admins to be presented with a list of their coworkers' accounts. 

Rather than focusing on the systems, I think it would make more sense to focus first on the managed accounts. While I haven't seen how the other credential synchronisations work, based on the help article, this should be similar. The plug-in options would allow the user to specify an account to use to connect to BeyondTrust (what I called USER before), then ASGRD would authenticate to BeyondTrust with that account. The user would then configure a credential object by specifying the managed account they want to check-out from BeyondTrust, and ASGRD would request that account's password and store it.

It would be a nice addition to work similarly for the Connections, but this would be a secondary request for us. BeyondTrust allows you to proxy RDP connections through it so that the session is recorded. We have work-around for doing this today by using the variable name of the connection in the credential object, but it would be nice to be integrated. Again though, I'd rather have the credentials working first. Maybe someone else can chime-in if they have a different idea.

[DevOma]

ok thanks again for your feedback :-)