cancel
Showing results for 
Search instead for 
Did you mean: 

Custom Variable containing password[1] or password[2] depending situation

Mario
Occasional Contributor

Custom Variable containing password[1] or password[2] depending situation

I am trying to make a custom variable in the Server Catalog of an LDAP Authentication Server that contains password[1] or [2].
Why? because I have multiple types of User Realms to enter in our system. It can be using Vasco Digipass or Google Authenticator.
Problem is that when using Google Authenticator, the final password that needs to be filled in the Role Windows Terminal Services for single signon == but when using the Vasco Digipass Realm, the final password that needs to be filled in the Role Windows Terminal Services for single signon==... As these Roles are identical except for Username and password definition. I was hoping to solve this with custom variables depending on the authentication servers they use. Problem is that the Server Catalog does not seem to contain the password variable...
Maybe there is another better way but i don't know it...
Anyone?
8 REPLIES 8
Mario
Occasional Contributor

Re: Custom Variable containing password[1] or password[2] depending situation

Seems like i have an issue with '' again.
It should read :

...
Problem is that when using Google Authenticator, the final password that needs to be filled in the Role Windows Terminal Services for single signon == '' but when using the Vasco Digipass Realm, the final password that needs to be filled in the Role Windows Terminal Services for single signon== ''.
Mario
Occasional Contributor

Re: Custom Variable containing password[1] or password[2] depending situation

Grrr
...
Problem is that when using Google Authenticator, the final password that needs to be filled in the Role Windows Terminal Services for single signon == \ but when using the Vasco Digipass Realm, the final password that needs to be filled in the Role Windows Terminal Services for single signon== \.
Mario
Occasional Contributor

Re: Custom Variable containing password[1] or password[2] depending situation

Grrr
...
Problem is that when using Google Authenticator, the final password that needs to be filled in the Role Windows Terminal Services for single signon == / but when using the Vasco Digipass Realm, the final password that needs to be filled in the Role Windows Terminal Services for single signon== /.
Mario
Occasional Contributor

Re: Custom Variable containing password[1] or password[2] depending situation

Grrr
...
[code]Problem is that when using Google Authenticator, the final password that needs to be filled in the Role Windows Terminal Services for single signon == but when using the Vasco Digipass Realm, the final password that needs to be filled in the Role Windows Terminal Services for single signon== .[/code]
Mario
Occasional Contributor

Re: Custom Variable containing password[1] or password[2] depending situation

I give up trying to escape the code variables used.

...
Problem is that when using Google Authenticator, the final password that needs to be filled in the Role Windows Terminal Services for single signon == password but when using the Vasco Digipass Realm, the final password that needs to be filled in the Role Windows Terminal Services for single signon== password2.
zanyterp
Moderator

Re: Custom Variable containing password[1] or password[2] depending situation

Yes, the server catalog does not have access to the password variable
Is it possible to adjust the realms so that the primary password is identical?
If not, the best solution will be to have either two roles, one for each auth type, or have two bookmarks for each resource and label it to indicate which auth server it goes with
Mario
Occasional Contributor

Re: Custom Variable containing password[1] or password[2] depending situation

Thanks for the information allthough it is not what I hoped for. Any reasons why password is not available?
It would be handy to avoid nearly identical redundant roles.
zanyterp
Moderator

Re: Custom Variable containing password[1] or password[2] depending situation

I am not sure on the technical reasons for it or if it was not something that was considered as it is already available for use in SSO policies.