I wonder if it's possible to get a little help/debugging with the config of my sssd.conf for nested group membership.
We're using LDAP (provided via an AD 2003 forest and the SFU schema) and Kerberos. It works fine with nss_ldap on RHEL and returns all groups a user is a memberOf.
The following msSFU attributes are used (although not populated for all users and groups):
Our sssd.conf (sanitised) is the following:
description = LDAP domain with AD server
id_provider = ldap
auth_provider = krb5
hpass_provider = krb5
cache_credentials = True
ldap_schema = rfc2307
ldap_id_use_start_tls = False
ldap_uri = ldap://SUB.DOMAIN.COM/
ldap_search_base = dc=SUB,dc=DOMAIN,dc=COM
ldap_default_bind_dn = BINDUSER@SUB
ldap_default_authtok_type = password
ldap_default_authtok = PASSWORD
ldap_user_object_class = user
ldap_user_search_base = OU=SITEUsers,DC=SUB,DC=DOMAIN,DC=COM
ldap_user_name = sAMAccountName
ldap_user_uid_number = msSFU30UidNumber
ldap_user_gid_number = msSFU30GidNumber
ldap_user_home_directory = msSFU30HomeDirectory
ldap_user_shell = msSFU30LoginShell
ldap_user_fullname = displayName
ldap_user_gecos = displayName
ldap_user_member_of = memberOf
ldap_group_search_base = OU=SITEGroups,DC=SUB,DC=DOMAIN,DC=COM
ldap_group_object_class = group
ldap_group_name = cn
ldap_group_gid_number = msSFU30GidNumber
ldap_force_upper_case_realm = True
ldap_tls_cacertdir = /etc/openldap/cacerts
krb5_kpasswd = DC1.SUB.DOMAIN.COM:749
krb5_realm = SUB.DOMAIN.COM
krb5_kdcip = DC1.SUB.DOMAIN.COM:88
The ldap_schema is set at rfc2307 since rfc2307bis does not appear to work at all when calling:
getent group GROUP_NAME ---- Returns blank
getent passwd USER_NAME ---- Returns all user attributes and the group entry (GID) msSFU30GidNumber but no group name
Setting ldap_group_member = member breaks the group name being looked up also on rfc2307 . A minimal configuration doesn't appear to help either.
I've attached 4 debug6 files (sanitised).
Two for rfc2307 and two for rfc2307bis - with and without the ldap_group_member being specified.
The Linux command ran was:
I would have expected it to output two groups cbu (2004) and comp (2000) for THE_USER.
If anyone could shed some light onto why the specification of ldap_group_member is a problem and why nested groups aren't working what I need to do to make it do that'd be fantastic.
during the GSSAPI initialisation in the LDAP provider the deprecated
option krb5_kdcip was still used. The patch replaces it with krb5_server
and a fall-back to krb5_kdcip.
This patch should fix trac ticket #692.
these two patches add support for FAST to the Kerberos provider as
requested in trac ticket #237. The first patch just modifies some helper
functions in krb5_child so that they can be used by the second patch.
We support FAST only with MIT Kerberos 1.8 or later, because with 1.7 it
is not possilbe to implement the 'try' option anthentication would fail
if the server does not support FAST.
This set of patches allows SSSD to use the more reliable entryUSN
against FreeIPA (and USNchanged against AD) when performing
If entryUSN(USNchanged) is not detected as available by checking rootdse
for lastUSN(highestCommittedUSN) then we fall back to use
modifyTimestamp which is fine in non-multimaster setups.
This set comprises 4 patches.
1. pass sdap_id_ctx to sdap_id_op functions (needed later).
2. cleanup unused vars and functions about rootdse to avoid confusion
3. add connection checks to test if USNs are available.
4. Change the code around to use the best USN method available and
fallback to the previous modifyTimestamp if not.
These pacthes have been briefly tested against a FreeIPA server with
the entryUSN configuration patch (still unpushed upstream) and all seem
to working fine.
Simo Sorce * Red Hat, Inc * New York
-----BEGIN PGP SIGNED MESSAGE-----
Patch 0001: Make sure we install sss_obfuscate as executable. Previously
it was being dropped in place without executable bits.
Patch 0002: Move all of the SSSD userspace tools into their own
subpackage in the sssd.spec.in
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
these two patches aim to fix trac ticket #672. While the first patch
only makes a utility function public the second adds some new layers to
the LDAP access provider. I've tried to make the changes in a way to
make it easy to add new rules (#670) and new expire policies (#673,
I would like to ask the reviewers to check if the new code is really as
flexible as I think and if it enough to evaluate the shadow expire
attribute here. TIA