Cisco ISE + Active Directory = Network accounts are unavailable

[stevenjklein]

We're rolling out Cisco ISE to all our Ethernet ports.

On any port where ISE has been turned on, Macs display this at the login screen: Network accounts are unavailable

For users with existing mobile accounts on those Macs, this isn't a problem because they can log in even without network access. Once they are logged in (and the CCAAgent posturing client does its thing), they have full network & internet access.

But anyone without a locally cached account simply can't log in.

This makes me think the Macs are unable to reach our Active Directory Domain Controllers.

(As a temporary workaround, we've kept an ISE-free Ethernet port at the help desk; we have users log in once using that port, so that their accounts get cached. But this isn't a good long-term solution.)

Our Cisco guy (a Mac user, but not a Mac expert) says everything is open internally and they should be able to reach the DCs. I thought maybe Macs are "phoning home" to Apple as a check for network access, but he said access to any host at apple.com domain is enabled by default.

Any ideas on how to fix this?

[philburk]

How is ISE access being controlled? By a user cert? By manual auth? Some other method like kerberos or MAC address? My experience with ISE is that the precondition for access usually requires a user be logged into the device first, such as a user cert kept in the user's keychain. That wouldn't be accessible until after the user logs in...

[stevenjklein]

Manual authentication. Even before 802.1x authentication, access to the ISE server itself and the DCs is supposed to work. (After all, if it didn't, there'd be no way to authenticate.)

Windows machines don't have this issue. I can walk up to any WinPC on our network, and log on with my network account.

But I can only do that on a Mac if I already have an account on that Mac.

[stevenjklein]

Okay, we've done more testing, and this is what we've learned…

Before a Mac gets to the login screen, it tries to connect to IP addresses at apple.com and akamai.com.

Our default access list (pre-ISE authentication) was only allowing access to internal network addresses. We first tested by allowing access to Apple's /8 network and Akamai's /8 network, and we didn't get the Network accounts are unavailable error.

Then we tried allowing only Apple, and the error came back. So we tried blocking Apple, and allowing Akamai, and didn't get the error. (Although there was another anomaly -- see below.)

Conclusion: If a Mac can't reach Akami, it shows Network accounts are unavailable.

Testing configuration: I used a MacBook Pro for testing. I started by booting to recovery, then erasing the main partition with Disk Utility, and then reinstalling macOS 10.12.6 from recovery. After that, I started up from the main partition, created a new account, and declined every option like Use location services, Use Siri, and Share Mac Analytics. . Then I joined it to our domain, and set the login window to Name and password.

There was absolutely no third-party software on this Mac. In other words, it was macOS itself that was trying to connect to Akamai.

Now, a further word about what happened when we blocked access to Apple's /8 network. When I tried to log in with a (non-cached) network account, I got as far as the screen that says Sign In with Your Apple ID. But the main part of that window was empty -- no radio buttons to Sign in… or Don't sign in." And the Back and Continue buttons were both grayed-out. And curiously, this is when the Mac popped up the 802.11x login window. I didn't authenticate -- I just waited, and after a delay of perhaps 30 seconds, the Sign in with… window populated with its normal content, and I was able to click Don't sign in and then Continue*.

I wish the startup process was less opaque. Why is this Mac trying to connect to Akamai? And why does it refuse to let me talk to my domain server if Akamai is blocked?

The only thing that comes to mind is that it's checking for internet access, using (perahps) the same process it uses to check for captive wifi portals. Maybe it's trying to connect to http://captive.apple.com/hotspot-detect.html, and maybe that's hosted by Akamai.