On Tue, Nov 22, 2016 at 09:23:39AM +0100, Lukas Slebodnik wrote:
On (21/11/16 18:09), zfnoctis@gmail.com wrote:
What is the appropriate usage of these scripts? Should I run "stap nested_group_perf.stp" and in another terminal run id $username or su - $username ?.
Yes, but you will also neet to install systemtap-devel on fedora. You might also use id_perf.stp just for id stap /usr/share/sssd/systemtap/id_perf.stp
Also iirc kernel-debuginfo, but this should be pulled by stap automatically (I think).
It is not required to restart the script between successive id runs, the variables are cleared when systemtap detects id had started or finished.
The situation is little bit different for nested_group_perf.stp Please note that since the script is supposed to be used in scenarios such as tracing "id" performance, which typically involve multiple group requests. Therefore, the variables are not zeroed out and you need to interrupt the script manually with Ctrl+C.
Also I have setup a new Fedora 24 VM with sssd 1.14.2. I am not sure what is going on, but there appears to be some issues with group lookups and now it is affecting sudo. I have not encountered these issues on Ubuntu 16.04 with sssd 1.13 so far.
Adding an AD group, say, MY.DOMAIN\linuxadmins, to /etc/sudoers, "%MY.DOMAIN\linuxadmins ALL=(ALL) ALL" does not allow group members to elevate privileges. I have verified the users are in the group via id, and I have verified the group contains the users via "getent group MY.DOMAIN\linuxadmins". However simply adding the users directly to /etc/sudoers allows elevation.
Users are not seen as members of groups after attempting to elevate with sudo. As in id and getent group no longer show the user as belonging to that group.
I also noticed the following error from systemctl status sssd (potentially same as fedorahosted.org/sssd/ticket/2982):
"Nov 21 10:25:00 fc24-vm.my.domain sssd[nss][729]: More groups have the same GID [965793034]in directory server. SSSD will not work correctly."
This appears to be resolved by modifying ldap_idmap settings. For example:
ldap_idmap_range_min=100000 ldap_idmap_range_max=2000100000 ldap_idmap_range_size=2000000000
Have you changed id mapping related options before? If yes, did you remove sssd cache? rm -f /var/lib/sss/db/*
I do not see a reason why changing idmapping options should fix problem with "More groups have the same"
I am now very concerned that 1.14 means I cannot use sssd for non-graphical environments if sudo cannot find group members.
Missing groups might cause problems also for other programs and not just for sudo. Feel free to file a fedora BZ with sanitized sssd configuration and sssd log files. https://fedorahosted.org/sssd/wiki/Troubleshooting
I think if this issue happens after the cache is cleared, it would be nice to peek at the ldb cache with ldbsearch to see which objects have the duplicate gid..