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
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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
-----Message d'origine----- De : sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] De la part de Sumit Bose Envoyé : lundi 21 septembre 2015 18:17 À : End-user discussions about the System Security Services Daemon sssd-users@lists.fedorahosted.org 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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Tue, Sep 22, 2015 at 07:41:20AM +0000, Guillaume Polaert wrote:
-----Message d'origine----- De : sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] De la part de Sumit Bose Envoyé : lundi 21 septembre 2015 18:17 À : End-user discussions about the System Security Services Daemon sssd-users@lists.fedorahosted.org 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
sssd-users@lists.fedorahosted.org