Hi
"getent group <name>" does not give any output at all. However "getent passwd" looks correctly up in the AD:
$ getent passwd zmir2 zmir2:*:2956636:100:Hans Schou:/home/zmir2:/bin/bash $ grep -c ^zmir2 /etc/passwd 0
nsswitch looks fine: $ egrep "^(group|passwd)" /etc/nsswitch.conf passwd: files sss group: files sss
SSO is working fine with both ssh and samba share.
$ realm list foo.org type: kerberos realm-name: FOO.ORG domain-name: foo.org configured: kerberos-member server-software: active-directory client-software: winbind required-package: oddjob-mkhomedir required-package: oddjob required-package: samba-winbind-clients required-package: samba-winbind required-package: samba-common-tools login-formats: %U login-policy: allow-any-login foo.org type: kerberos realm-name: FOO.ORG domain-name: foo.org configured: kerberos-member server-software: active-directory client-software: sssd required-package: oddjob required-package: oddjob-mkhomedir required-package: sssd required-package: adcli required-package: samba-common-tools login-formats: %U login-policy: allow-realm-logins
# cat /etc/sssd/sssd.conf [sssd] domains = foo.org config_file_version = 2 services = nss, pam [domain/foo.org] ad_domain = foo.org krb5_realm = FOO.ORG 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 = False use_fully_qualified_names = False fallback_homedir = /home/%u access_provider = ad
All on Red Hat 7.6.
The goal is to use an AD group in a samba share but it obviously does not lookup groups in the AD, only specific users.
On Fri, Mar 29, 2019 at 9:25 AM Hans Schou hsc@miracle.dk wrote:
"getent group <name>" does not give any output at all. However "getent passwd" looks correctly up in the AD:
$ getent passwd zmir2 zmir2:*:2956636:100:Hans Schou:/home/zmir2:/bin/bash $ grep -c ^zmir2 /etc/passwd 0
nsswitch looks fine: $ egrep "^(group|passwd)" /etc/nsswitch.conf passwd: files sss group: files sss
…
# cat /etc/sssd/sssd.conf [sssd] domains = foo.org config_file_version = 2 services = nss, pam [domain/foo.org] ad_domain = foo.org krb5_realm = FOO.ORG 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 = False use_fully_qualified_names = False fallback_homedir = /home/%u access_provider = ad
All on Red Hat 7.6.
The goal is to use an AD group in a samba share but it obviously does not lookup groups in the AD, only specific users.
Two things to check:
1. You are setting ldap_id_mapping = False, so that means sssd will only map groups that have the gidNumber attribute. If there is no gidNumber attribute on the group, sssd ignores it.
2. sssd only maps only security groups (universal, domain local, global).
In terms of #2, here are the AD group types, with an asterisk next to the ones that sssd maps:
* groupType: -2147483646 (global security group) * groupType: -2147483644 (domain local security group) groupType: -2147483643 (builtin group) * groupType: -2147483640 (universal security group) groupType: 2 (global distribution group) groupType: 4 (local distribution group) groupType: 8 (universal distribution group)
If you want sssd to map a universal distribution group, you will need to change it to be a mail-enabled universal security group instead.
On Fri, 29 Mar 2019 at 16:49, James Ralston ralston@pobox.com wrote:
On Fri, Mar 29, 2019 at 9:25 AM Hans Schou hsc@miracle.dk wrote:
# cat /etc/sssd/sssd.conf
...
[domain/foo.org]
...
ldap_id_mapping = False
...
1. You are setting ldap_id_mapping = False, so that means sssd will
only map groups that have the gidNumber attribute. If there is no gidNumber attribute on the group, sssd ignores it.
Yes, that was the problem. Changed to True and it is working.
It was the default value and I guess there must be a good explanation for having it that way.
Thanks.
On Mon, Apr 1, 2019 at 2:18 AM Hans Schou hsc@miracle.dk wrote:
On Fri, 29 Mar 2019 at 16:49, James Ralston ralston@pobox.com wrote:
- You are setting ldap_id_mapping = False, so that means sssd will only map groups that have the gidNumber attribute. If there is no gidNumber attribute on the group, sssd ignores it.
Yes, that was the problem. Changed to True and it is working.
It was the default value and I guess there must be a good explanation for having it that way.
Beware: if you were getting successful user lookups with ldap_id_mapping = false, almost certainly, it was because those user objects in AD had POSIX attributes (uidNumber, gidNumber, loginShell) set.
Setting ldap_id_mapping = true will *change* the uid and gid values that sssd returns for those users, because with LDAP id mapping, sssd is no longer using the POSIX attributes to determine uid/gid values; it is using a mapping algorithm based on the account SID/RID value. (See the "Mapping Algorithm" section of sssd-ad(5).)
If your site has already started down the road of using POSIX attributes in AD, then you have two choices:
1. Set ldap_id_mapping = false to continue to use the POSIX attributes, and ensure all user/group objects in AD that need to be visible via sssd have them.
2. Set ldap_id_mapping = true, and accept that this will change the uid/gid values of all user/group objects from whatever they were set to using POSIX attributes (uidNumber and gidNumber, specifically).
For a new site, ldap_id_mapping = true is arguably the best way to go, but once you have started down the POSIX attributes path, switching to ldap_id_mapping = true can cause a large amount of breakage.
Also, for the record, ldap_id_mapping = true is the default for id_provider = ad. (This is also covered in sssd-ad(5).)
sssd-users@lists.fedorahosted.org
-
Hans Schou -
James Ralston