#2436 ipa user private group not found
Closed: Fixed None Opened 5 years ago by jhrozek.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 6): Bug 1139044

Description of problem:

In IPA on RHEL6, I see errors logging in as a user:

[root@ipa slapd-EXAMPLE-COM]# ssh -l ipauser1 $(hostname)
ipauser1@ipa.example.com's password:
Could not chdir to home directory /home/ipauser1: No such file or directory
id: cannot find name for group ID 982000001
-sh-4.1$ exit

From sssd log (from IPA client here) I see:

(Sun Sep  7 13:50:26 2014) [sssd[be[example.com]]] [sdap_get_generic_ext_step]
(0x0400): calling ldap_search_ext with [(&(cn=ipauser1)(objectclass=groupofname
s)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))][cn=accounts,dc=example,dc=com].

Checking the group info in IPA:

[root@ipa slapd-EXAMPLE-COM]# ipa group-show ipauser1 --all --raw
  dn: cn=ipauser1,cn=groups,cn=accounts,dc=example,dc=com
  cn: ipauser1
  description: User private group for ipauser1
  gidnumber: 982000001
  ipauniqueid: bbef789c-36be-11e4-a38e-0000c0a87a65
  mepmanagedby: uid=ipauser1,cn=users,cn=accounts,dc=example,dc=com
  objectclass: posixgroup
  objectclass: ipaobject
  objectclass: mepManagedEntry
  objectclass: top

I do not see objectclass groupofnames.

If I add that, I can start seeing user private group:

[root@ipa slapd-EXAMPLE-COM]# ldapmodify  -D "cn=Directory Manager" -w
Secret123 <<EOF
dn: cn=ipauser1,cn=groups,cn=accounts,dc=example,dc=com
add: objectClass
objectClass: groupofnames
EOF

modifying entry "cn=ipauser1,cn=groups,cn=accounts,dc=example,dc=com"

[root@ipa slapd-EXAMPLE-COM]# getent group ipauser1
ipauser1:*:982000001:
[root@ipa slapd-EXAMPLE-COM]# ssh -l ipauser1 $(hostname)
ipauser1@ipa.example.com's password:
Last login: Sun Sep  7 14:08:14 2014 from ipa.example.com
Could not chdir to home directory /home/ipauser1: No such file or directory
-sh-4.1$


Version-Release number of selected component (if applicable):
ipa-server-3.0.0-42.el6.x86_64
sssd-1.11.6-29.el6.x86_64


How reproducible:
always

Steps to Reproduce:
1. On RHEL6.6 server setup IPA server wtih DNS (ipa-server-install --setup-dns
--forwarder=<IP> ...)
2. ipa user-add ipauser1 --first=f --last=l --password
3. kinit ipauser1 # set password
4. getent group ipauser1
5. ssh -l ipauser1 $(hostname)


Actual results:
cannot see user private group for ipauser1.

Expected results:
can see upg for ipauser1 without having to add groupaddnames manually


Additional info:

regression -> blocker. Michal has a WIP patch.

blockedby: =>
blocking: =>
changelog: =>
coverity: =>
design: =>
design_review: => 0
feature_milestone: =>
fedora_test_page: =>
priority: major => blocker
review: True => 0
selected: =>
testsupdated: => 0

confirmed I'm seing this on a test F21-on-F21 (client and server) deployment , though strangely not on my production deployment with F19 server but F21 client. Probably a candidate for F21 freeze exception, I'll file a downstream bug.

In the case that works, groupofnames does not match on my user's private group, but does match on a couple of other non-private groups - perhaps as long as some group matches the groupofnames check, the user's private group is picked up later and the bug is hidden? Anyway, I definitely confirm it in a clean deployment using ipa user-add and not using any supplementary groups.

Replying to [comment:3 adamwill]:

In the case that works, groupofnames does not match on my user's private group, but does match on a couple of other non-private groups - perhaps as long as some group matches the groupofnames check, the user's private group is picked up later and the bug is hidden? Anyway, I definitely confirm it in a clean deployment using ipa user-add and not using any supplementary groups.

On IPA server, regular POSIX group (added with ipa group-add) have both posixGroup and groupOfNames, regular non-POSIX groups have only groupOfNames and user private groups only carry posixGroup.

So we need to have a way on the client to match several object classes for the same object type which we haven't done before.

Actually, correction: after a reboot, I'm seeing this bug in my production deployment too (the one where my user is a member of some other groups). So I guess it was a regression in a recent sssd update, either 1.12.1-1 or 1.12.0-7 ?

[adamw@adam live]$ id
uid=1001(adamw) gid=1001 groups=1001,491(mock),157400008(sysadmins) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

note there's no name associated with group 1001. Found my first practical consequence of this too - virt-manager won't work:

Unable to connect to libvirt.

Failed to find group record for gid '1001'

edit: For F21 this looks like a regression in 1.12.1-1 . I downgraded all packages to 1.12.0-7.fc21 , restarted sssd , logged in on a VT and that login has correct 'id' output.

_comment0: Actually, correction: after a reboot, I'm seeing this bug in my production deployment too (the one where my user is a member of some other groups). So I guess it was a regression in a recent sssd update, either 1.12.1-1 or 1.12.0-7 ?

{{{
[adamw@adam live]$ id
uid=1001(adamw) gid=1001 groups=1001,491(mock),157400008(sysadmins) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
}}}

note there's no name associated with group 1001. Found my first practical consequence of this too - virt-manager won't work:

{{{
Unable to connect to libvirt.

Failed to find group record for gid '1001'
}}}
=> 1410402622800809

Patch is on review.

owner: somebody => mzidek
patch: 0 => 1

milestone: NEEDS_TRIAGE => SSSD 1.11.7
resolution: => fixed
status: new => closed

Metadata Update from @jhrozek:
- Issue assigned to mzidek
- Issue set to the milestone: SSSD 1.11.7

3 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/3478

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata