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, 3 months
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
1 year, 9 months
Failed gssapi-with-mic
by Sergei Gerasenko
Hi,
I've run into a dead end debugging a case of passwordless authentication between two IPA'd hosts. Running `sshd -p 5000 -d` on the receiving host (let's call it HOST_B), I see this:
```
Postponed gssapi-with-mic for postgres from x.x.x.x port 57607 ssh2 [preauth]
debug1: Received some client credentials
debug1: ssh_gssapi_k5login_exists: Checking existence of file /home/USER/.k5login
Failed gssapi-with-mic for postgres from x.x.x.x port 57607 ssh2
```
The client then gets an interactive password prompt. Here are some facts and things I've tried:
* If I put the user into `.k5login` on the receiving host and it works.
* The receiving host is correctly enrolled into IPA. I can ssh from it to other hosts using GSSAPI.
* I can issue `kvno host/HOST_B` on the connecting host and I get a service ticket.
* It looks like all this happens before any pam stuff kicks in (?). So I'm ruling PAM issues out.
* No errors in the logs of the KDCs.
* The ticket from the connecting host is not expired.
* The sssd version is 1.16.0.
* Turning up the debugging in sssd with `debug_level = 7` for the domain section doesn't reveal anything obvious.
What else could I check?
Thanks for any ideas,
SG
2 years, 2 months
Access alternative yubikey slots
by Orion Poplawski
I configured a YubiKey on Windows using the YubiKey minidriver with the
following certificates:
- my "orion" certificate - went into slot 9a PIV Auth
- A MacOS keychain cert per their docs - when into slot 9d Key Management
- Another auth certificate for "orion-admin" - went into slot 82
I'm able to authenticate on Windows as either orion or orion-admin, but on
Linux with sssd it does not see the orion-admin certificate. What needs to
happen to support this?
Thanks!
--
Orion Poplawski
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/
2 years, 2 months
Problem with resolving unqualified group names
by Ondrej Valousek
Hi List,
I have noticed that in my case both
getent passwd <username>@<domain> and getent passwd <username>
works, but
getent group <groupname>@<domain>
does not, only:
getent group <groupname>
works.
Is that expected behavior?
Thanks,
Ondrej
2 years, 3 months
Re: Fwd: Re: disable querying trusted "foreign" domains
by Michael Ströder
Sumit,
thanks for your answer.
Sumit Bose <sbose(a)redhat.com> wrote:
> Michael Ströder wrote:
>> I'm currently trouble-shooting performance issues on CentOS 6.10 running
>> sssd 1.13.3 using sssd-ad as backend.
>>
>> Enumeration is already disabled.
>>
>> Also these options were set (DNS names obfuscated):
>> ad_enabled_domains = ad1.example.com
>> ad_server = dc1.ad1.example.com, dc2.ad1.example.com
>> ad_enable_dns_sites = false
>>
>> Looking sssd still asks various naming contexts of the *many* other
>> trusted domains.
>>
>> Any clue how to effectively disable all "foreign" lookups?
>
> ad_enabled_domains will ignore requests looking up users and groups from
> domains not listed but I guess if a user from domain ad1.example.com is
> a member of a group from ad2.example.com this group will still be looked
> up.
Fortunately every group needed should be in forest ad1.example.com.
> Setting 'subdomain_provider = none' should disable all kind of domain
> discovery.
I couldn't find this in the man pages.
Where is this parameter documented?
Is it already available in package sssd-1.13.3-60.el6.x86_64 on
RHEL/CentOS 6.10?
Is it a global or a domain-specific parameter?
We tried that (both global and domain), but no change.
Still all domains are tried which are found beneath
DC=DomainDnsZones,DC=ad1,DC=example,DC=com. My impression is also that
this is done recursively leading to sssd contacting 70+ domains...
> But depending on the other stetting you might e.g. have to
> set ldap_idmap_default_domain_sid to tell SSSD about the domain SID of
> the local domain to make automatic id-mapping work.
No ID-mapping needed in this case. The MS AD entries contains uidNumber
and gidNumber attributes.
Ciao, Michael.
2 years, 3 months
sssd with sudo and non posix groups
by Leonard Lawton
I have a group in ldap(I'm using 389DS) called "_all" which has a
groupofnames object class. Members are stored with the uniquemember
attrtibute. The users in the group are able to login fine via ssh using
this setup. However, I can't seem to figure out how to get sudo(via
ldap) to work with my needs.
The problem seems to be that I am using uniquemember which my
configuration is not interpreting. I can't use rfc2307 and fall back to
posix groups(and memberUID) only as I rely heavily on the groupofnames's
functionality, so I really need to keep that. How can I configure sssd
to let me use sudo while having a groupofnames as an authoritative source?
Here is my config:
[domain/dingos]
ldap_schema = rfc2307bis
ldap_group_search_base = dc=dingos?sub?
ldap_user_search_base = ou=people,dc=dingos
ldap_uri = ldaps://ldap-server
ldap_tls_cacertdir = /etc/openldap/cacerts
sudo_provider = ldap
ldap_access_filter = (|(memberof=cn=_all,ou=hosts,ou=roles,dc=dingos))
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
cache_credentials = false
access_provider = ldap
debug_level = 0x3ff0
ldap_sudo_search_base = ou=SUDOers,ou=roles,dc=dingos
entry_cache_timeout = 1
[sssd]
config_file_version = 2
services = nss, pam, sudo
domains = dingos
2 years, 3 months
disable querying trusted "foreign" domains
by Michael Ströder
HI!
I'm currently trouble-shooting performance issues on CentOS 6.10 running
sssd 1.13.3 using sssd-ad as backend.
Enumeration is already disabled.
Also these options were set (DNS names obfuscated):
ad_enabled_domains = ad1.example.com
ad_server = dc1.ad1.example.com, dc2.ad1.example.com
ad_enable_dns_sites = false
Looking sssd still asks various naming contexts of the *many* other
trusted domains.
Any clue how to effectively disable all "foreign" lookups?
Ciao, Michael.
2 years, 3 months
