sssd-users February 2014

sssd-users@lists.fedorahosted.org

17 participants
14 discussions

Connection to ad via ldap failing
by Nordgren, Bryce L -FS 17 Feb '14

17 Feb '14

Well, I guess the title is a little misleading. The ldap connection is working like a champ. I configured sssd to bind using my own credentials, and that's working. The searches are successful and return the correct result. Things I don't understand: * Sssd performs two ldap searches for my username, not one. * Using wireshark, I don't even see it trying to bind to AD using the account it finds (twice). * sssd fails to authenticate me, but the logs seems to indicate to me that everything it tried succeeded. This is on a VM with a minimal install of Fedora 19. The setup roughly follows https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%2… with local modifications to enable id mapping. I'm attaching edited versions of sssd.conf, sssd_pam.log, sssd_nss.log, and the output of wireshark (stupidly named sssd.log.) pam and nss are both at debug level 9. Does anyone have any suggestions as to what I should try? Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.

3 16

SSSD 1.8.x with samba4 DC
by Richard Connon 17 Feb '14

17 Feb '14

Hi, I'm using sssd 1.8.4 (debian package) as a client for a samba4 domain, currently with one DC. The domain has unix UIDs and GIDs stored so no idmapping is required. The config I have (so far) is this: [sssd] config_file_version = 2 services = nss, pam domains = DOMAIN [nss] [pam] [domain/DOMAIN] auth_provider = krb5 chgpass_provider = krb5 dns_search_domain = ads.domain.tld id_provider = ldap krb5_realm = ADS.DOMAIN.TLD ldap_sasl_authid = HOST$(a)ADS.DOMAIN.TLD ldap_sasl_mech = GSSAPI ldap_schema = rfc2307bis ldap_user_name = sAMAccountName So far NSS seems to be working (kind of) but is very slow to retrieve each user/group the first time and is very slow for queries where the user/group does not exist. The only messages appearing in any relevant logs are the following 2: In sssd_DOMAIN.log: (Fri Feb 14 18:07:37 2014) [sssd[be[DOMAIN]]] [load_backend_module] (0x0010): Error (2) in module (ldap) initialization (sssm_ldap_autofs_init)! In syslog file auth.log: Feb 14 19:20:06 unifi sssd_be: GSSAPI Error: Miscellaneous failure (see text) (Matching credential (ldap/ads.domain.tld(a)DOMAIN.TLD) not found) The former seems to be quite harmless but the latter repeats quite frequently and seems to suggest SSSD is trying to use an invalid kerberos ticket for the LDAP connection. This principal name is invalid for two reasons, first there is no LDAP service on "ads.domain.tld" it is on "dc02.ads.domain.tld", second "DOMAIN.TLD" is not the name of my realm, it is "ADS.DOMAIN.TLD" Does anyone have any idea what causes the latency in responding to NSS queries and whether I need to worry about the GSSAPI errors? Finally I have not yet succeeded in getting this setup to work for PAM. I haven't been able to try very easily due to the NSS latency issues. Thanks in advance, Richard

4 8

Auth not working with OpenDJ backend LDAP server
by Ganesh Hariharan 13 Feb '14

13 Feb '14

I configured the centos client with system-config-auth, essentially I need to login from terminal or over ssh with the username and credentials of my ldap server.... please help and below is the configuration [domain/default] ldap_id_use_start_tls = True cache_credentials = True ldap_search_base = dc=sysopminds,dc=com krb5_realm = EXAMPLE.COM krb5_server = kerberos.example.com id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_uri = ldaps://10.0.0.6 ldap_tls_cacertdir = /etc/openldap/cacerts [sssd] services = nss, pam config_file_version = 2 domains = default [nss] [pam] [sudo] [autofs] [ssh] [pac]

4 3

SSSD slow to start, slow to work
by Erinn Looney-Triggs 10 Feb '14

10 Feb '14

I have a RHEL 5.10 system running sssd version sssd-1.5.1-70.el5, SSSD is configured as a client of two IPA servers, config will be at the bottom. This thing has been chugging along for years at this point without issue, but performance hit the wall this morning and SSSD appears to be the issue. logins using kerberos are taking an extremely long time, I expect because of user data enumeration, sudo passwords are taking an extremely long time, su passwords etc. Cranking up debugging is not revealing anything glaring to my untrained eye. Running an anonymous ldapsearch against the IPA servers (suggested in debug documentation) is not possible as anonymous binds are disabled on the server end. Though the connection does go through enough to indicate that such is the case. As well restarting SSSD takes a very long time, ~1-2 minutes when compared with other systems on the same platform/hardware (seconds). Any folks have ideas? Please CC me as I am subscribed to the digest. Thanks, -Erinn Config: [sssd] config_file_version = 2 # Number of times services should attempt to reconnect in the # event of a crash or restart before they give up reconnection_retries = 3 debug_level = 10 # If a back end is particularly slow you can raise this timeout here sbus_timeout = 30 services = nss, pam domains = example.com [nss] # The following prevents SSSD from searching for the root user/group in # all domains (you can add here a comma-separated list of system accounts that # are always going to be /etc/passwd users, or that you want to filter out). filter_groups = root,apache filter_users = root,apache reconnection_retries = 3 [pam] reconnection_retries = 3 [domain/example.com] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = example.com id_provider = ipa auth_provider = ipa access_provider = ipa chpass_provider = ipa ipa_server = _srv_, ipa.example.com ldap_tls_cacert = /etc/ipa/ca.crt enumeration = true

3 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users February 2014