sssd-users May 2017

sssd-users@lists.fedorahosted.org

19 participants
23 discussions

SSSD list allowed users only
by Ali, Saqib 29 May '17

29 May '17

We are using SSSD for authentication using LDAP. And I filter the user access using *simple_allow_groups* as follows: access_provider = simple simple_allow_groups = Computer Admins Is it possible to get a list of ONLY allowed users using *getent*? There is an option enumeration, but this lists all users. I am only interested in the allowed users.

4 8

Re: [Samba] Samba 4.4, sssd, adcli; windows hosts cannot authenticate
by Steve Dainard 28 May '17

28 May '17

On Sun, May 28, 2017 at 1:38 AM, Rowland Penny via samba <samba(a)lists.samba.org> wrote: > On Sat, 27 May 2017 21:45:29 -0700 > Steve Dainard via samba <samba(a)lists.samba.org> wrote: > >> I'm running samba 4.4.4 on el7. I'm attempting to provide a share >> auth by Kerberos or for non-kerberos hosts auth by password on Linux >> or Windows (7) >> clients. >> >> We have uid/gid/group memberships in AD and typically configure >> Linux hosts with a kerberos/sssd/ldap configuration which uses >> attributes from AD, but are not joined to domain. > > You have 'security = ADS' in smb.conf and from 'man smb.conf' > > SECURITY = ADS > > In this mode, Samba will act as a domain member in an ADS realm. To > operate in this mode, the machine running Samba will need to have > Kerberos installed and configured and Samba will need to be joined > to the ADS realm using the net utility. > Right, the host is joined to the domain, via adcli, rather than net. > >> >> I need to be able to automate the domain join with salt stack, so I'm >> stuck using adcli to join the machine as it has a plain-text password >> option, I then push sssd.conf, /etc/krb5.conf, and /etc/samba/smb.conf >> to the samba host. > > Never heard of 'salt' until now and I don't really understand what it > brings to the party ? In context, makes sure people understand I've used adcli, rather than using the net command and must continue to do so, so that I can automate joining samba servers to the domain. > > From what you have posted the default realm is > 'AD.LOCALDOMAIN.COM' but your clients are in the dns domain > 'dhcp.localdomain.com', I am no kerberos expert, but this wouldn't work > with a Samba AD DC. Right, the server is configured as a member server, not a domain controller. Also this doesn't seem to be a 'kerberos' issue, as my Linux clients who auth via kerberos are able to properly authenticate on a protected share without password prompts, and I see a cifs kerberos ticket on my Linux client. The Linux clients also have fqdn's in the same domain as the samba server, not the ad domain. So it appears it might be Windows implementation that has an issue with clients having a different domain name than the servers. That doesn't explain user/password authentication not working on the Windows client, I'm definitely missing something on this side, I'm thinking NTLM may not work with encrypted passwords although I thought this didn't apply to newer versions of samba. This seems related https://social.technet.microsoft.com/Forums/en-US/8249ad4c-69aa-41ba-8863-8… I'll give it a run when I'm back in the office. > > It sounds like you could replace the salt machine with a Samba AD DC > and then you wouldn't have all the problems you are having, but I > understand that you want to use salt. The only problem I can see, you > have set up smb.conf to connect to an AD DC. Salt is only for configuration management, it doesn't matter too much in this context. As mentioned, I'm joining the samba server as a member of the domain, not using it as a domain controller, and using it as a DC is not an option. > > >> When I attempt to connect from a domain joined Windows client I get >> prompted for credentials, and domain credentials do not work. It seems >> like the id of the user isn't passed through or looked up correctly >> after Kerberos auth, and the user is labelled as a guest user. Guest >> users are mapped to bad user in samba config. Here's a bit of logging >> when the Windows client tries to access a >> share: https://pastebin.com/pbEqj9ZR > > Actually unknown users (i.e. Bad User) are mapped to the Unix user > 'nobody', they probably wouldn't be if you were using an AD DC with > the windows clients joined to the domain. Whichever user a bad user is being mapped to, I believe this is at the root of the problem with the Windows client. I think Kerberos is working for the initial auth/handshake, but somehow user id doesn't carry through to match actual permissions on the share. But that this does work for a Linux client machine/user is what is confounding. > > The other problem you have here is, sssd has nothing to do with Samba, > it is not Samba package, you may get better help from the sssd-users > mailing list, mainly because, if you are using sssd, it is this that > is doing your authentication. Yes, I've sent this mail to both lists. > > Rowland > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba

1 0

[SSSD][AD][GPO] GPOs Found but Not Applied
by Ledford, Donald 22 May '17

22 May '17

Hello, We've got a RHEL 6.9 system in testing for AD integration. We have to use 6.x due to compatibility issues with software that will eventually be deployed to the system so moving to RHEL 7.3 isn't an option. Currently we're working on getting SSSD integrated with AD on this box. So far everything except GPO restrictions are working. Users can login via their AD credentials, their groups are enumerated, home directories are made automatically, etc. The only piece left is GPO based access restrictions. We'd really like to use AD GPOs to set who can and can't login via SSH. To this end we've made a new OU for the Linux server, placed it's AD object in the OU, and attached a GPO to the OU with a test user account in the "Deny log on through Remote Desktop Services" policy setting. So far this hasn't been working and the test account can always login through SSH. The SSSD system can see the GPOs attached to the OU all the way up to the domain root, but does not think any of the GPOs apply to it. We've got "ad_gpo_access_control = enforcing" set in sssd.conf but it doesn't seem to be doing anything. According to the logs SSSD is parsing all the GPO LDAP attributes then deciding none of the GPOs apply, without parsing the GPO INI files themselves. I have confirmed manually that the server's Kerberos credentials will return results via LDAP queries and can mount the domain SYSVOL share as well as read the GPO files in the share. So I'm not sure why SSSD won't apply the GPO settings. I've attached a sanitized sssd.conf file and selected parts of the sssd_ad.domain.com.log file to this post. Here's the relevant version info: RHEL 6.9 - Linux ad-lnx-test.ad.domain.com 2.6.32-696.1.1.el6.x86_64 #1 SMP Tue Mar 21 12:19:18 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux yum info sssd: Name : sssd Arch : x86_64 Version : 1.13.3 Release : 56.el6 Size : 34 k Repo : installed From repo : rhel-6-server-rpms Any thoughts on why this isn't working are much appreciated. -- -Donald

4 11

Cluster VIP for LDAP hosts.
by TomK 20 May '17

20 May '17

Hey Guy's, Cluster VIP for LDAP hosts. Does SSSD support this now? Or should it still be a comma seperated list? Have a Windows AD DC cluster made up of 8 servers. Would be handy to use that (ie company-dom.com) instead of the individual hosts that make this up. In case the AD / DC team removes hosts from a cluster, we would not need to update anything on our end if we were using just the domain. -- Cheers, Tom K. ------------------------------------------------------------------------------------- Living on earth is expensive, but it includes a free trip around the sun.

2 2

Can all ldap controls be removed when using access_provider=ad
by Abhijit Tikekar 19 May '17

19 May '17

All, We use access_provider=ad along with ad_access_filter to control authentication based on specific group memberships. But we also have configured several low level ldap control as shown below: #ldap_id_mapping = true #ldap_use_tokengroups = False #ldap_sasl_mech = GSSAPI #ldap_uri = #ldap_sudo_search_base = ou #ldap_user_search_base = dc #ldap_user_object_class = user #ldap_group_search_base = ou= #ldap_group_object_class = group #ldap_user_home_directory = unixHomeDirectory #ldap_user_principal = userPrincipalName #ldap_access_order = filter, expire #ldap_account_expire_policy = ad # ldap_schema = ad I’ve seen several posts where it is suggested that when using “access_provider=ad”, these ldap configurations are no longer needed. I just want to get some clarification on this forum regarding how safe it is to remove all the items listed above and do we run a risk of any potential issues later? Here is a complete SSSD conf. [sssd] domains = services = nss, pam, sudo config_file_version = 2 debug_level = 0 [nss] [pam] [sudo] debug_level=0 [domain/] debug_level=0 ad_server = xxxxx id_provider = ad auth_provider = ad access_provider = ad sudo_provider = ad krb5_realm = #ldap_id_mapping = true #ldap_use_tokengroups = False #ldap_sasl_mech = GSSAPI #ldap_uri = ldap://xxxxxx #ldap_sudo_search_base = #ldap_user_search_base = #ldap_user_object_class = #ldap_group_search_base = #ldap_group_object_class = #ldap_user_home_directory = #ldap_user_principal = #ldap_access_order = filter, expire #ldap_account_expire_policy = ad #ldap_schema = ad ad_access_filter = cache_credentials = true override_homedir = /home/%d/%u default_shell = /bin/bash Thanks in advance for any inputs. ~ Abhi

2 1

kerberos ticket not renewed in 15.2/master
by Joakim Tjernlund 19 May '17

19 May '17

Sequence: login into MATE or Plasma suspend to ram wait until krbtgt expires wakeup computer unlock screen klist will show the old expired ticket. lock/unlock screen again(well after networking is up) klist still shows the old ticket. No SSO/NFS possible until manually doing a kinit to get a fresh ticket Anyone else see this? Jocke

4 15

sAMAccountName with gid in requests
by Sébastien QUESSON 19 May '17

19 May '17

Hi, on sssd 1.13.4-1ubuntu1.5: looking at sssd_domain.tls.log with debug level 9, I can see many wrong group requests. After flushing ssd cache and restarting: [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(gidNumber=10117)(objectClass=group)(sAMAccountName=*)(&(gidNumber=*)(!(gidNumber=0))))][DC=domain,DC=tld]. => it is valid, but few milliseconds later: [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(sAMAccountName=10107)(objectClass=group)(sAMAccountName=*)(&(gidNumber=*)(!(gidNumber=0))))][DC=domain,DC=tld] returns nothing, because sAMAccountName=10107 does not exists in sssd_nss.log, it generates many errors such [sssd[nss]] [nss_cmd_getpwnam_search] (0x0040): No results for getpwnam call [nss_cmd_getgrnam_search] (0x0040): No results for getgrnam call is it expected or a misconfiguration on my test environment? attached : sssd.conf

2 2

Users able to login but unable to sudo
by Abhijit Tikekar 18 May '17

18 May '17

Hi, On multiple machines where SSSD is being used, “sudo” has stopped working. Users can authenticate successfully based on their group memberships, but are unable to elevate privileges. [first.last@hostname ~]$ sudo su [sudo] password for first.last: Sorry, try again. [sudo] password for first.last: Here is the SSSD Configuration: [sssd] domains = X.Y.LOCAL services = nss, pam, sudo config_file_version = 2 debug_level = 0 [nss] [pam] [sudo] debug_level=10 [domain/x.y.local] debug_level=0 ad_server = AD.x.y.local id_provider = ad auth_provider = ad access_provider = ad sudo_provider = ad ldap_id_mapping = true ldap_use_tokengroups = False ldap_sasl_mech = GSSAPI krb5_realm = X.Y.LOCAL ldap_uri = ldap://AD.x.y.local ldap_sudo_search_base = ou= ldap_user_search_base = dc= ldap_user_object_class = user ldap_group_search_base = ou ldap_group_object_class = group ldap_user_home_directory = unixHomeDirectory ldap_user_principal = userPrincipalName ldap_access_order = filter, expire ldap_account_expire_policy = ad ldap_access_filter = cache_credentials = true override_homedir = /home/%d/%u default_shell = /bin/bash ldap_schema = ad Here is sssd_sudo.log with level set to 10 (Wed May 17 13:33:51 2017) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=first.last)(sudoUser=first.last)(sudoUser=#xxxxxxxxx)(sudoUser=%yyyyyyyy)(sudoUser=%zzzzzz)] (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x24216e0 (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x241d2f0 (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Running timer event 0x24216e0 "ltdb_callback" (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Destroying timer event 0x241d2f0 "ltdb_timeout" (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Ending timer event 0x24216e0 "ltdb_callback" (Wed May 17 13:33:51 2017) [sssd[sudo]] [sudosrv_get_rules] (0x2000): About to get sudo rules from cache (Wed May 17 13:33:51 2017) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(name=defaults)))] (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x2421880 (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x241bd70 (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Running timer event 0x2421880 "ltdb_callback" (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Destroying timer event 0x241bd70 "ltdb_timeout" (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Ending timer event 0x2421880 "ltdb_callback" (Wed May 17 13:33:51 2017) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] (0x0400): Returning 0 rules for [<default options>@x.y.local] (Wed May 17 13:33:51 2017) [sssd[sudo]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x241dbe0][17] (Wed May 17 13:33:51 2017) [sssd[sudo]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x241dbe0][17] (Wed May 17 13:33:51 2017) [sssd[sudo]] [sudosrv_cmd] (0x2000): Using protocol version [1] (Wed May 17 13:33:51 2017) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name 'first.last' matched without domain, user is first.last (Wed May 17 13:33:51 2017) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name 'first.last' matched without domain, user is first.last (Wed May 17 13:33:51 2017) [sssd[sudo]] [sudosrv_cmd_parse_query_done] (0x0200): Requesting rules for [first.last] from [<ALL>] (Wed May 17 13:33:51 2017) [sssd[sudo]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/x.y.local/first.last] (Wed May 17 13:33:51 2017) [sssd[sudo]] [sudosrv_get_user] (0x0200): Requesting info about [first.last(a)x.y.local] (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x2411ce0 (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x241bcf0 (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Running timer event 0x2411ce0 "ltdb_callback" (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Destroying timer event 0x241bcf0 "ltdb_timeout" (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Ending timer event 0x2411ce0 "ltdb_callback" (Wed May 17 13:33:51 2017) [sssd[sudo]] [sudosrv_get_user] (0x0400): Returning info for user [first.last(a)x.y.local] (Wed May 17 13:33:51 2017) [sssd[sudo]] [sudosrv_get_rules] (0x0400): Retrieving rules for [first.last] from [x.y.local] (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x2416450 (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x241a150 (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Running timer event 0x2416450 "ltdb_callback" (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Destroying timer event 0x241a150 "ltdb_timeout" (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Ending timer event 0x2416450 "ltdb_callback" (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x2412df0 (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x2421340 (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Running timer event 0x2412df0 "ltdb_callback" (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Destroying timer event 0x2421340 "ltdb_timeout" (Wed May 17 13:33:51 2017) [sssd[sudo]] [ldb] (0x4000): Ending timer event 0x2412df0 "ltdb_callback" (Wed May 17 13:33:51 2017) [sssd[sudo]] [sysdb_search_group_by_gid] (0x0400): No such entry Verified that correct %groupname entry exists under /etc/sudoers file. What else can be checked? Thanks, ~ abhi

2 4

Authenticating to RODC using SSSD
by Abhijit Tikekar 15 May '17

15 May '17

Hi, Has anyone had any success while setting up SSSD with RODC AD Server? We are setting this up on CentOS 6.8 machines but doesn't seem to work. Computer object is created and replicated to RODC. Verified that all configuration file parameters are identical to the ones mentioned in the link below. https://access.redhat.com/discussions/2838371 I assume we still have to join the server to RODC? Is the joining process still the same as we do for a Writable DC. When using "net ads join" I get the following error: Failed to join domain: Failed to set account flags for machine account (NT_STATUS_NOT_SUPPORTED) in the logs, we also get the following( Debug level set to 7) (Tue Feb 14 11:20:42 2017) [sssd[be[x.y.local]]] [sdap_set_sasl_options] (0x0100): Will look for testdmzlin(a)X.Y.LOCAL in default keytab (Tue Feb 14 11:20:42 2017) [sssd[be[x.y.local]]] [select_principal_from_keytab] (0x0200): trying to select the most appropriate principal from keytab (Tue Feb 14 11:20:42 2017) [sssd[be[x.y.local]]] [find_principal_in_keytab] (0x0400): No principal matching testdmzlin(a)X.Y.LOCAL found in keytab. (Tue Feb 14 11:20:42 2017) [sssd[be[x.y.local]]] [find_principal_in_keytab] (0x0400): No principal matching TESTDMZLIN$(a)X.Y.LOCAL found in keytab. (Tue Feb 14 11:20:42 2017) [sssd[be[x.y.local]]] [find_principal_in_keytab] (0x0400): No principal matching host/testdmzlin(a)X.Y.LOCAL found in keytab. (Tue Feb 14 11:20:42 2017) [sssd[be[x.y.local]]] [find_principal_in_keytab] (0x0400): No principal matching *$(a)X.Y.LOCAL found in keytab. (Tue Feb 14 11:20:42 2017) [sssd[be[x.y.local]]] [find_principal_in_keytab] (0x0400): No principal matching host/*(a)X.Y.LOCAL found in keytab. (Tue Feb 14 11:20:42 2017) [sssd[be[x.y.local]]] [find_principal_in_keytab] (0x0400): No principal matching host/*@(null) found in keytab. But if i try to query this RODC using "ldapsearch" it works. ldapsearch -H ldap://RODC_ServerName.x.y.local/ -Y GSSAPI -N -b "dc=x,dc=y,dc=local" "(&(objectClass=user)(sAMAccountName=firstname.lastname))" What else can I check to troubleshoot this issue? Thanks, ~ Abhi

3 12

Thank You!
by Orion Poplawski 08 May '17

08 May '17

IPA/SSSD developers - I'm writing to give everyone involved in the IPA and sssd projects a big "Thank You". I've been poking at IPA for a little over 4 years now, looking to migrate away from our 389ds LDAP configuration. There have been lots of hurdles to jump, bugs to fix, as well as a complete change of direction (from migrating users to moving to an AD trust). Along the way I have received a huge amount of assistance from a large group of incredibly helpful people, including (but not limited to) Jakub Hrozek, Lukas Slebodnik, Simo Sorce, Pavel Březina, Nalin Dahyabhai, Rob Crittenden. My apologies if I left anyone out. I have two machines left to convert to IPA and can hardly believe sometimes that I've finally arrived at this point. So, thanks again for everyone for their work on this incredibly complex and critical set of software. - Orion -- Orion Poplawski Technical Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 http://www.nwra.com

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users May 2017