Let's define the following scenario
Under these circumstances, the following scenario occurs
This may pose a security concern in the case of PAM, because even though in general once logged in into a certain windows system, it is good to use the SSO functionality to be able to access all applications as that user without having to reauthenticate, if the system is immediately reused a non-admin might be able to assume PAM administrative roles. So this requires some kind of action to deactivate this behaviour
The reason why this is occurring is because user logs onto their federation domain while logging into their VDI system. Once this login goes through successfully, ADFS saves the device as a known device.
Now when user tries to access any other application using any account of the same federation domain (in our case PAM), ADFS will check if the device from which the login attempt is happening , is saved in their sessions or not. If it is, it will go ahead and log the user to that account (irrespective of what user is providing as the username in the subsequent login attempts). This is how ADFS is configured in this case. Azure is not playing a role here, because Azure is federated to ADFS and it is ADFS who decides if the device logging in is a known device or not.
CA Privileged Access Management, several versions
By default, the authentication context in CA PAM for an IdP (Configuration --> SAML --> SP Configuration --> Configured Remote SAML IdP) is specified as
This means that the IdP will decide what authentication method it wants to use. In this particular case, since ADFS has kept tracking of the user logged in, it will use IWA and it will return a valid username as explained above, irrespective of what user we want to log in to PAM as.
If it is required that the username and password for logging in to PAM is specified, then the Authentication context for the IdP, in this case Azure must be configured not to look up if the device was already registered in a sessio or not. This may be achieved by changing the Authentication context to PasswordProtectedTransport
This will force PAM to request username and password (while authenticating in the IdP of course) while the rest of applications will continue to benefit from the regular SSO behaviour