Cannot authenticate using enterprise principal

[Oleg Baranov]

Hi Community,

Cannot authenticate using user's secondary email as an alternative name 
(need to setup an email server with several virtual domains).

According to https://bugzilla.redhat.com/show_bug.cgi?id=1328552 this is 
expected to work but seems I'm missing something.

Created a fresh VM just to deal with the issue:

[root@mgsauth02 ol]# cat /etc/fedora-release
Fedora release 37 (Thirty Seven)

[root@mgsauth02 ol]# ipa --version
VERSION: 4.10.1, API_VERSION: 2.251

all packages updated.

Repeating commands from the testscript 
https://bugzilla.redhat.com/show_bug.cgi?id=1328552#c13

[root@mgsauth02 ol]# ipa user-add tuser --first test --last user --password
Password:
Enter Password again to verify:
------------------
Added user "tuser"
------------------
   User login: tuser
   First name: test
   Last name: user
   Full name: test user
   Display name: test user
   Initials: tu
   Home directory: /home/tuser
   GECOS: test user
   Login shell: /bin/sh
   Principal name: [e-mail]
   Principal alias: [e-mail]
   User password expiration: 20221224134753Z
   Email address: [e-mail]
   UID: 1563000004
   GID: 1563000004
   Password: True
   Member of groups: ipausers
   Kerberos keys available: True

[root@mgsauth02 ol]# kinit admin
Password for [e-mail]:
[root@mgsauth02 ol]# ipa user-add-principal tuser talias talias\@ent.test
---------------------------------
Added new aliases to user "tuser"
---------------------------------
   User login: tuser
   Principal alias: [e-mail], [e-mail]@TESTRELM.CO, 
[e-mail]

[root@mgsauth02 ol]# kinit talias
Password for [e-mail]:
Password expired.  You must change it now.
Enter new password:
Enter it again:
[root@mgsauth02 ol]# klist
Ticket cache: KCM:0:60382
Default principal: [e-mail]

Valid starting       Expires              Service principal
12/24/2022 13:51:02  12/25/2022 13:10:41 krbtgt/[e-mail]

[root@mgsauth02 ol]# kinit -C talias
Password for [e-mail]:
[root@mgsauth02 ol]# klist
Ticket cache: KCM:0:52413
Default principal: [e-mail]

Valid starting       Expires              Service principal
12/24/2022 13:52:32  12/25/2022 13:18:25 krbtgt/[e-mail]

=== So far OK. But when trying alias in email-form:

[root@mgsauth02 ol]# kinit talias\@ent.test
kinit: Client '[e-mail]@TESTRELM.CO' not found in Kerberos 
database while getting initial credentials

[root@mgsauth02 ol]# kinit -E talias\@ent.test
kinit: Client '[e-mail]@TESTRELM.CO' not found in Kerberos 
database while getting initial credentials

And the following appears in /var/log/krb5kdc.log:

Dec 24 13:54:32 mgsauth02.infra.smartshell.gg krb5kdc[1119](info): 
AS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), 
aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), 
aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17), 
camellia128-cts-cmac(25)}) 10.255.0.252: CLIENT_NOT_FOUND: 
[e-mail]@TESTRELM.CO for krbtgt/[e-mail], Client 
not found in Kerberos database
Dec 24 13:54:32 mgsauth02.infra.smartshell.gg krb5kdc[1119](info): 
closing down fd 11

Tried adding "|krb5_use_enterprise_principal = True|" to sssd.conf as 
mentioned in 
https://www.freeipa.org/page/V4/Support_of_UPN_for_trusted_domains but 
without any change .

Any advice, please?

[Alexander Bokovoy]

On la, 24 joulu 2022, Oleg Baranov via FreeIPA-users wrote:
> Hi Community,
>
> Cannot authenticate using user's secondary email as an alternative 
> name (need to setup an email server with several virtual domains).
>
> According to https://bugzilla.redhat.com/show_bug.cgi?id=1328552 this 
> is expected to work but seems I'm missing something.

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 ([e-mail]) instead
of [e-mail]@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 [e-mail]
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=[e-mail])(krbPrincipalName:caseIgnoreIA5Match:=[e-mail])))" 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: [e-mail]@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. [e-mail].

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
[e-mail] 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.
> Created a fresh VM just to deal with the issue:
>
> [root@mgsauth02 ol]# cat /etc/fedora-release
> Fedora release 37 (Thirty Seven)
>
> [root@mgsauth02 ol]# ipa --version
> VERSION: 4.10.1, API_VERSION: 2.251
>
> all packages updated.
>
> Repeating commands from the testscript 
> https://bugzilla.redhat.com/show_bug.cgi?id=1328552#c13
>
> [root@mgsauth02 ol]# ipa user-add tuser --first test --last user --password
> Password:
> Enter Password again to verify:
> Added user "tuser"
>
> User login: tuser
>   First name: test
>   Last name: user
>   Full name: test user
>   Display name: test user
>   Initials: tu
>   Home directory: /home/tuser
>   GECOS: test user
>   Login shell: /bin/sh
>   Principal name: [e-mail]
>   Principal alias: [e-mail]
>   User password expiration: 20221224134753Z
>   Email address: [e-mail]
>   UID: 1563000004
>   GID: 1563000004
>   Password: True
>   Member of groups: ipausers
>   Kerberos keys available: True
>
> [root@mgsauth02 ol]# kinit admin
> Password for [e-mail]:
> [root@mgsauth02 ol]# ipa user-add-principal tuser talias talias\@ent.test
> Added new aliases to user "tuser"
>
> User login: tuser
>   Principal alias: [e-mail], [e-mail]@TESTRELM.CO, 
> [e-mail]
>
> [root@mgsauth02 ol]# kinit talias
> Password for [e-mail]:
> Password expired.  You must change it now.
> Enter new password:
> Enter it again:
> [root@mgsauth02 ol]# klist
> Ticket cache: KCM:0:60382
> Default principal: [e-mail]
>
> Valid starting       Expires              Service principal
> 12/24/2022 13:51:02  12/25/2022 13:10:41 krbtgt/[e-mail]
>
> [root@mgsauth02 ol]# kinit -C talias
> Password for [e-mail]:
> [root@mgsauth02 ol]# klist
> Ticket cache: KCM:0:52413
> Default principal: [e-mail]
>
> Valid starting       Expires              Service principal
> 12/24/2022 13:52:32  12/25/2022 13:18:25 krbtgt/[e-mail]
>
> === So far OK. But when trying alias in email-form:
>
> [root@mgsauth02 ol]# kinit talias\@ent.test
> kinit: Client '[e-mail]@TESTRELM.CO' not found in Kerberos 
> database while getting initial credentials
>
> [root@mgsauth02 ol]# kinit -E talias\@ent.test
> kinit: Client '[e-mail]@TESTRELM.CO' not found in Kerberos 
> database while getting initial credentials
>
> And the following appears in /var/log/krb5kdc.log:
>
> Dec 24 13:54:32 mgsauth02.infra.smartshell.gg krb5kdc[1119](info): 
> AS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), 
> aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), 
> aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17), 
> camellia128-cts-cmac(25)}) 10.255.0.252: CLIENT_NOT_FOUND: 
> [e-mail]@TESTRELM.CO for krbtgt/[e-mail], 
> Client not found in Kerberos database
> Dec 24 13:54:32 mgsauth02.infra.smartshell.gg krb5kdc[1119](info): 
> closing down fd 11
>
> Tried adding "|krb5_use_enterprise_principal = True|" to sssd.conf as 
> mentioned in 
> https://www.freeipa.org/page/V4/Support_of_UPN_for_trusted_domains but 
> without any change .
>
> Any advice, please?