11:47 a.m.
I'm having an issue with sssd failing to look up user or group names from an AD
provider. The error occurs on both modern Fedora and Centos 7 systems joined to AD via
realm commands. On Centos 7, the version of SSSD is 1.16.0, and that is the version on
which I am reporting.
The systems will work perfectly for a long time (up to months) and then suddenly start
failing. The most noticeable failure is that "ls -l" of files will give UID/GID
numbers, not names, and also ssh into the system will report the error "/usr/bin/id:
cannot find name for group ID".
The failure can be temporarily cured with commands such as:
getent passwd username
getent group "domain users"
but after a short period of time the failure resumes. Clearing the cache via
"sss_cache -E" also causes the problem to immediately manifest.
I ran some tests with logging enabled. NSS debug level set to 6. The test is to issue the
command:
ls -ld dpotterv
When things are working, I see:
drwx------. 19 dpotterv domain users 29 Jun 1 10:08 dpotterv
When things are failing, I see:
drwx------. 19 900209170 900200513 29 Jun 1 10:08 dpotterv
Here are the entries from the nss log for FAILURE:
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [accept_fd_handler] (0x0400): Client connected!
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [sss_cmd_get_version] (0x0200): Received client
version [1].
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [sss_cmd_get_version] (0x0200): Offered version
[1].
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [nss_getby_id] (0x0400): Input ID: 900209170
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_send] (0x0400): CR #21: New request
'User by ID'
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_select_domains] (0x0400): CR #21:
Performing a multi-domain search
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_search_domains] (0x0400): CR #21: Search
will check the cache and check the data provider
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_set_domain] (0x0400): CR #21: Using
domain [local]
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR #21: Looking
up UID:900209170@local
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #21:
Checking negative cache for [UID:900209170@local]
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #21:
[UID:900209170@local] is not present in negative cache
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #21: Looking
up [UID:900209170@local] in cache
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_idminmax_check] (0x0200): id exceeds
min/max boundaries
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #21: ID
[UID:900209170@local] was filtered out
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_locate_dom_cache_done] (0x0040):
cache_req_search_recv returned [1432158300]: ID is outside the allowed range
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_process_result] (0x0400): CR #21:
Finished: Error 1432158300: ID is outside the allowed range
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [client_recv] (0x0200): Client disconnected!
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [accept_fd_handler] (0x0400): Client connected!
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [sss_cmd_get_version] (0x0200): Received client
version [1].
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [sss_cmd_get_version] (0x0200): Offered version
[1].
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [nss_getby_id] (0x0400): Input ID: 900200513
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_send] (0x0400): CR #22: New request
'Group by ID'
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_select_domains] (0x0400): CR #22:
Performing a multi-domain search
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_search_domains] (0x0400): CR #22: Search
will check the cache and check the data provider
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_set_domain] (0x0400): CR #22: Using
domain [local]
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR #22: Looking
up GID:900200513@local
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #22:
Checking negative cache for [GID:900200513@local]
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #22:
[GID:900200513@local] is not present in negative cache
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #22: Looking
up [GID:900200513@local] in cache
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_idminmax_check] (0x0200): id exceeds
min/max boundaries
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #22: ID
[GID:900200513@local] was filtered out
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_locate_dom_cache_done] (0x0040):
cache_req_search_recv returned [1432158300]: ID is outside the allowed range
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_process_result] (0x0400): CR #22:
Finished: Error 1432158300: ID is outside the allowed range
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [client_recv] (0x0200): Client disconnected!
I should note that in the sssd config file, I have:
[domain/local]
min_id = 3000
max_id = 199999
id_provider = local
access_provider = permit
remove_homedir = false
[domain/anl]
min_id = 200000
ldap_idmap_range_size = 100000000
cache_credentials = false
id_provider = ad
access_provider = ad
auth_provider = ad
chpass_provider = ad
ldap_schema = ad
ldap_id_mapping = true
(Yes, we have a very large range size. Currently, about 0.75 million SIDs in the AD
forest, and someone wanted room for growth.)
Looking at the log entries, I see what looks like normal flow of events. A multi-domain
search is initiated, and the first domain searched is the local one.
It correctly determines that the ID is outside the range that is valid for this domain,
and it returns.
What is not happening is a subsequent search of the ANL domain where the ID is valid!
The following is the NSS log when I do "getent passwd dpotterv", which
succeeds:
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [accept_fd_handler] (0x0400): Client connected!
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [sss_cmd_get_version] (0x0200): Received client
version [1].
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [sss_cmd_get_version] (0x0200): Offered version
[1].
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [nss_getby_name] (0x0400): Input name: dpotterv
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_send] (0x0400): CR #27: New request
'User by name'
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_process_input] (0x0400): CR #27: Parsing
input name [dpotterv]
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name
'dpotterv' matched without domain, user is dpotterv
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_set_name] (0x0400): CR #27: Setting name
[dpotterv]
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_select_domains] (0x0400): CR #27:
Performing a multi-domain search
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_domains] (0x0400): CR #27: Search
will check the cache and check the data provider
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_set_domain] (0x0400): CR #27: Using
domain [local]
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_prepare_domain_data] (0x0400): CR #27:
Preparing input data for domain [local] rules
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR #27: Looking
up dpotterv@local
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #27:
Checking negative cache for [dpotterv@local]
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #27:
[dpotterv@local] is not present in negative cache
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #27: Looking
up [dpotterv@local] in cache
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #27: Object
[dpotterv@local] was not found in cache
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_dp] (0x0400): CR #27: Looking up
[dpotterv@local] in data provider
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #27: Looking
up [dpotterv@local] in cache
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #27: Object
[dpotterv@local] was not found in cache
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_ncache_add_to_domain] (0x0400):
CR #27: Adding [dpotterv@local] to negative cache
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [sss_ncache_set_str] (0x0400): Adding
[NCE/USER/local/dpotterv@local] to negative cache
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_set_domain] (0x0400): CR #27: Using
domain [anl]
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_prepare_domain_data] (0x0400): CR #27:
Preparing input data for domain [anl] rules
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR #27: Looking
up dpotterv@anl
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #27:
Checking negative cache for [dpotterv@anl]
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #27:
[dpotterv@anl] is not present in negative cache
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #27: Looking
up [dpotterv@anl] in cache
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR #27: Object
found, but needs to be refreshed.
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_dp] (0x0400): CR #27: Looking up
[dpotterv@anl] in data provider
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request
for [0x5560f40e6b50:1:dpotterv@anl@anl]
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request
for [anl][0x1][BE_REQ_USER][name=dpotterv@anl:-]
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering
request [0x5560f40e6b50:1:dpotterv@anl@anl]
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #27: Looking
up [dpotterv@anl] in cache
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_ncache_filter] (0x0400): CR #27:
This request type does not support filtering result by negative cache
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_done] (0x0400): CR #27: Returning
updated object [dpotterv@anl]
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_create_and_add_result] (0x0400): CR #27:
Found 1 entries in domain anl
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request:
[0x5560f40e6b50:1:dpotterv@anl@anl]
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_done] (0x0400): CR #27: Finished:
Success
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [client_recv] (0x0200): Client disconnected!
This looks like a completely routine multi-domain search by name, first searching the
local domain, and then searching the ANL domain, where it queries and receives an answer
from the AD data provider.
So, is there a bug in sssd wherein it is failing to continue multi-domain searches by ID
when an ID is out of range for local? Or is there something I'm doing wrong in the
sssd config? I'm happy to do further debugging. What logs (and level) might be
useful?
Our needs are fairly simple. ID's below 200000 are local, everything else is divided
into large slices for AD domain(s), and we are joined to one large AD domain.
Thanks for any insight!
11:53 a.m.
This is a bug that was fixed recently upstrea, but not in RHEL/centos yet.
Do you actually use the local domain?
On 1 Jun 2018, at 18:47, David Potterveld
<jongle.a.moi(a)gmail.com> wrote:
I'm having an issue with sssd failing to look up user or group names from an AD
provider. The error occurs on both modern Fedora and Centos 7 systems joined to AD via
realm commands. On Centos 7, the version of SSSD is 1.16.0, and that is the version on
which I am reporting.
The systems will work perfectly for a long time (up to months) and then suddenly start
failing. The most noticeable failure is that "ls -l" of files will give UID/GID
numbers, not names, and also ssh into the system will report the error "/usr/bin/id:
cannot find name for group ID".
The failure can be temporarily cured with commands such as:
getent passwd username
getent group "domain users"
but after a short period of time the failure resumes. Clearing the cache via
"sss_cache -E" also causes the problem to immediately manifest.
I ran some tests with logging enabled. NSS debug level set to 6. The test is to issue the
command:
ls -ld dpotterv
When things are working, I see:
drwx------. 19 dpotterv domain users 29 Jun 1 10:08 dpotterv
When things are failing, I see:
drwx------. 19 900209170 900200513 29 Jun 1 10:08 dpotterv
Here are the entries from the nss log for FAILURE:
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [accept_fd_handler] (0x0400): Client connected!
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [sss_cmd_get_version] (0x0200): Received client
version [1].
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [sss_cmd_get_version] (0x0200): Offered version
[1].
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [nss_getby_id] (0x0400): Input ID: 900209170
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_send] (0x0400): CR #21: New request
'User by ID'
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_select_domains] (0x0400): CR #21:
Performing a multi-domain search
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_search_domains] (0x0400): CR #21:
Search will check the cache and check the data provider
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_set_domain] (0x0400): CR #21: Using
domain [local]
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR #21: Looking
up UID:900209170@local
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #21:
Checking negative cache for [UID:900209170@local]
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #21:
[UID:900209170@local] is not present in negative cache
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #21: Looking
up [UID:900209170@local] in cache
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_idminmax_check] (0x0200): id exceeds
min/max boundaries
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #21: ID
[UID:900209170@local] was filtered out
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_locate_dom_cache_done] (0x0040):
cache_req_search_recv returned [1432158300]: ID is outside the allowed range
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_process_result] (0x0400): CR #21:
Finished: Error 1432158300: ID is outside the allowed range
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [client_recv] (0x0200): Client disconnected!
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [accept_fd_handler] (0x0400): Client connected!
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [sss_cmd_get_version] (0x0200): Received client
version [1].
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [sss_cmd_get_version] (0x0200): Offered version
[1].
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [nss_getby_id] (0x0400): Input ID: 900200513
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_send] (0x0400): CR #22: New request
'Group by ID'
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_select_domains] (0x0400): CR #22:
Performing a multi-domain search
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_search_domains] (0x0400): CR #22:
Search will check the cache and check the data provider
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_set_domain] (0x0400): CR #22: Using
domain [local]
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR #22: Looking
up GID:900200513@local
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #22:
Checking negative cache for [GID:900200513@local]
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #22:
[GID:900200513@local] is not present in negative cache
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #22: Looking
up [GID:900200513@local] in cache
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_idminmax_check] (0x0200): id exceeds
min/max boundaries
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #22: ID
[GID:900200513@local] was filtered out
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_locate_dom_cache_done] (0x0040):
cache_req_search_recv returned [1432158300]: ID is outside the allowed range
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [cache_req_process_result] (0x0400): CR #22:
Finished: Error 1432158300: ID is outside the allowed range
(Fri Jun 1 11:17:59 2018) [sssd[nss]] [client_recv] (0x0200): Client disconnected!
I should note that in the sssd config file, I have:
[domain/local]
min_id = 3000
max_id = 199999
id_provider = local
access_provider = permit
remove_homedir = false
[domain/anl]
min_id = 200000
ldap_idmap_range_size = 100000000
cache_credentials = false
id_provider = ad
access_provider = ad
auth_provider = ad
chpass_provider = ad
ldap_schema = ad
ldap_id_mapping = true
(Yes, we have a very large range size. Currently, about 0.75 million SIDs in the AD
forest, and someone wanted room for growth.)
Looking at the log entries, I see what looks like normal flow of events. A multi-domain
search is initiated, and the first domain searched is the local one.
It correctly determines that the ID is outside the range that is valid for this domain,
and it returns.
What is not happening is a subsequent search of the ANL domain where the ID is valid!
The following is the NSS log when I do "getent passwd dpotterv", which
succeeds:
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [accept_fd_handler] (0x0400): Client connected!
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [sss_cmd_get_version] (0x0200): Received client
version [1].
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [sss_cmd_get_version] (0x0200): Offered version
[1].
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [nss_getby_name] (0x0400): Input name: dpotterv
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_send] (0x0400): CR #27: New request
'User by name'
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_process_input] (0x0400): CR #27:
Parsing input name [dpotterv]
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name
'dpotterv' matched without domain, user is dpotterv
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_set_name] (0x0400): CR #27: Setting
name [dpotterv]
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_select_domains] (0x0400): CR #27:
Performing a multi-domain search
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_domains] (0x0400): CR #27:
Search will check the cache and check the data provider
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_set_domain] (0x0400): CR #27: Using
domain [local]
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_prepare_domain_data] (0x0400): CR #27:
Preparing input data for domain [local] rules
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR #27: Looking
up dpotterv@local
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #27:
Checking negative cache for [dpotterv@local]
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #27:
[dpotterv@local] is not present in negative cache
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #27: Looking
up [dpotterv@local] in cache
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #27: Object
[dpotterv@local] was not found in cache
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_dp] (0x0400): CR #27: Looking up
[dpotterv@local] in data provider
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #27: Looking
up [dpotterv@local] in cache
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #27: Object
[dpotterv@local] was not found in cache
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_ncache_add_to_domain] (0x0400):
CR #27: Adding [dpotterv@local] to negative cache
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [sss_ncache_set_str] (0x0400): Adding
[NCE/USER/local/dpotterv@local] to negative cache
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_set_domain] (0x0400): CR #27: Using
domain [anl]
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_prepare_domain_data] (0x0400): CR #27:
Preparing input data for domain [anl] rules
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR #27: Looking
up dpotterv@anl
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #27:
Checking negative cache for [dpotterv@anl]
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #27:
[dpotterv@anl] is not present in negative cache
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #27: Looking
up [dpotterv@anl] in cache
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR #27: Object
found, but needs to be refreshed.
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_dp] (0x0400): CR #27: Looking up
[dpotterv@anl] in data provider
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request
for [0x5560f40e6b50:1:dpotterv@anl@anl]
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating
request for [anl][0x1][BE_REQ_USER][name=dpotterv@anl:-]
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering
request [0x5560f40e6b50:1:dpotterv@anl@anl]
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #27: Looking
up [dpotterv@anl] in cache
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_ncache_filter] (0x0400): CR #27:
This request type does not support filtering result by negative cache
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_search_done] (0x0400): CR #27:
Returning updated object [dpotterv@anl]
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_create_and_add_result] (0x0400): CR
#27: Found 1 entries in domain anl
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting
request: [0x5560f40e6b50:1:dpotterv@anl@anl]
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [cache_req_done] (0x0400): CR #27: Finished:
Success
(Fri Jun 1 11:34:14 2018) [sssd[nss]] [client_recv] (0x0200): Client disconnected!
This looks like a completely routine multi-domain search by name, first searching the
local domain, and then searching the ANL domain, where it queries and receives an answer
from the AD data provider.
So, is there a bug in sssd wherein it is failing to continue multi-domain searches by ID
when an ID is out of range for local? Or is there something I'm doing wrong in the
sssd config? I'm happy to do further debugging. What logs (and level) might be
useful?
Our needs are fairly simple. ID's below 200000 are local, everything else is divided
into large slices for AD domain(s), and we are joined to one large AD domain.
Thanks for any insight!
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahost...
3:10 p.m.
I'm not sure that we do need it... I think it was put in the config as a placeholder
for old accounts on legacy systems when deciding on how UID ranges should be mapped when
we ultimately migrate to a FreeIPA domain that trusts our AD forest. We're having some
issues getting permission from the AD managers to set up the required trust, but
that's another story. Until that's ironed out, we are joining systems to the
domain with "realm" using the SID<->UID mapping that FreeIPA will use.
I've found a workaround for the bug for us. If I just comment out the
"max_id" line in domain/local, then everything goes back to normal. With only a
small number of IDs in local, and anything imported from legacy systems well below the
start of the SID mapping, I don't think we need to try and enforce the upper limit.
Thanks,
David
2:16 p.m.
On 1 Jun 2018, at 22:10, David Potterveld
<jongle.a.moi(a)gmail.com> wrote:
I'm not sure that we do need it…
Then removing the local domain is also a valid workaround for this issue.
I think it was put in the config as a placeholder for old accounts on
legacy systems when deciding on how UID ranges should be mapped when we ultimately migrate
to a FreeIPA domain that trusts our AD forest. We're having some issues getting
permission from the AD managers to set up the required trust, but that's another
story. Until that's ironed out, we are joining systems to the domain with
"realm" using the SID<->UID mapping that FreeIPA will use.
I've found a workaround for the bug for us. If I just comment out the
"max_id" line in domain/local, then everything goes back to normal. With only a
small number of IDs in local, and anything imported from legacy systems well below the
start of the SID mapping, I don't think we need to try and enforce the upper limit.
Thanks,
David
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahost...
2147
days inactive
2149
days old
sssd-users@lists.fedorahosted.org
3 comments
2 participants
participants (2)
-
David Potterveld -
Jakub Hrozek