sssd-users January 2016

sssd-users@lists.fedorahosted.org

28 participants
30 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

heads-up: new code to fetch sudo rules from an IPA server coming to Fedora and RHEL-6
by Jakub Hrozek 01 Feb '16

01 Feb '16

Hi, the sssd's code that fetches sudo rules from the IPA server got an overhaul recently. The search would no longer be performed against the compat tree, but against IPA's native LDAP tree. This would have the advantage that environments that don't use the slapi-nis' compat tree for another reason (like old or non-Linux clients) would no longer require slapi-nis to be running at all. We'd like to get some tests for this new code! If you're running Fedora , you can just upgrade to the packages from Fedora's update testing. If you're running RHEL-6.7 and would like to see what is cooking for 6.8, you can try this repository: https://copr.fedorainfracloud.org/coprs/jhrozek/SSSD-6.8-preview/ RHEL-7 wouldn't receive this code until 7.3, so we don't have test packages for el7 yet..

3 3

sssd + openldap + simple bind + tls + pam
by Marcelo Coelho 31 Jan '16

31 Jan '16

Hi all, I've been struggling to setup a centralized authentication system for quite some time. It is composed by: - openldap 2.4.43, with TLS self-signed certs (root chain is ok): ldaps://serv; - pam 1.2.1; pambase 20150213; - sssd 1.13.1; - openssh 7.1. Currently I'm trying to authenticate a LDAP user in the server that hosts openldap. ldapsearch -x shows me stuff correctly, with TLS working. If I try to connect through the command-line, the logs show sssd getting stuff from openldap with success. But, login fails: <log> login[xxxx]: pam_sss(login:auth): authentication success; logname=LOGIN uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=user_a login[xxxx]: FAILED LOGIN (1) on '/dev/tty1' FOR 'UNKNOWN', Authentication failure </log> Also, id user_a fails, getent passwd user_a fails. Have no idea what may be wrong (if sssd, ldap DB, whatever). sssd.conf [sssd] config_file_version = 2 services = pam domains = LDAP debug_level = 4 [nss] [pam] debug_level = 5 [domain/LDAP] debug_level = 4 id_provider = ldap auth_provider = ldap access_provider = ldap cache_credentials = false ldap_uri = ldaps://server ldap_schema = rfc2307 ldap_search_base = dc=casa,dc=lan ldap_id_use_start_tls = true ldap_tls_cacert = /etc/openldap/ssl/cacert.pem ldap_tls_cacertdir = /etc/openldap/ssl ldap_tls_reqcert = demand tls_reqcert = demand ldap_user_search_base = ou=People,dc=casa,dc=lan ldap_user_home_directory = homeDirectory ldap_user_shell = loginShell ldap_group_search_base = ou=Group,dc=casa,dc=lan ldap_access_filter = memberOf=ou=People,dc=casa,dc=lan # Leave this as password ldap_default_authtok_type = password system-auth auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass #auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_sss.so use_first_pass auth required pam_deny.so account required pam_unix.so account sufficient pam_localuser.so #account sufficient pam_succeed_if.so uid < 500 quiet #account [default=bad success=ok user_unknown=ignore] pam_sss.so #account [default=bad success=ok] pam_sss.so account sufficient pam_sss.so account required pam_permit.so nsswitch.conf passwd: compat sss shadow: compat sss group: compat sss hosts: files dns networks: files dns services: db files protocols: db files rpc: db files ethers: db files netmasks: files netgroup: files bootparams: files automount: files aliases: files Thanks in advance!

2 2

translate trusted domain users to local users
by Bolke de Bruin 29 Jan '16

29 Jan '16

Hi, In my setup (hello Hadoop!) I have the requirement to simplify user names from a trusted domain (Ad -> FreeIPA -> sssd) so they don’t contain “@“. Furthermore, “id username” needs to return information. Thus bolke(a)ad.local <mailto:bolke@ad.local> needs to become bolke (or bolke_ad_local). And “id -Gn bolke” needs to return my group memberships. I tried setting auth_to_local = { RULE:[1:$1@$0](^.*@AD.LOCAL$)s/@AD.LOCAL// DEFAULT } in /etc/krb5.conf, but that does not seem to work. How do I go about this? Thanks! Bolke

3 2

please do not remove enumeration from AD provider
by James Ralston 28 Jan '16

28 Jan '16

On Wed, May 6, 2015 at 4:27 AM, Jakub Hrozek <jhrozek(a)redhat.com> wrote: > You know, just this morning, I was thinking about enumeration. It > doesn't work for IPA views at all for example. It doesn't work for > trusted domains at all either (except for some limited support in AD > trusted domains that is very untested) > > I wonder if we could just remove enumeration from IPA and AD back > ends in some major release. Please don't do this. Enumeration is a very useful feature. It allows us to do things like this: $ getent passwd | grep -i lastname The equivalent ldapsearch command is much more tedious: $ ldapsearch -z 0 -E pr=2147483647/noprompt -o ldif-wrap=no -L -L -H 'ldap:///dc%3Dexample%2Cdc%3Dorg -Y GSSAPI -N -b "dc=example,dc=org" "(&(objectClass=user)(cn=*lastname*))" dn cn sAMAccountName More generically, enumeration is the way Unix/Linux has always worked. Even getting users to change from: grep -i lastname /etc/passwd To this: getent passwd | grep -i lastname ...has been a struggle. We also have various services that (unfortuantely) pre-load the passwd and group files at startup by enumerating them with getpwent_r() and getgrent_r(), instead of using the get*nam_r() and get*id_r() functions as-needed. These services break outright if enumeration is disabled. (Yes, these services are broken. Yes, they shouldn't do that. But our ability to fix them is extremely limited at best, because we don't control them.) Finally, we have many systems that cannot be joined to Active Directory (for policy reasons, not technical reasons). But we want to use the same passwd/group entries on those systems as returned by sssd on hosts that are joined to Active Directory. We do this by scraping the output of "getent -s sss passwd" and "getent -s sss group" and manually merging it into the local passwd and group files (respectively) on these hosts. > It's just a legacy feature, so those who need it can fall back to > the LDAP provider.. But the LDAP provider doesn't support ID mapping; only the AD provider does. And ID mapping is the main reason we use sssd. I'm not asking you to make enumeration the default. It shouldn't be; it should be something you only turn on if you need it, and you KNOW you need it. But if you need it, you NEED it. Please don't take it away.

7 17

SSSD Client Auth on LDAP Server -both Client & Server CentOS6.7
by steven.murdoch＠cdk.com 28 Jan '16

28 Jan '16

Hi - I am new to SSSD and LDAP, and my first posting - so please bare with me. # getent passwd only displays the local users - will not display the LDAP users and is driving me insane - ldapsearch seems to work I am using SSSD with TLS to authenticate to LDAP Server The CA.crt files were self signed certificates. I used # cacertdir_rehash to create to create the sym-link to the CA.crt on both Client and Server My LDAP Server hostname is 'ActDir-VM-Test' My SSSD Client hostname is 'SSSD-VM-Test' Here are my files: Server - /etc/openldap/slapd.conf: allow bind_v2 allow bind_anon_dn pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args TLSCACertificatePath /etc/openldap/cacerts TLSCACertificateFile /etc/openldap/cacerts/CA.crt TLSCertificateFile /etc/openldap/cacerts/server.crt TLSCertificateKeyFile /etc/openldap/cacerts/server.key TLSCipherSuite HIGH:MEDIUM:+TLSv1 TLSVerifyClient never access to dn.sub="dc=vmlab,dc=ari,dc=cdk,dc=hosting" by anonymous read by * read access to dn.base="" by anonymous none by * read database config access to * by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * none database monitor access to * by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read by dn.exact="cn=Manager,dc=vmlab,dc=ari,dc=cdk,dc=hosting" read by * none access to * by users read database bdb suffix "dc=vmlab,dc=ari,dc=cdk,dc=hosting" checkpoint 1024 15 rootdn "cn=Manager,dc=vmlab,dc=ari,dc=cdk,dc=hosting" rootpw p@ssw0rd loglevel 256 sizelimit unlimited # Server - ldap.conf: TIMELIMIT 120 ssl start_tls URI ldap://ActDir-VM-Test:389/ BASE cn=Manager,dc=vmlab,dc=ari,dc=cdk,dc=hosting TLS_REQCERT allow TLSCACertificatePath /etc/openldap/cacerts TLSCACertificateFile /etc/openldap/cacerts/CA.crt # Server - /etc/sysconfig/ldap: SLAPD_LDAP=yes # Run slapd with -h "... ldapi:/// ..." # yes/no, default: yes SLAPD_LDAPI=no # Run slapd with -h "... ldaps:/// ..." # yes/no, default: no SLAPD_LDAPS=no # Server - /etc/pam.d/password-auth-ac #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_sss.so use_first_pass auth required pam_deny.so account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 type= password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so # Server: - /etc/pam.d/system-auth-ac #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_sss.so use_first_pass auth required pam_deny.so account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 type= password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so # Server - /etc/nsswitch.conf passwd: files sss shadow: files sss group: files sss # Client - /etc/sssd/sssd.conf: [sssd] services = nss, pam config_file_version = 2 domains = vmlab authconfig --enablesssd --enablesssdauth --enablelocauthorize --enableldap --enableldaptls --enableldapauth --ldapserver=ldap://ActDir-VM-Test.vmlab.ari.cdk.hosting:389 --ldapbasedn=dc=vmlab,dc=ari,dc=cdk,dc=hosting --disablekrb5 --disablenis --enablerfc2307bis --enablemkhomedir --enablecachecreds --update [domain/vmlab] id_provider = ldap auth_provider = ldap # Timming entry_cache_timeout = 600 ldap_network_timeout = 3 ldap_uri = ldap://ActDir-VM-Test.vmlab.ari.cdk.hosting:389 ldap_user_search_base = dc=ActDir-VM-Test,dc=vmlab,dc=ari,dc=cdk,dc=hosting ldap_tls_reqcert = demand cache_credentials = True ldap_tls_cacertdir = /etc/openldap/cacerts ldap_access_filter = memberOf=CN=Manager,OU=Users,DC=ActDir-VM-Test,DC=vmlab,DC=ari,DC=cdk,DC=hosting ldap_tls_cacert = /etc/openldap/cacerts/CA.crt ldap_tls_reqcert = demand ldap_default_bind_dn = cn=Manager,ou=Users,dc=vmlab,dc=ari,dc=cdk,dc=hosting ldap_default_authtok_type = password ldap_default_authtok = p@ssw0rd enumerate = true [nss] filter_users = root, sshd, named, avahi, haldaemon, dbus, radiusd, news, nscd filter_groups = root, sshd, named, avahi, haldaemon, dbus, radiusd, news, nscd reconnection_retries = 3 entry_cache_timeout = 300 entry_cache_nowait_percentage = 75 debug_level = 6 [pam] reconnection_retries = 3 # The enumerate = True will only be enabled during testing - if I ever get it working - then it will be removed. Client - /etc/openldap/ldap.conf: idle_timelimit 3600 TIMELIMIT 120 bind_timelimit 120 SASL_NOCANON on TLSCACertificatePath /etc/openldap/cacerts TLSCACertificateFile /etc/openldap/cacerts/CA.crt #TLS_CACERTDIR /etc/openldap/cacerts #TLS_CACERT /etc/openldap/cacerts/CA.crt #TLS_CACERT /etc/openldap/cacerts/19913717.0 ssl start_tls TLS_REQCERT allow HOST ActDir-VM-Test.vmlab.ari.cdk.hosting BASE dc=ActDir-VM-Test,dc=vmlab,dc=ari,dc=cdk,dc=hosting URI ldap://ActDir-VM-Test.vmlab.ari.cdk.hosting:389 TLS_CACERTDIR /etc/openldap/cacerts ldap_default_bind_dn cn=Manager,dc=vmlab,dc=ari,dc=cdk,dc=hosting ldap_default_authtok p@ssw0rd BINDDN uid=Manager,ou=Users,dc=ActDir-VM-Test,dc=vmlab,dc=ari,dc=cdk,dc=hosting # Client - the PAM files password-auth-ac and the system-auth-ac files are the same as the Server: Client - nsswitch.conf: passwd: files sss shadow: files sss group: files sss uid Manager gid ldap #base CN=vmlab,OU=Users,DC=vmlab,DC=ari,DC=cdk,DC=hosting base DC=vmlab,DC=ari,DC=cdk,DC=hosting uri ldap://ActDir-VM-Test.vmlab.ari.cdk.hosting # Client - ldapsearch: # ldapsearch -x -ZZ -H ldap://ActDir-VM-Test.vmlab.ari.cdk.hosting -b dc=vmlab,dc=ari,dc=cdk,dc=hosting objectclass=* # extended LDIF # # LDAPv3 # base <dc=vmlab,dc=ari,dc=cdk,dc=hosting> with scope subtree # filter: objectclass=* # requesting: ALL # # vmlab.ari.cdk.hosting dn: dc=vmlab,dc=ari,dc=cdk,dc=hosting objectClass: dcObject objectClass: organization dc: vmlab o: vmlab # Users, vmlab.ari.cdk.hosting dn: ou=Users,dc=vmlab,dc=ari,dc=cdk,dc=hosting objectClass: organizationalUnit ou: Users # Steve xxxxxxxxx, Users, vmlab.ari.cdk.hosting dn: cn=Steve Murdoch,ou=Users,dc=vmlab,dc=ari,dc=cdk,dc=hosting cn: Steve xxxxxxxx sn: xxxxxxxx objectClass: inetOrgPerson userPassword:: cEBzc3cwcmQ= uid: sxxxxxxxx # Bob Jones, Users, vmlab.ari.cdk.hosting dn: cn=Bob Jones,ou=Users,dc=vmlab,dc=ari,dc=cdk,dc=hosting cn: Bob Jones sn: Jones objectClass: inetOrgPerson userPassword:: cEBzc3cwcmQ= uid: bjones # Tom xxxxxxxx, Users, vmlab.ari.cdk.hosting dn: cn=Tom xxxxxxxx,ou=Users,dc=vmlab,dc=ari,dc=cdk,dc=hosting cn: Tom xxxxxxxx sn: xxxxxxxx objectClass: inetOrgPerson userPassword:: cEBzc3cwcmQ= uid: txxxxxxxx # Max xxxxxxxx, Users, vmlab.ari.cdk.hosting dn: cn=Max xxxxxxxx,ou=Users,dc=vmlab,dc=ari,dc=cdk,dc=hosting cn: Max xxxxxxxx sn: xxxxxxxx objectClass: inetOrgPerson userPassword:: cEBzc3cwcmQ= uid: mxxxxxxxx # Platform, Users, vmlab.ari.cdk.hosting dn: cn=Platform,ou=Users,dc=vmlab,dc=ari,dc=cdk,dc=hosting cn: Platform objectClass: groupOfNames member: cn=Bob Jones,cn=Steve xxxxxxxx,cn=Tom xxxxxxxx,cn=Max xxxxxxxx,ou=Users ,dc=vmlab,dc=ari,dc=cdk,dc=hosting member: cn=Rod Stewart,ou=Users,dc=vmlab,dc=ari,dc=cdk,dc=hosting member: cn=Steve xxxxxxxx,ou=Users,dc=vmlab,dc=ari,dc=cdk,dc=hosting member: cn=Tom xxxxxxxx,ou=Users,dc=vmlab,dc=ari,dc=cdk,dc=hosting # mpitman, Users, vmlab.ari.cdk.hosting dn: uid=mxxxxxxxx,ou=Users,dc=vmlab,dc=ari,dc=cdk,dc=hosting cn: Mike xxxxxxxx sn: xxxxxxxx objectClass: inetOrgPerson userPassword:: cEBzc3cwcmQ= uid: mxxxxxx # root, Users, vmlab.ari.cdk.hosting dn: uid=root,ou=Users,dc=vmlab,dc=ari,dc=cdk,dc=hosting cn: root sn: root objectClass: inetOrgPerson userPassword:: cEBzc3cwcmQ= uid: root # search result search: 3 result: 0 Success # numResponses: 10 # Any help much appreciated - thanks a lot.

4 19

Re: disable ad backend group filtering? (was Re: Re: speeding up iterative enumeration?)
by James Ralston 27 Jan '16

27 Jan '16

On Wed, Jan 27, 2016 at 4:07 AM, Jakub Hrozek <jhrozek(a)redhat.com> wrote: > On Tue, Jan 26, 2016 at 05:50:06PM -0500, James Ralston wrote: > > > It's a long story, but what we are trying to do here is to take > > regular snapshots of our AD users and groups, and sssd's > > getpwnam()/getgrnam() mapping is the perfect way to do it. I > > think I understand why distribution groups are filtered by default > > (they're not security-enabled in AD, and can't be used in Windows > > ACLs), but in this one particular case, we really do want to be > > able to enumerate every single group. > > can you try setting: > ldap_group_type = nosuchattr > ? > > That should trick sssd into not seeing the group type at all and > would avoid filtering I guess (not tested). Unfortunately, this doesn't work: if sssd can't determine the group type, it filters ALL groups, instead of filtering no groups. Hmmm. If sssd can't determine the group type, wouldn't it be better to filter no groups, instead of all groups? Because filtering all groups is essentially the same thing as disabling group lookups entirely. That doesn't seem like the best behavior to choose. Then again, maybe a cleaner approach would be to add a ldap_group_filtering option, and make the default value true (filter groups that aren't security groups)? Tricking sssd by telling it to look at the wrong field for the group type seems like a hack. :-(

2 1

disable ad backend group filtering? (was Re: Re: speeding up iterative enumeration?)
by James Ralston 27 Jan '16

27 Jan '16

On Tue, Jan 26, 2016 at 3:03 PM, Jakub Hrozek <jhrozek(a)redhat.com> wrote: > On Tue, Jan 26, 2016 at 02:19:42PM -0500, James Ralston wrote: > >> Here's the problem: unless the user/group objects already happen to be >> in sssd's cache, enumerating the passwd/group entries in this way is >> very slow: 3-5 entries per second, at best. For a larger AD domain, >> the program can take 10-15 minutes to perform this iterative >> enumeration, which is much longer than we'd prefer. >> >> Can anyone think of a way to make this iterative enumeration go >> faster? > > Did you try mounting the cache to tmpfs to get rid of the cache writes? > > [...] That's… a very clever idea. From testing using tmpfs to back /var/lib/sss/db, the speed of lookups increases by about an order of magnitude: about 44 lookups per second, instead of 4-5 lookups per second. We have around 5,000 AD objects, so the ~100 second wait would be tolerable. A related question: is there any possibility of adding an option to the ad backend to disable the filtering of distribution groups (group type flag 0x8)? It's a long story, but what we are trying to do here is to take regular snapshots of our AD users and groups, and sssd's getpwnam()/getgrnam() mapping is the perfect way to do it. I think I understand why distribution groups are filtered by default (they're not security-enabled in AD, and can't be used in Windows ACLs), but in this one particular case, we really do want to be able to enumerate every single group.

4 8

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users January 2016