Pre-auth machine tunnel and Windows password expiry

Has anyone had experiences of password expiry on a users AD account when using the ZPA pre-auth machine tunnel? During testing we are finding that the user auth’s with the old expired password successfully, Windows then prompts for a password change, this fails to write the password back due to the machine tunnel dropping out during this prompt. The user is now effectively locked out as password has expired yet they cannot reset it.

Are you allowing a CACHED Credential Log in on the device in question ----- a pre-auth login — should be authed by the machine to AD – via cert and your ZPA instance — and allow for an interactive log in —

Thanks for getting back to me. We are indeed and the pre-auth part is working and a user can log in successfully (including a new user to the device) at which point it switches over to a user tunnel.

The issue is when a users password has expired, Windows won’t let them in until they have changed their password. While on the password change screen it appears the machine tunnel has dropped and as the user is not logged into the device properly yet the user tunnel has not started so no line of sight to the domain controllers to complete a password change.

So you need to ensure that the has access to a system in their ZPA that allows for access to AD to change passwords —

Are you allowing the use of cached credentials or are you interactive logins only

image001.jpg

If a machine or user tunnel is not up and running surely we have no access via ZPA? Or do we think that the machine tunnel is up but no rules available for ZPA to allow the connection back to the DC’s for password change?

Users can log into Windows with cached credentials however as the machine tunnel is up they will log in interactively.

If a machine or user tunnel is not up and running surely we have no access via ZPA? ---- The machine Tunnel to ZPA is based on these things —

A Machine or Client Cert — issued by your ZPA ROOT or 3rd party or internal CA for ZPA use ( 1 step of trust) ------ next – an app segment definition that details out How to connect to your AD — and the Ephemeral port range used by AD for a Password reset (2nd layer of trust AD can and will talk to APP connector same DC) ------- third a Server Group — containing the APP Segment to service the machines on the Tunnel ------- (3rd layer of trust) The APP & Server group is only accessible to the select group of user with the Machine Cert above the proper Authentication / Zscaler APP profile and Policy that will allow that user to leverage the tunnel

Or do we think that the machine tunnel is up but no rules available for ZPA to allow the connection back to the DC’s for password change? <----- this right here ----- if the User can hit CRTL-ALT-DEL — and see Zscaler Diagnostics as a choice ---- the Machine Tunnel is deployed ------- in Zscaler Client Connector Portal ----- go to APP Profiles ---- and Click on Machine Tunnels ------ You should see your Test devices here ----------

If you can deploy the tunnel ----- but not get connected all the way in and see the Machine in ZPA — there is a configuration issue with the deployment ----- please open a case with Zscaler ----

Users can log into Windows with cached credentials however as the machine tunnel is up they will log in interactively.<--------------- Correct

It has been a while however this has now been resolved. It was indeed firewall rules blocking access however it was caused because devices connecting in via ZPA were not getting the correct AD Site and therefore not talking to the domain controllers. New site created and all now working as expected.

1 Like

That makes sense — in our testing it was a separation of the DC in the production domain to the root level domain controllers — we had to give access to both sides