Active Directory domain authorization on CentOS 7.2 servers with SSSD

[Aleksey Maksimov]

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-dire...

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(a)ad.holding.com
  login-policy: allow-permitted-logins
  permitted-logins:
  permitted-groups: KOM-SRV-Linux-Admins(a)ad.holding.com

However, getent does not return information about domain accounts:

[root@KOM-OVIRT1 ~]# getent passwd aleksey(a)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:[e-mail]]
(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:[e-mail]]

------------------------------------------------

/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?

[Justin Stephenson]

On 10/19/2016 10:19 AM, aleksey.maksimov(a)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-dire...
>
>  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(a)ad.holding.com
>    login-policy: allow-permitted-logins
>    permitted-logins:
>    permitted-groups: KOM-SRV-Linux-Admins(a)ad.holding.com
>
>  However, getent does not return information about domain accounts:
>
>  [root@KOM-OVIRT1 ~]# getent passwd aleksey(a)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:[e-mail]]
>  (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:[e-mail]]
>
>  ------------------------------------------------
>
>  /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(a)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(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>

[Aleksey Maksimov]

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

[Jakub Hrozek]

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.

[Aleksey Maksimov]

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

[Jakub Hrozek]

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.

[Aleksey Maksimov]

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(a)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,D...
(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,D...
(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!

[Jakub Hrozek]

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

[Aleksey Maksimov]

In what section of the sssd.conf I should add "ldap_idmap_default_domain_sid" ?

In man sssd.conf no information

[Jakub Hrozek]

On Thu, Oct 20, 2016 at 09:49:21AM -0000, Aleksey Maksimov wrote:
>  In what section of the sssd.conf I should add
> "ldap_idmap_default_domain_sid" ? 
>  In man sssd.conf no information 
[domain/]

[Aleksey Maksimov]

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(a)ad.holding.com

---------------------------------------------