sssd-ad + ldap mapping uid issue

[Guillaume Polaert]

Hi everyone,

I'm using sssd-ad and I have unexpected behaviour with the ldap_mapping_id module.
I'll try to be clear as possible :)

The unexpected behaviour concerned Group ID, they are inconsistency.
For any reason, at any moment GIDs can be changed.

The AD contains about 10 domains, and 200 000 users. Domain RIDs can be very large.
I override the min, max, and slice values to extend the available window.
I've also set a default domain sid in order to be sure one (the main) domain will be
consistency.

But it doesn't work.
What can be the origin of GIDs overwriting?

Maybe, I have a problem with my configuration file.

/etc/sssd/sssd.conf
[sssd]
config_file_version = 2
services = nss, pam, sudo
domains = LDAP, domain.ad

[nss]
filter_groups = root,ldap,named,avahi,haldaemon,dbus,...
filter_users = root,ldap,named,avahi,haldaemon,dbus, ...

[pam]

[sudo]

[domain/LDAP]
id_provider = ldap
sudo_provider = ldap
auth_provider = ldap
cache_credentials = True
ldap_uri = ldaps://ldap1:636
ldap_tls_cacert = /etc/openldap/cacerts/ldap_rootca.pem
ldap_tls_reqcert = hard
ldap_default_bind_dn = ...
ldap_default_authtok_type = obfuscated_password
ldap_default_authtok = ...
ldap_search_base = base_dn
enumerate = True
ldap_referrals = False
ldap_schema = rfc2307
ldap_sudo_search_base = base_dn


[domain/domain.ad]
id_provider = ldap
access_provider = ad
auth_provider = ad
cache_credentials = True
enumerate = False
debug_level = 9

## Override attributes
override_gid = 513
override_homedir = /data/users/%u
default_shell = /bin/bash

## LDAP config
ldap_uri = ldaps://ad-server:3269
ldap_tls_cacert = /etc/openldap/cacerts/bundle-certificates.pem
ldap_tls_reqcert = hard
ldap_search_base = base_dn
ldap_group_search_base = group_dn
ldap_schema = ad

## Mapping confiugration
ldap_id_mapping = True
ldap_idmap_default_domain_sid = S-1-5-21-...932
# Allow 2000 domains, and 1 million entries per domain
# Min uid for AD account (100000)
ldap_idmap_range_min =  100000
ldap_idmap_range_max = 2000100000
ldap_idmap_range_size = 1000000

I've just found this in the log file.

(Wed Aug 26 15:22:37 2015) [sssd[be[dc.example.com]]] [ldb] (0x4000): commit ldb
transaction (nesting: 3)
(Wed Aug 26 15:22:37 2015) [sssd[be[dc.example.com]]] [sdap_get_primary_name] (0x0400):
Processing object grp_cluster1_developer
(Wed Aug 26 15:22:37 2015) [sssd[be[dc.example.com]]] [sdap_get_primary_name] (0x0400):
Processing object grp_audit_cluster1_developer
(Wed Aug 26 15:22:37 2015) [sssd[be[dc.example.com]]] [sdap_get_primary_name] (0x0400):
Processing object grp_audit_cluster1_user
(Wed Aug 26 15:22:37 2015) [sssd[be[dc.example.com]]] [sdap_add_incomplete_groups]
(0x1000): Mapping group [grp_audit_cluster1_user] objectSID to unix ID
(Wed Aug 26 15:22:37 2015) [sssd[be[dc.example.com]]] [sdap_add_incomplete_groups]
(0x2000): Group [grp_audit_cluster1_user] has objectSID
[S-1-5-21-3095416536-3097367016-2845470932-840751]
(Wed Aug 26 15:22:37 2015) [sssd[be[dc.example.com]]] [sdap_add_incomplete_groups]
(0x2000): Group [grp_audit_cluster1_user] has mapped gid [940751]
(Wed Aug 26 15:22:37 2015) [sssd[be[dc.example.com]]] [sdap_add_incomplete_groups]
(0x2000): Adding fake group grp_audit_cluster1_user to sysdb
(Wed Aug 26 15:22:37 2015) [sssd[be[dc.example.com]]] [ldb] (0x4000): start ldb
transaction (nesting: 3)
(Wed Aug 26 15:22:37 2015) [sssd[be[dc.example.com]]] [ldb] (0x4000): Added timed event
"ltdb_callback": 0x1ee6fc0

[ ...]

(Wed Aug 26 15:22:38 2015) [sssd[be[dc.example.com]]] [ldb] (0x4000): commit ldb
transaction (nesting: 1)
(Wed Aug 26 15:22:38 2015) [sssd[be[dc.example.com]]] [ldb] (0x4000): start ldb
transaction (nesting: 1)
(Wed Aug 26 15:22:38 2015) [sssd[be[dc.example.com]]] [sdap_get_primary_name] (0x0400):
Processing object grp_audit_cluster1_user
(Wed Aug 26 15:22:38 2015) [sssd[be[dc.example.com]]] [sdap_save_group] (0x0400):
Processing group grp_audit_cluster1_user
(Wed Aug 26 15:22:38 2015) [sssd[be[dc.example.com]]] [sdap_save_group] (0x4000): AD group
[grp_audit_cluster1_user] has type flags 0x80000004.
(Wed Aug 26 15:22:38 2015) [sssd[be[dc.example.com]]] [sdap_save_group] (0x1000): Mapping
group [grp_audit_cluster1_user] objectSID
[S-1-5-21-3095416536-3097367016-2845470932-840751] to unix ID
(Wed Aug 26 15:22:38 2015) [sssd[be[dc.example.com]]] [sdap_attrs_add_ldap_attr] (0x2000):
Adding original DN [CN=grp_audit_cluster1_user,....] to attributes of
[grp_audit_cluster1_user].
(Wed Aug 26 15:22:38 2015) [sssd[be[dc.example.com]]] [sdap_attrs_add_ldap_attr] (0x2000):
Adding original mod-Timestamp [20150717152801.0Z] to attributes of
[grp_audit_cluster1_user].
(Wed Aug 26 15:22:38 2015) [sssd[be[dc.example.com]]] [sdap_process_ghost_members]
(0x0400): The group has 3 members
(Wed Aug 26 15:22:38 2015) [sssd[be[dc.example.com]]] [sdap_process_ghost_members]
(0x0400): Group has 3 members
(Wed Aug 26 15:22:38 2015) [sssd[be[dc.example.com]]] [sdap_process_ghost_members]
(0x0400): Adding ghost member for group [N5218058]
(Wed Aug 26 15:22:38 2015) [sssd[be[dc.example.com]]] [sdap_process_ghost_members]
(0x0400): Adding ghost member for group [O3049031]
(Wed Aug 26 15:22:38 2015) [sssd[be[dc.example.com]]] [sdap_save_group] (0x0400): Storing
info for group grp_audit_cluster1_user




Guillaume Polaert | Ingensi | @gpolaert - https://twitter.com/gpolaert

[Sumit Bose]

On Mon, Sep 21, 2015 at 03:51:13PM +0000, Guillaume Polaert wrote:
>  Hi everyone,
>  
>  I'm using sssd-ad and I have unexpected behaviour with the ldap_mapping_id module.
>  I'll try to be clear as possible :)
>  
>  The unexpected behaviour concerned Group ID, they are inconsistency.
>  For any reason, at any moment GIDs can be changed.
>  
>  The AD contains about 10 domains, and 200 000 users. Domain RIDs can be very large.
>  I override the min, max, and slice values to extend the available window.
>  I've also set a default domain sid in order to be sure one (the main) domain will be
> consistency.
>  
>  But it doesn't work.
>  What can be the origin of GIDs overwriting?
>  
>  Maybe, I have a problem with my configuration file.
>  
>  /etc/sssd/sssd.conf
>  [sssd]
>  config_file_version = 2
>  services = nss, pam, sudo
>  domains = LDAP, domain.ad
>  
>  [nss]
>  filter_groups = root,ldap,named,avahi,haldaemon,dbus,...
>  filter_users = root,ldap,named,avahi,haldaemon,dbus, ...
>  
>  [pam]
>  
>  [sudo]
>  
>  [domain/LDAP]
>  id_provider = ldap
>  sudo_provider = ldap
>  auth_provider = ldap
>  cache_credentials = True
>  ldap_uri = ldaps://ldap1:636
>  ldap_tls_cacert = /etc/openldap/cacerts/ldap_rootca.pem
>  ldap_tls_reqcert = hard
>  ldap_default_bind_dn = ...
>  ldap_default_authtok_type = obfuscated_password
>  ldap_default_authtok = ...
>  ldap_search_base = base_dn
>  enumerate = True
>  ldap_referrals = False
>  ldap_schema = rfc2307
>  ldap_sudo_search_base = base_dn
>  
>  
>  [domain/domain.ad]
>  id_provider = ldap 
it there a reason why you use 'ldap' here and not 'ad'?

Can you give examples how the GID changes?

bye,
Sumit

>  access_provider = ad
>  auth_provider = ad
>  cache_credentials = True
>  enumerate = False
>  debug_level = 9
>  
>  ## Override attributes
>  override_gid = 513
>  override_homedir = /data/users/%u
>  default_shell = /bin/bash
>  
>  ## LDAP config
>  ldap_uri = ldaps://ad-server:3269
>  ldap_tls_cacert = /etc/openldap/cacerts/bundle-certificates.pem
>  ldap_tls_reqcert = hard
>  ldap_search_base = base_dn
>  ldap_group_search_base = group_dn
>  ldap_schema = ad
>  
>  ## Mapping confiugration
>  ldap_id_mapping = True
>  ldap_idmap_default_domain_sid = S-1-5-21-...932
>  # Allow 2000 domains, and 1 million entries per domain
>  # Min uid for AD account (100000)
>  ldap_idmap_range_min =  100000
>  ldap_idmap_range_max = 2000100000
>  ldap_idmap_range_size = 1000000
>  
>  I've just found this in the log file.
>  
>  (Wed Aug 26 15:22:37 2015) [sssd[be[dc.example.com]]] [ldb] (0x4000): commit ldb
> transaction (nesting: 3)
>  (Wed Aug 26 15:22:37 2015) [sssd[be[dc.example.com]]] [sdap_get_primary_name] (0x0400):
> Processing object grp_cluster1_developer
>  (Wed Aug 26 15:22:37 2015) [sssd[be[dc.example.com]]] [sdap_get_primary_name] (0x0400):
> Processing object grp_audit_cluster1_developer
>  (Wed Aug 26 15:22:37 2015) [sssd[be[dc.example.com]]] [sdap_get_primary_name] (0x0400):
> Processing object grp_audit_cluster1_user
>  (Wed Aug 26 15:22:37 2015) [sssd[be[dc.example.com]]] [sdap_add_incomplete_groups]
> (0x1000): Mapping group [grp_audit_cluster1_user] objectSID to unix ID
>  (Wed Aug 26 15:22:37 2015) [sssd[be[dc.example.com]]] [sdap_add_incomplete_groups]
> (0x2000): Group [grp_audit_cluster1_user] has objectSID
> [S-1-5-21-3095416536-3097367016-2845470932-840751]
>  (Wed Aug 26 15:22:37 2015) [sssd[be[dc.example.com]]] [sdap_add_incomplete_groups]
> (0x2000): Group [grp_audit_cluster1_user] has mapped gid [940751]
>  (Wed Aug 26 15:22:37 2015) [sssd[be[dc.example.com]]] [sdap_add_incomplete_groups]
> (0x2000): Adding fake group grp_audit_cluster1_user to sysdb
>  (Wed Aug 26 15:22:37 2015) [sssd[be[dc.example.com]]] [ldb] (0x4000): start ldb
> transaction (nesting: 3)
>  (Wed Aug 26 15:22:37 2015) [sssd[be[dc.example.com]]] [ldb] (0x4000): Added timed event
> "ltdb_callback": 0x1ee6fc0
>  
>  [ ...]
>  
>  (Wed Aug 26 15:22:38 2015) [sssd[be[dc.example.com]]] [ldb] (0x4000): commit ldb
> transaction (nesting: 1)
>  (Wed Aug 26 15:22:38 2015) [sssd[be[dc.example.com]]] [ldb] (0x4000): start ldb
> transaction (nesting: 1)
>  (Wed Aug 26 15:22:38 2015) [sssd[be[dc.example.com]]] [sdap_get_primary_name] (0x0400):
> Processing object grp_audit_cluster1_user
>  (Wed Aug 26 15:22:38 2015) [sssd[be[dc.example.com]]] [sdap_save_group] (0x0400):
> Processing group grp_audit_cluster1_user
>  (Wed Aug 26 15:22:38 2015) [sssd[be[dc.example.com]]] [sdap_save_group] (0x4000): AD
> group [grp_audit_cluster1_user] has type flags 0x80000004.
>  (Wed Aug 26 15:22:38 2015) [sssd[be[dc.example.com]]] [sdap_save_group] (0x1000): Mapping
> group [grp_audit_cluster1_user] objectSID
> [S-1-5-21-3095416536-3097367016-2845470932-840751] to unix ID
>  (Wed Aug 26 15:22:38 2015) [sssd[be[dc.example.com]]] [sdap_attrs_add_ldap_attr]
> (0x2000): Adding original DN [CN=grp_audit_cluster1_user,....] to attributes of
> [grp_audit_cluster1_user].
>  (Wed Aug 26 15:22:38 2015) [sssd[be[dc.example.com]]] [sdap_attrs_add_ldap_attr]
> (0x2000): Adding original mod-Timestamp [20150717152801.0Z] to attributes of
> [grp_audit_cluster1_user].
>  (Wed Aug 26 15:22:38 2015) [sssd[be[dc.example.com]]] [sdap_process_ghost_members]
> (0x0400): The group has 3 members
>  (Wed Aug 26 15:22:38 2015) [sssd[be[dc.example.com]]] [sdap_process_ghost_members]
> (0x0400): Group has 3 members
>  (Wed Aug 26 15:22:38 2015) [sssd[be[dc.example.com]]] [sdap_process_ghost_members]
> (0x0400): Adding ghost member for group [N5218058]
>  (Wed Aug 26 15:22:38 2015) [sssd[be[dc.example.com]]] [sdap_process_ghost_members]
> (0x0400): Adding ghost member for group [O3049031]
>  (Wed Aug 26 15:22:38 2015) [sssd[be[dc.example.com]]] [sdap_save_group] (0x0400): Storing
> info for group grp_audit_cluster1_user
>  
>  
>  
>  
>  Guillaume Polaert | Ingensi | @gpolaert - https://twitter.com/gpolaert
>   
>  _______________________________________________
>  sssd-users mailing list
>  sssd-users(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[Guillaume Polaert]

> -----Message d'origine-----
> De : sssd-users-bounces(a)lists.fedorahosted.org
> [mailto:[e-mail]] De la part de Sumit Bose
> Envoyé : lundi 21 septembre 2015 18:17
> À : End-user discussions about the System Security Services Daemon
> <sssd-users(a)lists.fedorahosted.org&gt;
> Objet : Re: [SSSD-users] sssd-ad + ldap mapping uid issue
>
> On Mon, Sep 21, 2015 at 03:51:13PM +0000, Guillaume Polaert wrote:
> > Hi everyone,
> > 
> > I'm using sssd-ad and I have unexpected behaviour with the ldap_mapping_id
> module.
> > I'll try to be clear as possible :)
> > 
> > The unexpected behaviour concerned Group ID, they are inconsistency.
> > For any reason, at any moment GIDs can be changed.
> > 
> > The AD contains about 10 domains, and 200 000 users. Domain RIDs can be very large.
> > I override the min, max, and slice values to extend the available window.
> > I've also set a default domain sid in order to be sure one (the main) domain will
> be consistency.
> > 
> > But it doesn't work.
> > What can be the origin of GIDs overwriting?
> > 
> > Maybe, I have a problem with my configuration file.
> > 
> > /etc/sssd/sssd.conf
> > [sssd]
> > config_file_version = 2
> > services = nss, pam, sudo
> > domains = LDAP, domain.ad
> > 
> > [nss]
> > filter_groups = root,ldap,named,avahi,haldaemon,dbus,...
> > filter_users = root,ldap,named,avahi,haldaemon,dbus, ...
> > 
> > [pam]
> > 
> > [sudo]
> > 
> > [domain/LDAP]
> > id_provider = ldap
> > sudo_provider = ldap
> > auth_provider = ldap
> > cache_credentials = True
> > ldap_uri = ldaps://ldap1:636
> > ldap_tls_cacert = /etc/openldap/cacerts/ldap_rootca.pem
> > ldap_tls_reqcert = hard
> > ldap_default_bind_dn = ...
> > ldap_default_authtok_type = obfuscated_password ldap_default_authtok = 
> > ...
> > ldap_search_base = base_dn
> > enumerate = True
> > ldap_referrals = False
> > ldap_schema = rfc2307
> > ldap_sudo_search_base = base_dn
> > 
> > 
> > [domain/domain.ad]
> > id_provider = ldap
>
> it there a reason why you use 'ldap' here and not 'ad'?
>  
No reason, it's just a rest of the previous configuration. However, I have the
same behaviour with ad instead of ldap.

> Can you give examples how the GID changes?
>  
For sure,
at the startup (rm -fr /var/lib/sss/{db,mc}*)
getent group grp_user_1 
grp_user_1:*:870781:user1,user2 ....

And at later, 
getent group grp_user_1 
grp_user_1:*:10584321:user1,user2 ....

Guillaume
> bye,
> Sumit
>
> > access_provider = ad
> > auth_provider = ad
> > cache_credentials = True
> > enumerate = False
> > debug_level = 9
> > 
> > ## Override attributes
> > override_gid = 513
> > override_homedir = /data/users/%u
> > default_shell = /bin/bash
> > 
> > ## LDAP config
> > ldap_uri = ldaps://ad-server:3269
> > ldap_tls_cacert = /etc/openldap/cacerts/bundle-certificates.pem
> > ldap_tls_reqcert = hard
> > ldap_search_base = base_dn
> > ldap_group_search_base = group_dn
> > ldap_schema = ad
> > 
> > ## Mapping confiugration
> > ldap_id_mapping = True
> > ldap_idmap_default_domain_sid = S-1-5-21-...932 # Allow 2000 domains, 
> > and 1 million entries per domain # Min uid for AD account (100000) 
> > ldap_idmap_range_min =  100000 ldap_idmap_range_max = 2000100000 
> > ldap_idmap_range_size = 1000000
> > 
> > I've just found this in the log file.
> > 
> > (Wed Aug 26 15:22:37 2015) [sssd[be[dc.example.com]]] [ldb] (0x4000): 
> > commit ldb transaction (nesting: 3) (Wed Aug 26 15:22:37 2015) 
> > [sssd[be[dc.example.com]]] [sdap_get_primary_name] (0x0400): 
> > Processing object grp_cluster1_developer (Wed Aug 26 15:22:37 2015) 
> > [sssd[be[dc.example.com]]] [sdap_get_primary_name] (0x0400): 
> > Processing object grp_audit_cluster1_developer (Wed Aug 26 15:22:37 
> > 2015) [sssd[be[dc.example.com]]] [sdap_get_primary_name] (0x0400): 
> > Processing object grp_audit_cluster1_user (Wed Aug 26 15:22:37 2015) 
> > [sssd[be[dc.example.com]]] [sdap_add_incomplete_groups] (0x1000): 
> > Mapping group [grp_audit_cluster1_user] objectSID to unix ID (Wed Aug 
> > 26 15:22:37 2015) [sssd[be[dc.example.com]]] 
> > [sdap_add_incomplete_groups] (0x2000): Group [grp_audit_cluster1_user] 
> > has objectSID [S-1-5-21-3095416536-3097367016-2845470932-840751]
> > (Wed Aug 26 15:22:37 2015) [sssd[be[dc.example.com]]] 
> > [sdap_add_incomplete_groups] (0x2000): Group [grp_audit_cluster1_user] 
> > has mapped gid [940751] (Wed Aug 26 15:22:37 2015) 
> > [sssd[be[dc.example.com]]] [sdap_add_incomplete_groups] (0x2000): 
> > Adding fake group grp_audit_cluster1_user to sysdb (Wed Aug 26 
> > 15:22:37 2015) [sssd[be[dc.example.com]]] [ldb] (0x4000): start ldb 
> > transaction (nesting: 3) (Wed Aug 26 15:22:37 2015) 
> > [sssd[be[dc.example.com]]] [ldb] (0x4000): Added timed event 
> > "ltdb_callback": 0x1ee6fc0
> > 
> > [ ...]
> > 
> > (Wed Aug 26 15:22:38 2015) [sssd[be[dc.example.com]]] [ldb] (0x4000): 
> > commit ldb transaction (nesting: 1) (Wed Aug 26 15:22:38 2015) 
> > [sssd[be[dc.example.com]]] [ldb] (0x4000): start ldb transaction 
> > (nesting: 1) (Wed Aug 26 15:22:38 2015) [sssd[be[dc.example.com]]] 
> > [sdap_get_primary_name] (0x0400): Processing object grp_audit_cluster1_user (Wed Aug
> 26 15:22:38 2015) [sssd[be[dc.example.com]]] [sdap_save_group] (0x0400): Processing group
> grp_audit_cluster1_user (Wed Aug 26 15:22:38 2015) [sssd[be[dc.example.com]]]
> [sdap_save_group] (0x4000): AD group [grp_audit_cluster1_user] has type flags
> 0x80000004.
> > (Wed Aug 26 15:22:38 2015) [sssd[be[dc.example.com]]] 
> > [sdap_save_group] (0x1000): Mapping group [grp_audit_cluster1_user] objectSID
> [S-1-5-21-3095416536-3097367016-2845470932-840751] to unix ID (Wed Aug 26 15:22:38 2015)
> [sssd[be[dc.example.com]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding original DN
> [CN=grp_audit_cluster1_user,....] to attributes of [grp_audit_cluster1_user].
> > (Wed Aug 26 15:22:38 2015) [sssd[be[dc.example.com]]] [sdap_attrs_add_ldap_attr]
> (0x2000): Adding original mod-Timestamp [20150717152801.0Z] to attributes of
> [grp_audit_cluster1_user].
> > (Wed Aug 26 15:22:38 2015) [sssd[be[dc.example.com]]] 
> > [sdap_process_ghost_members] (0x0400): The group has 3 members (Wed 
> > Aug 26 15:22:38 2015) [sssd[be[dc.example.com]]] 
> > [sdap_process_ghost_members] (0x0400): Group has 3 members (Wed Aug 26 
> > 15:22:38 2015) [sssd[be[dc.example.com]]] [sdap_process_ghost_members] 
> > (0x0400): Adding ghost member for group [N5218058] (Wed Aug 26 
> > 15:22:38 2015) [sssd[be[dc.example.com]]] [sdap_process_ghost_members] 
> > (0x0400): Adding ghost member for group [O3049031] (Wed Aug 26 
> > 15:22:38 2015) [sssd[be[dc.example.com]]] [sdap_save_group] (0x0400): 
> > Storing info for group grp_audit_cluster1_user
> > 
> > 
> > 
> > 
> > Guillaume Polaert | Ingensi | @gpolaert - https://twitter.com/gpolaert
> > 
>
> > _______________________________________________
> > sssd-users mailing list
> > sssd-users(a)lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>
> _______________________________________________
> sssd-users mailing list
> sssd-users(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>

[Sumit Bose]

On Tue, Sep 22, 2015 at 07:41:20AM +0000, Guillaume Polaert wrote:
>  >-----Message d'origine-----
>  >De : sssd-users-bounces(a)lists.fedorahosted.org
> [mailto:[e-mail]] De la part de Sumit Bose
>  >Envoyé : lundi 21 septembre 2015 18:17
>  >À : End-user discussions about the System Security Services Daemon
> <sssd-users(a)lists.fedorahosted.org&gt;
>  >Objet : Re: [SSSD-users] sssd-ad + ldap mapping uid issue
>  >
>  >On Mon, Sep 21, 2015 at 03:51:13PM +0000, Guillaume Polaert wrote:
>  >> Hi everyone,
>  >> 
>  >> I'm using sssd-ad and I have unexpected behaviour with the ldap_mapping_id
> module.
>  >> I'll try to be clear as possible :)
>  >> 
>  >> The unexpected behaviour concerned Group ID, they are inconsistency.
>  >> For any reason, at any moment GIDs can be changed.
>  >> 
>  >> The AD contains about 10 domains, and 200 000 users. Domain RIDs can be very
> large.
>  >> I override the min, max, and slice values to extend the available window.
>  >> I've also set a default domain sid in order to be sure one (the main) domain
> will be consistency.
>  >> 
>  >> But it doesn't work.
>  >> What can be the origin of GIDs overwriting?
>  >> 
>  >> Maybe, I have a problem with my configuration file.
>  >> 
>  >> /etc/sssd/sssd.conf
>  >> [sssd]
>  >> config_file_version = 2
>  >> services = nss, pam, sudo
>  >> domains = LDAP, domain.ad
>  >> 
>  >> [nss]
>  >> filter_groups = root,ldap,named,avahi,haldaemon,dbus,...
>  >> filter_users = root,ldap,named,avahi,haldaemon,dbus, ...
>  >> 
>  >> [pam]
>  >> 
>  >> [sudo]
>  >> 
>  >> [domain/LDAP]
>  >> id_provider = ldap
>  >> sudo_provider = ldap
>  >> auth_provider = ldap
>  >> cache_credentials = True
>  >> ldap_uri = ldaps://ldap1:636
>  >> ldap_tls_cacert = /etc/openldap/cacerts/ldap_rootca.pem
>  >> ldap_tls_reqcert = hard
>  >> ldap_default_bind_dn = ...
>  >> ldap_default_authtok_type = obfuscated_password ldap_default_authtok = 
>  >> ...
>  >> ldap_search_base = base_dn
>  >> enumerate = True
>  >> ldap_referrals = False
>  >> ldap_schema = rfc2307
>  >> ldap_sudo_search_base = base_dn
>  >> 
>  >> 
>  >> [domain/domain.ad]
>  >> id_provider = ldap
>  >
>  >it there a reason why you use 'ldap' here and not 'ad'?
>  No reason, it's just a rest of the previous configuration. However, I have the same
> behaviour with ad instead of ldap.
>  
>  >Can you give examples how the GID changes?
>  For sure,
>  at the startup (rm -fr /var/lib/sss/{db,mc}*)
>  getent group grp_user_1 
>  grp_user_1:*:870781:user1,user2 ....
>  
>  And at later, 
>  getent group grp_user_1 
>  grp_user_1:*:10584321:user1,user2 .... 
Thank you for checking with the ad provider as well. Full SSSD logs are
needed here. Please find details about how to enable logging at
https://fedorahosted.org/sssd/wiki/Troubleshooting . If you prefer feel
free to send the logs to me directly. Ideally the logs should cover the
time from startup until the gid changes.

bye,
Sumit

>  
>  Guillaume
>  >bye,
>  >Sumit
>  >