Bug 1135433

master:
    2284e50c801a53541016eb9a5af00d1250d36afb
    0321da68a393943797ea8cb9eb5e9672431ff8f4 
sssd-1-11:
    ffe42e0158df6e4b2aad91e9a0cd75aff05be8c4

Please add stpes to verify

This will be difficult to verify with default installation given that DS side in Bug 1140888 was fixed.

But I am thinking we may add a new test FreeIPA permission allowing reading entryusn (i.e. effectively revert https://fedorahosted.org/freeipa/ticket/4534) to all authenticated members in all entries to force DS return dereferenced entries without objectclass:

1) Install FreeIPA server
2) Install FreeIPA client
3) On server, add the permission:

# ipa permission-add test --attrs entryusn --right read --bindtype all --subtree SUFFIX

How can we confirm this has succeeded?

How/where would we see the dereference code fail processing initgroups?


[root@vm8 ~]# kinit admin
Password for admin.COM: 

[root@vm8 ~]# ipa user-add testuser1 --first=f --last=l
----------------------
Added user "testuser1"
----------------------
  User login: testuser1
  First name: f
  Last name: l
  Full name: f l
  Display name: f l
  Initials: fl
  Home directory: /home/testuser1
  GECOS: f l
  Login shell: /bin/sh
  Kerberos principal: testuser1.COM
  Email address: testuser1.com
  UID: 1370600003
  GID: 1370600003
  Password: False
  Member of groups: ipausers
  Kerberos keys available: False

[root@vm8 ~]# ipa permission-add test --attrs entryusn --right read --bindtype all --subtree "dc=ipa2,dc=example,dc=com"
-----------------------
Added permission "test"
-----------------------
  Permission name: test
  Granted rights: read
  Effective attributes: entryusn
  Bind rule type: all
  Subtree: dc=ipa2,dc=example,dc=com

[root@vm8 ~]# ipa user-add testuser2 --first=f --last=l----------------------
Added user "testuser2"
----------------------
  User login: testuser2
  First name: f
  Last name: l
  Full name: f l
  Display name: f l
  Initials: fl
  Home directory: /home/testuser2
  GECOS: f l
  Login shell: /bin/sh
  Kerberos principal: testuser2.COM
  Email address: testuser2.com
  UID: 1370600004
  GID: 1370600004
  Password: False
  Member of groups: ipausers
  Kerberos keys available: False

On the client:

[root@vm9 ~]# id testuser1
uid=1370600003(testuser1) gid=1370600003(testuser1) groups=1370600003(testuser1)
[root@vm9 ~]# id testuser2
uid=1370600004(testuser2) gid=1370600004(testuser2) groups=1370600004(testuser2)

Is there a log entry I can look for to confirm this?

If resolving admin user in SSSD succeeds even after applying my proposed reproduction in Comment 5, I am not aware of other reproduction steps. If this is the case (and Jakub also does not know any), I would verify as SanityOnly.

Just testing "id" for sanity is good enough. To make sure the dereference call is used and not the individual lookups, set ldap_deref_threshold=1 in the domain section or test with users who are members of 10 or more groups.

Verified.

Version ::

Results ::

See comment #6 above for first part.

Next part, I added 2 users (testuser3 and testuser4) to 20 groups (testgroup1..20) on the IPA Server.

Then on the client check with id command:

[root@vm9 ~]# kdestroy -A
[root@vm9 ~]# service sssd stop; rm -rf /var/lib/sss/{db,mc}/*; service sssd start
Redirecting to /bin/systemctl stop  sssd.service
Redirecting to /bin/systemctl start  sssd.service
[root@vm9 ~]# id testuser3
uid=1370600025(testuser3) gid=1370600025(testuser3) groups=1370600025(testuser3),1370600008(testgroup4),1370600012(testgroup8),1370600015(testgroup11),1370600019(testgroup15),1370600023(testgroup19),1370600007(testgroup3),1370600011(testgroup7),1370600016(testgroup12),1370600020(testgroup16),1370600006(testgroup2),1370600010(testgroup6),1370600017(testgroup13),1370600021(testgroup17),1370600024(testgroup20),1370600005(testgroup1),1370600009(testgroup5),1370600013(testgroup9),1370600014(testgroup10),1370600018(testgroup14),1370600022(testgroup18)
[root@vm9 ~]# id testuser4
uid=1370600026(testuser4) gid=1370600026(testuser4) groups=1370600026(testuser4),1370600024(testgroup20),1370600017(testgroup13),1370600009(testgroup5),1370600022(testgroup18),1370600015(testgroup11),1370600020(testgroup16),1370600006(testgroup2),1370600005(testgroup1),1370600011(testgroup7),1370600010(testgroup6),1370600018(testgroup14),1370600023(testgroup19),1370600016(testgroup12),1370600007(testgroup3),1370600012(testgroup8),1370600021(testgroup17),1370600014(testgroup10),1370600019(testgroup15),1370600008(testgroup4),1370600013(testgroup9)

And then just to make sure, I also added ldap_deref_threshold=1 in the domain section and reran the id check:

[root@vm9 ~]# vi /etc/sssd/sssd.conf
[root@vm9 ~]# service sssd stop; rm -rf /var/lib/sss/{db,mc}/*; service sssd start
Redirecting to /bin/systemctl stop  sssd.service
Redirecting to /bin/systemctl start  sssd.service
[root@vm9 ~]# id testuser3
uid=1370600025(testuser3) gid=1370600025(testuser3) groups=1370600025(testuser3),1370600008(testgroup4),1370600012(testgroup8),1370600015(testgroup11),1370600019(testgroup15),1370600023(testgroup19),1370600007(testgroup3),1370600011(testgroup7),1370600016(testgroup12),1370600020(testgroup16),1370600006(testgroup2),1370600010(testgroup6),1370600017(testgroup13),1370600021(testgroup17),1370600024(testgroup20),1370600005(testgroup1),1370600009(testgroup5),1370600013(testgroup9),1370600014(testgroup10),1370600018(testgroup14),1370600022(testgroup18)
[root@vm9 ~]# id testuser4
uid=1370600026(testuser4) gid=1370600026(testuser4) groups=1370600026(testuser4),1370600024(testgroup20),1370600017(testgroup13),1370600009(testgroup5),1370600022(testgroup18),1370600015(testgroup11),1370600020(testgroup16),1370600006(testgroup2),1370600005(testgroup1),1370600011(testgroup7),1370600010(testgroup6),1370600018(testgroup14),1370600023(testgroup19),1370600016(testgroup12),1370600007(testgroup3),1370600012(testgroup8),1370600021(testgroup17),1370600014(testgroup10),1370600019(testgroup15),1370600008(testgroup4),1370600013(testgroup9)

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0441.html