Cisco ISE 3.2 REST ID store

[rdstoknes]

I have configured the REST ID store with Azure AD, and I am able to synchronize groups from our external directory to ISE.

My intention was to use this for AUTHZ of external accounts (guests in our Azure tenant) that authenticate for VPN access through our ASA using SAML IdP with Azure AD. The AUTH works fine, but when I enable the AUTHZ on the ASA querying our ISE server with the username the login fails. From the ROPC log I can see the following:

"error":{"code":"Request_ResourceNotFound","message":"Resource 'user@externaldomain.com' does not exist or one of its queried reference-property objects are not present."

This probably makes sense, since all guest accounts get a UPN of user_externaldomain.com#EXT#@yourdomain.com, but their primary email address is however stored in the guest account.

I have tried adding user attribute for mail in the REST ID store, but with no effect. I have also tried adding additional API permissions for the Azure App registration (such as email and groupmember.read.all) but the result is the same.

So the question is: Is there any way to lookup guest accounts through the REST ID integration with Azure, for example through referencing another property of the account besides the UPN, or maybe some kind of transformation rule to rewrite the UPN of external accounts?

Maybe it will come down to a feature request with the ISE team for this.

Brgds, Rune

[ahollifield]

https://community.cisco.com/t5/security-knowledge-base/cisco-ise-with-microsoft-active-directory-azure-ad-and-intune/ta-p/4763635

[rdstoknes]

Thanks for replying. I am familiar with the document, but I don't see how it answers my question. If I'd have to guess I would think you are implying that all REST ID lookups are done with the UPN.
Could you elaborate?

[Greg Gibbs]

AFAIK, the only identity ISE can use to perform the REST ID lookups is the UPN. The Groups and Attributes added in the REST ID Store configuration in ISE can only be used as matching conditions in the Authorization Policies.

[hslai]

@rdstoknes Try user.objectid as the Unique User Identifier in SAML SSO.

One customer told us that they were able to retrieve the groups of guest accounts after configuring it this way.

[rdstoknes]

@hslaithanks for the suggestion. Any suggestion on how to achieve this?

[rdstoknes]

@hslai, so this had to mature a while before I realized what you were suggesting. I originally thought that you were implying some change in the App ID registration for the ISE <-> ROPC connection, but of course you were suggesting that I should change the Unique User Identifier claim in the App ID registration for the ASA <-> SAML authentication towards Azure AD.

By using the user.localuserprincipalname for the Unique User Identifier claim I now get the user_externaldomain.com#EXT#@yourdomain.com returned from Azure as a claim, and this is passed to ISE for authorization. The problem is, by looking at the ROPC log it doesn't look like this is processed or passed correctly to the external REST ID store:
2023-10-08 13:14:25,879 INFO [http-nio-9601-exec-9][[]] cisco.ise.ropc.controllers.ClientCredController -::::- UPN: user_externaldomain.com , RestIdStoreName: null, Attrname: null

As you can see, the ...#EXT#@yourdomain.com part of the UPN is not present in the ROPC log, but it is in the ISE live log so it's definitely passed to ISE from the ASA. Since you mentioned a customer who had successfully achieved this I would be most eager to hear any details on how to make it work like they did.

Thanks for getting me a bit further on this, and hopefully you have some tips to get me all the way! #fingerscrossed

[hslai · Accepted solution]

Try user.objectid instead. Note that the ISE NA Live logs and detailed reports would likely show this as the Username or subject so that we need another means to find the associated the user for reporting, etc.

Additionally, we might need the app as both enterprise application (for SAML SSO) and regular app registration (for OpenID, OAuth2/ROPC).

[rdstoknes]

Hi @hslai, you are correct. I actually tried using user.objectid already, but the AUTHZ policy still failed for this. That is why I kept looking for another claim type to be returned that would represent the full "local" UPN (which is the xxx#EXT#@yourdomain.com) and this was the user.localuserprincipalname. Even though this would turn up in the logs with the expected UPN that could be matched against Azure AD, the AUTHZ policy would still fail.

I digged a little more into the REST ID store log in ISE, and noticed that by using the object ID (like you suggested) it would actually appear to have a match:
2023-10-09 08:38:16,860 INFO [http-nio-9601-exec-1][[]] cisco.ise.ropc.controllers.ClientCredController -::::- UPN: 730dxxxx-xxxx-xxxx-xxxx-3375bf08xxxx , RestIdStoreName: AzureAD, Attrname: ExternalGroups

Whereas mentioned in my previous post, using the claim type local UPN would have the log return RestIdStoreName: null.

I tried changing it into user.objectid once more, and also cleared out all other tweaks and changes I have tried for both the ASA tunnel-group and the ISE AUTHZ policy during my trials, and now it finally works.

Like you say, this implies obscuring the actual authorization event (having to match an ID with an actual user account in case of troubleshooting), but at least it will work for authorizing guest accounts by using group membership.

I will tag your response as the accepted solution, thank you for your contribution here!

/Rune