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 (raduser@some.domain) instead
of raduser@some.dom...@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@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=ab...@fedoraproject.org)(krbPrincipalName:caseIgnoreIA5Match:=ab...@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....@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. ab...@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
u...@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.
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: tu...@testrelm.co
Principal alias: tu...@testrelm.co
User password expiration: 20221224134753Z
Email address: tu...@testrelm.co
UID: 1563000004
GID: 1563000004
Password: True
Member of groups: ipausers
Kerberos keys available: True
[root@mgsauth02 ol]# kinit admin
Password for ad...@testrelm.co:
[root@mgsauth02 ol]# ipa user-add-principal tuser talias talias\\@ent.test
---------------------------------
Added new aliases to user "tuser"
---------------------------------
User login: tuser
Principal alias: tu...@testrelm.co, talias\@ent.t...@testrelm.co,
tal...@testrelm.co
[root@mgsauth02 ol]# kinit talias
Password for tal...@testrelm.co:
Password expired. You must change it now.
Enter new password:
Enter it again:
[root@mgsauth02 ol]# klist
Ticket cache: KCM:0:60382
Default principal: tu...@testrelm.co
Valid starting Expires Service principal
12/24/2022 13:51:02 12/25/2022 13:10:41 krbtgt/testrelm...@testrelm.co
[root@mgsauth02 ol]# kinit -C talias
Password for tal...@testrelm.co:
[root@mgsauth02 ol]# klist
Ticket cache: KCM:0:52413
Default principal: tu...@testrelm.co
Valid starting Expires Service principal
12/24/2022 13:52:32 12/25/2022 13:18:25 krbtgt/testrelm...@testrelm.co
=== So far OK. But when trying alias in email-form:
[root@mgsauth02 ol]# kinit talias\\@ent.test
kinit: Client 'talias\@ent.t...@testrelm.co' not found in Kerberos
database while getting initial credentials
[root@mgsauth02 ol]# kinit -E talias\\@ent.test
kinit: Client 'talias\@ent.t...@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:
talias\@ent.t...@testrelm.co for krbtgt/testrelm...@testrelm.co,
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
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
