sssd-users August 2013

sssd-users@lists.fedorahosted.org

24 participants
18 discussions

multiple domain support - Active Directory
by Ben H 14 Aug '13

14 Aug '13

What level of support is there for supporting multiple active directory domains that have trust relationships established with each other (either one/two/external/forest). If I have an environment with DomA <> DomB, it would currently appear that I would need to create two separate SSSD domains in my .conf file, one for each domain as well as create a computer account in each domain and associated keytab entries on the local host. In effect, the machine would be "joined" to two domains at once. Would this work? Is there another way where one can be joined only to a single domain and still authenticated trusted users? The only documentation I can find regarding AD and trusts involves IPA trusted domains. Thank you.

2 1

ldap bind fails
by Marcus Moeller 13 Aug '13

13 Aug '13

Hi all, I am trying to use the AD provider in order to connect a client to our Active Directory. I have to mention, that our DNS Setup is somewhat broken, so reverse lookups do not work by default. When I now try connect, with reverse lookups not working, I got an error: ... (Mon Aug 12 14:40:08 2013) [sssd[be[D.ETHZ.CH]]] [resolve_srv_send] (0x0200): The status of SRV lookup is resolved (Mon Aug 12 14:40:08 2013) [sssd[be[D.ETHZ.CH]]] [get_server_status] (0x1000): Status of server 'novo.d.ethz.ch' is 'name resolved' (Mon Aug 12 14:40:08 2013) [sssd[be[D.ETHZ.CH]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Mon Aug 12 14:40:08 2013) [sssd[be[D.ETHZ.CH]]] [be_resolve_server_process] (0x0200): Found address for server novo.d.ethz.ch: [172.31.65.60] TTL 938 (Mon Aug 12 14:40:08 2013) [sssd[be[D.ETHZ.CH]]] [sdap_kinit_kdc_resolved] (0x1000): KDC resolved, attempting to get TGT... (Mon Aug 12 14:40:08 2013) [sssd[be[D.ETHZ.CH]]] [create_tgt_req_send_buffer] (0x1000): buffer size: 43 (Mon Aug 12 14:40:08 2013) [sssd[be[D.ETHZ.CH]]] [set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt child (Mon Aug 12 14:40:08 2013) [sssd[be[D.ETHZ.CH]]] [write_pipe_handler] (0x0400): All data has been sent! (Mon Aug 12 14:40:08 2013) [[sssd[ldap_child[1917]]]] [main] (0x0400): ldap_child started. (Mon Aug 12 14:40:08 2013) [[sssd[ldap_child[1917]]]] [unpack_buffer] (0x1000): total buffer size: 43 (Mon Aug 12 14:40:08 2013) [[sssd[ldap_child[1917]]]] [unpack_buffer] (0x1000): realm_str size: 9 (Mon Aug 12 14:40:08 2013) [[sssd[ldap_child[1917]]]] [unpack_buffer] (0x1000): got realm_str: D.ETHZ.CH (Mon Aug 12 14:40:08 2013) [[sssd[ldap_child[1917]]]] [unpack_buffer] (0x1000): princ_str size: 18 (Mon Aug 12 14:40:08 2013) [[sssd[ldap_child[1917]]]] [unpack_buffer] (0x1000): got princ_str: ldapmap1/d.ethz.ch (Mon Aug 12 14:40:08 2013) [[sssd[ldap_child[1917]]]] [unpack_buffer] (0x1000): keytab_name size: 0 (Mon Aug 12 14:40:08 2013) [[sssd[ldap_child[1917]]]] [unpack_buffer] (0x1000): lifetime: 86400 (Mon Aug 12 14:40:08 2013) [[sssd[ldap_child[1917]]]] [ldap_child_get_tgt_sync] (0x0100): Principal name is: [ldapmap1/d.ethz.ch(a)D.ETHZ.CH] (Mon Aug 12 14:40:08 2013) [[sssd[ldap_child[1917]]]] [ldap_child_get_tgt_sync] (0x0100): Using keytab [default] (Mon Aug 12 14:40:08 2013) [[sssd[ldap_child[1917]]]] [prepare_response] (0x0400): Building response for result [0] (Mon Aug 12 14:40:08 2013) [[sssd[ldap_child[1917]]]] [pack_buffer] (0x1000): result [0] krberr [0] msgsize [37] msg [FILE:/var/lib/sss/db/ccache_D.ETHZ.CH] (Mon Aug 12 14:40:08 2013) [[sssd[ldap_child[1917]]]] [main] (0x0400): ldap_child completed successfully (Mon Aug 12 14:40:08 2013) [sssd[be[D.ETHZ.CH]]] [read_pipe_handler] (0x0400): EOF received, client finished (Mon Aug 12 14:40:08 2013) [sssd[be[D.ETHZ.CH]]] [sdap_get_tgt_recv] (0x0400): Child responded: 0 [FILE:/var/lib/sss/db/ccache_D.ETHZ.CH], expired on [1376347208] (Mon Aug 12 14:40:08 2013) [sssd[be[D.ETHZ.CH]]] [sdap_cli_auth_step] (0x0100): expire timeout is 900 (Mon Aug 12 14:40:08 2013) [sssd[be[D.ETHZ.CH]]] [sdap_cli_auth_step] (0x1000): the connection will expire at 1376312108 (Mon Aug 12 14:40:08 2013) [sssd[be[D.ETHZ.CH]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: gssapi, user: ldapmap1/d.ethz.ch (Mon Aug 12 14:40:08 2013) [sssd[be[D.ETHZ.CH]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-2)[Local error] (Mon Aug 12 14:40:08 2013) [sssd[be[D.ETHZ.CH]]] [sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database)] ... Any idea why this might happen? Greets Marcus

3 8

id_provider ad and ldap_filter issue
by Vladimir Akhmarov 08 Aug '13

08 Aug '13

Hello, I have a strange problem using new "id_provider = ad" and "ldap_filter = memberOf=cn=Linux Admins,OU=Common Groups,DC=example,DC=com" option. The problem is that I always can log on to the system no matter the user is member of the ldap_filter group or not. I want to filter out all domain users except those that are member of special group named "Linux Admins". Please help me to resolve this issue. In the attachment there are sssd logs. Here are some technical info: Active Directory 2008 R2 CentOS 6.4 [root@testlinux ~]# uname -a Linux testlinux 2.6.32-358.14.1.el6.x86_64 #1 SMP Tue Jul 16 23:51:20 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux [root@testlinux ~]# sssd --version 1.9.2 [root@testlinux ~]# cat /etc/krb5.conf [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = EXAMPLE.COM dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h renew_lifetime = 7d forwardable = true default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 arcfour-hmac default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 arcfour-hmac permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 arcfour-hmac [realms] EXAMPLE.COM = { } [domain_realm] example.com = EXAMPLE.COM .example.com = EXAMPLE.COM [root@testlinux ~]# cat /etc/samba/smb.conf [global] workgroup = EXAMPLE realm = EXAMPLE.COM security = ads client signing = yes client use spnego = yes kerberos method = secrets and keytab password server = * [root@testlinux ~]# cat /etc/sssd/sssd.conf [sssd] config_file_version = 2 domains = example.com services = nss, pam debug_level = 0x2000 [nss] override_shell = /bin/bash override_homedir = /home/%d/%u debug_level = 0x2000 [pam] debug_level = 0x2000 [domain/example.com] id_provider = ad access_provider = ad auth_provider = ad chpass_provider = ad ldap_schema = ad ldap_referrals = false ldap_id_mapping = true ldap_force_upper_case_realm = true ldap_filter = memberOf=cn=Linux Admins,OU=Common Groups,DC=example,DC=com cache_credentials = false debug_level = 0x2000 Best regards, Vladimir Akhmarov

3 6

Errors in auth.log
by Terry Arter 08 Aug '13

08 Aug '13

Hi, I'm using sssd for the first time and I'm seeing these errors in the auth.log file: Aug 5 15:30:07 ***** sssd_be: canonuserfunc error -7 Aug 5 15:30:07 ***** sssd_be: _sasl_plugin_load failed on sasl_canonuser_init for plugin: ldapdb I've Googled for a solution but haven't found one. I'm using Ubuntu 12.04LTS with sssd - 1.8.6. Any help is appreciated. Cheers, T.

4 10

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

Re: [SSSD-users] Use of TLS security certificates in sssd for ldap authentication ?
by Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) 02 Aug '13

02 Aug '13

I have been testing different configurations of sssd and RHEL V6.3 and V6.4. The sssd version on RHEL V6.3 is sssd-1.8.0-32.el6.x86_64 The sssd version on RHEL V6.4 is sssd-1.9.2-82.el6.x86_64 Recently in reviewing my configuration and comparing same to a customers sssd.conf I noticed that I was not able to authenticate ldap users on the RHEL V6.3 system without some reference to a TLS security certificate. More to the point, you must point specifically at the certificate itself and not just the directory in which the certificate can be found: # This doesn't seem to work in RHEL V6.3 #ldap_tls_cacertdir = /etc/openldap/osncerts # This line seems to be required for RHEL v6.3 ldap_tls_cacert = /etc/openldap/osncerts/server.pem If this line is commented or is not in the sssd.conf, authentication fails and I see this error in the /var/log/messages file: Could not start TLS encryption. TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user. I also see that no reference what so ever to the TLS certificate is required in RHEL V6.4 running the later version of sssd. Can anyone explain this ? Are there any plans to require a security certificate in sssd when using ldap for authentication ? Are there any plans to force encrypted communicates in sssd when using ldap for authentication ? Al Licause

3 6

Re: [SSSD-users] ls not displaying group names...only gid's...using sssd
by Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) 01 Aug '13

01 Aug '13

I am working with a customer running RHEL V6.4. They are using ldap for authentication. No problem authenticating a users login but the gids are not consistantly being translated to group names when running id,ls -l or other commands that display the group information. They are using sssd with caching enabled. They are using encrypted communications between the client and server but at my request they switched to unencrypted (port 389) so we could capture a tcpdump. The dump was taken for an ls -l command and it does show two differnt gid's sent to the ldap server and the correct group names are being returned. However, the ls command only shows the gid values and not the names. They mentioned that if they run getent group groupname, sssd will cache that information for a while until the entry times out and then the group names are no longer displayed. I am not sure how to further debug this and cannot explain why when the ldap server returns the correct group names, it is not being displayed by the host commands. Can anyone suggest some other techniques to find out where the group names are being dropped ? Any help greatly appreciated. Al Licause

2 5

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users August 2013