sssd-users April 2016

sssd-users@lists.fedorahosted.org

20 participants
23 discussions

Enumerate users from external group from AD trust
by Bolke de Bruin 29 Nov '19

29 Nov '19

Hello, I have sssd 1.13.00 working against FreeIPA 4.2 domain. This domain has a trust relationship with a active directory domain. One of the systems we are using requires to enumerate all users in groups by (unfortunate) design (Apache Ranger). This is done by using “getent group”. During this enumeration the full user list for a group that has a nested external member group* is not always returned so we thought to add “getent group mygroup” in order to get more details. Unfortunately this does not seem to work consistently: sometimes this gives information sometimes it does not: [root@master centos]# getent group ad_users ad_users:*:1950000004: [root@master centos]# id bolke(a)ad.local UID=1796201107(bolke(a)ad.local) GID=1796201107(bolke(a)ad.local) groepen=1796201107(bolke(a)ad.local),1796200513(domain users@ad.local),1796201108(test@ad.local) [root@master centos]# getent group ad_users ad_users:*:1950000004:bolke@ad.local <mailto:bolke@ad.local> If I clear the cache (sss_cache -E) the entry is gone again: [root@master centos]# getent group ad_users ad_users:*:1950000004: My question is how do I get sssd to enumerate *all users* in a group consistently? Thanks! Bolke * https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/trust-gro…

3 15

full_name_format and supplemental groups
by Orion Poplawski 25 Oct '16

25 Oct '16

Running IPA with an AD trust. Users are in AD. Trying to use full_name_format = %1$s to strip the domain from user names. This appears to break supplemental groups in strange ways. On the IPA server: Without full_name_format: # id orion(a)ad.nwra.com uid=470202603(orion(a)ad.nwra.com) gid=470202603(orion(a)ad.nwra.com) groups=470202603(orion(a)ad.nwra.com),470200513(domain users(a)ad.nwra.com),470204703(pirep rd users(a)ad.nwra.com),470204714(wireless access@ad.nwra.com),470204715(nwra-users@ad.nwra.com),470204701(boulder@ad.nwra.com),470207608(heimdall users(a)ad.nwra.com),470200512(domain admins(a)ad.nwra.com),470207124(andreas admins(a)ad.nwra.com) With: # id orion(a)ad.nwra.com uid=470202603(orion) gid=470202603(orion) groups=470202603(orion) If I add: default_domain_suffix = ad.nwra.com # id orion uid=470202603(orion) gid=470202603(orion) groups=470202603(orion),470200512(domain admins),470207608(heimdall users),470204714(wireless access),470204715(nwra-users),470204701(boulder),470204703(pirep rd users),470207124(andreas admins),470200513(domain users) Which I guess makes some sense as you'd need to add the domain suffix back on to find the groups. But this appears to completely break IPA clients (with full_name_format = %1$s and default_domain_suffix = ad.nwra.com): # id orion(a)ad.nwra.com id: orion(a)ad.nwra.com: no such user # id orion id: orion: no such user >From looking at the server logs, it looks like only the IPA domain is searched If I reset the server back to normal (drop full_name_format and default_domain_suffix): # id orion uid=470202603(orion) gid=470202603(orion) groups=470202603(orion) I don't get any supplemental groups. I see sssd errors like: (Mon Mar 30 15:20:52 2015) [sssd[be[nwra.com]]] [sysdb_mod_group_member] (0x0400): Error: 2 (No such file or directory) (Mon Mar 30 15:20:52 2015) [sssd[be[nwra.com]]] [sysdb_update_members_ex] (0x0020): Could not add member [orion] to group [name=domain admins,cn=groups,cn=nwra.com,cn=sysdb]. Skipping. Is t trying "cn=groups,cn=nwra.com,cn=sysdb" instead of "cn=groups,cn=ad.nwra.com,cn=sysdb" -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 http://www.nwra.com

3 7

netlink messages on Infiniband causing sssd to exit
by Ryan Novosielski 19 Aug '16

19 Aug '16

Over time, I’ve been having seemingly random sssd quits that I’ve not been able to figure out. Today, I finally traced it to fluctuations on my Infiniband fabric: sssd.log (Tue Nov 3 13:17:59 2015) [sssd] [message_type] (0x0200): netlink Message type: 16 (Tue Nov 3 13:17:59 2015) [sssd] [link_msg_handler] (0x1000): netlink link message: iface idx 4 (ib0) flags 0x1003 (broadcast,multicast,up) (Tue Nov 3 13:17:59 2015) [sssd] [message_type] (0x0200): netlink Message type: 16 (Tue Nov 3 13:17:59 2015) [sssd] [link_msg_handler] (0x1000): netlink link message: iface idx 4 (ib0) flags 0x11043 (broadcast,multicast,up,running,lower) This exactly corresponds to the time in /var/log/messages for the unexplained shutdown: 2015-11-03T13:17:59-05:00 node75 sssd[pam]: Shutting down 2015-11-03T13:17:59-05:00 node75 sssd[be[default]]: Shutting down 2015-11-03T13:17:59-05:00 node75 sssd[nss]: Shutting down Here is sssd_default.log for good measure: (Tue Nov 3 13:17:59 2015) [sssd[be[default]]] [sbus_remove_watch] (0x2000): 0x1414770/0x14133d0 (Tue Nov 3 13:17:59 2015) [sssd[be[default]]] [sbus_remove_watch] (0x2000): 0x1414770/0x13fef90 (Tue Nov 3 13:17:59 2015) [sssd[be[default]]] [be_ptask_destructor] (0x0400): Terminating periodic task [Cleanup of default] (Tue Nov 3 13:17:59 2015) [sssd[be[default]]] [sdap_handle_release] (0x2000): Trace: sh[0x14bd850], connected[1], ops[(nil)], ldap[0x1424260], destructor_lock[0], release_memory[0] (Tue Nov 3 13:17:59 2015) [sssd[be[default]]] [remove_connection_callback] (0x4000): Successfully removed connection callback. (Tue Nov 3 13:17:59 2015) [sssd[be[default]]] [sbus_remove_watch] (0x2000): 0x1415970/0x1416430 (Tue Nov 3 13:17:59 2015) [sssd[be[default]]] [remove_socket_symlink] (0x4000): The symlink points to [/var/lib/sss/pipes/private/sbus-dp_default.18702] (Tue Nov 3 13:17:59 2015) [sssd[be[default]]] [remove_socket_symlink] (0x4000): The path including our pid is [/var/lib/sss/pipes/private/sbus-dp_default.18702] (Tue Nov 3 13:17:59 2015) [sssd[be[default]]] [remove_socket_symlink] (0x4000): Removed the symlink (Tue Nov 3 13:17:59 2015) [sssd[be[default]]] [be_client_destructor] (0x0400): Removed PAM client (Tue Nov 3 13:17:59 2015) [sssd[be[default]]] [be_client_destructor] (0x0400): Removed NSS client I can duplicate this by manually taking down the Infiniband link: [root@node24 ~]# service sssd status sssd (pid 9132) is running... [root@node24 ~]# ifdown ib0 [root@node24 ~]# service sssd status sssd dead but pid file exists I have also noticed that sssd will not start on boot. As I know that Infiniband tends to flutter a little bit before the link comes up, I’m thinking this is probably the same cause. Can anyone explain this behavior and tell me what I might do to prevent it? -- ____ *Note: UMDNJ is now Rutgers-Biomedical and Health Sciences* || \\UTGERS |---------------------*O*--------------------- ||_// Biomedical | Ryan Novosielski - Senior Technologist || \\ and Health | novosirj(a)rutgers.edu - 973/972.0922 (2x0922) || \\ Sciences | OIRT/High Perf & Res Comp - MSB C630, Newark `'

5 7

Re: "Child not responding" on loaded servers
by Patrick Coleman 01 May '16

01 May '16

On 29 Apr 2016 9:10 pm, "Lukas Slebodnik" <lslebodn(a)redhat.com> wrote: > > On (29/04/16 17:56), Patrick Coleman wrote: > >Hi, > > > >We've got a number of machines using sssd to connect to LDAP for auth. > >In the past we've had problems with sssd crashing regularly[1], but > >after posting here we built some custom packages to disable netlink > >notifications from the kernel, and it's generally improved. > > > >We're still seeing auth failures across random machines - perhaps 1-2% > >when we run a process which connects to all hosts. The machines are > >generally heavily loaded when this happens, and sssd.log looks like: > > > Do you meand IO related load or CPU related load? Lots of both, but we're typically IO bound more of the time. > If there is issue with CPU then you can mount sssd cache to tmpfs > to avoid such issues. (there are plans to improve it in 1.14) Cool, I'll give that a go. Cheers Patrick

2 1

Prevent sudo queries to ldap for service accounts
by Jared Watkins 29 Apr '16

29 Apr '16

Hello.. I've got sssd 1.11.5 running on ubuntu trusty and I'm seeing some behavior that I'd like to change. When local service account users run sudo commands the sssd sudo module is triggering ldap lookups. For NSS data I'm suppressing these with filter_users/filter_groups but there does not seem to be a way of doing that for the sudo module. This is despite the fact that in nsswitch files comes before sss. I've gone through the docs and the list archive but couldn't find anything on point for this. Any help is appreciated. Thanks, Jared

2 3

"Child not responding" on loaded servers
by Patrick Coleman 29 Apr '16

29 Apr '16

Hi, We've got a number of machines using sssd to connect to LDAP for auth. In the past we've had problems with sssd crashing regularly[1], but after posting here we built some custom packages to disable netlink notifications from the kernel, and it's generally improved. We're still seeing auth failures across random machines - perhaps 1-2% when we run a process which connects to all hosts. The machines are generally heavily loaded when this happens, and sssd.log looks like: (Fri Apr 29 09:31:19 2016) [sssd] [ping_check] (0x0020): A service PING timed out on [nss]. Attempt [0] (Fri Apr 29 09:31:29 2016) [sssd] [tasks_check_handler] (0x0020): Child (meraki) not responding! (yet) (Fri Apr 29 09:31:39 2016) [sssd] [tasks_check_handler] (0x0020): Child (meraki) not responding! (yet) (Fri Apr 29 09:31:39 2016) [sssd] [ping_check] (0x0020): A service PING timed out on [nss]. Attempt [0] While sssd is in this state, it seems to deny auth randomly for LDAP users - they receive "connection closed by remote host". It will eventually restart its children, but that doesn't seem to fix the problem. Logs for the meraki domain and for nss indicate the subprocesses are running: /var/log/sssd/sssd_meraki.log (Fri Apr 29 09:30:53 2016) [sssd[be[meraki]]] [sdap_save_user] (0x0400): Storing info for user blinken (Fri Apr 29 09:31:22 2016) [sssd[be[meraki]]] [sdap_initgr_rfc2307_next_base] (0x0400): Searching for groups with base [dc=meraki,dc=com] (Fri Apr 29 09:31:22 2016) [sssd[be[meraki]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(memberuid=blinken)(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!( gidNumber=0))))][dc=meraki,dc=com]. (Fri Apr 29 09:31:22 2016) [sssd[be[meraki]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set /var/log/sssd/sssd_nss.log (Fri Apr 29 09:31:22 2016) [sssd[nss]] [nss_cmd_getgrgid_search] (0x0080): No matching domain found for [1155] (Fri Apr 29 09:31:22 2016) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [blinken] from [<ALL>] (Fri Apr 29 09:31:22 2016) [sssd[nss]] [nss_cmd_initgroups_search] (0x0100): Requesting info for [blinken@meraki] (Fri Apr 29 09:31:26 2016) [sssd[nss]] [calc_flat_name] (0x0080): Flat name requested but domain has noflat name set, falling back to domain name (Fri Apr 29 09:31:26 2016) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [meraki] from [<ALL>] (Fri Apr 29 09:31:26 2016) [sssd[nss]] [nss_cmd_initgroups_search] (0x0080): No matching domain found for [meraki], fail! We first saw the behaviour on sssd 1.11.7 and have upgraded to sssd version 1.13.4, with more or less the same symptoms. We've turned enumerate on and off with no apparent change in behaviour. Does anyone have any suggestions here? Let me know if I can provide more detailed debugging information (perhaps off-list). Cheers, Patrick 1. https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.…

2 1

cache question
by Ondrej Valousek 29 Apr '16

29 Apr '16

Hi List, [root@machine ~]# sss_cache -g mpeg2 No cache object matched the specified search [root@machine ~]# getent -s sss group mpeg2 mpeg2:*:139: Is this normal behavior? I have deleted mpeg2 group recently... Only after I do 'sss_cache -G' it goes away eventually.... Thanks, Ondrej ----- The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18.

4 10

=?utf-8?q?=5BSSSD-users=5D?=(&(objectClass=sudoRole)(modifyTimestamp>=1)) => fail
by Michael Ströder 28 Apr '16

28 Apr '16

HI! I'm currently testing a custom build of sssd 1.13.4 against OpenLDAP server. I notice this filter in the log: (&(objectClass=sudoRole)(modifyTimestamp>=1)) Obviously it's a USN fallback filter since USN attribute is not available on OpenLDAP. But the LDAP syntax of assertion value "1" is wrong and therefore no match. Ciao, Michael.

2 3

minimal sssd-ldap build
by Michael Ströder 28 Apr '16

28 Apr '16

HI! I'd like to create really minimal custom builds of sssd-ldap even without krb5 stuff currently for Debian Wheezy/Jessie. Are there any recommendations for achieving this? I have a test installation tested with SSH, sudo, NSS built like this which required krb5-devel files though: /configure -q \ --prefix=/opt/sssd \ --disable-krb5-locator-plugin \ --disable-pac-responder \ --disable-cifs-idmap-plugin \ --without-python2-bindings \ --without-python3-bindings \ --without-selinux \ --without-semanage \ --with-sudo \ --without-autofs \ --with-ssh \ --with-crypto=libcrypto \ --with-syslog=syslog \ --without-samba \ --without-nfsv4-idmapd-plugin \ --without-libwbclient \ --without-libnl \ --disable-config-lib \ --disable-intgcheck-reqs \ --disable-nls \ --disable-rpath ln -s \ /opt/sssd/lib/libnss_sss.so.2 \ /lib/x86_64-linux-gnu/libnss_sss.so.2 ln -s \ /opt/sssd/lib/security/pam_sss.so \ /lib/x86_64-linux-gnu/security/pam_sss.so One issue with memberof module installed into /usr/lib/x86_64-linux-gnu/ldb/modules/: ldb: unable to dlopen /usr/lib/x86_64-linux-gnu/ldb/modules/ldb/memberof.la : /usr/lib/x86_64-linux-gnu/ldb/modules/ldb/memberof.la: invalid ELF header Moving the files and setting LDB_MODULES_PATH did not help. Ciao, Michael.

3 5

Cache issues on update [SEC=UNOFFICIAL]
by Kosseck, Adam MR 28 Apr '16

28 Apr '16

UNOFFICIAL Hi, I've noticed a cache issue in SSSD 1.12 on RHEL 6 after executing a global update via ansible (ansible all -m yum -a "name=* state=latest"). Essentially after the update, queries against the cache appear to return invalid (incomplete) results on all 12 RHEL boxes that were updated. Issuing an "sss_cache -E" does not correct the issue, but it is fixed after stopping SSSD, deleting the DB (rm /var/lib/sss/db/*) and then restarting SSSD. SSSD --version appears to report as 1.12.4 both before and after the update. User query after patching: id "username" uid=xxx(username) guid=xxx(group 1) groups=xxx(group 1) The UID and GUIDs above are correct - but incomplete as the user is a member of 28 groups. User query results both before patching and after patching (after removing /var/lib/sss/db/*) id "username" uid=xxx(username) guid=xxx(group 1) groups=xxx(group 1),xxx(group 2),xxx(group 3), xxx(group 4), xxx(group 5), xxx(group 5), xxx(group 6), etc This may be related to the same SSSD bug seen in this environment that was discussed last week (inconsistent SSSD behaviour). I'm hoping that 1.13 resolves this issue when RHEL 6.8 is released. My SSSD config is below and the entries applied as fixes for the previous issue are bolded: [sssd] config_file_version = 2 debug_level = 1 domains = <domain> services = nss, pam, ssh, pac, sudo default_domain_suffix = <domain> [domain/<domain>] debug_level = 1 id_provider = ad access_provider = ad auth_provider = ad chpass_provider = ad ldap_schema = ad ad_enable_gc = false # Permits offline logins: cache_credentials = true default_shell = /bin/bash fallback_homedir = /home/%d/%u #Use FQDN for logins - when multiple domains share same username use_fully_qualified_domain_names = true # Ignore forest root domain, but have to specify current domain SID because of RHEL bug - see https://fedorahosted.org/sssd/ticket/2828 subdomains_provider = none ldap_idmap_default_domain_sid = <SID> #Don't attempt to auto update DNS records dyndns_update = false [ssh] debug_level = 1 [nss] debug_level = 1 filter_users = root,oracle,grid,mfe,postfix filter_groups = root [pam] debug_level = 1 [sudo] debug_level = 1 [pac] debug_level = 1

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users April 2016