Bug 1915820
Summary: | ipa server does not authenticate a user with enterprise principal | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 9 | Reporter: | Filip Dvorak <fdvorak> |
Component: | ipa | Assignee: | Alexander Bokovoy <abokovoy> |
Status: | CLOSED WONTFIX | QA Contact: | ipa-qe <ipa-qe> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | unspecified | CC: | abokovoy, frenaud, ftrivino, pcech, rcritten, tscherf |
Target Milestone: | beta | Keywords: | Triaged |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2022-07-13 07:28:26 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Filip Dvorak
2021-01-13 13:35:13 UTC
I think the issue is on your side: when you define an alias, you should be defining it without our realm. kinit -E raduser will result in a search issued by KDC with the following LDAP filter: "(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=raduser)(krbPrincipalName:caseIgnoreIA5Match:=raduser)))" I have tried to use the same scenario except for "ipa user-add-principal". I used this command without REALM -> "ipa user-add-principal otpuser altuser "raduser\@test.ipa"". But the result is the same: # ipa user-add-principal otpuser altuser "raduser\@test.ipa" ----------------------------------- Added new aliases to user "otpuser" ----------------------------------- User login: otpuser Principal alias: otpuser, raduser\@test.ipa, altuser [root@ci-vm-10-0-139-150 ~]# echo -e "Secret123" | kinit -c otpuser.cache otpuser Password for otpuser: Password expired. You must change it now. Enter new password: kinit: Cannot read password while getting initial credentials [root@ci-vm-10-0-139-150 ~]# kinit -c otpuser.cache otpuser Password for otpuser: Password expired. You must change it now. Enter new password: Enter it again: # ipa user-show otpuser User login: otpuser First name: otp Last name: user Home directory: /home/otpuser Login shell: /bin/sh Principal name: otpuser Principal alias: otpuser, raduser\@test.ipa, altuser Email address: otpuser UID: 1684400001 GID: 1684400001 User authentication types: otp, radius Account disabled: False Password: True Member of groups: ipausers Kerberos keys available: True # echo 123otp | kinit -T otpuser.cache altuser Enter OTP Token Value: # export KRB5_TRACE=/dev/stdout # echo 123otp | kinit -T otpuser.cache -E raduser [12843] 1610554244.837542: Resolving unique ccache of type KCM [12843] 1610554244.837543: Getting initial credentials for raduser\@test.ipa [12843] 1610554244.837544: FAST armor ccache: otpuser.cache [12843] 1610554244.837545: Retrieving otpuser -> krb5_ccache_conf_data/fast_avail/krbtgt\/TESTREALM.COM\@TESTREALM.COM@X-CACHECONF: from FILE:otpuser.cache with result: 0/Success [12843] 1610554244.837546: Read config in FILE:otpuser.cache for krbtgt/TESTREALM.COM: fast_avail: yes [12843] 1610554244.837547: Using FAST due to armor ccache negotiation result [12843] 1610554244.837548: Getting credentials otpuser -> krbtgt/TESTREALM.COM using ccache FILE:otpuser.cache [12843] 1610554244.837549: Retrieving otpuser -> krbtgt/TESTREALM.COM from FILE:otpuser.cache with result: 0/Success [12843] 1610554244.837550: Armor ccache sesion key: aes256-cts/97B4 [12843] 1610554244.837552: Creating authenticator for otpuser -> krbtgt/TESTREALM.COM, seqnum 0, subkey aes256-cts/B3EA, session key aes256-cts/97B4 [12843] 1610554244.837554: FAST armor key: aes256-cts/1D75 [12843] 1610554244.837556: Sending unauthenticated request [12843] 1610554244.837557: Encoding request body and padata into FAST request [12843] 1610554244.837558: Sending request (1122 bytes) to TESTREALM.COM [12843] 1610554244.837559: Initiating TCP connection to stream 10.0.139.150:88 [12843] 1610554244.837560: Sending TCP request to stream 10.0.139.150:88 [12843] 1610554244.837561: Received answer (449 bytes) from stream 10.0.139.150:88 [12843] 1610554244.837562: Terminating TCP connection to stream 10.0.139.150:88 [12843] 1610554244.837563: Response was from master KDC [12843] 1610554244.837564: Received error from KDC: -1765328378/Client not found in Kerberos database [12843] 1610554244.837565: Decoding FAST response kinit: Client 'raduser\@test.ipa' not found in Kerberos database while getting initial credentials 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) instead of raduser@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 altuser raduser 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. Thank you taking your time and submitting this request for Red Hat Enterprise Linux 8. Unfortunately, this bug cannot be kept even as a stretch goal and was postponed to RHEL9. Postponed for RHEL 9.2.0 (after krb5 1.20 migration is completed). Reason shortly: krb5 1.20 migration will affect canonicalization of the principals, the UPNs will be affected. After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened. |