Hello SSSD guru`s!
I want to set up Active Directory domain authorization in my CentOS 7.2 servers with SSSD.
For this I use SSSD as described here: https://blog.it-kb.ru/2016/10/15/join-debian-gnu-linux-8-6-to-active-directo...
I have set up for several servers and everything works well. But on the last one server SSSD does not work as they should.
I attached this server to the domain using the realm utility. It looks nice.
[root@KOM-OVIRT1 ~]# realm list
ad.holding.com type: kerberos realm-name: AD.HOLDING.COM domain-name: ad.holding.com configured: kerberos-member server-software: active-directory client-software: sssd required-package: oddjob required-package: oddjob-mkhomedir required-package: sssd required-package: adcli required-package: samba-common login-formats: %U@ad.holding.com login-policy: allow-permitted-logins permitted-logins: permitted-groups: KOM-SRV-Linux-Admins@ad.holding.com
However, getent does not return information about domain accounts:
[root@KOM-OVIRT1 ~]# getent passwd aleksey@ad.holding.com [root@KOM-OVIRT1 ~]#
getent for local accounts work:
[root@KOM-OVIRT1 ~]# getent passwd root root:x:0:0:root:/root:/bin/bash
My /etc/sssd/sssd.conf: ------------------------------------------------ [sssd] domains = ad.holding.com config_file_version = 2 services = nss, pam default_domain_suffix = ad.holding.com
[nss] debug_level=9
[domain/ad.holding.com] ad_server = kom-dc01.ad.holding.com, kom-dc02.ad.holding.com ad_domain = ad.holding.com krb5_realm = AD.HOLDING.COM realmd_tags = manages-system joined-with-adcli cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = True fallback_homedir = /home/%d/%u access_provider = ad debug_level=9 ------------------------------------------------
/var/log/sssd/sssd_nss.log:
(Wed Oct 19 16:54:44 2016) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [ad.holding.com][4097][1][name=aleksey] (Wed Oct 19 16:54:44 2016) [sssd[nss]] [sbus_add_timeout] (0x2000): 0x7f8794b5f9a0 (Wed Oct 19 16:54:44 2016) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x7f8792bce0d0:1:aleksey@ad.holding.com] (Wed Oct 19 16:54:44 2016) [sssd[nss]] [sbus_remove_timeout] (0x2000): 0x7f8794b5f9a0 (Wed Oct 19 16:54:44 2016) [sssd[nss]] [sbus_dispatch] (0x4000): dbus conn: 0x7f8794b5b120 (Wed Oct 19 16:54:44 2016) [sssd[nss]] [sbus_dispatch] (0x4000): Dispatching. (Wed Oct 19 16:54:44 2016) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 1 errno: 11 error message: Fast reply - offline (Wed Oct 19 16:54:44 2016) [sssd[nss]] [nss_cmd_getby_dp_callback] (0x0040): Unable to get information from Data Provider Error: 1, 11, Fast reply - offline Will try to return what we have in cache (Wed Oct 19 16:54:44 2016) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x7f8792bce0d0:1:aleksey@ad.holding.com]
------------------------------------------------
/var/log/sssd/sssd_ad.holding.com.log
(Wed Oct 19 16:53:21 2016) [sssd[be[ad.holding.com]]] [be_get_account_info] (0x0200): Got request for [0x1001][1][name=aleksey] (Wed Oct 19 16:53:21 2016) [sssd[be[ad.holding.com]]] [be_get_account_info] (0x0100): Request processed. Returned 1,11,Fast reply - offline
What could be the problem?
On 10/19/2016 10:19 AM, aleksey.maksimov@it-kb.ru wrote:
Hello SSSD guru`s!
I want to set up Active Directory domain authorization in my CentOS 7.2 servers with SSSD.
For this I use SSSD as described here: https://blog.it-kb.ru/2016/10/15/join-debian-gnu-linux-8-6-to-active-directo...
I have set up for several servers and everything works well. But on the last one server SSSD does not work as they should.
I attached this server to the domain using the realm utility. It looks nice.
[root@KOM-OVIRT1 ~]# realm list
ad.holding.com type: kerberos realm-name: AD.HOLDING.COM domain-name: ad.holding.com configured: kerberos-member server-software: active-directory client-software: sssd required-package: oddjob required-package: oddjob-mkhomedir required-package: sssd required-package: adcli required-package: samba-common login-formats: %U@ad.holding.com login-policy: allow-permitted-logins permitted-logins: permitted-groups: KOM-SRV-Linux-Admins@ad.holding.com
However, getent does not return information about domain accounts:
[root@KOM-OVIRT1 ~]# getent passwd aleksey@ad.holding.com [root@KOM-OVIRT1 ~]#
getent for local accounts work:
[root@KOM-OVIRT1 ~]# getent passwd root root:x:0:0:root:/root:/bin/bash
My /etc/sssd/sssd.conf:
[sssd] domains = ad.holding.com config_file_version = 2 services = nss, pam default_domain_suffix = ad.holding.com
[nss] debug_level=9
[domain/ad.holding.com] ad_server = kom-dc01.ad.holding.com, kom-dc02.ad.holding.com ad_domain = ad.holding.com krb5_realm = AD.HOLDING.COM realmd_tags = manages-system joined-with-adcli cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = True fallback_homedir = /home/%d/%u access_provider = ad debug_level=9
/var/log/sssd/sssd_nss.log:
(Wed Oct 19 16:54:44 2016) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [ad.holding.com][4097][1][name=aleksey] (Wed Oct 19 16:54:44 2016) [sssd[nss]] [sbus_add_timeout] (0x2000): 0x7f8794b5f9a0 (Wed Oct 19 16:54:44 2016) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x7f8792bce0d0:1:aleksey@ad.holding.com] (Wed Oct 19 16:54:44 2016) [sssd[nss]] [sbus_remove_timeout] (0x2000): 0x7f8794b5f9a0 (Wed Oct 19 16:54:44 2016) [sssd[nss]] [sbus_dispatch] (0x4000): dbus conn: 0x7f8794b5b120 (Wed Oct 19 16:54:44 2016) [sssd[nss]] [sbus_dispatch] (0x4000): Dispatching. (Wed Oct 19 16:54:44 2016) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 1 errno: 11 error message: Fast reply - offline (Wed Oct 19 16:54:44 2016) [sssd[nss]] [nss_cmd_getby_dp_callback] (0x0040): Unable to get information from Data Provider Error: 1, 11, Fast reply - offline Will try to return what we have in cache (Wed Oct 19 16:54:44 2016) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x7f8792bce0d0:1:aleksey@ad.holding.com]
/var/log/sssd/sssd_ad.holding.com.log
(Wed Oct 19 16:53:21 2016) [sssd[be[ad.holding.com]]] [be_get_account_info] (0x0200): Got request for [0x1001][1][name=aleksey] (Wed Oct 19 16:53:21 2016) [sssd[be[ad.holding.com]]] [be_get_account_info] (0x0100): Request processed. Returned 1,11,Fast reply - offline
What could be the problem?
Hello,
I cannot confirm if the link you provided has the correct steps, but if realmd is installed then a successful realm join command should take care of the required configuration changes and domain joining steps for you.
The log message 'Fast reply - offline' usually means that somewhere earlier on in the logs the SSSD backend was marked offline. I would search for 'mark_offline' in the domain log file and look just above this to get an idea of what causes the backend to be set offline.
I also noticed this in the realm output
permitted-groups: KOM-SRV-Linux-Admins@ad.holding.com
Please check that you are attempting to query or resolve a user in this AD group.
This may also be of some help:
https://fedorahosted.org/sssd/wiki/Troubleshooting
-Justin
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
Hello, Justin!
"I cannot confirm if the link you provided has the correct steps"
These steps I tested on several other servers. Everything works. The problem occurred on only one server (I wrote about this earlier). This is the most strange in this situation.
"I would search for 'mark_offline' in the domain log file and look just above this to get an idea of what causes the backend to be set offline. "
Here's what I found in the domain log:
(Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'msk-dc01.holding.com' as 'not working' (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [ad_user_data_cmp] (0x1000): Comparing LDAP with LDAP (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [fo_set_port_status] (0x0400): Marking port 389 of duplicate server 'msk-dc01.holding.com' as 'not working' (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [ad_user_data_cmp] (0x1000): Comparing LDAP with LDAP (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [sdap_handle_release] (0x2000): Trace: sh[0x7f590093da10], connected[1], ops[(nil)], ldap[0x7f5900927d10], destructor_lock[0], release_memory[0] (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [remove_connection_callback] (0x4000): Successfully removed connection callback. (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [be_mark_offline] (0x2000): Going offline! (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [be_mark_offline] (0x2000): Initialize check_if_online_ptask. (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [be_ptask_create] (0x0400): Periodic task [Check if online (periodic)] was created (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [be_ptask_schedule] (0x0400): Task [Check if online (periodic)]: scheduling task 82 seconds from now [1476885227] (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [be_run_offline_cb] (0x0080): Going offline. Running callbacks. (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [sdap_id_op_connect_done] (0x4000): notify offline to op #1 (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [be_mark_dom_offline] (0x1000): Marking subdomain holding.com offline (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [be_mark_subdom_offline] (0x1000): Marking subdomain holding.com as inactive (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [ad_subdomains_root_conn_done] (0x0040): Failed to connect to AD server: [11](Resource temporarily unavailable) (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [get_subdomains_callback] (0x0400): Backend returned: (1, 11, <NULL>) [Provider is Offline (Have exhausted maximum number of retries for service)] (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [be_queue_next_request] (0x4000): Queued request filed successfully. (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [sdap_id_op_connect_done] (0x4000): notify offline to op #2 (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [be_mark_dom_offline] (0x1000): Marking subdomain holding.com offline (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [be_mark_subdom_offline] (0x4000): Subdomain already inactive (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [ad_subdomains_root_conn_done] (0x0040): Failed to connect to AD server: [11](Resource temporarily unavailable) (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [sdap_id_release_conn_data] (0x4000): releasing unused connection (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [get_subdomains_callback] (0x0400): Backend returned: (0, 0, <NULL>) [Success (Success)] (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [be_queue_next_request] (0x4000): Request queue is empty.
Why SSSD is trying to access the root domain controller (msk-dc01.holding.com) ?
In our case, the root domain controllers have access restrictions. This is a normal situation for large domains.
In my configuration file sssd.conf explicitly specified domain controllers that SSSD should use for authorization
[domain/ad.holding.com] ad_server = kom-dc01.ad.holding.com, kom-dc02.ad.holding.com
On Thu, Oct 20, 2016 at 05:58:50AM -0000, Aleksey Maksimov wrote:
Hello, Justin!
"I cannot confirm if the link you provided has the correct steps"
These steps I tested on several other servers. Everything works. The problem occurred on only one server (I wrote about this earlier). This is the most strange in this situation.
"I would search for 'mark_offline' in the domain log file and look just above this to get an idea of what causes the backend to be set offline. "
Here's what I found in the domain log:
(Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'msk-dc01.holding.com' as 'not working' (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [ad_user_data_cmp] (0x1000): Comparing LDAP with LDAP (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [fo_set_port_status] (0x0400): Marking port 389 of duplicate server 'msk-dc01.holding.com' as 'not working' (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [ad_user_data_cmp] (0x1000): Comparing LDAP with LDAP (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [sdap_handle_release] (0x2000): Trace: sh[0x7f590093da10], connected[1], ops[(nil)], ldap[0x7f5900927d10], destructor_lock[0], release_memory[0] (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [remove_connection_callback] (0x4000): Successfully removed connection callback. (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [be_mark_offline] (0x2000): Going offline! (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [be_mark_offline] (0x2000): Initialize check_if_online_ptask. (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [be_ptask_create] (0x0400): Periodic task [Check if online (periodic)] was created (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [be_ptask_schedule] (0x0400): Task [Check if online (periodic)]: scheduling task 82 seconds from now [1476885227] (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [be_run_offline_cb] (0x0080): Going offline. Running callbacks. (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [sdap_id_op_connect_done] (0x4000): notify offline to op #1 (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [be_mark_dom_offline] (0x1000): Marking subdomain holding.com offline (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [be_mark_subdom_offline] (0x1000): Marking subdomain holding.com as inactive (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [ad_subdomains_root_conn_done] (0x0040): Failed to connect to AD server: [11](Resource temporarily unavailable) (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [get_subdomains_callback] (0x0400): Backend returned: (1, 11, <NULL>) [Provider is Offline (Have exhausted maximum number of retries for service)] (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [be_queue_next_request] (0x4000): Queued request filed successfully. (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [sdap_id_op_connect_done] (0x4000): notify offline to op #2 (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [be_mark_dom_offline] (0x1000): Marking subdomain holding.com offline (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [be_mark_subdom_offline] (0x4000): Subdomain already inactive (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [ad_subdomains_root_conn_done] (0x0040): Failed to connect to AD server: [11](Resource temporarily unavailable) (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [sdap_id_release_conn_data] (0x4000): releasing unused connection (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [get_subdomains_callback] (0x0400): Backend returned: (0, 0, <NULL>) [Success (Success)] (Wed Oct 19 16:52:25 2016) [sssd[be[ad.holding.com]]] [be_queue_next_request] (0x4000): Request queue is empty.
Why SSSD is trying to access the root domain controller (msk-dc01.holding.com) ?
Because it's trying to read the list of trusted domains in the forest.
In our case, the root domain controllers have access restrictions. This is a normal situation for large domains.
In my configuration file sssd.conf explicitly specified domain controllers that SSSD should use for authorization
[domain/ad.holding.com] ad_server = kom-dc01.ad.holding.com, kom-dc02.ad.holding.com
Yes, but the trusted domains are discovered by the "subdomains_provider" which always uses SRV discovery to read the list of AD DCs. Starting with sssd-1.14 you can use a new option "ad_enabled_domains" to only list the domains sssd should be allowed to "see".
In previous versions, the only other workaround is to disable the subdomains provider completely: subdomains_provider = none but then you need to define the domain SID manually if you want to use ID-mapping.
I have sssd 1.13.0 (the package is installed from the CentOS repository)
Installed Packages Name : sssd Arch : x86_64 Version : 1.13.0 Release : 40.el7_2.12 Size : 34 k Repo : installed From repo : updates
Don't understand how I can solve the problem.
And the most important thing. I don't understand why the problem is not reproduced on other my servers with CentOS 7.2
On Thu, Oct 20, 2016 at 08:17:40AM -0000, Aleksey Maksimov wrote:
I have sssd 1.13.0 (the package is installed from the CentOS repository)
Installed Packages Name : sssd Arch : x86_64 Version : 1.13.0 Release : 40.el7_2.12 Size : 34 k Repo : installed From repo : updates
Don't understand how I can solve the problem.
With this version, by disabling the subdomains provider: subdomains_provider=none
And the most important thing. I don't understand why the problem is not reproduced on other my servers with CentOS 7.2
I don't see the whole log, but perhaps some component on this system is asking for a username or a ID number from outside the joined domain.
Ok Jakub.
I changed my file sssd.conf and restarted the service
[domain/ad.holding.com] ... subdomains_provider = none
# service sssd stop; rm -f /var/lib/sss/db/* ; rm -f /var/lib/sss/mc/* ; service sssd start # getent passwd aleksey@ad.holding.com
getent does not return a result :(
sssd_ad.holding.com.log:
(Thu Oct 20 12:06:40 2016) [sssd[be[ad.holding.com]]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Oct 20 12:06:40 2016) [sssd[be[ad.holding.com]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Oct 20 12:06:50 2016) [sssd[be[ad.holding.com]]] [sbus_dispatch] (0x4000): dbus conn: 0x7f99ec1390e0 (Thu Oct 20 12:06:50 2016) [sssd[be[ad.holding.com]]] [sbus_dispatch] (0x4000): Dispatching. (Thu Oct 20 12:06:50 2016) [sssd[be[ad.holding.com]]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Oct 20 12:06:50 2016) [sssd[be[ad.holding.com]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Oct 20 12:07:00 2016) [sssd[be[ad.holding.com]]] [sbus_dispatch] (0x4000): dbus conn: 0x7f99ec1390e0 (Thu Oct 20 12:07:00 2016) [sssd[be[ad.holding.com]]] [sbus_dispatch] (0x4000): Dispatching. (Thu Oct 20 12:07:00 2016) [sssd[be[ad.holding.com]]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Thu Oct 20 12:07:00 2016) [sssd[be[ad.holding.com]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sbus_dispatch] (0x4000): dbus conn: 0x7f99ec16dcb0 (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sbus_dispatch] (0x4000): Dispatching. (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.dataprovider.getAccountInfo on path /org/freedesktop/sssd/dataprovider (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [be_get_account_info] (0x0200): Got request for [0x1001][1][name=aleksey] (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [be_req_set_domain] (0x0400): Changing request domain from [ad.holding.com] to [ad.holding.com] (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_search_user_next_base] (0x0400): Searching for users with base [DC=ad,DC=holding,DC=com] (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_print_server] (0x2000): Searching 10.1.0.9 (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(sAMAccountName=aleksey)(objectclass=user)(sAMAccountName=*)(&(uidNumber=*)(!(uidNumber=0))))][DC=ad,DC=holding,DC=com]. (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sAMAccountName] (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [unixUserPassword] (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber] (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gecos] (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [unixHomeDirectory] (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginShell] (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPrincipalName] (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [name] (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectGUID] (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectSID] (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [primaryGroupID] (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [whenChanged] (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uSNChanged] (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accountExpires] (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl] (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 7 (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_op_add] (0x2000): New operation 7 timeout 6 (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_process_result] (0x2000): Trace: sh[0x7f99ec179340], connected[1], ops[0x7f99ec185de0], ldap[0x7f99ec174170] (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE] (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_get_generic_ext_add_references] (0x1000): Additional References: ldap://DomainDnsZones.ad.holding.com/DC=DomainDnsZones,DC=ad,DC=holding,DC=com (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_process_result] (0x2000): Trace: sh[0x7f99ec179340], connected[1], ops[0x7f99ec185de0], ldap[0x7f99ec174170] (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_op_destructor] (0x2000): Operation 7 finished (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [generic_ext_search_handler] (0x4000): Request included referrals which were ignored. (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [generic_ext_search_handler] (0x4000): Ref: ldap://DomainDnsZones.ad.holding.com/DC=DomainDnsZones,DC=ad,DC=holding,DC=com (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_search_user_process] (0x0400): Search for users, returned 0 results. (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_get_users_done] (0x0040): Failed to retrieve users (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_id_op_done] (0x4000): releasing operation connection (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f99ec18aca0 (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f99ec189090 (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [ldb] (0x4000): Running timer event 0x7f99ec18aca0 "ltdb_callback" (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [ldb] (0x4000): Destroying timer event 0x7f99ec189090 "ltdb_timeout" (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [ldb] (0x4000): Ending timer event 0x7f99ec18aca0 "ltdb_callback" (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sysdb_search_by_name] (0x0400): No such entry (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sysdb_search_groups] (0x2000): Search groups with filter: (&(objectclass=group)(ghost=aleksey)) (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f99ec185390 (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f99ec18a600 (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [ldb] (0x4000): Running timer event 0x7f99ec185390 "ltdb_callback" (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [ldb] (0x4000): Destroying timer event 0x7f99ec18a600 "ltdb_timeout" (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [ldb] (0x4000): Ending timer event 0x7f99ec185390 "ltdb_callback" (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sysdb_search_groups] (0x2000): No such entry (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sysdb_delete_user] (0x0400): Error: 2 (No such file or directory) (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Success) (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_process_result] (0x2000): Trace: sh[0x7f99ec179340], connected[1], ops[(nil)], ldap[0x7f99ec174170] (Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing!
On Thu, Oct 20, 2016 at 09:31:34AM -0000, Aleksey Maksimov wrote:
(Thu Oct 20 12:07:04 2016) [sssd[be[ad.holding.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(sAMAccountName=aleksey)(objectclass=user)(sAMAccountName=*)(&(uidNumber=*)(!(uidNumber=0))))][DC=ad,DC=holding,DC=com].
That's what I said earlier, if your configuration relies on ID mapping and you disable the subdomains provider, you need to define your domain SID with ldap_idmap_default_domain_sid
In what section of the sssd.conf I should add "ldap_idmap_default_domain_sid" ? In man sssd.conf no information
Thank You Jakub ! You're a true friend :)
The final solution works: ---------------------------------------------
[sssd] ... default_domain_suffix = ad.holding.com
[domain/ad.holding.com] ad_server = kom-dc01.ad.holding.com, kom-dc02.ad.holding.com ... subdomains_provider = none ldap_idmap_default_domain_sid = S-1-5-21-xxx-xxx-xxx simple_allow_groups = KOM-SRV-Linux-Admins@ad.holding.com
---------------------------------------------
sssd-users@lists.fedorahosted.org
-
Aleksey Maksimov -
Jakub Hrozek -
Justin Stephenson