Cisco ISE 3.2 Multi-Domain Join Issues/Questions/Bug?

Jkloz · ‎02-22-2024

Cisco community:

Looking for a bit of assistance / advice here, not sure if I'm running into an ISE Bug, or something isn't working as I'm expecting it to. We are currently in beginning phases of a domain migration at our organization, and we authenticate endpoints via computer certificates issued by a CA, and users by x.509 certificates on a smartcard.

We currently have our ISE cluster joined to both domains (one root domain that we own, and one sub/child-domain that we have local DC's, and domain administration rights on, via 2 separate AD Join Points). Both domains have the same alternative UPN suffix configured that matches x.509 certs on a smartcard for user authentication. The issue we're seeing is that ISE never looks at the 2nd join point, once a match is made on the UPN in the first domain. A small snippet of the AD_Agent.log is below:

----------------------------------------------------------------------------------------------------------------

2024-02-21 15:10:30,015 VERBOSE,140249397192448,IdentityRewriteHandler::rewriteIdentity() - For domain rewrite rules are disable,rewriteIdentity(),lsass/server/auth-providers/ad-open-provider/config-manager/identity_rewrite_handler.cpp:371
2024-02-21 15:10:30,015 DEBUG ,140249397192448,IdentityRewriteHandler::freeMemory,freeMemory(),lsass/server/auth-providers/ad-open-provider/config-manager/identity_rewrite_handler.cpp:612
2024-02-21 15:10:30,015 DEBUG ,140249397192448,IdentityRewriteHandler::freeMemory free REG_MULTI_SZ,freeMemory(),lsass/server/auth-providers/ad-open-provider/config-manager/identity_rewrite_handler.cpp:623
2024-02-21 15:10:30,015 VERBOSE,140249397192448,AdIdentityNamePreprocessor::build: input name 123456789.AD@ZZZ, joinPoint AAA.BBB.YYY@ZZZ.com,build(),lsass/server/auth-providers/ad-open-provider/ad_identity_name_preprocessor.cpp:258
2024-02-21 15:10:30,015 VERBOSE,140249397192448,AdIdentityNamePreprocessor::isUPN: detected UPN 123456789.AD@ZZZ,isUPN(),lsass/server/auth-providers/ad-open-provider/ad_identity_name_preprocessor.cpp:153
2024-02-21 15:10:30,015 DEBUG ,140249397192448,AdIdentityNamePreprocessor::build: handle lookup by UPN,build(),lsass/server/auth-providers/ad-open-provider/ad_identity_name_preprocessor.cpp:312
2024-02-21 15:10:30,015 DEBUG ,140249397192448,AdForestDiscoverer::getForestByDnsSuffix: ZZZ suffix does not match any domain,getForestByDnsSuffix(),lsass/server/auth-providers/ad-open-provider/ad_discoverer.cpp:199
2024-02-21 15:10:30,015 DEBUG ,140249397192448,AdForestDiscoverer::getForestByAltUpnSuffix: ZZZ suffix match alternative UPN suffix in ZZZ.YYY@AAA.com forest,getForestByAltUpnSuffix(),lsass/server/auth-providers/ad-open-provider/ad_discoverer.cpp:225
2024-02-21 15:10:30,015 DEBUG ,140249397192448,AdIdentityNamePreprocessor::build: Forest ZZZ.YYY@AAA.com , JP: AAA.BBB.YYY@ZZZ.com,build(),lsass/server/auth-providers/ad-open-provider/ad_identity_name_preprocessor.cpp:331
2024-02-21 15:10:30,015 DEBUG ,140249397192448,AdIdentityNamePreprocessor::build: matched valid forest ZZZ.YYY@AAA.com from UPN suffix,build(),lsass/server/auth-providers/ad-open-provider/ad_identity_name_preprocessor.cpp:338
2024-02-21 15:10:30,015 DEBUG ,140249397192448,AdIdentityName:: set key to UPN|MAIL,AdExplicitUpnName(),lsass/server/auth-providers/ad-open-provider/ad_identity_name.cpp:96
2024-02-21 15:10:30,015 VERBOSE,140249397192448,AdIdentityNamePreprocessor::checkUniqueness: identity name 123456789.ADM@ZZZ is expected to be unique,checkUniqueness(),lsass/server/auth-providers/ad-open-provider/ad_identity_name_preprocessor.cpp:124
2024-02-21 15:10:30,015 VERBOSE,140249397192448,AdIdentityResolver::prepareSearches: identity 123456789.ADM@ZZZ, JP AAA.BBB.YYY@ZZZ.com , markup true, knownDomain true, isAllowedJoinedDomainOnly false ,prepareSearches(),lsass/server/auth-providers/ad-open-provider/ad_identity_resolver_impl.cpp:538
2024-02-21 15:10:30,015 DEBUG ,140249397192448,AdIdentityResolver::prepareSearches: GC search required,prepareSearches(),lsass/server/auth-providers/ad-open-provider/ad_identity_resolver_impl.cpp:572
2024-02-21 15:10:30,015 VERBOSE,140249397192448,AdIdentityResolver::examineDomains: AAA.BBB.YYY@ZZZ.com,examineDomains(),lsass/server/auth-providers/ad-open-provider/ad_iden[Ktity_resolver_impl.cpp:601
2024-02-21 15:10:30,015 VERBOSE,140249397192448,AdIdentityResolver::examineDomains: AAA.BBB.YYY@ZZZ.com,examineDomains(),lsass/server/auth-providers/ad-open-provider/ad_identity_resolver_impl.cpp:601
2024-02-21 15:10:30,015 VERBOSE,140249397192448,AdAuthenDomains::isAllowed: trusted domain AAA.BBB.YYY@ZZZ.com is NOT in authentication domains list,isAllowed(),lsass/server/auth-providers/ad-open-provider/ad_authen_domains.cpp:184
2024-02-21 15:10:30,015 DEBUG ,140249397192448,AdIdentityResolver::examineDomain(): joined domain is not configured as authentication domain and ignoreAuthDomains is not set. skipping search identity,examineDomains(),lsass/server/auth-providers/ad-open-provider/ad_identity_resolver_impl.cpp:651
2024-02-21 15:10:30,015 VERBOSE,140249397192448,AdIdentityResolver::examineDomains: ZZZ.YYY@AAA.com,examineDomains(),lsass/server/auth-providers/ad-open-provider/ad_identity_resolver_impl.cpp:601

----------------------------------------------------------------------------------------------------------------

Identities/domain names have been changed, but essentially a handle lookup is performed by our ISE node, looks up identity UPN, no domain matches are found, then proceeds to try to match on alternative UPN suffix, which is found in our primary domain, where the account we are trying to authenticate does not reside. ISE never checks the 2nd AD Join point for the alt UPN/user account.

I also ran into this bug: https://bst.cisco.com/quickview/bug/CSCwe94876/ regarding AD cache of alternative UPN suffixes not updating, and didn't know if this is something we may be running into. That said, I've tried disjoining these nodes from the 2nd domain, rejoined them, and the problem still persists.

Any insight is appreciated!

Arne Bier · ‎02-22-2024

On each Join Point, you have the option of allowing certain domains (see the "Allowed Domains" tab), in the case where there is two-way trust between domains. Have a look there to see if you can perhaps exclude the domains in a Join Point that you don't want to search on?

Do you have an Identity Source Sequence that contains both Join Points, and if so, perhaps you have some luck with this setting at the bottom of the Identity Source Sequence page:

Jkloz · ‎02-22-2024

Thanks for the quick reply. We've got each join point only configured with the respective domain/subdomain, and we also have the "Treat as if the user was not found and proceed to the next store in the sequence" selected on both join points. The AD_Agent.log above was from the test of the 2nd join point/user lookup from the tests you can run directly from ISE. So, I don't know why ISE is even looking at the other join point from an alternative UPN suffix perspective. Tomorrow we are going to try to remove the trust relationship between domains and see if that makes a difference in the way ISE processes the lookups for the join points. We are trying to figure out whether or not this is an ISE issue or a Domain issue.

Keep in mind the same alternative UPN suffix is configured on both domains/join points as we have x509 certs/smartcards that we need to authenticate on each domain for the time being, in both domains, until we collapse the legacy domain/DC's. It looks like from an Active Directory perspective, there's potentially an issue with having duplicate UPN's in forests with a trust relationship, and the trust may block requests from Domain A to Domain B through a collision detection process.

https://community.spiceworks.com/topic/1428755-can-domains-that-have-a-forest-trust-have-the-same-upn-configured-on-them/