id command not returning group names. only sid is returned.

[Abhijit Tikekar]

Hi,

This is regarding the AD group name resolution in SSSD.

We are using SSSD between CentOS and Microsoft AD. Integration works fine
and users are able to authenticate without any issues. For SSSD
installation, we were just using the Base repo and using yum to install the
latest version available.

Lately we noticed that after user login, the "id" command returns only the
SID's and not the corresponding group name. I checked the installation and
made sure no step was missed. This is causing issues when users use "sudo"
(We have added specific group names under sudoers and the match fails
because no group names were returned.. only SID's)

Previously this used to work fine(Version 1.11.6). but the version
currently being installed via yum is V 1.12.4.

I could not find any reference to such behavior online with respect to V
1.12.4-47 and hence posting here.Has anyone experience similar issues with
this version?

Please advise.

Thanks,

~ Abhi

[Pavel Reichl]

On 08/21/2015 10:30 PM, Abhijit Tikekar wrote:
>  Hi,
>
>  This is regarding the AD group name resolution in SSSD.
>
>  We are using SSSD between CentOS and Microsoft AD. Integration works 
>  fine and users are able to authenticate without any issues. For SSSD 
>  installation, we were just using the Base repo and using yum to 
>  install the latest version available.
>
>  Lately we noticed that after user login, the "id" command returns only 
>  the SID's and not the corresponding group name. I checked the 
>  installation and made sure no step was missed. This is causing issues 
>  when users use "sudo" (We have added specific group names under 
>  sudoers and the match fails because no group names were returned.. 
>  only SID's)
>
>  Previously this used to work fine(Version 1.11.6). but the version 
>  currently being installed via yum is V 1.12.4.
>
>  I could not find any reference to such behavior online with respect to 
>  V 1.12.4-47 and hence posting here.Has anyone experience similar 
>  issues with this version?
>
>  Please advise.
>
>  Thanks,
>
>  ~ Abhi
>
>
>  _______________________________________________
>  sssd-users mailing list
>  sssd-users(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users 
Hello, could you please
set debug_level in domain section and check logs 
in /var/log/sssd ? Feel free to obfuscate the logs and share it. Thanks!

[Lukas Slebodnik]

On (24/08/15 08:38), Pavel Reichl wrote:
> On 08/21/2015 10:30 PM, Abhijit Tikekar wrote:
> >Hi,
> >
> >This is regarding the AD group name resolution in SSSD.
> >
> >We are using SSSD between CentOS and Microsoft AD. Integration works fine
> >and users are able to authenticate without any issues. For SSSD
> >installation, we were just using the Base repo and using yum to install the
> >latest version available.
> >
> >Lately we noticed that after user login, the "id" command returns only the
> >SID's and not the corresponding group name. I checked the installation and
> >made sure no step was missed. This is causing issues when users use "sudo"
> >(We have added specific group names under sudoers and the match fails
> >because no group names were returned.. only SID's)
> >
> >Previously this used to work fine(Version 1.11.6). but the version
> >currently being installed via yum is V 1.12.4.
> >
> >I could not find any reference to such behavior online with respect to V
> >1.12.4-47 and hence posting here.Has anyone experience similar issues with
> >this version?
> > 
I'm not aware of any issues with that version and Active Directory.
I also cannot see a reason whyt there should be SID instead of names.
In most cases, there could be just GID without name, but not with SID.

Could you briefly describe steps used to jopind linux machine to AD?
Could you describe hierarchy of you AD servers?

> >Please advise.
> >
> >Thanks,
> >
> >~ Abhi
> >
> >
> Hello, could you please set debug_level in domain section and check logs in
> /var/log/sssd ? Feel free to obfuscate the logs and share it. Thanks! 
Please also provide sssd configuration file (/etc/sssd/sssd.conf)

@see also upstream troubleshooting wiki page
https://fedorahosted.org/sssd/wiki/Troubleshooting

LS

[Abhijit Tikekar]

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@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 =
services = nss, pam, sudo
config_file_version = 2
debug_level = 0

[nss]

[pam]

[sudo]
debug_level=2

[domain/]
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.

Thanks again,

~ Abhi


On Tue, Aug 25, 2015 at 5:34 AM, Lukas Slebodnik <lslebodn(a)redhat.com&gt;
wrote:

>  On (24/08/15 08:38), Pavel Reichl wrote:
>  >
>  >
>  >On 08/21/2015 10:30 PM, Abhijit Tikekar wrote:
>  >>Hi,
>  >>
>  >>This is regarding the AD group name resolution in SSSD.
>  >>
>  >>We are using SSSD between CentOS and Microsoft AD. Integration works fine
>  >>and users are able to authenticate without any issues. For SSSD
>  >>installation, we were just using the Base repo and using yum to install
>  the
>  >>latest version available.
>  >>
>  >>Lately we noticed that after user login, the "id" command returns only
>  the
>  >>SID's and not the corresponding group name. I checked the installation
>  and
>  >>made sure no step was missed. This is causing issues when users use
>  "sudo"
>  >>(We have added specific group names under sudoers and the match fails
>  >>because no group names were returned.. only SID's)
>  >>
>  >>Previously this used to work fine(Version 1.11.6). but the version
>  >>currently being installed via yum is V 1.12.4.
>  >>
>  >>I could not find any reference to such behavior online with respect to V
>  >>1.12.4-47 and hence posting here.Has anyone experience similar issues
>  with
>  >>this version?
>  >>
>  I'm not aware of any issues with that version and Active Directory.
>  I also cannot see a reason whyt there should be SID instead of names.
>  In most cases, there could be just GID without name, but not with SID.
>
>  Could you briefly describe steps used to jopind linux machine to AD?
>  Could you describe hierarchy of you AD servers?
>
>  >>Please advise.
>  >>
>  >>Thanks,
>  >>
>  >>~ Abhi
>  >>
>  >>
>  >Hello, could you please set debug_level in domain section and check logs
>  in
>  >/var/log/sssd ? Feel free to obfuscate the logs and share it. Thanks!
>
>  Please also provide sssd configuration file (/etc/sssd/sssd.conf)
>
>  @see also upstream troubleshooting wiki page
>  https://fedorahosted.org/sssd/wiki/Troubleshooting
>
>  LS
>  _______________________________________________
>  sssd-users mailing list
>  sssd-users(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>

[Lukas Slebodnik]

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@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

[Abhijit Tikekar]

my bad.. yes.. that was because of sanitization.. Here is the complete
sssd.conf.

Log file after debug level 9 is big and exceeds the mailing list limits. Is
it okay to send it to you directly?

[sssd]
domains = example.com
services = nss, pam, sudo
config_file_version = 2
debug_level = 0

[nss]

[pam]

[sudo]
debug_level=2

[domain/example.com]
debug_level=9
ad_server = server.example.com
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 = EXAMPLE.COM
ldap_uri = ldap://server.example.com
ldap_sudo_search_base = ou=a,ou=b,ou=c HQ,ou=d,ou=e,dc=example,dc=com
ldap_user_search_base = dc=example,dc=com
ldap_user_object_class = user
ldap_group_search_base = ou=a,ou=b,ou=c HQ,ou=d,ou=e,dc=example,dc=com
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=cn=Group_Name,ou=a,ou=b,ou=c
HQ,ou=d,ou=e,dc=example,dc=com
cache_credentials = true
override_homedir = /home/%d/%u
default_shell = /bin/bash
ldap_schema = ad


Many Thanks,

~ Abhi

On Tue, Aug 25, 2015 at 12:31 PM, Lukas Slebodnik <lslebodn(a)redhat.com&gt;
wrote:

>  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@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
>  _______________________________________________
>  sssd-users mailing list
>  sssd-users(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>

[Lukas Slebodnik]

On (25/08/15 16:24), Abhijit Tikekar wrote:
> my bad.. yes.. that was because of sanitization.. Here is the
> complete
> sssd.conf.
>
> Log file after debug level 9 is big and exceeds the mailing list limits. Is
> it okay to send it to you directly?
>  
Sure.

LS

[Abhijit Tikekar]

Hi Lukas/Pavel,

SSSD is now working correctly for us. Following changes were done:

1. We had to add "ldap_use_tokengroups = False" in sssd.conf file. This got
rid of the SID's and now only the GID/group name is retrieved.

2. I believe the reason 'id' only pulled gid's for some groups without the
names was probably because sssd was still keeping hold of the old cache. I
had to manually drop the cache file (/var/lib/sss/db) and then restart sssd
service. After this, the id command displays the data correctly. Had tried
sss_cache -E but that didn't flush the cache it seems..

Thanks again for all the help.

~ Abhi

On Wed, Aug 26, 2015 at 12:55 AM, Lukas Slebodnik <lslebodn(a)redhat.com&gt;
wrote:

>  On (25/08/15 16:24), Abhijit Tikekar wrote:
>  >my bad.. yes.. that was because of sanitization.. Here is the complete
>  >sssd.conf.
>  >
>  >Log file after debug level 9 is big and exceeds the mailing list limits.
>  Is
>  >it okay to send it to you directly?
>  >
>  Sure.
>
>  LS
>  _______________________________________________
>  sssd-users mailing list
>  sssd-users(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>