Complex BYOD guest access with Entra ID Security Groups - Not working

[bailey-hawker]

Hello ISEberg,

My team is currently working with a customer to deploy a complex BYOD wireless guest access SSID at 100 sites using Entra ID as the IDP. The network technology in use is Meraki MR access points using Cisco ISE on the backend for authentication.

We have followed the legendary guide from Greg Gibbs and have successfully setup a basic BYOD guest access SSID that uses Entra ID for authenticating and self-registering the users device into a MAB list - no issues with this implementation. Works perfectly for a single Site A. (https://community.cisco.com/t5/security-knowledge-base/ise-byod-flow-using-entra-id/ta-p/4400675)

The trouble we are having is implementing security controls to prevent User A from being able to log into Site B if they are not apart of the Site B Entra Security Group. This is a security requirement from our customer that must be met. The user once authenticated also should not be prompted for re-login for 30 days so the endpoint mac must be persistent in the endpoint group for 30 days.

Entra ID is returning the users security group GUIDs in the SAML response to ISE after a successful authentication but ISE does not store the security groups against the endpoint, making it impossible to build policy that is based on the users group membership. After the user registers an endpoint via the first portal redirect AuthZ flow, the security group attribute is gone and when the device comes back around to authenticate the second time (once the MAC is stored in the endpoint list), we can't find a way to check the users security groups.

[Greg Gibbs]

The 'remember me' flow is based purely on MAB and the check against the defined Endpoint Identity Group, so there is no way to perform a check against Entra ID in that flow.

The EIG is assigned by the Guest Type, which is associated with the Guest Portal, so I can't think of a way to do it other than creating a unique EIG, Guest Type, Guest Portal, and Authorization Profile per site and using the network device location as a condition to dictate which Guest Portal they are directed to.

It might be an okay solution for two sites, but would not scale well for a large number of sites.

This would be a better use case for 802.1x, but that gets very tricky (and problematic) with non-managed devices.

[bailey-hawker]

Thanks for the prompt response Greg.

Yes, we have considered building 100 portals, 100 EIG etc. In theory, is there any reason why this approach would not function? We understand that this is not a scalable approach however it would largely be a set and forget build. Is it possible to have 100 enterprise apps in Entra ID that can be uniquely used by the 100 portal redirects? 

We have engaged TAC and are currently working with them for more information and potentials workarounds. It is quite surprising to discover how inflexible the Entra ID integration is. The SAML groups are being returned to ISE so there is the potential for capturing this information in the logs via the API and custom embedding it against the endpoint as a custom attribute. This is not a path we'd like to go down but if it's the only way it's possible then we will need to investigate. We are using ISE for two other SSIDs (1x and MAB) so swapping out the product at this point is not feasible.

[Greg Gibbs]

The SAML integration uses the MS Graph API, which has it's own caveats and limitations.

There are no published scale numbers for the Portals, Guest Types, or EIGs so you might need to pose that question to TAC. I would think it would be possible in theory and you could look at using APIs or IaC tools to automate the repeated config.

ISE will not let you create more than one SAML connection with the same Entra ID tenant, however, so you would have to use one enterprise app with all the relevant Entity IDs.

[bailey-hawker]

Thanks, how would the security groups be able to be checked if all incoming auths hit the same Enterprise App? We can't see how any security group membership logic could be implemented as the there would be 100 security groups associated with the Enterprise app, and as long as User A was in any of the groups, access would be granted which would remove the security control.

[ahollifield]

MDM >>> BYOD. You exact scenario is why BYOD is a NIGHTMARE.