[Freeipa-users] Re: Cannot authenticate using enterprise principal

On la, 24 joulu 2022, Oleg Baranov via FreeIPA-users wrote: We only support use of out-of-realm UPNs for out of realm users, e.g. users from trusted Active Directory forests. For in-realm users only the aliases from the same realm are supported. We had a bug https://bugzilla.redhat.com/show_bug.cgi?id=1915820 for this which was closed due to lack of priority. My comment 3 on that bug details what work needs to be done to implement the support: ------------- As for the alias lookup not working, this is in dbget_princ() in the first condition -- if we are asked for in-realm canonicalization, we unparse without outer realm and reparse without escaping @ and /, then ipadb_fetch_principals uses this principal (raduser(a)some.domain) instead of raduser@some.domain(a)IPA1.TEST. The logic here is the same as in upstream's KDB driver but we store principal alias fqdn with our realm. AD stores these aliases without own realm but it has a list of UPN suffixes to allow. We can add a code to dbget_alias() to have a list of own UPN suffixes that can be added to aliases and then don't add our realm to them when storing in LDAP it would require changes in both dbget_alias and to IPA framework. # ipa user-add-principal foobar raduser(a)some.domain ipa: ERROR: The realm for the principal does not match the realm for this IPA server and if 'some.domain' would be a registered UPN suffix for our realm, then we would allow it. This, however, would only work for a canonicalised request as we don't have realm aliasing support yet. ------------- Since you have added the alias by escaping inner '@', it was added with our own realm but gets searched without it and cannot match. I did the same on my F37 instance and it generates the following LDAP query recorded in the LDAP server logs: [25/Dec/2022:10:18:09.400934339 +0100] conn=6 op=238611 SRCH base="dc=example,dc=test" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=abbra@fedoraproject.org)(krbPrincipalName:caseIgnoreIA5Match:=abbra@fedoraproject.org)))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge uid nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink ipaIdpConfigLi..." [25/Dec/2022:10:18:09.401476598 +0100] conn=6 op=238611 RESULT err=0 tag=101 nentries=0 wtime=0.000345739 optime=0.000548334 etime=0.000891630 Since the entry actually contains the full principal krbprincipalname: abbra\@fedoraproject.org(a)EXAMPLE.TEST it does not match in the search. Until we fix it by adding a support to allow registered UPN suffixes for our realm, the only way to get around it is to use direct ldapmodify with a principal without outer realm, e.g. abbra(a)fedoraproject.org. We have so-called 'realm domains' support which we use to advertise as UPN namespaces to trusted Active Directory domain controllers, so theoretically we could simply add to 'ipa user-add-principal' a check of the suffixes against or 'realm domains'. If you are not using trust to AD, this would allow to add aliases for the primary realm and any of 'realm domains'. If you are using trust to AD, however, this would be a bit limiting because 'realm domains' get advertised over trust to AD and then that means they cannot contain any of the domains / UPN suffixes advertised by the trusted AD forests. The latter might become a problem to those who are using ipa.example.test for IPA and example.test for AD but want to add aliases user(a)example.test to IPA users. Obviously, this cannot be done on Kerberos level (no two realms that trust each other should claim ownership of a principal within a trusted realm). So there are unsolved issues like this that prevent a straight-forward addition of the out-of-IPA realm aliases. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland