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 week, 3 days
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 month
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
6 months, 1 week
sssd[be[1320]: Backend is offline
by Harald Dunkel
Hi folks,
sssd 1.16.3-1 (rebuilt for Debian 9), systemd
At boot time sssd_nss fails to initialize. systemctl status sssd
shows
root@srvl061:~# systemctl status sssd
* sssd.service - System Security Services Daemon
Loaded: loaded (/lib/systemd/system/sssd.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2018-11-22 11:57:30 CET; 46s ago
Main PID: 1312 (sssd)
Tasks: 5 (limit: 7372)
CGroup: /system.slice/sssd.service
|-1312 /usr/sbin/sssd -i --logger=files
|-1345 /usr/lib/x86_64-linux-gnu/sssd/sssd_be --domain example.com --uid 0 --gid 0 --logger=files
|-1533 /usr/lib/x86_64-linux-gnu/sssd/sssd_nss --uid 0 --gid 0 --logger=files
|-1534 /usr/lib/x86_64-linux-gnu/sssd/sssd_pam --uid 0 --gid 0 --logger=files
`-1535 /usr/lib/x86_64-linux-gnu/sssd/sssd_pac --uid 0 --gid 0 --logger=files
Nov 22 11:57:25 srvl061.ac.example.com systemd[1]: Starting System Security Services Daemon...
Nov 22 11:57:25 srvl061.ac.example.com sssd[1312]: Starting up
Nov 22 11:57:25 srvl061.ac.example.com sssd[be[1345]: Starting up
Nov 22 11:57:30 srvl061.ac.example.com sssd[1533]: Starting up
Nov 22 11:57:30 srvl061.ac.example.com sssd[1534]: Starting up
Nov 22 11:57:30 srvl061.ac.example.com sssd[1535]: Starting up
Nov 22 11:57:30 srvl061.ac.example.com systemd[1]: Started System Security Services Daemon.
Nov 22 11:57:45 srvl061.ac.example.com sssd[be[1345]: Backend is offline
Apparently this is a problem of resolvconf generating /etc/\
resolv.conf at boot time. If I replace it by a static file, then
the problem is gone.
Question is, how can I tell systemd to wait for resolv.conf?
Is there some timeout in the backend I could adjust? Does it
wait for the network at all?
Every helpful comment is highly appreciated
Regards
Harri
7 months
Is it possible to use the full username+domain name when using proxy_pam_target ?
by David Fournier
I've been tasked with adding two-factor authentication to one of our servers that will be exposed to the net. Requirements include using an existing 2FA system which uses RADIUS for authentication, and that users from both the client domain (unicorn.local) and the management domain (rainbow.local) can log in. The RADIUS server is the same for both domains.
I believed I could use sssd with auth_provider = proxy and then specify my RADIUS pam module in the proxy_pam_target, however after running tests it appears that sssd only provides the username part of the fully qualified username to proxy_pam_target (i.e. if the user is 'stranger(a)rainbow.local', only 'stranger' is passed to the modules specified in proxy_pam_target).
Is there a way/switch/configuration option that I would have missed that would allow passing the full username to my pam target?
Content of /etc/sssd/sssd.conf -------------------------------
[sssd]
domains = unicorn.local,rainbow.local
config_file_version = 2
services = nss, pam
full_name_format = %1$s@%2$s
[domain/unicorn.local]
id_provider = ldap
ldap_id_mapping = True
ldap_schema = AD
ldap_group_nesting_level = 8
ldap_uri = ldap://pradad1001.unicorn.local
ldap_search_base = dc=unicorn,dc=local
ldap_default_bind_dn = CN=linuxldap,CN=Users,DC=unicorn,DC=local
ldap_default_authtok_type = password
ldap_default_authtok = *************
default_shell = /bin/bash
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = simple
simple_allow_groups = L_Unicorn_SSH_Admins
auth_provider = proxy
proxy_pam_target = sssdauthproxy
[domain/rainbow.local]
id_provider = ldap
ldap_id_mapping = True
ldap_schema = AD
ldap_group_nesting_level = 8
ldap_uri = ldap://otherad2001.rainbow.local
ldap_search_base = dc=rainbow,dc=local
ldap_default_bind_dn = CN=linuxldap,CN=Users,DC=rainbow,DC=local
ldap_default_authtok_type = password
ldap_default_authtok = **************
default_shell = /bin/bash
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = simple
simple_allow_groups = L_Rainbow_SSH_Admins
auth_provider = proxy
proxy_pam_target = sssdauthproxy
End Content of /etc/sssd/sssd.conf -------------------------------
Content of sssdauthproxy -------------------------------------
auth required pam_warn.so
auth required pam_radius_auth.so
End Content of sssdauthproxy -------------------------------------
Note that I added pam_warn.so right before pam_sss.so, the output shows the difference in users:
Apr 24 17:16:58 SAclt001 sshd[15553]: pam_warn(sshd:auth): function=[pam_sm_authenticate] service=[sshd] terminal=[ssh] user=[stranger(a)rainbow.local] ruser=[<unknown>] rhost=[bbb.bbb.bbb.bb]
Apr 24 17:16:58 SAclt001 proxy_child: pam_warn(sssdauthproxy:auth): function=[pam_sm_authenticate] service=[sssdauthproxy] terminal=[ssh] user=[stranger] ruser=[] rhost=[bbb.bbb.bbb.bb]
Thanks for reading that far!
7 months, 1 week
password change fails for user with 'change password on next login' selected in AD
by soham chakraborty
Hi,
I have the following issue.
1) I have created a new user in AD.
2) When forcing user to change password at next logon in AD, password change does not work from the Linux client.
But, if I don't force the user to change password at next logon in AD, then after logging in, I can change password of the user with passwd command.
Is this normal? If not, why is this happening?
My sssd.conf file is:
# cat /etc/sssd/sssd.conf
[sssd]
domains = ad.corp.org
config_file_version = 2
services = nss, pam, ssh
debug_level = 9
[pam]
pam_pwd_expiration_warning = 7
offline_credentials_expiration = 5
debug_level = 9
[domain/ad.corp.org]
id_provider = ad
auth_provider = ad
chpass_provider = ad
access_provider = simple
ad_server = ad-server1, ad-server2, ad-server3
cache_credentials = true
krb5_store_password_if_offline = true
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = false
fallback_homedir = /home/%u
simple_allow_groups = foo, bar, baz
debug_level = 9
7 months, 1 week
Re: Problems with subdomains_provider & group membership
by Jakub Hrozek
On Tue, Apr 23, 2019 at 12:03:20PM +0000, Ondrej Valousek wrote:
> Hi List,
> I just noticed that sssd is unable to detect any groups user belongs to after I set
> Subdomains_provider = none
> In my sssd.conf
>
> Using AD provider, using token groups, not using fully qualified names.
> Is this an expected behavior?
> Note I switched subdomain_provider off as otherwise sssd keeps poking around and requesting domain controllers which are not available.
btw this was solved by using ad_enabled_domains=joined.domain
7 months, 1 week
sss_obfuscate and conf.d
by Mario Rossi
Hi sssd users!
I am trying to encrypt a password via sss_obfuscate , but the binary
refuses to work to conf.d/ folder configs
root@sd7[/etc/sssd]# sss_obfuscate -d 'LDAP' -f sssd.conf.se
Enter password:
Re-enter password:
No such domain LDAP
If I append the contents of conf.d/LDAP.conf to sssd.conf.se, it works
as expected
root@sd7[/etc/sssd]# sss_obfuscate -d 'LDAP' -f sssd.conf.se
Enter password:
Re-enter password:
root@sd7[/etc/sssd]#
root@sd7[/etc/sssd]# rpm -q sssd
sssd-1.16.2-13.el7_6.5.x86_64
root@sd7[/etc/sssd]# cat /etc/centos-release
CentOS Linux release 7.6.1810 (Core)
Thanks
7 months, 1 week
Windows 10 Roaming Profile Issue
by Bob Smith
Hi,
On Windows Server 2008 R2 Enterprise, Profiles path is \\fs\profiles\rprofile
On Centos Version 7, Samba Version 4.7.1 and ROLE_DOMAIN_MEMBER
I'm getting Event ID 1521 on Windows 10 PC and roaming profile is not working.
I was told the roaming profile works with winbind, but I'm using sssd. My issue is that Domain Admins is unknown to the Unix OS. Does roaming profile work with sssd?
Thanks!
B.
7 months, 2 weeks
