The reason I ask is because I use a bunch of storage appliances that offer Secure-NFS (NETAPP, EMC UNITY, etc.), but they only support NIS, IDMU, RFC2307, and RFC2307bis style Identity Mapping, all of which require manual assignment of UID/GID numbers to objects in LDAP, which is untenable for large environments. Microsoft even removed Unix Attribute editor from their LDAP GUI for the RFC2307 attributes in Windows Server 2016 to push people away from using rfc2307.
I would like to be able to provide a link to an RFC or design document describing the SSSD ID Mapping algorithm so that these 3rd party vendors can incorporate an identical identity mapping algorithm into their products, so that I can use their Secure-NFS product in conjunction with sssd and have the uid and gid numbers match up with the other Linux hosts in our environment.
I worked an sssd configuration case with my OS vendor in the last 3 weeks.
I have resolution and it's working 100% correctly.
Just wanted to double-check. A second set of eyes to verify this solution
is all above board.
The problem manifested itself in our multi-domain AD forest with Posix
Attributes. One parent domain that has a transitive trust with 4
(regional) child domains.
Thus all 4 child domains trust each other. All users and groups are stored
in the 4 child domains.
The original problem was that I was disabling subdomains_provider and
explicitly defining each of the 4 child domains. I had:
domains = amer.company.com,apac.company.com, ....
That worked great -- for everything except universal groups. Universal
groups exist in the first domain in which they're created, but they're
replicated to each domain. However, each child domain for this group's
membership only has the local users of that domain. The full universal
group membership is stored only in the global catalog (GC).
The problem? The GC lookups are done in the subdomain_provider's code. So
by disabling subdomains_provider, I was disabling GC lookups. Thus, I was
getting the group membership only of the first child domain queried (
What that amounted to is that remote support personnel couldn't log into
local boxes, because they weren't listed in the allowed groups.
So I re-wrote the sssd.conf file and only explicitly defined the one local
child domain. I left on subdomain_provider, so it auto-discovered the
other domains (sssctl domain-list confirms this).
domains = amer.company.com
ldap_search_base = dc=AMER,dc=COMPANY,dc=COM
ldap_search_base = dc=APAC,dc=COMPANY,dc=COM
So then, universal groups showed all memberships. The only remaining
problem was that now it was only searching the amer.company.com child
domain. So while a remote user was listed as a member of an allowed
universal group, the details of that user's account was not known.
I couldn't add these auto-discovered domains to the "domains" line. (only
domains explicitly defined in sssd.conf file are allowed in this line
apparently). But I was able to add:
domain_resolution_order = amer.company.com, emea.company.com,
apac.company.com, japn.company.com, company.com
Now all works 100%.
Is this all legit? Do you see any problems with above final sssd.conf
Following through the troubleshooting guide and getting stuck on step 3.
Absolutely no output occurs in the sssd log (good or bad) even with [nss] debug_level=6. Running strace on getent I can confirm that the sss library is getting loaded.
open("/lib64/libnss_sss.so.2", O_RDONLY) = 3
open("/lib64/libnss3.so", O_RDONLY) = 3
open("/lib64/libnssutil3.so", O_RDONLY) = 3
Looking in the sssd output I can see that the nss responder has started
(Thu Oct 10 22:22:50 2019) [sssd[nss]] [sss_process_init] (0x0400): Responder initialization complete (explicitly configured)
What other steps can be preformed to help debug this issue? We are using a custom distribution with an older gcc/glibc toolchain with the following configuration.
I am running sssd-1.16.4-21.el7.x86_64 (from CR repo) on a CentOS 7 client. I authenticate to AD 2016, and control access to servers using GPO. For some reason, a completely unprivileged user in AD is allowed to login, and I'd like to understand why.
Here's a sanitized sssd.conf:
domains = prd.domain.com
config_file_version = 2
services = nss, pam, sudo
full_name_format = %1$s
default_domain_suffix = prd.domain.com
debug_level = 9
ad_domain = prd.domain.com
ad_site = XX1
ad_server = dc000.prd.domain.com, dc001.prd.domain.com
krb5_realm = PRD.DOMAIN.COM
realmd_tags = manages-system joined-with-samba
cache_credentials = false
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = true
use_fully_qualified_names = True
fallback_homedir = /home/%u
access_provider = ad
ldap_sudo_search_base = DC=domain,DC=com
entry_cache_sudo_timeout = 10
enumerate = true
dyndns_update = false
ad_gpo_access_control = enforcing
ldap_idmap_default_domain_sid = S-1-5-21-6607581186-1994368826-2594857426
ldap_idmap_default_domain = prd.domain.com
ad_gpo_implicit_deny = true
auto_private_groups = true
ad_gpo_ignore_unreadable = true
When I try to SSH to the client using my unprivileged user, I am getting the following output from the SSSD debug:
[sysdb_gpo_get_gpo_result_setting] (0x0400): key [SeDenyRemoteInteractiveLogonRight] value [*S-1-5-32-546]
[ad_gpo_access_check] (0x0400): RESULTANT POLICY:
[ad_gpo_access_check] (0x0400): gpo_map_type: Remote Interactive
[ad_gpo_access_check] (0x0400): allowed_size = 0
[ad_gpo_access_check] (0x0400): denied_size = 1
[ad_gpo_access_check] (0x0400): denied_sids = S-1-5-32-546
... snip ...
[ad_gpo_access_check] (0x0400): CURRENT USER:
[ad_gpo_access_check] (0x0400): user_sid = S-1-5-21-6607581186-1994368826-2594857426-2570
[ad_gpo_access_check] (0x0400): group_sids = S-1-5-21-6607581186-1994368826-2594857426-513
[ad_gpo_access_check] (0x0400): group_sids = S-1-5-11
[ad_gpo_access_check] (0x0400): POLICY DECISION:
[ad_gpo_access_check] (0x0400): access_granted = 1
[ad_gpo_access_check] (0x0400): access_denied = 0
[ad_gpo_access_done] (0x0400): GPO-based access control successful.
I'm trying to understand why this user is being granted access. I find it especially confusing as there is clearly one deny sid and no allow sids detected. The wanted behaviour is that the user should be denied access as long as I've not explicitly allowed it in AD.
In order to ssh using AD account i had to comment out this line in password-auth:
password-auth-ac:account [default=bad success=ok user_unknown=ignore] pam_sss.so
prior to doing so i was getting this error in /etc/log/secure:
pam_sss(sshd:account): Access denied for user : 4 (system error)
and my ssh session immediately terminated. has anyone else seen this and know why pam_sss.so is upset?
Implemented AD/KRB/SSSD with both RH6 and RH7.
RH7 no issues, as we are using auto_private_groups that was added to 1.16.1.
In RH6 the issue ( sssd 1.13 ) is, that all users getting the same groups and it is a clear security gap.
The only way to avoid this, based on the KB articles, is to use AD posix attributes. If we don't waht to use this setup, is there any other recommended way ?
The example of user/group representation, where all users getting the same gid=273200513(domain users) :
id username uid=2755191114(ncircle) gid=273200513(domain users) groups=273200513(domain users)