#3501 Accessing IdM kerberos ticket fails while id mapping is applied
Closed: Fixed 2 years ago Opened 2 years ago by sbose.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1486053

Please note that this Bug is private and may not be accessible as it contains confidential Red Hat customer information.

Description of problem:

IdM setup with ID mapping. The users RID(e.g. 655845) would be mapped to
UID(e.g. 3000003). Unfortunately, accessing kerberos ticket fails as below...

$ klist
klist: Invalid UID in persistent keyring name while getting default ccache

It appears the UID in persistent keyring still points to RID resolved from AD.
We tried with FILE:/ type, however, the file is created with usual RID instead
of UID.

$ ls -l /tmp/krb5ccache_posixuser -n
-rw------- 1 655845 655845 161 Jul 18 11:02 /tmp/krb5ccache_posixuser


Version-Release number of selected component (if applicable):

RedHat Enterprise Linux 7.4
sssd
IPA/AD Trust


How reproducible:

 # ipa idview-add test_view
  # ipa idoverrideuser-add test_view 'jstephen\posixuser' --uid=300003
  # ipa idview-apply test_view --hostgroups=allipasystems

==================================================

[root@rhel7-ipa-client ~]# getent passwd posixuser@jstephen.local
posixuser@jstephen.local:*:300003:10000:posixuser:/home/jstephen.local/posixuse
r:/bin/bash
[root@rhel7-ipa-client ~]# ssh posixuser@jstephen.local@localhost
Password:
Last login: Mon Aug 28 12:07:28 2017 from ::1
[posixuser@jstephen.local@rhel7-ipa-client ~]$ klist
klist: Invalid UID in persistent keyring name while getting default ccache
[posixuser@jstephen.local@rhel7-ipa-client ~]$ echo $KRB5CCNAME
KEYRING:persistent:10001



Actual results:

klist
klist: Invalid UID in persistent keyring name while getting default ccache

Expected results:

There shouldn't be any error.


Additional info:

Metadata Update from @sbose:
- Issue assigned to sbose

2 years ago

The reason for this issue is that the view name is not set properly in the domain objects if the view is not the default view when SSSD is started with an empty cache. As a workaround SSSD can be restarted without removing the cache.

To check the view name at runtime you can call

gdb -p $(pidof sssd_be) --batch -ex 'up 100' -ex 'p main_ctx->confdb_ctx->doms->view_name'

Metadata Update from @sbose:
- Issue set to the milestone: None

2 years ago

Metadata Update from @sbose:
- Custom field patch adjusted to on

2 years ago

Metadata Update from @jhrozek:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1486053

2 years ago

I'll leave this ticket open in the meantime while we ask if RHEL needs this fixed also in 6.x

On (11/09/17 15:44), Jakub Hrozek wrote:

jhrozek added a new comment to an issue you are following:
I'll leave this ticket open in the meantime while we ask if RHEL needs this fixed also in 6.x

I think it should not be about backporting to rhel. But fix was quite simple
and it would be good to fix it also in LTM branch. I do not expect 2 mandays
for fixing it.

LS

Metadata Update from @jhrozek:
- Issue close_status updated to: Fixed
- Issue set to the milestone: SSSD 1.15.4
- Issue status updated to: Closed (was: Open)

2 years ago

I opened https://pagure.io/SSSD/sssd/issue/3536 to track the backport. No need to keep this ticket open when the issue is already fixed in master.

Metadata Update from @jhrozek:
- Issue set to the milestone: SSSD 1.16.0 (was: SSSD 1.15.4)

2 years ago

Login to comment on this ticket.

Metadata