SSSD list allowed users only
by Ali, Saqib
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.
6 years, 10 months
Re: [Samba] Samba 4.4, sssd, adcli; windows hosts cannot authenticate
by Steve Dainard
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...
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
6 years, 10 months
[SSSD][AD][GPO] GPOs Found but Not Applied
by Ledford, Donald
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
6 years, 11 months
Cluster VIP for LDAP hosts.
by TomK
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.
6 years, 11 months
Can all ldap controls be removed when using access_provider=ad
by Abhijit Tikekar
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
6 years, 11 months
kerberos ticket not renewed in 15.2/master
by Joakim Tjernlund
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
6 years, 11 months
sAMAccountName with gid in requests
by Sébastien QUESSON
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
6 years, 11 months
Users able to login but unable to sudo
by Abhijit Tikekar
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
6 years, 11 months
Authenticating to RODC using SSSD
by Abhijit Tikekar
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
6 years, 11 months
Thank You!
by Orion Poplawski
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
6 years, 11 months
