sssd-users July 2013

sssd-users@lists.fedorahosted.org

18 participants
15 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

Fwd: Use LDAPs for *_provider = ad
by Chris Hartman 06 Aug '13

06 Aug '13

On Tue, Jul 30, 2013 at 4:24 PM, Dmitri Pal <dpal(a)redhat.com> wrote: > MSFT is just paranoid about it. While you may be right, I think that an "ad" provider in SSSD implies that AD is supported no matter what configuration is being used on the server, especially if that configuration is "suggested" as indicated by the verbose log message. I imagine that this functionality would only need a few more configuration parameters to work. Namely, ldap_tls_*, ldap_service_port, maybe a few others? I believe SSSD supports GSSAPI over SSL/TLS when the provider is LDAP, so, to me, it's a matter of giving more fine-grain control in the configuration file when the provider is AD. -Chris

3 10

Using SSSD with Samab4 DC
by Chris Hayes 01 Aug '13

01 Aug '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone, My aim is to have consistent Active Directory Users/Groups to Unix UID/GID designations across several Linux machines joined to that domain. Ideally without explicitly setting these in the directory. After failing to get Winbind with a RID backend to work as desired, a Samba user suggested that I try using SSSD instead. For the last few hours I've been trying to get this to work; but without much luck. Right now I'm hitting a problem whereby SSSD's unable to find valid users because none of my directory users have the attribute "dataExpireTimestamp" and this is part of the search filter. (Wed Jul 31 00:21:58 2013) [sssd[be[DEVDOM]]] [sysdb_search_users] (0x0400): Search users with filter: (&(objectclass=user)(&(!(dataExpireTimestamp=0))(dataE xpireTimestamp<=1375226518)(!(lastLogin=*)))) (Wed Jul 31 00:21:58 2013) [sssd[be[DEVDOM]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x186bbc0 (Wed Jul 31 00:21:58 2013) [sssd[be[DEVDOM]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x186bce0 (Wed Jul 31 00:21:58 2013) [sssd[be[DEVDOM]]] [ldb] (0x4000): tevent: Destroying timer event 0x186bce0 "ltdb_timeout" (Wed Jul 31 00:21:58 2013) [sssd[be[DEVDOM]]] [ldb] (0x4000): tevent: Ending timer event 0x186bbc0 "ltdb_callback" (Wed Jul 31 00:21:58 2013) [sssd[be[DEVDOM]]] [sysdb_search_users] (0x0400): No such entry I've tried explicitly setting this without any luck. IT seems to be ignoring the following line. ldap_user_search_base = CN=Users,DC=devdom,DC=orange,DC=local?subtree?(objectCategory=User) And here's what I mean about that attribute affecting the search. First using the filter that SSSD is using, second time using one that doesn't reference the "dataExpireTimestamp" attribute. /usr/local/samba/bin/ldbsearch -H ldaps://192.168.1.33 '(&(objectclass=user)(&(!(dataExpireTimestamp=0))(dataExpireTimestamp<=1375224572))))' - -UAdministrator%XXX -b CN=Users,DC=devdom,DC=orange,DC=local # returned 0 records # 0 entries # 0 referrals /usr/local/samba/bin/ldbsearch -s sub -H ldaps://192.168.1.33 '(&(objectclass=user)(!(lastLogin=*)))' -UAdministrator%XXX -b CN=Users,DC=devdom,DC=orange,DC=local [...] # returned 5 records # 5 entries # 0 referrals I'm running SSSD version 1.8.4, and Samba4 version 4.0.6 as my Domain Controller. This is my current SSSD configuration (/etc/sssd/sssd.conf): [sssd] domains = DEVDOM services = nss, pam config_file_version = 2 reconnection_retries = 3 sbus_timeout = 30 [nss] filter_groups = root filter_users = root reconnection_retries = 3 [pam] offline_credentials_expiration = 0 reconnection_retries = 3 [domain/DEVDOM] debug_level = 9 description = LDAP domain with AD server id_provider = ldap auth_provider = krb5 ;auth_provider = ldap ldap_default_bind_dn = cn=Administrator,cn=Users,DC=devdom,DC=orange,DC=local ldap_default_authtok_type = password ldap_default_authtok = XXX ;ldap_user_object_class = person ;ldap_user_name = msSFU30Name ;ldap_user_uid_number = msSFU30UidNumber ;ldap_user_gid_number = msSFU30GidNumber ;ldap_user_home_directory = msSFU30HomeDirectory ;ldap_user_shell = msSFU30LoginShell ;ldap_user_principal = userPrincipalName ;ldap_group_object_class = group ;ldap_group_name = msSFU30Name ;ldap_group_gid_number = msSFU30GidNumber enumerate = TRUE ;cache_credentials = TRUE chpass_provider = krb5 ;tls_reqcert = demand ;ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt ldap_id_mapping = True ldap_idmap_default_domain_sid = S-1-5-21-2003857637-2616505931-2053645484 ldap_idmap_range_min = 70000 ldap_idmap_range_max = 7000000 ldap_schema = ad ;; kerberos config ;; auth_provider = krb5 krb5_server = hirst.devdom.orange.local krb5_realm = DEVDOM.ORANGE.LOCAL krb5_changepw_principle = kadmin/changepw krb5_ccachedir = /tmp krb5_ccname_template = FILE:%d/krb5cc_%U_XXXXXX krb5_auth_timeout = 15 ;cache_credentials = True ;; https://lists.fedorahosted.org/pipermail/sssd-devel/2012-May/009677.html ;; ldap_referrals = False ;ldap_search_base = CN=users,DC=devdom,DC=orange,DC=local ldap_user_search_base = CN=Users,DC=devdom,DC=orange,DC=local?subtree?(objectCategory=User) ;ldap_group_search_base = CN=Users,DC=devdom,DC=orange,DC=local??(objectCategory=User) Any ideas as to what could help would be really appreciated. Thanks for your time, - -- Chris Hayes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR+FM5AAoJELgO0A8EguAKbF0IAKIjfYwO2zFpuhmk97TgsV21 T/nFBTpMPbkv7qsELkI5E+s+E4xo66nowrVG2GYuO9DBQ1MxCjNamR8Py/8Qa9de 0CIcWzCKe1/SYLNmQ30AOcNxc1S0n3Z7rMTtXDUU/O7gj/v/qbb174lFnn+7+l9R B8MJ1YFmZUrgcJrs33X+antsIqcIfbQptXt1Z6CUH/qSFEmJ58fhE5fXeQJIw07n 9UxokKmE3HN19bIBwQQ1QHBskcg0oGqrRO/oHE9Jqb3y1CKZlvjsLFJlsi/9aUr2 lppZB9OECXSJyovQNj4R0QboU+AKkO6QNefrUyekUxws/OZNeU7PWCCQ8/HtdlY= =LP+G -----END PGP SIGNATURE-----

4 5

Use LDAPs for *_provider = ad
by Chris Hartman 30 Jul '13

30 Jul '13

Hi guys! Is there anyway I can force my SSSD clients running 1.9.5 (Ubuntu 12.04) and 1.9.2 (CentOS 6) to bind to LDAPs (port 636) instead of LDAP (port 389) when my providers are all set to "ad"? Consequently, I'll need to specify a certificate to be used to verify the server's authenticity. I'm using service discovery and have SRV records in place on my domain controllers. Here's my config: [sssd] config_file_version = 2 debug_level = 0 reconnection_retries = 3 sbus_timeout = 30 services = nss, pam domains = DOMAIN [pam] debug_level = 0 [nss] debug_level = 0 filter_users = root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm filter_groups = root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm reconnection_retries = 3 [domain/DOMAIN] debug_level = 0 ad_domain = DOMAIN.local id_provider = ad auth_provider = ad chpass_provider = ad access_provider = ad enumerate = true cache_credentials = true fallback_homedir = /home/%u dyndns_update = true dyndns_update_ptr = true ldap_schema = ad ldap_id_mapping = true Thanks! -Chris

4 9

kinit: Cannot find KDC...
by Bryan Harris 30 Jul '13

30 Jul '13

Hi all, I've followed the sssd page for connecting RHEL 6 to a Windows 2008 for authentication. It works on all our servers except one, and I'm getting confused. I've even gone as far as to clone a working VM and rename, give it a new ip address, etc. and even after that it still doesn't work (but just on that one machine). When I run kinit -k host/server.ad.domain.com(a)AD.DOMAIN.COM I get the following message: kinit: Cannot find KDC for requested realm while getting initial credentials Whereas on other servers running that same command just works. Has anyone experienced this before? All server are configured the same but one server doesn't work. Here is my krb5.conf file, and the commands I used to generate the keytab. I can post logs I'll just have to sanitize them first. [logging] default = FILE:/var/log/krb5libs.log [libdefaults] default_realm = AD.DOMAIN.COM dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h renew_lifetime = 7d rdns = false forwardable = yes [realms] [domain_realm] setspn -A host/server.ad.domain.com(a)AD.DOMAIN.COM server setspn -L server ktpass /princ host/server.ad.domain.com(a)AD.DOMAIN.COM /out server-host.keytab /crypto all /ptype KRB5_NT_PRINCIPAL -desonly /mapuser CNOC\server$ /pass * Any help would be greatly appreciated. Bryan

3 4

Re: [SSSD-users] Not finding /usr/lib64/libsss_sudo.so on RHEL V6.4
by Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) 29 Jul '13

29 Jul '13

Ok...that did it. I installed libsss_sudo-1.9.2-82.el6.x86_64.rpm on two different RHEL V6.4 systems and now sudo is working through sssd and our ldap server. But I am not finding this library in the RHEL V6.3 distro, so does that mean sudo with sssd can not be used in Red Hat prior to V6.4 ? I tried installing the sssd-1.9.2* on a v6.3 system and it failed with gobs of missing dependencies. Al Licause From: Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) Sent: Wednesday, July 24, 2013 11:06 AM To: 'End-user discussions about the System Security Services Daemon' Subject: RE: Not finding /usr/lib64/libsss_sudo.so on RHEL V6.4 Guess I should look before asking. I found the following rpm that was not installed on my systems: libsss_sudo-1.9.2-82.el6.x86_64.rpm I guess I'll try to install that and give it shot. Al Licause From: Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) Sent: Wednesday, July 24, 2013 11:03 AM To: 'End-user discussions about the System Security Services Daemon' Subject: RE: Not finding /usr/lib64/libsss_sudo.so on RHEL V6.4 I guess I should have mentioned that I have the following installed: sudo-1.8.6p3-7.el6.x86_64 Al Licause From: Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) Sent: Wednesday, July 24, 2013 10:57 AM To: 'End-user discussions about the System Security Services Daemon' Subject: Not finding /usr/lib64/libsss_sudo.so on RHEL V6.4 I thought I had this working only to realize on the two systems it appeared to be working, I was actually using the local sudoers file. Now that I have that and a few other nits covered, I think I almost have this working but when the ldap user attempts to sudo, they get the following: $ sudo date sudo: Unable to dlopen /usr/lib64/libsss_sudo.so: (null) sudo: Unable to initialize SSS source. Is SSSD installed on your machine? We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: #1) Respect the privacy of others. #2) Think before you type. #3) With great power comes great responsibility. [sudo] password for ldap33: So my question is....where do I find the libsss_sudo.so library ? And which RPM was supposed to contain and install this component ? Al Licause

5 19

Re: [SSSD-users] Not finding /usr/lib64/libsss_sudo.so on RHEL V6.4
by Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) 24 Jul '13

24 Jul '13

Guess I should look before asking. I found the following rpm that was not installed on my systems: libsss_sudo-1.9.2-82.el6.x86_64.rpm I guess I'll try to install that and give it shot. Al Licause From: Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) Sent: Wednesday, July 24, 2013 11:03 AM To: 'End-user discussions about the System Security Services Daemon' Subject: RE: Not finding /usr/lib64/libsss_sudo.so on RHEL V6.4 I guess I should have mentioned that I have the following installed: sudo-1.8.6p3-7.el6.x86_64 Al Licause From: Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) Sent: Wednesday, July 24, 2013 10:57 AM To: 'End-user discussions about the System Security Services Daemon' Subject: Not finding /usr/lib64/libsss_sudo.so on RHEL V6.4 I thought I had this working only to realize on the two systems it appeared to be working, I was actually using the local sudoers file. Now that I have that and a few other nits covered, I think I almost have this working but when the ldap user attempts to sudo, they get the following: $ sudo date sudo: Unable to dlopen /usr/lib64/libsss_sudo.so: (null) sudo: Unable to initialize SSS source. Is SSSD installed on your machine? We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: #1) Respect the privacy of others. #2) Think before you type. #3) With great power comes great responsibility. [sudo] password for ldap33: So my question is....where do I find the libsss_sudo.so library ? And which RPM was supposed to contain and install this component ? Al Licause

1 0

Re: [SSSD-users] Not finding /usr/lib64/libsss_sudo.so on RHEL V6.4
by Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) 24 Jul '13

24 Jul '13

I guess I should have mentioned that I have the following installed: sudo-1.8.6p3-7.el6.x86_64 Al Licause From: Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) Sent: Wednesday, July 24, 2013 10:57 AM To: 'End-user discussions about the System Security Services Daemon' Subject: Not finding /usr/lib64/libsss_sudo.so on RHEL V6.4 I thought I had this working only to realize on the two systems it appeared to be working, I was actually using the local sudoers file. Now that I have that and a few other nits covered, I think I almost have this working but when the ldap user attempts to sudo, they get the following: $ sudo date sudo: Unable to dlopen /usr/lib64/libsss_sudo.so: (null) sudo: Unable to initialize SSS source. Is SSSD installed on your machine? We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: #1) Respect the privacy of others. #2) Think before you type. #3) With great power comes great responsibility. [sudo] password for ldap33: So my question is....where do I find the libsss_sudo.so library ? And which RPM was supposed to contain and install this component ? Al Licause

1 0

Not finding /usr/lib64/libsss_sudo.so on RHEL V6.4
by Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) 24 Jul '13

24 Jul '13

I thought I had this working only to realize on the two systems it appeared to be working, I was actually using the local sudoers file. Now that I have that and a few other nits covered, I think I almost have this working but when the ldap user attempts to sudo, they get the following: $ sudo date sudo: Unable to dlopen /usr/lib64/libsss_sudo.so: (null) sudo: Unable to initialize SSS source. Is SSSD installed on your machine? We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: #1) Respect the privacy of others. #2) Think before you type. #3) With great power comes great responsibility. [sudo] password for ldap33: So my question is....where do I find the libsss_sudo.so library ? And which RPM was supposed to contain and install this component ? Al Licause

1 0

Announcing SSSD 1.11 beta 2
by Jakub Hrozek 24 Jul '13

24 Jul '13

=== SSSD 1.11 beta 2 === The SSSD team is proud to announce the second beta release of version 1.11 of the System Security Services Daemon. This pre-release does not bring substantial changes visible to the end-user. It is intended to be part of the development of FreeIPA 3.3 and its focus of supporting legacy (non-SSSD) clients in a setup where IPA server established a trust relationship with an Active Directory clients. A Fedora Test Day aimed at exercising the new features is planned for July 25th. See the Test Day page for more information: https://fedoraproject.org/wiki/Test_Day:2013-07-25_AD_trusts_with_POSIX_att… As always, the source is available from https://fedorahosted.org/sssd. == Feedback == Please provide comments, bugs and other feedback via the sssd-devel or sssd-users mailing lists: https://lists.fedorahosted.org/mailman/listinfo/sssd-devel https://lists.fedorahosted.org/mailman/listinfo/sssd-users == Highlights == * Includes several fixes related to setup where the SSSD is running on IPA client in a special "server mode". * The default DNS timeouts have been tweaked in order to allow the c-ares resolver to cycle through all available name servers * The pysss module now contains a new method `getgroupslist` that provides a Python interface to the POSIX `getgroupslist(3)` call * The sss_debuglevel tool is now able to change debug level of all responders, including PAC or autofs == Tickets Fixed == https://fedorahosted.org/sssd/ticket/1965 man: document that the default access provider in AD provider is "permit" https://fedorahosted.org/sssd/ticket/1988 [RFE] sss_cache has no option to clear all cached entries of all types https://fedorahosted.org/sssd/ticket/1997 When resolving a SID, search for groups first, then users https://fedorahosted.org/sssd/ticket/1998 sssd-ad man page states that ad_server can be an IP address even though SSSD doesn't support that https://fedorahosted.org/sssd/ticket/2005 SSSD filter out ldap user/group if uid/gid is zero https://fedorahosted.org/sssd/ticket/2009 Disallow or warn if full_name_format is set to a non-default value when IPA server mode is on https://fedorahosted.org/sssd/ticket/2023 AD provider in server mode follows referrals https://fedorahosted.org/sssd/ticket/2025 pysss module linking is broken == Documentation Changes == * The dns_resolver_timeout option default value was changed from 5 to 6 seconds. At the same time, the timeout that controls how long the internal resolver communicates with a single DNS server was changed to 2 seconds. This change would allow the resolver to cycle through up to 3 nameservers until the `dns_resolver_timeout` fires. * the sss_cache utility gained a new option -E. This option is a shortcut to tell sss_cache to invalidate all entries in the cache. Please note that invalidating sudo rules is still not implemented as it requires cooperation with the back end as well. == Detailed Changelog == This changelog does not include commits already released in 1.10.1 release. To see all changes since 1.11 beta2, run: $ git shortlog sssd-1_11_0_beta1..sssd-1_11_0_beta2 from a directory that contains the SSSD git checkout. Alexander Bokovoy (3): * build: fix dependencies for pysss module * pysss: add pysss.getgrouplist(username) * pysss: prevent crashing when group is unresolvable Jakub Hrozek (13): * Bumping the version for the 1.11 beta2 release * LDAP: When resolving a SID, search for groups first, then users * MAN: clarify the default access provider for AD * MAN: IP addresss does not work when used for ad_server * MAN: Clarify the min_id/max_id limits further * Remove unused be_ctx->sigchld_ctx * IPA: warn if full_name_format is customized in server mode * AD: Set the bool value same as default value in opts * Fix the default FQDN format * SUDO: realloc with sizeof(uint32_t) when adding uint32_t * KRB5: Do not send PAC in server mode * LDAP: Use domain-specific name where appropriate * Updating translations for the 1.11 beta2 release Lukas Slebodnik (11): * BUILD: Use pkg-config to detect cmocka * Use conditional build for retrieving ccache. * Remove unused function parameter * Fix clang format string warning. * Use functionm ldb_dn_get_linearized to format struct ldb_dn * Add mising argument required by format string * Remove unused memory context from function unpack_authtok * Fix warnings: uninitialized variable * Fix autotols warnings: macro xyz not found in library * Fix possible dereference of a NULL pointer. * Every time release allocated memory in function py_sss_getgrouplist Michal Zidek (5): * sss_cache: Add option to invalidate all entries * Missing space in debug message * Remove unused constant. * Set default DNS resolution timeout to 6 seconds. * Lower timeout to contact DNS server Ondrej Kos (1): * TOOLS: Update all services with sss_debuglevel Pavel Březina (1): * remove unused variable

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users July 2013