Fields changed

summary: ldap_group_gid_number overwritten => ldap_group_gid_number overwritten with default value

I forgot the sssd.conf:

[sssd]
domains = XXX.XXX.DOMAIN.COM
services = nss, pam
config_file_version = 2


[domain/XXX.XXX.DOMAIN.COM]
id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = ad
ldap_id_mapping = False
ldap_group_gid_number = extensionAttribute9
debug_level = 7

_comment0: I forgot the sssd.conf:

[sssd]
domains = XXX.XXX.DOMAIN.COM
services = nss, pam
config_file_version = 2

[domain/XXX.XXX.DOMAIN.COM]
id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = ad
ldap_id_mapping = False

ldap_group_gid_number = extensionAttribute9

debug_level = 7
=> 1463154553603797
_comment1: I forgot the sssd.conf:

{{{
[sssd]
domains = XXX.XXX.DOMAIN.COM
services = nss, pam
config_file_version = 2

[domain/XXX.XXX.DOMAIN.COM]
id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = ad
ldap_id_mapping = False

ldap_group_gid_number = extensionAttribute9

debug_level = 7
}}} => 1463154668780453

I can't reproduce this in my setup. Is there any chance the attribute is being overriden for the root domain (or the domain the sssd is enrolled with) but not the child domains? That would be in fact expected, because right now the config file only configures the domain we're enrolled with, not the child domains (we have ticket #2599 that tracks that enhancement).

In my test environment, I first see the main domain being initialized:

(Sun May 15 14:36:51 2016) [sssd[be[win.trust.test]]] [sdap_get_map] (0x0400): Option ldap_user_gid_number has value myowngid

and then the trusted domain, only with defaults:

(Sun May 15 14:36:51 2016) [sssd[be[win.trust.test]]] [sdap_copy_map] (0x0400): Option ldap_user_gid_number has value gidNumber

Notice the first uses sdap_get_map which reads the config file and creates the mappings, but the second uses sdap_copy_map which only copies the default mappings.

I have no other domains configured. The sssd.conf I uploaded is my complete config. Is there a way that the AD servers set this default value? And if so is there a way to ignore it?

_comment0: I have no other domains configured. The sssd.conf I uploaded is my complete config. Is there a way that the AD servers set this default value? => 1463472659751589

The trusted domains are not configured, but discovered automatically. Even from your opening comment I see that the value was correctly overriden for the main domain:

(Fri May 13 17:24:23 2016) [sssd[be[DOMAIN]]] [sdap_get_map] (0x0400): Option ldap_group_gid_number has value extensionAttribute9

But sssd used the default values for the trusted domain:

(Fri May 13 17:24:23 2016) [DOMAIN]]] [sdap_copy_map] (0x0400): Option ldap_group_gid_number has value gidNumber

If you are not using accounts from the other trusted domains, you can disable their autodetection with:

subdomains_provider = none

Please note we are working on a better way to selectively enable/disable domains as part of ticket #2828.

Thanks for your quick reply subdomains_provider = none works like you explained. The custom value is not overwritten by the default value anymore. At least in the log.

However the outcome of this is surprising to me. I overwrite ldap_group_gid_number with the attribute extensionAttribute9 which contains a valid numeric gid e.g. 3536 which my user is also part of. I would expect my gid to be 3536 which is not the case. The primary gid is still the value of gidNumber. I am also loosing all non primary groups of my user.

I deleted /var/lib/sss/db/* to get rid if the cache and the mapping.

Do I misunderstand the meaning of ldap_group_gid_number? Or is there a problem?

No, I would not expect that. I wonder if disabling the tokengroups support with ldap_use_tokengroups would help here? If not, it would be best to see the logs.

Without logs, I'm afraid I can't really help you here. The logs might show what are the searches actually looking for and what the server is returning.

I'm sorry, but it seems to me that sssd is behaving correctly here and without the logs, I don't think I can help any further, so I'm closing the ticket.

resolution: => invalid
status: new => closed

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/4053

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.