SAMBA share server with SSSD and NTLM even possible?
by Erinn Looney-Triggs
I have a system that is joined to an AD domain via SSSD, it was happily
running samba and serving shares using either kerberos or password
authentication, with the update to Samba 4.7.1 in the RHEL 7.5 release,
all of that stopped working.
samba config file:
[global]
log level = 5
password server = *
realm = AD.EXAMPLE.COM
encrypt passwords = yes
kerberos method = system keytab
workgroup = AD
server string = %h samba
security = ADS
map to guest = Bad User
interfaces = <valid IP>
hosts allow = <valid IP blocks>
load printers = no
passdb backend = tdbsam
dns proxy = no
max log size = 5000
bind interfaces only = no
restrict anonymous = 2
#============================ Share Definitions
==============================
[images]
comment = example images
path = /var/eng/
guest ok = no
printable = no
write list =
create mask = 0664
directory mask = 0775
read only = no
valid users = +valid-example-group
force group =
browseable = yes
Now samba will not even start without either libwbclient or
sssd-libwbclient installed with the above configuration. After
installing sssd-libwbclient and modifying valid users to:
valid users = AD\valid-example-group
kerberos based connections will work just fine. However password based
connections for windows systems that are not AD joined, or smbclient
without kerberos, does not work. I believe this is falling back to NTLM
and NTLM is simply not supported by SSSD correct?
Oddly, what used to work, with basically a call to getgrnam() no longer
works in 4.7.1 release of samba and there seems to be no mention that I
can find as to why. Any thoughts?
It looks an awful lot like, if we need to support both krb and password
based connections we will need to use winbind, correct? Or is there
another way to make this thing work? If I have to use winbind it looks
like I need to use 'net ads join' or 'realm join
--client-software=winbind' but it then seems to me that the system will
be joined to the AD twice, once to use SSSD, and once for winbind is
this correct? Is there a way to make winbind and SSSD work together?
Further it looks like, according to this:
https://bugzilla.redhat.com/show_bug.cgi?id=1558560 that RHEL 7.6 with
Samba 4.8.1 will require winbind to be running period. I believe that
statement to be a bit of an oversimplification because sssd-libwbclient
should still work, or am I misunderstanding?
Any guidance here would be great, this seems to be a fairly murky area,
or my google fu is weak.
-Erinn
4 months, 1 week
ad_access_filter and splitting group listing with backslash
by TomK
Hey All,
Given this example below which spans the entire line:
ad_access_filter = (|(memberOf=CN=group-of
-admins,OU=XYZ,DC=blah,DC=blah,DC=blah)(memberOf=CN=group-of
-managers,OU=XYZ,DC=blah,DC=blah,DC=blah)(memberOf=CN=group-of
-minions,OU=XYZ,DC=blah,DC=blah,DC=blah)(memberOf=CN=group-of
-analysts,OU=XYZ,DC=blah,DC=blah,DC=blah)(memberOf=CN=group-of
-limited,OU=XYZ,DC=blah,DC=blah,DC=blah)(memberOf=CN=group-of
-viewers,OU=XYZ,DC=blah,DC=blah,DC=blah))
Has anyone tried to use a backslash to split the line like this?
ad_access_filter = (| \
(memberOf=CN=group-of-admins,OU=XYZ,DC=blah,DC=blah,DC=blah) \
(memberOf=CN=group-of-managers,OU=XYZ,DC=blah,DC=blah,DC=blah) \
(memberOf=CN=group-of-minions,OU=XYZ,DC=blah,DC=blah,DC=blah) \
(memberOf=CN=group-of-analysts,OU=XYZ,DC=blah,DC=blah,DC=blah) \
(memberOf=CN=group-of-limited,OU=XYZ,DC=blah,DC=blah,DC=blah) \
(memberOf=CN=group-of-viewers,OU=XYZ,DC=blah,DC=blah,DC=blah))
Or would the backslashes get interpreted when SSSD reads the file?
--
Cheers,
Tom K.
4 months, 2 weeks
Issues with SSSD cache on version 1.13.4
by Beale (US), Gareth
We are running SUSE 12 SP3 which uses SSSD 1.13.4 which I believe is a LTM version.
Due to the large number of users and groups in our LDAP directory, and the limitations of some legacy Unix systems, we have some large groups that have been broken into "sub-groups" with the same GID but an incremental suffix. I don't believe this is an uncommon solution, and it has worked fine for many years. There are efforts underway to patch some older systems such that they can handle very large groups so that we can collapse these sub-groups, but it is a slow process and there are a lot of servers.
Recently we upgraded some Linux systems to SUSE 12 SP3 and this has made us transition to using SSSD instead of configuring LDAP in /etc/ldap/conf. In the last few weeks we have encountered an issue related to these groups with the same GID. Most of the time, everything works as before, and for instance "getent group" commands using either GID or (sub-group) name return results. However at times those commands return an empty list and the following error appears in the system log:
sssd[nss]: More groups have the same GID [nnnn] in directory server. SSSD will not work correctly.
(group ID elided in this email per company policy)
Using sss_cache to expire the entire cache, group cache or specific group from cache has no effect. I understand that this expires the entries, not removes them, but subsequent getent calls do not overwrite what was there, the error persists. Stopping SSSD, removing the cache DB and restarting was effective, but this is not a viable solution in production. Since the problem clears itself eventually (only to come back later) I tried various strategies, one of which was to do a "getent group" on every sub-group, and this does clear the problem (until it returns).
Since I discovered this issue on SUSE, others in the company have verified that it also appears in RH 6 and 7. RH 7 is running 1.16.0, so the problem is still present up to that release, though the above error message does not appear in the messages log. Instead there is an error in the sssd_nss.log:
[sssd[nss]] [cache_req_search_cache] (0x0020): CR #1122: Multiple objects were found when only one was expected!
Gareth
Gareth Beale (bemsid: 45600)
Enterprise High Performance Computing Service
Application Infrastructure Services
Global Information Technology Infrastrucure Services
Need help? http://iticket.web.boeing.com/secure/create.aspx?id=serverhpc / 425-234-0911
4 months, 3 weeks
System Error
by Alfredo De Luca
Hi all.
I run an SFTP server with Centos 7.4 with freeIPA and sssd.
There is a user that can connect no problem manually...but with a
polling application (I think is ListSFTP) I can see polling a lot of
directories... but all of sudden we receive
Sep 25 11:09:22 sftp sshd[12281]: pam_sss(sshd:account): Access denied
for user <USER>: 4 (System error)
Sep 25 11:09:22 sftp sshd[12281]: fatal: Access denied for user <USER>
by PAM account configuration [preauth]
In the same scan we can see all going ok...
Sep 25 11:09:01 sftp sshd[11820]: pam_unix(sshd:session): session opened
for user <USER> by (uid=0)
Sep 25 11:09:01 sftp sshd[11820]: pam_unix(sshd:session): session closed
for user <USER>
Sep 25 11:09:02 sftp sshd[11817]: Accepted publickey for <USER> from
<IP> port 44182 ssh2: RSA SHA256:PU0MfEffM866Dm4lCyk7Yve6z4bKodwM1Q9G9dyf3qE
Sep 25 11:09:02 sftp sshd[11817]: pam_unix(sshd:session): session opened
for user <USER> by (uid=0)
Sep 25 11:09:02 sftp sshd[11817]: pam_unix(sshd:session): session closed
for user <USER>
Sep 25 11:09:02 sftp sshd[11822]: Accepted publickey for <USER> from IP
port 44188 ssh2: RSA SHA256:PU0MfEffM866Dm4lCyk7Yve6z4bKodwM1Q9G9dyf3qE
Any idea?
--
Alfredo De Luca (Sourcesense)
Senior Devops Engineer
e. alfredo.deluca(a)sourcesense.com
4 months, 3 weeks
Fully qualified prompts shell prompts
by Lawrence Kearney
A bit of a confusing issue I have not been able to resolve. At times the
profile on a system produced the expected user prompt over SSH, and at
times a fully qualified one as detailed below.
# su - msteele
Sometimes I get:
# msteele@darkvixen102:~>
Sometimes I get:
# msteele@darkvixen102.dvc.darkvixen.com:/srv/nfs/home/
dvc.darkvixen.com/msteele>
The daemon version is 1.16.1 but it occurs with other versions as well and
on other platforms. This one is openSUSE Leap 15. There are no daemon
restarts or configuration changes between shell prompt changes.
Any thoughts on where to look for a root cause? The fully qualified prompt
can be an annoyance.
Many thanks as always,
-- lawrence
4 months, 3 weeks
sssd and openssl
by Chris Kowalczyk
Hello All,
I was wondering, are there any requirements regarding openssl versions
required for different sssd versions?
To be more specific, I have a quite old sssd-1.9 which uses ancient (pre
1.0.1) OpenSSL. How do you think, should I have any objections before
updating OpenSSL to something more secure?
Regards,
Chris
4 months, 4 weeks
Re: override_gid not changing default GID
by Jakub Hrozek
> On 14 Sep 2018, at 00:25, Kevin Murakoshi <ksmurakoshi(a)UCDAVIS.EDU> wrote:
>
> Hi All,
>
> I'm relatively new to SSSD, and this has me stumped. I'm trying to override the default GID for all the users on a OEL 7 system. I set override_gid = 100 in sssd.conf, but as far as i can tell nothing's happening. Looking into the sssd cache, I see:
>
> dn: name=riceboy(a)ad3.ucdavis.edu,cn=users,cn=ad3.ucdavis.edu,cn=sysdb
> createTimestamp: 1536876547
> fullName: riceboy
> gecos: riceboy
> gidNumber: 846575921
> name: riceboy(a)ad3.ucdavis.edu
> objectCategory: user
> uidNumber: 190295
>
> When I set auto_private_groups = true, the GID does change:
>
> dn: name=riceboy(a)ad3.ucdavis.edu,cn=users,cn=ad3.ucdavis.edu,cn=sysdb
> createTimestamp: 1536877117
> fullName: riceboy
> gecos: riceboy
> gidNumber: 190295
> name: riceboy(a)ad3.ucdavis.edu
> objectCategory: user
> uidNumber: 190295
I think this is a bug. Looking at the domain the user comes from and the domain defined in sssd.conf, this user comes from a trusted domain, correct? The domain defined in sssd.conf is ou.ad3.ucdavis.edu, but the domain the user comes from is ad3.ucdavis.edu
I could reproduce this in my local test, it seems that the override_gid option is not applied to subdomain users. E.g, using override_gid=55555 I can see the administrator user from the joined domain to have their gid overriden:
$ id administrator(a)win.trust.test
uid=1323800500(administrator(a)win.trust.test) gid=55555 groups=55555,1323800572(denied rodc password replication group(a)win.trust.test),1323800520(group policy creator owners(a)win.trust.test),1323800513(domain users(a)win.trust.test),1323800512(domain admins(a)win.trust.test),1323800519(enterprise admins(a)win.trust.test),1323800518(schema admins(a)win.trust.test)
But not the user from a trusted domain:
$ id administrator(a)child.win.trust.test
uid=52600500(administrator(a)CHILD.win.trust.test) gid=52600500(administrator(a)CHILD.win.trust.test) groups=52600500(administrator(a)CHILD.win.trust.test),52600513
Does override_gid work for you for users from the joined domain at least?
>
> Another data point (not sure if this is related), when I try and override the GID on an existing group, the name will change, but the GID will not. (original GID of "Domain Users" is 846575921)
> [root@tcsnd2 ~]# sss_override group-add "Domain Users(a)ad3.ucdavis.edu" -n NewName -g 1234567
> SSSD needs to be restarted for the changes to take effect.
> [root@tcsnd2 ~]# systemctl restart sssd
> [root@tcsnd2 ~]# id riceboy(a)ad3.ucdavis.edu
> uid=190295(riceboy) gid=846575921(newname) groups=846575921(newname),1170(status),1061419070(ism-us-systems),1061419998(iet-us-banner),1061419025(ism-us-status),1061419997(iet-us-edrs),1061419993(iet-us-
> rbds),1061419045(ism-us-ism),1234567(newname),1061419999(iet-us-ansible),1061419046(ism-us-isun-susers),1061419058(ism-us-netbackup),1061419074(ism-us-zenoss)
>
>
Hmm, this sounds like a bug as well. Does it work with any of the non-primary groups at least?
> I'm sure there's something simple I'm missing, any ideas?
>
>
>
>
> My sssd.conf file
>
> [nss]
> filter_groups = root
> filter_users = root
> reconnection_retries = 3
> debug_level = 2
>
> [pam]
> reconnection_retries = 3
> debug_level = 2
>
> [sssd]
> domains = ou.ad3.ucdavis.edu
> config_file_version = 2
> services = nss, pam, ifp
> debug_level = 2
>
> default_domain_suffix = AD3.UCDAVIS.EDU
>
> [domain/ou.ad3.ucdavis.edu]
> ad_domain = ou.ad3.ucdavis.edu
> krb5_realm = OU.AD3.UCDAVIS.EDU
> krb5_auth_timeout = 30
> debug_level = 4
> override_gid = 100
>
>
> cache_credentials = True
>
> id_provider = ad
> auth_provider = ad
> chpass_provider = ad
> access_provider = ad
> #ad_access_filter = (memberOf=CN=IET-US-Unit-PS,OU=US-byOrg,OU=Groups,OU=IET-New,OU=DEPARTMENTS,DC=ou,DC=ad3,DC=ucdavis,DC=edu)
>
> use_fully_qualified_names = True
>
> ;;; Must be false for UNIX UIDs to be retrieved from AD3
> ldap_id_mapping = false
> ldap_schema = ad
>
> krb5_store_password_if_offline = True
>
> default_shell = /bin/bash
> override_homedir = /home/%u
> fallback_homedir = /tmp/
> override_shell = /bin/ksh
> #auto_private_groups = true
>
> access_provider = simple
> simple_allow_groups = ISM-US-ISM(a)ou.ad3.ucdavis.edu, IET-US-BANNER(a)ou.ad3.ucdavis.edu
>
> ignore_group_members = TRUE
> ldap_use_tokengroups = True
> ldap_group_nesting_level = 0
> ldap_groups_use_matching_rule_in_chain = True
> ldap_initgroups_use_matching_rule_in_chain = True
> full_name_format = %1$s
> dyndns_update = false
> ~
>
> Kevin Murakoshi
> IET Enterprise Student Applications
>
> ksmurakoshi(a)ucdavis.edu
>
> (530) 752-0318 (office)
> (530) 219-8188 (cell)
>
>
>
>
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
5 months
override_gid not changing default GID
by Kevin Murakoshi
Hi All,
I'm relatively new to SSSD, and this has me stumped. I'm trying to override the default GID for all the users on a OEL 7 system. I set override_gid = 100 in sssd.conf, but as far as i can tell nothing's happening. Looking into the sssd cache, I see:
dn: name=riceboy(a)ad3.ucdavis.edu,cn=users,cn=ad3.ucdavis.edu,cn=sysdb
createTimestamp: 1536876547
fullName: riceboy
gecos: riceboy
gidNumber: 846575921
name: riceboy(a)ad3.ucdavis.edu
objectCategory: user
uidNumber: 190295
When I set auto_private_groups = true, the GID does change:
dn: name=riceboy(a)ad3.ucdavis.edu,cn=users,cn=ad3.ucdavis.edu,cn=sysdb
createTimestamp: 1536877117
fullName: riceboy
gecos: riceboy
gidNumber: 190295
name: riceboy(a)ad3.ucdavis.edu
objectCategory: user
uidNumber: 190295
Another data point (not sure if this is related), when I try and override the GID on an existing group, the name will change, but the GID will not. (original GID of "Domain Users" is 846575921)
[root@tcsnd2 ~]# sss_override group-add "Domain Users(a)ad3.ucdavis.edu" -n NewName -g 1234567
SSSD needs to be restarted for the changes to take effect.
[root@tcsnd2 ~]# systemctl restart sssd
[root@tcsnd2 ~]# id riceboy(a)ad3.ucdavis.edu
uid=190295(riceboy) gid=846575921(newname) groups=846575921(newname),1170(status),1061419070(ism-us-systems),1061419998(iet-us-banner),1061419025(ism-us-status),1061419997(iet-us-edrs),1061419993(iet-us-
rbds),1061419045(ism-us-ism),1234567(newname),1061419999(iet-us-ansible),1061419046(ism-us-isun-susers),1061419058(ism-us-netbackup),1061419074(ism-us-zenoss)
I'm sure there's something simple I'm missing, any ideas?
My sssd.conf file
[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3
debug_level = 2
[pam]
reconnection_retries = 3
debug_level = 2
[sssd]
domains = ou.ad3.ucdavis.edu
config_file_version = 2
services = nss, pam, ifp
debug_level = 2
default_domain_suffix = AD3.UCDAVIS.EDU
[domain/ou.ad3.ucdavis.edu]
ad_domain = ou.ad3.ucdavis.edu
krb5_realm = OU.AD3.UCDAVIS.EDU
krb5_auth_timeout = 30
debug_level = 4
override_gid = 100
cache_credentials = True
id_provider = ad
auth_provider = ad
chpass_provider = ad
access_provider = ad
#ad_access_filter = (memberOf=CN=IET-US-Unit-PS,OU=US-byOrg,OU=Groups,OU=IET-New,OU=DEPARTMENTS,DC=ou,DC=ad3,DC=ucdavis,DC=edu)
use_fully_qualified_names = True
;;; Must be false for UNIX UIDs to be retrieved from AD3
ldap_id_mapping = false
ldap_schema = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
override_homedir = /home/%u
fallback_homedir = /tmp/
override_shell = /bin/ksh
#auto_private_groups = true
access_provider = simple
simple_allow_groups = ISM-US-ISM(a)ou.ad3.ucdavis.edu, IET-US-BANNER(a)ou.ad3.ucdavis.edu
ignore_group_members = TRUE
ldap_use_tokengroups = True
ldap_group_nesting_level = 0
ldap_groups_use_matching_rule_in_chain = True
ldap_initgroups_use_matching_rule_in_chain = True
full_name_format = %1$s
dyndns_update = false
~
Kevin Murakoshi
IET Enterprise Student Applications
ksmurakoshi(a)ucdavis.edu
(530) 752-0318 (office)
(530) 219-8188 (cell)
5 months
Signature for recent downloads
by Jan Engelhardt
sssd-1.16.3 and sssd-2.0.0 were signed with a new key that has not been
published on the standard keyservers. Can you do that?
15:30 a4:../ldap/sssd > gpg --verify sssd-2.0.0.tar.gz.asc
gpg: keyserver option 'ca-cert-file' is obsolete; please use 'hkp-cacert' in dirmngr.conf
gpg: keyserver option 'no-try-dns-srv' is unknown
gpg: assuming signed data in 'sssd-2.0.0.tar.gz'
gpg: Signature made 2018-08-13T21:37:45 CEST
gpg: using RSA key 0x70C146062250BDFA
gpg: Can't check signature: No public key
15:30 a4:../ldap/sssd > gpg --recv-keys 0x70C146062250BDFA
gpg: keyserver option 'ca-cert-file' is obsolete; please use 'hkp-cacert' in dirmngr.conf
gpg: keyserver option 'no-try-dns-srv' is unknown
gpg: keyserver receive failed: No data
5 months, 1 week
Concerning "ldap_idmap_default_domain_sid", "[domain/default]", and "ldap_idmap_default_domain"
by Lawrence Kearney
I beleive I understand the use of the the "ldap_idmap_default_domain_sid"
directive. Most simply the MURMUR algorithm will be disabled and the domain
configuration designated as the "default" domain will be assigned to slice
[0]. My observation is that the UID-GID for an object becomes
(ldap_idmap_range_min + <object_RID>) in this configuration.
The man pages are less clear on why and how specifying which domain is the
default in a multi-domain configuration matters. My assumption is that the
sole purpose of the "[domain/default]" and "ldap_idmap_default_domain"
options is to do just that.
"[domain/default]"
- Is the entended use for this domain stanza header?
- Is is still a valid configuration choice?
"ldap_idmap_default_domain"
- Is the entended use for this configuration directive?
- If it is specified in one domain stanza in a multi-domain configuration
will the configuration be honored across other configured domains?
Many thanks as always,
-- lawrence
5 months, 2 weeks
