sssd-users July 2014

sssd-users@lists.fedorahosted.org

26 participants
17 discussions

ldap_sasl_mech EXTERNAL and SSL client authc
by Michael Ströder 18 Mar '15

18 Mar '15

HI! Is it possible to use SASL/EXTERNAL when connecting to a LDAP server with StartTLS or LDAPS using client certs? In a project they have certs in all systems anyway (because of using puppet) and I'd like to let the sssd instances on all the systems authenticate to the LDAP server to restrict visibility of LDAP entries by ACL. I'd like to avoid having to set/configure passwords for each system's sssd. Ciao, Michael.

5 22

Startup segfault loop of domain_be on Ubuntu 14.04
by Chris Hartman 22 Aug '14

22 Aug '14

Hi guys, Ubuntu 14.04 x86_64 SSSD 1.11.5 Active Directory backend I've been experiencing this problem for a few weeks with no luck in troubleshooting it. During boot, the sssd_be process will continually spawn and crash due to a segfault. When it gets stuck in this loop, domain account login is almost impossible (local accounts still work). I've attached sanitized logs and my sssd.conf file. Please have a look and let me know what you think. Thanks! -Chris

4 17

SSSD with AD provider - can't obtain group information in subdomain
by 杉山昌治 06 Aug '14

06 Aug '14

Hello I'm struggle with configuration of sssd to retrieve group information defined in a subdomain. I would have your support to solve my issue. Here is my AD configuration. There are 3 AD servers. Root Domain labroot.example.com (just for top AD management) Sub Domain labsso.labroot.example.com (user, global group and universal group are defined here) Subsub Domain labbu.labsso.labroot.example.com (local domain group is defined here) I created a user and groups in those AD servers as below. User/Groups in Domain sso.example.com ======================== User test_user (MemberOf=G-Group-Server) Group G-Role-ISOps-Server (Type: Global Group, Members=test_user, MemberOf=U-Role-ISOps-Server) Group U-Role-ISOps-Server (Type: Universal Group, Members=G-Role-ISOps-Server) User/Groups in Domain sso.example.com ======================== Group D-Role-Server (Type: Domain Local Group, Members=U-Role-ISOps-Server) As for SSSD, I tried to use both "1.11.6" and "1.12.1" with "AD provider" as backend. I expected to get all groups (G-Role-ISOps-Server, U-Role-ISOps-Server and D-ISOps-Server) as a result of "id test_user" command. But I could not find domain local group (D-Role-ISOps-Server) in groups of the user "test_user". as the result of "id test_user" command. I also could not find any members as the result of "getent group D-Role-ISOps-Server" command. I tried to use single domain (sso-ad-ad) and multiple domains (sso-ad-ad and bu-ad-ad) in sssd configuration, but the result is the almost same. (when I use sso-ad-ad domain only, I could not get anything as result of "getent group d-role-isops-server"). # id test_user uid=638201126(test_user) gid=638200513(domain users) groups=638200513(domain users),638201113(g-role-server),638201118(u-role-server),638200512(domain admins) # getent group d-role-isops-server d-role-isops-server:*:927601110: I'm not sure how SSSD AD provider searches group information based on members/memberOf attributes, I suspect missing "memberOf" in universal group (U-Role-*) and "member of domain local group" (U-Role-ISOps-Server) is out of scope of LABBU domain might be clue of my issue. Please advise me what's wrong on my configuration and resolution of my issue. Thanks in advance. Shoji *** Configurations and LDAP search results *** sssd.conf file ========== [sssd] config_file_version = 2 services = nss, pam domains = sso-ad-ad, bu-ad-ad # domains = sso-ad-ad [nss] fallback_homedir = /home/SSO/%u default_shell = /bin/bash [pam] [domain/sso-ad-ad] id_provider = ad auth_provider = ad access_provider = ad ad_server = jpbw0-in00-is82.labsso.labroot.isops.example.com ad_hostname = jpbw0-in00-is82.labsso.labroot.isops.example.com ldap_schema = ad ad_enable_gc = true ldap_id_mapping = true debug_level = 1 [domain/bu-ad-ad] id_provider = ad auth_provider = ad chpass_provider = ad ad_server = jpbw0-in00-is81.labbu.labsso.labroot.isops.example.com ad_hostname = jpbw0-in00-is81.labbu.labsso.labroot.isops.example.com ldap_id_mapping = true debug_level = 1 LDAP Search in Global Catalog of LABSSO ================================== I can search the domain local group in the global catalog. [root@jpbl0-in00-is11 providers]# ldapsearch -Y GSSAPI -LLL -H "ldap:// jpbw0-in00-is82.labsso.labroot.isops.example.com:3268" -b "DC=labsso,DC=labroot,DC=isops,DC=example,DC=com" "(&(name=d-role-isops-server)(objectclass=group)(name=*))" SASL/GSSAPI authentication started SASL username: host/ jpbl0-in00-is11.lab.isops.ibm.com(a)LABSSO.LABROOT.ISOPS.EXAMPLE.COM SASL SSF: 56 SASL data security layer installed. dn: CN=D-Role-ISOps-Server,OU=BU0-ISOps,OU=Roles,DC=labbu,DC=labsso,DC=labroot,DC=isops,DC=example,DC=com objectClass: top objectClass: group cn: D-Role-ISOps-Server description: Server Team distinguishedName: CN=D-Role-ISOps-Server,OU=BU0-ISOps,OU=Roles,DC=labbu,DC=labsso,DC=labroot,DC=isops,DC=example,DC=com instanceType: 0 whenCreated: 20131029185150.0Z whenChanged: 20131029185448.0Z uSNCreated: 17964 uSNChanged: 18034 name: D-Role-ISOps-Server objectGUID:: YflnJQk4IUK4YUAHO43J6w== objectSid:: AQUAAAAAAAUVAAAAml0mRju+InNXWri7VgQAAA== sAMAccountName: D-Role-ISOps-Server sAMAccountType: 536870912 groupType: -2147483644 objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=labroot,DC=isops,DC=example,DC=com dSCorePropagationData: 16010101000000.0Z LDAP Search in LABSSO ==================== I can not search the domain local group in normal domain. [root@jpbl0-in00-is11]# ldapsearch -Y GSSAPI -LLL -H "ldap:// jpbw0-in00-is82.labsso.labroot.isops.example.com" -b "DC=labsso,DC=labroot,DC=isops,DC=example,DC=com" "(&(name=d-role-isops-server)(objectclass=group)(name=*))" SASL/GSSAPI authentication started SASL username: host/ jpbl0-in00-is11.lab.isops.example.com(a)LABSSO.LABROOT.ISOPS.EXAMPLE.COM SASL SSF: 56 SASL data security layer installed. # refldap:// labbu.labsso.labroot.isops.example.com/DC=labbu,DC=labsso,DC=labroot, DC=isops,DC=example,DC=com # refldap:// DomainDnsZones.labsso.labroot.isops.example.com/DC=DomainDnsZones,DC= labsso,DC=labroot,DC=isops,DC=example,DC=com

2 11

Problems with High RIDs in large Active Directory environment
by Thomas Moore 31 Jul '14

31 Jul '14

I work in an Active Directory environment where new SIDs have RIDs over 280,000 when attempting to set ldap_idmap_range_size in sssd.conf anything larger that 268204 causes the following errors in the log file (Wed Jul 30 10:38:44 2014) [sssd[be[DOMAIN.EDU]]] [load_backend_module] (0x0010): Error (5) in module (ad) initialization (sssm_ad_id_init)! (Wed Jul 30 10:38:44 2014) [sssd[be[DOMAIN.EDU]]] [be_process_init] (0x0010): fatal error initializing data providers (Wed Jul 30 10:38:44 2014) [sssd[be[DOMAIN.EDU]]] [main] (0x0010): Could not initialize backend [5] I have tested in both Ubuntu 14.04 and CentOS 7.0 with the same results. Any help is greatly appreciated!

2 2

sssd services terminated
by Daniel Jung 30 Jul '14

30 Jul '14

Hi, Running centos 6 with sssd-1.8.0-32.el6.x86_64 and sssd-client-1.8.0-32.el6.x86_64. This particular problem seems to pop now and then. I looked thru the maillist/googled and there seems to be number of posts with similar symptoms, but didnt see exact bug number or recommended actions to resolve this issue. Could you advise please? The problem resolved after restarting sssd. sssd.log (Tue Jul 29 16:46:06 2014) [sssd] [mt_svc_sigkill] (0x0010): [LDAP][22259] is not responding to SIGTERM. Sending SIGKILL. (Tue Jul 29 16:48:18 2014) [sssd] [mt_svc_sigkill] (0x0010): [nss][22262] is not responding to SIGTERM. Sending SIGKILL. (Tue Jul 29 16:48:18 2014) [sssd] [mt_svc_exit_handler] (0x0010): Process [nss], definitely stopped! (Tue Jul 29 19:01:17 2014) [sssd] [monitor_quit] (0x0010): Monitor received Terminated: terminating children sssd_nss.log (Tue Jul 29 16:48:18 2014) [sssd[nss]] [sss_dp_init] (0x0010): Failed to connect to monitor services. (Tue Jul 29 16:48:18 2014) [sssd[nss]] [sss_process_init] (0x0010): fatal error setting up backend connector (Tue Jul 29 16:48:18 2014) [sssd[nss]] [sss_dp_init] (0x0010): Failed to connect to monitor services. (Tue Jul 29 16:48:18 2014) [sssd[nss]] [sss_process_init] (0x0010): fatal error setting up backend connector (Tue Jul 29 16:48:18 2014) [sssd[nss]] [sss_dp_init] (0x0010): Failed to connect to monitor services. (Tue Jul 29 16:48:18 2014) [sssd[nss]] [sss_process_init] (0x0010): fatal error setting up backend connector sssd_LDAP.log (Tue Jul 29 16:48:18:940606 2014) [sssd[be[LDAP]]] [confdb_get_domain_internal] (0x0020): No enumeration for [LDAP]! (Tue Jul 29 16:48:19:181330 2014) [sssd[be[LDAP]]] [be_process_init] (0x0020): No Session module provided for [LDAP] !! (Tue Jul 29 16:48:19:181468 2014) [sssd[be[LDAP]]] [be_process_init] (0x0020): No host info module provided for [LDAP] !! (Tue Jul 29 16:48:19:181550 2014) [sssd[be[LDAP]]] [main] (0x0020): Backend provider (LDAP) started! (Tue Jul 29 19:01:17:891413 2014) [sssd[be[LDAP]]] [confdb_get_domain_internal] (0x0020): No enumeration for [LDAP]! (Tue Jul 29 19:01:17:934694 2014) [sssd[be[LDAP]]] [be_process_init] (0x0020): No Session module provided for [LDAP] !! (Tue Jul 29 19:01:17:934781 2014) [sssd[be[LDAP]]] [be_process_init] (0x0020): No host info module provided for [LDAP] !! (Tue Jul 29 19:01:17:934831 2014) [sssd[be[LDAP]]] [main] (0x0020): Backend provider (LDAP) started!

2 3

rpc.gssd vs gssproxy
by Ondrej Valousek 23 Jul '14

23 Jul '14

Hi List, Sorry for the bit OT question. How do I enable gssproxy on F20? When I enable USE_GSSPROXY in /etc/sysconfig/nfs and systemctl start nfs-secure, rpc.gssd is started instead :( Same story in CentOS 7 Thanks, Ondrej

3 3

SSSD current config dump
by Felipe Pereira 22 Jul '14

22 Jul '14

Is there a way to dump all config settings? I'd like to know the defaults configured for everything I didn't set in the sssd.conf. tia -- Felipe

7 9

sssd_sudo receives 0 rules but ldap search returns 5, what is wrong?
by Teemu Keinonen 22 Jul '14

22 Jul '14

Hello, I’m configuring CentOS 6.5 server to authenticate users and sudo rights against local Samba 4.1.8 (compiled from source). Sssd is 1.9.2 from package repository. User authentication works OK, I can log in with user that exists only in Samba but sudoing with the same user fails. After hours of trying I still can’t get it right, sssd_sudo receives 0 rules from samba. Doing ldapsearch with criteria from logs do return sudoer entries as below. Am I missing something obvious? Below are (in order) ldapsearch, ssssd.conf and sssd_default.log (part which I think relevant). [root@dc1 sssd]# ldapsearch -h dc1 -Y GSSAPI -b OU=SUDOers,DC=teemu,DC=local '(&(objectClass=sudoRole)(|(!(sudoHost=*))(sudoHost=ALL)(sudoHost=Host01)(sudoHost=Host01.example.com)(sudoHost=192.168.0.21)(sudoHost=192.168.0.0/24)(sudoHost=fe80::786b:f4ff:fe87:3314)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*\\*)(sudoHost=*?*)(sudoHost=*\**)(sudoHost=*[*]*))))' SASL/GSSAPI authentication started SASL username: administrator(a)TEEMU.LOCAL SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <OU=SUDOers,DC=teemu,DC=local> with scope subtree # filter: (&(objectClass=sudoRole)(|(!(sudoHost=*))(sudoHost=ALL)(sudoHost=Host01)(sudoHost=Host01.example.com)(sudoHost=192.168.0.21)(sudoHost=192.168.0.0/24)(sudoHost=fe80::786b:f4ff:fe87:3314)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*\\*)(sudoHost=*?*)(sudoHost=*\**)(sudoHost=*[*]*)))) # requesting: ALL # # defaults, SUDOers, teemu.local dn: CN=defaults,OU=SUDOers,DC=teemu,DC=local objectClass: top objectClass: sudoRole cn: defaults description: Default sudoOption's go here instanceType: 4 whenCreated: 20140625194645.0Z whenChanged: 20140625194645.0Z uSNCreated: 3798 uSNChanged: 3798 name: defaults objectGUID:: vrCxbL/QkUGFyZWvELWj/w== objectCategory: CN=sudoRole,CN=Schema,CN=Configuration,DC=teemu,DC=local sudoOption: env_keep+=SSH_AUTH_SOCK distinguishedName: CN=defaults,OU=SUDOers,DC=teemu,DC=local # %wheel, SUDOers, teemu.local dn: CN=%wheel,OU=SUDOers,DC=teemu,DC=local objectClass: top objectClass: sudoRole cn: %wheel instanceType: 4 whenCreated: 20140626094147.0Z whenChanged: 20140626094147.0Z uSNCreated: 3800 uSNChanged: 3800 name: %wheel objectGUID:: jpGX5AmGUkimPw1yl+oZkA== objectCategory: CN=sudoRole,CN=Schema,CN=Configuration,DC=teemu,DC=local sudoUser: %wheel sudoHost: ALL sudoCommand: ALL distinguishedName: CN=%wheel,OU=SUDOers,DC=teemu,DC=local # reima, SUDOers, teemu.local dn: CN=reima,OU=SUDOers,DC=teemu,DC=local objectClass: top objectClass: sudoRole cn: reima instanceType: 4 whenCreated: 20140625194650.0Z whenChanged: 20140625194650.0Z uSNCreated: 3799 uSNChanged: 3799 name: reima objectGUID:: U1paZdVOSke2zmInSenFTg== objectCategory: CN=sudoRole,CN=Schema,CN=Configuration,DC=teemu,DC=local sudoUser: reima sudoHost: ALL sudoCommand: ALL distinguishedName: CN=reima,OU=SUDOers,DC=teemu,DC=local # search result search: 4 result: 0 Success # numResponses: 4 # numEntries: 3 Sssd.conf: [sssd] services = nss, pam, sudo config_file_version = 2 domains = default debug_level = 10 [nss] [pam] [sudo] debug_level = 10 [domain/default] debug_level = 10 id_provider = ldap sudo_provider = ldap ldap_schema = rfc2307bis ldap_referrals = false ldap_uri = ldap://dc1.teemu.local ldap_search_base = cn=Users,dc=teemu,dc=local ldap_sudo_search_base = ou=sudoers,dc=teemu,dc=local ldap_force_upper_case_realm = true # See man sssd-simple access_provider = simple # Uncomment to check for account expiration in DC # access_provider = ldap # ldap_access_order = expire # ldap_account_expire_policy = ad # Enumeration is discouraged for performance reasons. # enumerate = true ldap_default_bind_dn = cn=Administrator,cn=Users,dc=teemu,dc=local ldap_default_authtok = XXXXXX auth_provider = krb5 chpass_provider = krb5 ldap_sasl_mech = gssapi ldap_sasl_authid = dc1$(a)TEEMU.LOCAL krb5_realm = TEEMU.LOCAL krb5_server = dc1.teemu.local krb5_kpasswd = dc1.teemu.local ldap_krb5_keytab = /etc/krb5.sssd.keytab ldap_user_object_class = user ldap_user_name = samAccountName ldap_user_home_directory = unixHomeDirectory ldap_user_principal = userPrincipalName ldap_user_shell = loginShell ldap_group_object_class = group sssd_default.log: (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_sudo_refresh_connect_done] (0x0400): SUDO LDAP connection successful (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_sudo_load_sudoers_next_base] (0x0400): Searching for sudo rules with base [ou=sudoers,dc=teemu,dc=local] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=sudoRole)(|(!(sudoHost=*))(sudoHost=ALL)\ (sudoHost=dc1)(sudoHost=dc1)(sudoHost=10.0.2.15)(sudoHost=10.0.2.0/24)(sudoHost=192.168.1.1)(sudoHost=192.168.1.0/24)(sudoHost=fe80::a00:27ff:fede:ba44)(sudoHost=fe80::/6\ 4)(sudoHost=fe80::a00:27ff:fef3:dc1)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*\\*)(sudoHost=*?*)(sudoHost=*\**)(sudoHost=*[*]*))))][ou=sudoers,dc=teemu,dc=local]. (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoCommand] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoHost] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoUser] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoOption] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoRunAsUser] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoRunAsGroup] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoNotBefore] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoNotAfter] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoOrder] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uSNChanged] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 12 (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_process_result] (0x2000): Trace: sh[0xfed4e0], connected[1], ops[0xff7c20], ldap[0xfedba0] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_done] (0x1000): Total count [0] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_sudo_load_sudoers_process] (0x0400): Receiving sudo rules with base [ou=sudoers,dc=teemu,dc=local] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_sudo_load_sudoers_done] (0x0400): Received 0 rules

6 21

(no subject)
by Lance Reed 21 Jul '14

21 Jul '14

I am having a problem with sssd (1.9.2) and passwords expiration against IPA v.3.0.0-37. I have setup sssd to use IPA with LDAP not Kerberos since this is in EC2 and I don’t want to deal with assigning tickets to each ephemeral host. So far things are working great, with the one exception that due to IPA using “krbPasswordExpiration” instead of “shadowExpire” breaks the usage of expired passwords. I tried setting “ldap_pwd_policy = mit_kerberos”, which does allow expired passwords to be recognized, but then breaks the users ability to change passwords. I suspect it causes sssd to use al Kerberos code paths, which won’t work in this case. If anyone has any ideas on this I would appreciate and feedback. Thanks in advance. example conf [domain/LDAP] enumerate = true cache_credentials = True debug_level = 9 id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_schema = IPA ldap_uri = ldaps://ipa-use-1b.ec2.example.net ldap_user_search_base = dc=example,dc=net ldap_id_use_start_tls = true tls_reqcert = demand ldap_tls_cacert = /etc/ipa/ca.crt ldap_user_ssh_public_key = ipaSshPubKey #ldap_pwd_policy = shadow #ldap_user_shadow_expire = krbPasswordExpiration #ldap_pwd_policy = mit_kerberos [sssd] services = nss, pam, ssh config_file_version = 2 domains = LDAP [nss] [pam] [sudo] [autofs] [ssh] [pac]

3 2

Using sssd on HPC cluster without direct ldap access
by Jean-Baptiste Denis 17 Jul '14

17 Jul '14

Hello everybody, I've got an HPC cluster on a private network without access to our LDAP servers for reasons I don't have any influence on at the moment. Users connect to special nodes called submit nodes to submit (eh!) jobs on the cluster. Those nodes have access to the public facing network (hence our LDAP servers) and the cluster private network. At the moment, /etc/passwd /etc/group and /etc/shadow are simply dumped on all cluster nodes. I'd like to move away from this setup. How to update the submit nodes to use sssd with an ldap auth_provider should not cause any trouble. I'm concerned about the nodes accessible on the private network. I could configure submit nodes as ldap slaves, but there are security aspects in that setup I'd like to avoid. My question is quite simple : is there a way to leverage the "sssdified" submit nodes on other nodes using some kind of relay/proxy ? Any suggestion is welcome ! Jean-Baptiste

4 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users July 2014