The machine tunnel seems to be “available,” but we do not get all the functionality we expected.
I can tell it is set up because, diagnostics as the login screen shows Machine Tunnel if the user is not logged in.
However, a first time user to a new laptop with no cached credential cannot use the machine tunnel to log in. It seems to work after the user signs in via some other method and then logs out.
If a user loses their cached credentials (such as if the device is limited to one cached credential and another account gets cached replacing their cache) and their time-limited user tunnel authentication expires while the screen is locked, the user cannot unlock the screen and use the machine tunnel to log in. It appears to be stuck on the expired user tunnel and the user has no access to reauthenticate to the user tunnel or switch it to machine tunnel from the lock screen,
Are there solutions to those issues?
We have this use-case (First logon without cached credentials) working within our environment.
Only thing we found is if the laptop is newly imaged without internet access a 2x laptop restart is required to make Machine tunnel fully active for ‘first time logon’. We dont have “Machine Authentication Required” enabled but rather opted for the Machine tunnel Certificate posture check.
Have you tried the second restart yet ?
Highly recommend running ZCC 220.127.116.11 when using MT.
Is there documentation that lists all the steps to make it work at first login of a new user (including steps to restart the laptop more than once)?
Is there a link you can point to that details differences of requiring machine authentication vs certificate posture check? If not, can you describe pros and cons of each?
Help me understand your config then:
- So your ZCC installation using a ‘Policy Token’ which directs it Machine Token at the build stage?
- This allows the Machine tunnel to be enrolled and displays the ‘Diagnostic tab you mentioned’
- Is the laptop directly delivered to remote/home user then joined to home/remote wifi pre-windows logon ?
- Which version of ZCC are you using ?
- ‘Machine Authentication Required’ requires user Idp authentication before establishing connection.
Like you we are Hybrid joined and really wanted Posture checks for machine tunnel which has finally been released.
So just to clarify with your current config at first start-up you do see the Diagnostic tab ?
We are using 18.104.22.168.
At the login screen, ZScaler Diagnostics is available and shows Machine Tunnel available. It appears to be working because, if I enter an invalid user name, it says so instead of saying connection to the domain isn’t available.
The main issue is that it pre-Windows login using the machine tunnel does not seem to work for a new user until they have logged in once using another method such as AnyConnect Start Before Login or logging in from the office before taking the laptop home.
I don’t know how the machine tunnel is configured other than seeing the functionality available from the client side.
I need to be able to tell the people who configure the tunnel how we need them to set it up to make it work the way we need it to. (Allow users to be able to login using the machine tunnel and not rely on having cached credentials at either the login screen or the lock screen.)
The laptops are hybrid joined and used remotely.
My suggestion is to contact Zscaler Support as they resolved a similar issue for me.
As you know you have the ability to start a Packet capture which indicated that I was missing something in our ‘Domain Controller’ segment. Once I added the missing config everything worked as designed.
I do urge you to upgrade your ZCC version as it’s seriously outdated and I’d highly recommend ZCC 22.214.171.124.
I had a typo. We have 3.7.2, not 3.2.7.
Does updating the client also require making backend changes to support the newer client?
I see 4.0 is also available. Is 126.96.36.199 still the better choice?
Honestly, I haven’t tested ZCC 4.0 because it’s still LA.
For 3.9, no backend enhancement is required but like always I suggest testing it locally.
So far 188.8.131.52 meets all our stability & security requirements