ISE flow with Hybrid Azure AD

atsukane · ‎03-01-2022

Hi,

So I've been trying ISE BYOD flow with Azure AD.

https://community.cisco.com/t5/security-documents/ise-byod-flow-using-azure-ad/ta-p/4400675

ISE policy described in the above link works and I get Azure AD logon box, but after entering credentials I'm redirected to our ADFS.

This is due to us being Hybrid environment and have ADFS server as the federation server.

For guest WLAN DHCP scope, I'm using internal DNS server to resolve ISE for guest portal (private IP), and google DNS as secondary DNS.

This seems to be affecting AAD and ADFS connection as AAD should be hitting the public IP of the ADFS but our internal DNS is resolving it to a private IP and end up failing.

Using Google Public DNS would mean unable to resolve the ISE IP for portal.

I've looked at iana link below to see if there's a convenient DHCP option available but this is not the case

https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml

Any suggestion/ideas how I could get around this?

Thanks,

thomas · ‎03-06-2022

The title says Guest flow but the first sentence says BYOD flow.

This all sounds way over complicated for basic Guest Access.

I don't know why you are redirecting your AzureAD-authenticated users to ADFS.

I don't know what your goal is with any of this.

atsukane · ‎03-07-2022

@thomas

Reason for using AAD redirection is that currently our guest WLAN requires frequent reauthentication and when I enquired about how to get longer duration the AAD auth was suggested:

https://community.cisco.com/t5/network-access-control/cwa-for-guest-access-ad-auth-with-minimum-re-atuthentication/td-p/4505556

I was planning on using AAD redirection for employees with AD credential, and they'll access new WLAN for employees.

Employees' devices have Microsoft Authenticator app installed for MFA, and they'll mainly use mobile devices for MS Teams.

And if the above work then I was going to change the existing guest WLAN to self-registering for external guests.

(Currently our help desk guys generate random IDs on sponsored portal to provide temp ID and password for external guests. )

This is how I inherited this environment and am just trying to improve user experience.

###edited###

Updated the title.

Also to answer your question "I don't know why you are redirecting your AzureAD-authenticated users to ADFS."

It's not me redirecting AAD auth to ADFS. According to Microsoft support guys in my work, Hybrid Azure AD join requires a federation services, which is why AAD is talking to the onprem ADFS and apparently this is an expected behaviour.

thomas · ‎03-08-2022

You allude to 3-4 different access control scenarios above. Whenever talking about access control, it is important to be clear on the end-to-end components of each individual scenarios because how each one is handled can be very different. Talking about them all at the same time causes confusion as I you saw from my response.

1) BYOD: you mention ISE BYOD Flow Using Azure AD which is fine. I don't know what the issue or question is here.

2) Employees WLAN : this is typically separate from a BYOD WLAN. Employees WLAN is for trusted users with managed corporate endpoints while the BYOD implies an non-corporate endpoint (personal device) that has more risk that you want to potentially handle differently. I don't know what the specific question or issue is here.

3) Guest access :

Sponsored Guest: this is your current setup with your help desk sponsoring guests with random usernames & passwords.
Your actual problem is not ISE at all but your private, internal DNS server not being able to resolve public addresses and ISE private IP addresses for the guest portal. I suggest you ask the owner of your internal DNS box(es) why they cannot resolve public DNS addresses and fix that DNS server.
Self-Registered Guest : this is your goal for guests your goal is to use sponsored access by your help desk. Good - that will save your help desk team time in the future.

hslai · ‎03-09-2022

From what you wrote, it seems a DNS issue. I would suggest using DNS views in the internal DNS server(s) so the query results are based on the source IP subnets. Else, use another set of DNS servers for these user subnets.