Cisco ISE, AnyConnect NAM and Windows Hello (pincode)

[Torb3n]

Hi,

Anyone who has managed to get the Cisco AnyConnect NAM module to work together with Windows Hello?

We are using Cisco ISE 2.4 and AnyConnect 4.6/4.7 NAM for EAP Chaining.

It seems like the Windows Hello (pincode) will not trigger the NAM module for authentication/EAP.

[darossman]

Hello Guys,

Any updates on this case? 

[Mike.Cifelli]

I have not seen this issue.  AFAIK Windows hello pin is significant to the local machine? What is your NAM configuration? Do you have single sign-on enabled? Can you explain the workflow so the community can better assist? Has this been tested with AnyConnect + modules running 4.9.x? If so, is there any difference in test outcome?

[JoCalvini]

To answer the question, yes Hello factors (Pin or a gesture) are local to the machine. The OS uses TPM encrypted keys to protect gestures (face, fingerprint, etc.). The OS uses validated tickets or session tokens to access applications.

Hello workflow is more or less like this:

-Client OS kerberos provider signs Kerb preauthentication data with Hello key

-Client OS Kerberos provider sends a kerb request to a Domain controller (DC),

-DC validates preauthenticated data

-If valid, DC returns a TGT (Ticket-Granting ticket)

-Client OS validates Kerb distribution center certificate (that it's valid from a trusted domain)

-The OS passes the TGT to the Local Security Authority (lsass)

-LSA informs winlogon of succesful auth and uses is in.

This is more or less according to: https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication

When authenticating against Azure AD instead of a local DC, the workflow is similar except that Azure handles a session token instead of a TGT.

In both cases, Lsass caches the  TGT/Session token for future use. Other applications that use Hello basically read the LSA for granted tickets/tokens.

The question is then if the Cisco AnyConnect client can read the cached information in lsass and use it.

[j0e1]

Did anyone manage to get this working?

[ecanogut]

There is an enhancement request to support Windows Hello for Enterprise and NAM with SSO: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvk24320

[PeterLMSD]

I am having the same issue as well. I think this will require both Client and ISE changes to implement.

Running a hybrid device joined environment with Key rather than Certificate based trust and there is the "Special" Azure AD self signed certificate that gets generated after the desktop completes AAD + WHFB enrollment. So I would that user certificate would be the one we use to authenticate to ISE. The issue is that special certificate is a self signed one and wondering how the trust relationship would work as the certificate in the store contains "login.windows.net" or would we need to issue a new certificate signed by an internal CA to the device for this to work which we are doing anyway but am concerned if that User certificate expires and handling the two different use cases.

Current configuration:
Client side in NAM a Wired & Wireless using EAP-FAST and EAP-MSCHAPv2 using the Username & Password to auth
ISE User and Machine auth using EAP-FAST and EAP-MSCHAPv2 pointing to AD 

Future Configuration:
Client side Profile 1 in NAM a Wired & Wireless using EAP-FAST and EAP-MSCHAPv2 using the Username & Password to auth
Client side Profile 2 Option A in NAM a Wired & Wireless using EAP-TLS pulling Windows Hello for Business self signed certificate that contains the subject "login.windows.net" from the "Microsoft Passport Key Storage Provider" 
Client side Profile 2 Option B in NAM a Wired & Wireless using EAP-TLS pulling Windows Hello for Business corporate issued certificate from the "Microsoft Passport Key Storage Provider" where the issuer subject contains the correct string.

ISE Profile 1 - User and Machine auth using EAP-FAST and EAP-MSCHAPv2 pointing to AD 
ISE Profile 2 Option A - User and Machine auth using EAP-TLS trusting the self signed "login.windows.net" pointing to either onprem AD or Azure AD to validate that the certificate is really legitimate and associated to the user. Which I don't know how this could be done
ISE Profile 2 Option B - User and Machine auth using EAP-TLS trusting the internal CA issued certificate.. either just trusting the cert is fine or most likely needing to query a CRL or OCSP to make sure the internally issued certificate hasn't been revoked.

That is how I think it will need to work, but right now I can't see any way that this will work with the current NAM and ISE environment.

Or am I missing something?

[PeterLMSD]

I think I have found a semi work-around to this, it's not pretty or seamless but "it works".

Required components:

• Hybrid joined devices that have successfully enrolled in WHFB with PIN via Azure AD MFA Login and optionally Face or Fingerprint enrolled.
• Internal MS CA issuing Machine Certificates to all devices using standard Machine Certificate Template
• Internal MS CA issuing User Certificates with Certificate Template configured to "Microsoft Passport Key Storage Provider" ideally using PowerShell so you can monitor it's progress and make sure it works. We used this script as a basis: https://www.powershellgallery.com/packages/Generate-CertificateRequest/1.0/Content/Generate-CertificateRequest.ps1 and https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-deployment-rdp-certs (to make sure the Certificate Template is using the Passport CSP) and https://github.com/imabdk/Powershell/blob/master/Detect-WindowsHelloEnrollment.ps1 (to make sure you have enrolled in WHFB) 
• Look into if you want to enable Non-Destructive PIN reset Pin Reset | Microsoft Learn as if you do a "Forgotten PIN" then the WHFB container is removed, including the User Certificate you are using to authenticate to the network. 

1. Setup a new AnyConnect NAM Profile with Machine and User Authentication using EAP-TLS.
   1. Machine needs a MS CA Machine Certificate Template
   2. User needs a Certificate issued to the Passport CSP with the above WHFB Certificate Template

Then the NAM Profile needs for Machine set to EAP-TLS:

And optionally add Certificate Matching on the Machine Identity as required to lock it to the internal MS Issuing CA.

For User Auth also select EAP-TLS

And the important settings is on the User Auth Credentials page, you need to Prompt for Credentials, Remember forever, Select Smart Card certificates only, Remember Smart Card Pin Forever (This is probably the most important setting), and then for Certificate Matching match to the Issuer CN or any other way to reliably match to either the Subject CN or Issuer CN values.

Once this is set when AnyConnect attempts to Authenticate to the Wired or Wireless network you are prompted only once for the Smart Card Pin, which is the "Windows Hello PIN"

Is what you entered for the Windows Hello PIN:

So once you have trained your users they need to remember and enter the Windows Hello PIN at this prompt they should be ok.