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, 3 months
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, 4 months
Any way to convince realm join not to do authselect in RHEL8?
by Spike White
All,
Basically here is the realm command we use to join the appropriate regional
AD domain:
realm join -v --automatic-id-mapping=no
--computer-ou="OU=Servers,OU=UNIX,DC=$SUPPORTREGION,DC=COMPANY,DC=COM"
--user-principal="host/`hostname --fqdn`@$JOINDOMAIN" $JOINDOMAIN
As part of this, realm join internally runs the following command:
* /usr/bin/sh -c /usr/bin/authselect select sssd with-mkhomedir --force &&
/usr/bin/systemctl enable oddjobd.service && /usr/bin/systemctl start
oddjobd.service
But that sets /etc/pam.d/password-auth and /etc/pam.d/system-auth to a
sub-optimal PAM stack. I.e., not what we desire.
For example, 99.9% of our users are in AD. So we want to run pam_sssd
*before* pam_unix.
We are very comfortable with testing and debugging PAM stacks. We have a
stable, tested PAM stack that works great -- ever since RHEL7.
Basically, after the 'realm join' above is done, we have to overwrite
/etc/pam.d/{system-auth,password-auth,postlogin} with what we desire.
If 'realm join' can't be convinced to not run authselect, we're ok with
creating a custom/profile authselect profile with what we want. And then
convince realm join to run:
authselect select custom/profile
Instead of the above authselect select sssd
Prior to running 'realm join', I have to drop down a /etc/realmd.conf file
so that the 'realm join' behaves as I want it to. Is there any option in
realmd.conf to not run authselect or tailor the authselect command? Or may
a flag on the 'realm discover' command line?
I don't remember any of these problems with realm join on RHEL7. Maybe it
was running authconfig inappropriately as well -- and I just never noticed,
because I over-wrote with desired PAM stack?
Spike
1 year, 9 months
[alexander.fieroch@mpi-dortmund.mpg.de: SSSD + samba shares]
by Sumit Bose
----- Forwarded message from Alexander Fieroch <alexander.fieroch(a)mpi-dortmund.mpg.de> -----
Date: Mon, 20 May 2019 15:52:30 +0200
From: Alexander Fieroch <alexander.fieroch(a)mpi-dortmund.mpg.de>
To: sssd-users-owner(a)lists.fedorahosted.org
Subject: SSSD + samba shares
Hi,
I'm using SSSD for my AD integration and samba shares.
Since my last upgrade (ubuntu 18.10 -> 19.04) to samba 4.10.0 and sssd 1.16.3
samba shares are not working anymore and I got the error message in
/var/log/samba/log.smbd:
[2019/05/20 12:09:23.022488, 0]
../../source3/auth/auth_util.c:1386(make_new_session_info_guest)
create_local_token failed: NT_STATUS_NO_MEMORY
[2019/05/20 12:09:23.022542, 0] ../../source3/smbd/server.c:2041(main)
ERROR: failed to setup guest info.
Newer samba versions require a running winbindd but I use SSSD instead of
winbindd which was working before. The samba team says SSSD is not supported
by samba and I should use winbindd. But I want to stay with SSSD.
So what is the recommended SSSD and samba configuration to get samba shares
working while using SSSD?
Or is it not possible anymore to use only SSSD with samba shares without
winbind?
Thanks!
Best regards
/etc/samba/smb.conf:
[global]
disable netbios = Yes
dns proxy = No
domain master = No
kerberos method = system keytab
local master = No
log file = /var/log/samba/log.%m
map to guest = Bad User
max log size = 1000
obey pam restrictions = Yes
pam password change = Yes
panic action = /usr/share/samba/panic-action %d
passwd chat = *Enter\snew\s*\spassword:* %n\n
*Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
passwd program = /usr/bin/passwd %u
realm = DOMAIN
security = ADS
server role = member server
server string = %h %a
syslog = 0
unix password sync = Yes
usershare allow guests = Yes
workgroup = DOMAIN
----- End forwarded message -----
1 year, 9 months
SSSD and Samba
by Dav Banks
Hi There,
I was wondering if anyone has experience with using sssd for samba authentication. I’ve gotten sssd working for getent tools but when a user tries to access a share that they have permissions to via a group they get a permissions denied error. If I add the user directly to the ACL it works fine.
I can post more info but was just wondering if this is a known problem or just something strange with me.
-------------------------------
Dav Banks
1 year, 9 months
SSSD 1.11.5 AD groups vanish
by Jim Burwell
Hi,
I'm experiencing an issue with SSSD 1.11.5 running on Ubuntu 12.04.5
LTS. It's using the AD provider, pointing to AD servers with POSIX
groups configured (ldap_id_mapping = False).
The issue I'm experiencing is that all of a user's groups vanishes from
"id" and "groups" after several hours (appears to be 8-12 hours), except
for his/her login group.
sss_cache -E doesn't fix it
Restarting SSSD doesn't fix it.
However, stopping SSSD, removing /var/lib/sss/db/*, and restarting SSSD
does fix it.
After manually removing the cache files in the DB dir, SSSD will then
see all of a users groups until several hours pass, then, again, all but
his login group will vanish until the files are removed and SSSD
restarted again.
Is this a known issue, perhaps a bug fixed in some future version?
BTW, if you're wondering, the SSSD version I'm using is a backport of
1.11.5 found here in this PPA:
https://launchpad.net/~sssd/+archive/ubuntu/updates
This is how I'm able to use the AD provider with Ubuntu 12. I know it's
not supported, etc. I'm just looking for any insights or suggestions,
or whether a known bug exists for this version that exhibits this
"vanishing groups" behavior.
TIA,
- Jim
1 year, 9 months
sssd renew TGT with ssh gssapi
by Winberg Adam
Ok, so this is an old subject. I know that SSSD can only renew kerberos tickets which it itself has generated which is part of the reason for KCM. But trying out RHEL8, with KCM disabled (because of some weird behaviour reported in a bugzilla ticket), I am affected by this much more than on RHEL7. On RHEL7, sssd manages to renew my kerberos ticket even if I login to the server with sshd GSSAPI and forwarded credentials ('GSSAPIDelegateCredentials yes'). I am not sure why this works on RHEL7 when it according to documentation should not.
On RHEL7, the krb5_child.log clearly shows that SSSD renews my ticket:
(Fri May 31 00:08:45 2019) [[sssd[krb5_child[62512]]]] [main] (0x0400): krb5_child started.
(Fri May 31 00:08:45 2019) [[sssd[krb5_child[62512]]]] [unpack_buffer] (0x1000): total buffer size: [163]
(Fri May 31 00:08:45 2019) [[sssd[krb5_child[62512]]]] [unpack_buffer] (0x0100): cmd [248] uid [60483] gid [102] validate [true] enterprise principal [false] offline [false] UPN [a001329(a)AD.EXAMPLE.COM]
(Fri May 31 00:08:45 2019) [[sssd[krb5_child[62512]]]] [unpack_buffer] (0x0100): ccname: [KEYRING:persistent:60483] old_ccname: [KEYRING:persistent:60483] keytab: [/etc/krb5.keytab]
(Fri May 31 00:08:45 2019) [[sssd[krb5_child[62512]]]] [check_use_fast] (0x0100): Not using FAST.
(Fri May 31 00:08:45 2019) [[sssd[krb5_child[62512]]]] [switch_creds] (0x0200): Switch user to [60483][102].
(Fri May 31 00:08:45 2019) [[sssd[krb5_child[62512]]]] [switch_creds] (0x0200): Switch user to [0][0].
(Fri May 31 00:08:45 2019) [[sssd[krb5_child[62512]]]] [become_user] (0x0200): Trying to become user [60483][102].
(Fri May 31 00:08:45 2019) [[sssd[krb5_child[62512]]]] [main] (0x2000): Running as [60483][102].
(Fri May 31 00:08:45 2019) [[sssd[krb5_child[62512]]]] [k5c_setup] (0x2000): Running as [60483][102].
(Fri May 31 00:08:45 2019) [[sssd[krb5_child[62512]]]] [set_lifetime_options] (0x0100): Renewable lifetime is set to [7d]
(Fri May 31 00:08:45 2019) [[sssd[krb5_child[62512]]]] [set_lifetime_options] (0x0100): No specific lifetime requested.
(Fri May 31 00:08:45 2019) [[sssd[krb5_child[62512]]]] [set_canonicalize_option] (0x0100): Canonicalization is set to [true]
(Fri May 31 00:08:45 2019) [[sssd[krb5_child[62512]]]] [main] (0x0400): Will perform ticket renewal
(Fri May 31 00:08:45 2019) [[sssd[krb5_child[62512]]]] [renew_tgt_child] (0x1000): Renewing a ticket
(Fri May 31 00:08:45 2019) [[sssd[krb5_child[62512]]]] [validate_tgt] (0x2000): Found keytab entry with the realm of the credential.
(Fri May 31 00:08:45 2019) [[sssd[krb5_child[62512]]]] [validate_tgt] (0x0400): TGT verified using key for [LXSERV940$(a)AD.EXAMPLE.COM].
(Fri May 31 00:08:45 2019) [[sssd[krb5_child[62512]]]] [sss_send_pac] (0x0400): PAC responder contacted. It might take a bit of time in case the cache is not up to date.
(Fri May 31 00:08:45 2019) [[sssd[krb5_child[62512]]]] [k5c_send_data] (0x0200): Received error code 0
(Fri May 31 00:08:45 2019) [[sssd[krb5_child[62512]]]] [pack_response_packet] (0x2000): response packet size: [115]
(Fri May 31 00:08:45 2019) [[sssd[krb5_child[62512]]]] [main] (0x0400): krb5_child completed successfully
And as I said, this ticket is forwarded via SSH (logging in to the server via ssh with sssd debugging on yields no log at all from krb5_child, so SSSD is not involved in getting the ticket).
So, how does this work on RHEL7 and why does it not work on RHEL8?
Thanks.
1 year, 9 months
Login with sssd/ad works, but hangs after success
by Jason Pleau
Hi.
Some info:
OS: Linux Mint 18 (Ubuntu 16.04)
SSSD version: 1.13.4-1ubuntu1.13 (Downgraded from 1.13.4-1ubuntu1.14
to test is their new update broke something)
AD is on Windows Server (not sure which version).
Everything was working fine until this morning, I'm not aware if
anything changed on the Windows server.
Situation:
If I try to login with an AD user: su myuser(a)domain.com
I see this in log (/var/log/auth.log)
pam_sss(su:auth): authentication success; logname= uid=1005 euid=0
tty=/dev/pts/2 ruser=myuser rhost= user=myuser(a)domain.com
But the shell just hangs there for about 45 seconds and then spits out
"su: Authentication service cannot retrieve authentication info"
I noticed everytime I try this a new line appears in /var/log/sssd/sssd_nss.log:
(Thu May 23 12:02:14 2019) [sssd[nss]] [id_callback] (0x0010): The
Monitor returned an error [org.freedesktop.DBus.Error.NoReply]
if I try a wrong password I immediately get an authentication failure.
Any ideas on what I could try to fix this?
Thanks.
1 year, 9 months
Stupid question on ldap_user_email
by John Hearns
I have a test system which authenticates using sssd and an LDAP provider.
So far so good!
In my LDAP object there is the field 'mail' which is my correct email
address.
I know I can get this using an ldapsearch.
However I am asking if there is any clean and small utility which will
print this out?
I am asking as obviously scripts sometimes want to send email.
In sssd.conf there s the field ldap_user_email
How would this be queried?
1 year, 9 months
group memberships not updating
by Toby Blake
Hi,
We have noticed an issue where group memberships are not being updated
on a significant number of our machines.
It appears that this has been reported in the following two bug reports:
https://pagure.io/SSSD/sssd/issue/3869
https://pagure.io/SSSD/sssd/issue/3886
There hasn't been any activity on these for a few months now, so I thought
I would add a me-too, and offer to do any debugging necessary.
Thanks
Toby Blake
School of Informatics
University of Edinburgh
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
1 year, 9 months