[SSSD-users] id command not returning group names. only sid is returned.

Lukas Slebodnik lslebodn at redhat.com
Tue Aug 25 16:31:49 UTC 2015


On (25/08/15 11:27), Abhijit Tikekar wrote:
>Thanks for the assistance.
>
>
>In one of the setups, with Version 1.12.4, we were able to resolve this by
>adding ldap_use_tokengroups = False
> to sssd/conf. ( https://fedorahosted.org/sssd/ticket/2472)
>After adding this, all the group names are being resolved correctly and
>only GID's are being recorded.(No SID's). Since it's now resolving names
>correctly, sudo works as well.
>
>On another machine, with the exact same version, this change did not work
>as expected. It does pull only GID's now for the "id" command, but a
>majority of the group names are not resolved(Only GID is displayed). I've
>compared all the configurations files and they are identical. Both are
>looking at the same domain controller and have same ldap search base
>configured in sssd.conf. Also cleared the cache but "id" result stays the
>same.
>
>The only difference between these two is that the first one(where sssd
>works fine now) was created with CentOS 6.7/2.6.32-573. The other one was
>updated to latest from 6.6/504.
>
>Steps used to Join:
>
>
>1. Configured krb5.conf
>2. Configured smb.conf
>3. kinit <username>
>4. net ads join -k
>5. kinit -k HOSTNAME$
>6. net ads keytab create
>7. net ads keytab add host/hostname.domain at DOMAIN
>
>   Testing the join with "net ads testjoin"
>
>
>8. Configured sssd.conf
>9. authconfig --enablesssd --enablesssdauth --enablemkhomedir --update
>10.Configured /etc/nsswitch to use sss for sudo as well. Added "sudoers:
>files sss"
>
>11.service sssd start
>
>
>*SSSD Configuration:*
>
>[sssd]
>domains =
           ^^
          There is amissing name of existing domain
       Is it result of sanitisation of sssd.conf?
>services = nss, pam, sudo
>config_file_version = 2
>debug_level = 0
>
>[nss]
>
>[pam]
>
>[sudo]
>debug_level=2
>
>[domain/]
        ^^
       There is a missing name.
       Is it result of sanitisation of sssd.conf?
       BTW You can replace it with example.com for such purpose.  

>debug_level=4
>ad_server =
>id_provider = ad
>auth_provider = ad
>access_provider = ldap
>sudo_provider = ad
>ldap_id_mapping = true
>*ldap_use_tokengroups = False*
>ldap_sasl_mech = GSSAPI
>krb5_realm =
>ldap_uri = ldap://
>ldap_sudo_search_base =
>ldap_user_search_base =
>ldap_user_object_class = user
>ldap_group_search_base =
>ldap_group_object_class = group
>ldap_user_home_directory = unixHomeDirectory
>ldap_user_principal = userPrincipalName
>ldap_access_order = filter, expire
>ldap_account_expire_policy = ad
>ldap_access_filter = memberOf=
>cache_credentials = true
>override_homedir = /home/%d/%u
>default_shell = /bin/bash
>ldap_schema = ad
>
>
>@ Pavel.. Does Debug level needs to be anything specific. I tried level 4
>but did not see anything peculiar in the logs. Probably needs higher. I'll
>sanitize logs little bit and will post them here.
>
There should be at least some messages with debug level 4
but for troubleshooting it's better to use the highest value (9)

LS


More information about the sssd-users mailing list