Enumerate users from external group from AD trust
by Bolke de Bruin
Hello,
I have sssd 1.13.00 working against FreeIPA 4.2 domain. This domain has a trust relationship with a active directory domain.
One of the systems we are using requires to enumerate all users in groups by (unfortunate) design (Apache Ranger). This is done by using
“getent group”. During this enumeration the full user list for a group that has a nested external member group* is not always returned so we thought to
add “getent group mygroup” in order to get more details. Unfortunately this does not seem to work consistently: sometimes this gives information sometimes it does not:
[root@master centos]# getent group ad_users
ad_users:*:1950000004:
[root@master centos]# id bolke(a)ad.local
UID=1796201107(bolke(a)ad.local) GID=1796201107(bolke(a)ad.local) groepen=1796201107(bolke(a)ad.local),1796200513(domain users@ad.local),1796201108(test(a)ad.local)
[root@master centos]# getent group ad_users
ad_users:*:1950000004:bolke@ad.local <mailto:bolke@ad.local>
If I clear the cache (sss_cache -E) the entry is gone again:
[root@master centos]# getent group ad_users
ad_users:*:1950000004:
My question is how do I get sssd to enumerate *all users* in a group consistently?
Thanks!
Bolke
* https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/trust-g...
1 year, 1 month
SSSD strangeness
by simonc99＠hotmail.com
Hi All
We've got SSSD 1.13.0 installed as part of a Centos 7.2.1511 installation.
We've used realmd to join the host concerned to our 2008R2 AD system. This went really well, and consequently we've been using SSSD to provide login services and kerberos integration for our fairly large hadoop system.
The authconfig that's implicitly run as part of realmd produces the following sssd.conf:
[sssd]
domains = <joined domain>
config_file_version = 2
services = nss, pam
[pam]
debug_level = 0x0080
[nss]
timeout = 20
force_timeout = 600
debug_level = 0x0080
[domain/<joined domain>]
ad_domain = <joined domain>
krb5_realm = <JOINED DOMAIN>
realmd_tags = manages-system joined-with-samba
cache_credentials = true
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = False
fallback_homedir = /home/%u@%d
access_provider = simple
simple_allow_groups = <AD group allowing logins>
krb5_use_kdc_info = False
entry_cache_timeout = 300
debug_level = 0x0080
ad_server = <active directory server>
As I've said - this works really well. We did have some stability issues initially, but they've been fixed by defining the 'ad_server' rather than using autodiscovery.
Logins work fine, kerberos TGTs are issued on login, and password changes are honoured correctly.
However, in general day to day use, we have noticed a few anomalies, that we just can't track down.
Firstly (this has happened a few times), a user will change their AD password (via a Windows PC).
Subsequent logins - sometimes with specific client software - fail with
pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=<remote PC name> user=<username>
pam_sss(sshd:auth): received for user <username>: 17 (failure setting user credentials)
So in this example, the person concerned has changed their AD password. Further attempts to access this system via SSH work fine. However, using SFTP doesn't work (the above is output into /var/log/secure).
There are no local controls on sftp logins, and the user concerned was working fine (using both sftp and ssh) until they updated their password.
There is no separate sftp daemon running, and it only affects one individual currently (but we have seen some very similar instances before)
The second issue we have is around phantom groups in AD.
Hadoop uses an id -Gn command to see group membership for authorisation.
With some users - we've seen 6 currently - we see certain groups failing to be looked up:
id -Gn <username>
id: cannot find name for group ID xxxxyyyyy
<group name> <group name> <group name> <group name> <etc...>
The xxxxyyyyy indicates:
xxxx = hashed realm name
yyyyy = RID from group in AD
We can't find any group with that number on the AD side!
We can work around this by adding a local group (into /etc/group) for the GIDs affected. This means the id -Gn runs correctly, and the hadoop namenode can function correctly - but this is a workaround and we'd like to get to the bottom of the issue.
Rather than flooding this post now with logfiles, just thought I'd see if this looked familiar to anyone. Happy to upload any logs, amend logging levels, etc.
Many thanks
Simon
1 year, 2 months
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
2 years, 3 months
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.
2 years, 3 months
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
2 years, 4 months
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
2 years, 4 months
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
2 years, 4 months
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
2 years, 4 months
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...
2 years, 4 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)
2 years, 4 months
