7.4/W10 - Smartcard Auth SSO - asks for pin twice (client & desktop)

[alsmk2]

I'm having trouble with smartcard authentication on a newly deployed W10 image. A user is prompted for a PIN when inserting the card by the View client, but when they try to open a desktop, the credentials don't appear to be passed through and the user is presented with a windows logon screen where they can either enter their username/ pass, or re-enter their SC pin.

The setup is identical to a previous W7 deployment that has been working for several years without issue. From a windows perspective, the same services are enabled on both images, and they both use the same middleware and version (Gemalto.NET). I can't see any differences between the images at all - would anyone have ideas on what I could try?

Thinclient - 10zig (latest firmware - 6.x)

W10 1703

View 7.4

All certs valid / root certs imported to the gold image

UEM is also installed with the registry "Compatibility fix for VMware Horizon smartcard redirection" enabled as per the following KB:

VMware Knowledge Base 

Thanks in advance!

[alsmk2]

This looks to be a UEM issue - without the agent installed in the desktop, both the W7 & W10 images SSO functionality works.

Testing agents shows the following:

9.2 - SSO fails on the desktop.

9.3 - As above.

9.4 - As above.

The production gold image uses agent 9.1; however, this causes a different intermittent issue with IE/ Windows Explorer crashing. The issue is intermittent (one in ten logons), but enough that it is also not an option.

Is there anyway in UEM to ensure the agent does not interfere with USB or the middleware (Gemalto IDgo 800)? There are no UEM Smart Policies in place, but I've added the "UemFlags" dword for good measure. From a UEM perspective there are zero errors in the logs, and this is the same from Windows too - no eventlog errors, or errors in any of the view agent logs.

[DEMdev]

Hi alsmk2,

Does the issue also occur if no DirectFlex, application blocking, and privilege elevation settings are configured?

[alsmk2]

Thanks for the response!

Of those three, there is only DirectFlex in use - the config is as basic as can be (couple of mapped drives / one printer / couple of reg settings). Previous tests using GPO settings to disable DirectFlex entirely made no difference at all.

I haven't tested this with the 9.4 agent. Would you suggest disabling it via GP, or manually turning it off on all the profiles?

[DEMdev]

Hi alsmk2,

If the problem also occurs without any DirectFlex-enabled config files (and without any application blocking or privilege elevation settings), you're most probably running into an issue with the Horizon agent. If you want to double-check that by disabling DirectFlex, you can indeed do so by configuring that through Group Policy, or maybe temporarily disable/modify the DirectFlex-enabled config files (depending on how many you have)?

I don't know enough about Horizon to ask any relevant questions, but I'll try to find out...

[alsmk2]

It looks like you were spot on with DirectFlex - manually disabling it across all profiles seems to work. I'm not sure why this didn't work when disabling it via GP previously though.

I'm assuming that this is something to do with the hook driver at this point then? Would you have any ideas on the next steps? The middleware in use doesn't have any application / executables associated with it to add to the blacklist. It's literally a minidriver and CP driver.

[DEMdev]

Hi alsmk2,

Given that your "Disable DirectFlex" GPO didn't do the trick last time, can you double-check that the Compatibility fix for VMware Horizon smartcard redirection policy setting did indeed make it to your endpoints?

The DirectFlexHookLoadLibrary REG_DWORD at HKCU\Software\Policies\Immidio\Flex Profiles should be set to 0.

[alsmk2]

Just double-checked this and it is indeed set to 0.

[DEMdev]

Hi alsmk2,

Could you please try the following on an affected system?

• Run regedit as an admin, and create a REG_DWORD registry value DebugLogging under HKLM\Software\Immidio\Flex Profiles, set to 263 decimal (107 hex).
• As the logged-on user, launch DebugView, and make sure that Capture | Capture Win32 is checked.
• Launch a simple test executable (notepad, for instance).
• Post the DebugView log.
• Optionally, remove that DebugLogging registry value (and the registry key leading up to it).

UPDATED 2018-06-07 – I just spoke with a colleague who actually knows about Horizon, USB, smart cards, and redirection thereof (I only know about UEM :-), and he asked me pass on the following questions and suggestion:

• Are you using USB redirection to redirect your smart cards, or smart card redirection?
• Just to make sure: these are Linux- or Windows-based thin clients, not zero clients, right?
• Assuming you previously set uemFlags to 1, can you try setting it to 257 decimal (101 hex)?