9:19 a.m.
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: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?
1:54 p.m.
New subject: Active Directory domain authorization on CentOS 7.2 servers with SSSD
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: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(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
>
12:58 a.m.
New subject: Active Directory domain authorization on CentOS 7.2 servers with SSSD
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
2:33 a.m.
New subject: Active Directory domain authorization on CentOS 7.2 servers with SSSD
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.
3:17 a.m.
New subject: Active Directory domain authorization on CentOS 7.2 servers with SSSD
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
3:35 a.m.
New subject: Active Directory domain authorization on CentOS 7.2 servers with SSSD
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.
4:31 a.m.
New subject: Active Directory domain authorization on CentOS 7.2 servers with SSSD
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!
4:40 a.m.
New subject: Active Directory domain authorization on CentOS 7.2 servers with SSSD
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
4:49 a.m.
New subject: Active Directory domain authorization on CentOS 7.2 servers with SSSD
In what section of the sssd.conf I should add "ldap_idmap_default_domain_sid" ?
In man sssd.conf no information
5:43 a.m.
New subject: Active Directory domain authorization on CentOS 7.2 servers with SSSD
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
---------------------------------------------
2739
days inactive
2740
days old
sssd-users@lists.fedorahosted.org
10 comments
3 participants
participants (3)
-
Aleksey Maksimov -
Jakub Hrozek -
Justin Stephenson