While doing a PoC of the Unified Access Gateway we discovered that it does not allow a user with a expired password to login and fails with "Access denied". We've tested this with the Horizon Client for Mac, Windows and iOS and the experience is the same. Logging in using a Dell P25 zero client or with a Horizon Client that points directly to the connection server correctly prompt the user that the password is expired and allows them to enter the old and new password to update it. We have an open support case but keep getting conflicting answers on whether this should or shouldn't work with the UAG. We do happen to have a RADIUS server configured for MFA and I suspect this is why it doesn't work. Can anyone let us know whether this should or shouldn't work?
I have a case open on this and they mentioned that they are working with you on it. I wanted to post here for the benefit of anyone else that may encounter this.
We've confirmed that the UAG supports updating a users password when it has expired if you only use pass-through authentication. The problem appears to be that our UAG are configured for radius-auth which is denying the login because the password is expired. It seems like we need to have the UAG first do pass-through authentication to validate the users account is valid/update the password if necessary and then push to the RADIUS server for MFA.
When the environment is configured for RADIUS or SecurID 2FA, that authentication must succeed before there is any subsequent interaction with AD. It's true for Connection Server and UAG. The 2FA is mandatory.
With RADIUS, the user enters username and RADIUS passcode. UAG or Connection Server (depending on where RADIUS auth is configured) sends a RADIUS Access-Request. If it gets a RADIUS Access-Reject response from the RADIUS server it is not permitted to proceed and puts up an Access Denied error. The only allowed responses for it to proceed are an Access-Accept, or an Access-Challenge.
The first thing to do is check the logs on the RADIUS server to determine what the response was. Also check the RADIUS server to determine how it handles expired passwords. You may require support from teh RADIUS server vendor to configure this correctly.
Some vendors use the RADIUS passcode in the Access-Request as an AD or LDAP password. Some will allow an authentication attempt using an expired password knowing that the user has been authenticated and to allow the user past that for subsequent password change, e.g. through the subsequent password workflow when AD can be contacted.
UAG is normally deployed in a DMZ where often there is no contact with AD. If the RADIUS server rejects the authentication request for any reason, access is denied. That's correct behaviour and the same behaviour with Connection Server.
Thanks markbenson, we are doing the later where we enter the AD username and password and the RADIUS server handles the workflow to do a device push for MFA. If that times out then the user is prompted to enter a passcode that is generated from the app installed on their device. I have the team that manages the RADIUS server looking at our options to respond with a Access-Accept instead of Access-Reject when the AD password is expired.
One of the early engineers on the case suggested shifting RADIUS from the UAG to the connection server. The thought was that if the UAG is configured to only do pass-through authentication it would offload that to the connection server and then the connection server would enforce RADIUS. It sounds like we would have the same issue doing that as well?
BenFB - yes. That's correct. Wherever 2FA auth happens (UAG or Horizon Connection Server), the RADIUS server (or RSA SecurID server) has the authority to stop the 2FA auth flow by simply sending an Access-Reject (access denied) response. Many RADIUS servers that use a password (LDAP/AD) as the passcode deal with authentication exceptions for exactly this situation.
Verify that this is what is happening here from RADIUS server logs.
They pulled the logs from the RADIUS server and confirmed that it's responding with Access-Reject after identifying the user has invalid credentials. They are looking into options to instead respond with an Access-Accept so the UAG/Connection Server can handle updating the users expired password.
We've actually been able to inadvertently prove that this works. We have a test account where they are setting the password to expire. If I immediately try to login after they set the password to expired we can get the RADIUS server to respond with a Access-Accept since it's not aware the password is expired yet. Then we are correctly prompted that the password is expired and needs to be updated.
we are seeing the same problem now but the Radius is handled on Connection Server level and not on UAG. The radius provider is OKTA. I'm pretty sure it used to work prior to UAG 2111 version though