User profile download issue

[skozlovs]

I'm working with a customer that has both machine (WIn10) and user authentication enabled via EAP-TLS. Machine auth works fine and existing users also fine. However, when a new user is trying to login to the machine it's unable to load profiles/certificates from AD and denied network access.

At what stage a new user profile download happens? Is it in machine login state or in user state?

If in user state, how’s the user certificate loaded into machine if AD is not available (low impact mode) until user is authenticated?

Is this the case where certain ports should be opened on switch's ACL to allows client communication to AD or there is another way around?

Regards,

Stan

[Craig Hyps]

See example dACL here for AD login access: How To: Transitioning ISE From Monitor Mode  (search for "445")

This could be applied as a default ACL as discussed in this doc, but I typically apply this type of dACL after successful Windows machine auth.  It will then allow the access needed to establish secure communication to domain controller for GPOs and user login to occur prior to actual user login.

[paul]

Craig,

I don't think the default ACL or DACL works at least in my experience.  The problem I have seen is if the Windows OS is told to do Computer or User EAP-TLS and a new user logs in the supplicant tries to transition to user cert.  The process breaks leaving the device in MAB hitting the bottom rule which typically give limited access to the network.  You wouldn't want to allow AD access in the limited access condition typically.

This has been a problem for years on wireless when doing first user login.  Clients usually told their users that they had to do first user login on wired where they weren't running ISE.  Now with ISE in both places it is a challenge.

I have solved this issue before with NAM and setting up multiple profiles.  The main profile will do Computer and User not EAP chaining though.  The second profile does just Computer.

Is there a decent way around this using Windows supplicant?

I am doing a large install now where we are doing EAP-TLS Computer or User certs so I am going to do extensive testing on this, but for now my plan is to use NAM because it has worked for me in the past.

[Craig Hyps]

To allow needed communication to AD, then you have couple choices--either provide as default (also requirement for Easy Connect), or it is applied as a result of Machine auth.  Otherwise PC will not have DC access and some policies/profiles cannot be downloaded. 

[paul]

We have full access to the network as part of Machine Auth. The problem is the Windows supplicant does a failed Dot1x authentication when it tries to transition to user mode but no certificate is present. If the Windows supplicant would be able to delay the transition to ensure certificate is autoenrolled then this would work, but I haven’t found a way to do this. As soon as user logs in supplicant tries to transition, no cert, dot1x fails, user stuck in unknown device MAB rule which you aren’t typically going to allow AD access. The Windows supplicant isn’t smart enough to fall back to Computer auth when no user cert is present. It simply says “You told me to transition to user mode authentication, I can’t, best of luck to you”.

Has that not been your experience?

[Craig Hyps]

My response is specific to the original question on AD communications.  In the case you are describing, it is not an AD access issue, but supplicant behavior which ISE cannot resolve other than possibly redirect user to a help page.

[paul]

If you reread the original post, the question was really around the exact issue I am describing. Supplicant configured as Computer or User EAP-TLS and new user login is having issues. I was just clarifying that I don’t think DACLs or Port ACLs are going to solve the problem as the supplicant is going to fail Dot1x and they will end up in default MAB condition.

[Parag Mahajan]

I am following this communication. I have same requirement for one of my customer. Yes, I am also trying to find workaround. Even if its not ISE issue as such but its process/onboarding issue. I agree with @Paul that we do not want to give domain access for All MAB endpoints. One of the possible solution can be

1. If you profile those domain joined machine and place it in particular identity group. Then you  give domain access to that identity group so that at least non domain MAB endpoint will be denied.

I am also researching if below supplicant will help in this scenario.

[paul]

We have tried the single sign on settings with no luck. If you get them to work please let me know.

You can use the profiled as domain computer or MAR as a means to give these devices more access when they fail to MAB. MAR and AD profiling both have their caveats of course.

Sent from my iPhone

[Parag Mahajan]

Thanks for quick reply. I am interested to know caveats you are referring for AD Profiling.

I was planning to profile domain joined machine using DHCP user class ID. Do you see any issue into it.

[paul]

That should work. The AD profiler using if hostname exists in AD calls into question on the DNS scavenging setup and DHCP lease time to ensure accurate FQDN values in reverse lookup

Sent from my iPhone

[Craig Hyps]

Access to AD prior to successful auth is obviously a policy decision in the end a balance between security and availability.

AD probe does not require DNS for reverse lookup.  It is simply one option for triggering AD probe.  The machine name used for AD Probe can be acquired via:

• 802.1X Machine Auth
• DHCP Option 12 (Hostname)
• DNS - reverse lookup of learned IP

There are multiple methods to help discern if host is trusted.  One of them, of course, is machine auth, but others include profiling, posture, prior registration to ISE/MDM/DM, or implicit via AD user auth (active or passive).

Craig

[skozlovs]

Thanks to all for the help.

Here is a Cisco article that explains sequence of the events and it looks very accurate and applicable to both Win 7 and Win 10, thought the article is bit old.

https://www.cisco.com/en/US/docs/solutions/Enterprise/Campus/IBD/1XbaseCG.pdf

According to the article user GPO load happening after the 802.1X user authentication, so it's catch 22...

From the discussion above and our tests there are seems to be few workarounds e.g. open AD ports/IPs in ACL-Default or try to profile AD joined machines and authZ them to allow GPO loads. But none of them a clear cut.... BTW, we've tested profiling via AD probes and in our case it's unreliable, so we ruled it out.

This use case seems to be very popular, so I'm curious how it's resolved for the other customers...

[paul]

For me if the customer is looking to do EAP-TLS Computer or User it forces me into AnyConnect NAM because I can do multiple network definitions.  So you can setup a progression like this in your wired profiles:

1. EAP-TLS User
2. EAP-TLS Computer
3. No Auth

So if the system is in the user space and the user cert is there #1 is priority.  If the system is in computer space or in user space but first time user login and cert isn't there then #2 works.

I don't really like adding NAM to my installs, but when doing EAP-TLS User/Computer it gives me the most options.