Hi Ronny,
we probably cannot implement SSO in the way suggested because of the following reasons:
- the implementation of our management modules differs depending on the provided APIs we can use. Many of them does not support Windows principals, especially not with multiple hops (client -> server -> destination host)
- we aim to have our solutions work in the same way on all platforms (windows, macOS and mobile)
What we can think of though is the following approach:
- we introduce a new type of credential called “SSO Credential” which actually does not contain a password (or even does not contain a username, if this credential is shared in a team)
- when royal ts/x tries to connect a connection that is referencing a SSO credential for the first time, it asks the user for username and/or pwd and caches this for the lifetime of the application.
What do you think?
Cheers,
Michael
Hi,
to be honest, this is not my needet usecase, because...
we have strictly restricted Clients, the user is an autologonuser, no one can change anything in the front of this computer. On every reboot all configs will be reloadet and exist local files will be overwritten.
Ronny Schuerer
SSO Single Sign On from RoyalTs to RTS-Server, needs for seperate authenticatin in a bigger AD environment.
Thus, an account-dependent assignment of the configs is possible, a user account / password combination is not feasible because the passwords are constantly changing.
1 person likes this idea