On Tue, Dec 01, 2015 at 05:02:39PM +0100, Petr Cech wrote:
On 11/27/2015 10:35 AM, Jakub Hrozek wrote:
>On Thu, Nov 19, 2015 at 05:57:56PM +0100, Petr Cech wrote:
>>On 11/12/2015 06:04 PM, Jakub Hrozek wrote:
>>>On Thu, Nov 12, 2015 at 04:54:21PM +0100, Petr Cech wrote:
>>>>>On 11/11/2015 02:42 PM, Jakub Hrozek wrote:
>>>>>>>Hi, I think it's a good idea to only say we don't
handle services for
>>>>>>>IPA subdomains. But I also think it would be better to
shortcut the
>>>>>>>request sooner, in ipa_subdomain_account_send() to avoid even
sending an
>>>>>>>LDAP query.
>>>>>Hi Jakub,
>>>>>
>>>>>new patch is attached. During the testing... I found out, that I use
wrong
>>>>>set up. Subdomains are connected to FreeIPA with trusted AD.
>>>What's wrong about it? I think we/should/ test this setup..
>>
>>Hi Jakub,
>>
>>I was confused about it. I haven't got such environment with IP trust. But
>>now I have one.
>>
>>>
>>>>>
>>>>>So... patch is here, but I would like set up my environment properly
and
>>>>>then I will inform you:-)
>>>>>
>>>>>Regards
>>>>>
>>>>>Petr
>>
>>But I still do something wrong. I set up environment:
>>
>>AD server: dom-78.abc...
>>FreeIPA server: mirfak.persei.dev
>>FreeIPA client: algol.persei.dev
>>
>>I set up the trust between IPA and AD. And then I tried on ipa clinet:
>># getent services ldap/mirfak.persei.dev(a)PERSEI.DEV
>
>This is not a different kind of service (a Kerberos service principal).
>The ticket is about services resolvable via libc's NSS interface:
>
https://www.gnu.org/software/libc/manual/html_node/Name-Service-Switch.ht...
Hi Jakub,
thank you for documentation.
>
>See man 5 nsswitch conf for some more info. The API used for resolving
>services is described in man 3 getservent and similar. Normally services
>are stored on the filesystem, similar to local users, see cat
>/etc/services. But custom services can also be stored in LDAP or other
>sources. And while we support looking up services, the IPA back end does
>not and currently if you do:
> getent services -s sss dns
This command is usefull. I have used:
# getent services -s sss dns(a)persei.dev
>
>The logs would show:
>(Fri Nov 27 09:31:13 2015) [sssd[be[ipa.test]]] [be_get_account_info] (0x0200): Got
request for [0x1005][FAST BE_REQ_SERVICES][1][name=dns]
>(Fri Nov 27 09:31:13 2015) [sssd[be[ipa.test]]] [be_req_set_domain] (0x0400):
Changing request domain from [ipa.test] to [ipa.test]
>(Fri Nov 27 09:31:13 2015) [sssd[be[ipa.test]]] [services_get_send] (0x1000):
Preparing to search for services with filter [(&(cn=dns)(objectclass=ipService))]
>(Fri Nov 27 09:31:13 2015) [sssd[be[ipa.test]]] [sdap_id_op_connect_step] (0x4000):
reusing cached connection
>(Fri Nov 27 09:31:13 2015) [sssd[be[ipa.test]]] [sdap_get_services_next_base]
(0x0400): Searching for services with base [cn=accounts,dc=ipa,dc=test]
>(Fri Nov 27 09:31:13 2015) [sssd[be[ipa.test]]] [sdap_print_server] (0x2000):
Searching 192.168.122.100
>(Fri Nov 27 09:31:13 2015) [sssd[be[ipa.test]]] [sdap_get_generic_ext_step] (0x0400):
calling ldap_search_ext with
[(&(cn=dns)(objectclass=ipService))][cn=accounts,dc=ipa,dc=test].
>(Fri Nov 27 09:31:13 2015) [sssd[be[ipa.test]]] [sdap_get_generic_ext_step] (0x1000):
Requesting attrs: [objectClass]
>(Fri Nov 27 09:31:13 2015) [sssd[be[ipa.test]]] [sdap_get_generic_ext_step] (0x1000):
Requesting attrs: [cn]
>(Fri Nov 27 09:31:13 2015) [sssd[be[ipa.test]]] [sdap_get_generic_ext_step] (0x1000):
Requesting attrs: [ipServicePort]
>(Fri Nov 27 09:31:13 2015) [sssd[be[ipa.test]]] [sdap_get_generic_ext_step] (0x1000):
Requesting attrs: [ipServiceProtocol]
>(Fri Nov 27 09:31:13 2015) [sssd[be[ipa.test]]] [sdap_get_generic_ext_step] (0x1000):
Requesting attrs: [entryUSN]
>(Fri Nov 27 09:31:13 2015) [sssd[be[ipa.test]]] [sdap_get_generic_ext_step] (0x2000):
ldap_search_ext called, msgid = 16
>(Fri Nov 27 09:31:13 2015) [sssd[be[ipa.test]]] [sdap_op_add] (0x2000): New operation
16 timeout 2
>(Fri Nov 27 09:31:13 2015) [sssd[be[ipa.test]]] [sdap_process_result] (0x2000):
Trace: sh[0xeedc00], connected[1], ops[0xf1aca0], ldap[0xef0bb0]
>(Fri Nov 27 09:31:13 2015) [sssd[be[ipa.test]]] [sdap_process_message] (0x4000):
Message type: [LDAP_RES_SEARCH_RESULT]
>(Fri Nov 27 09:31:13 2015) [sssd[be[ipa.test]]] [sdap_get_generic_op_finished]
(0x0400): Search result: Success(0), no errmsg set
>(Fri Nov 27 09:31:13 2015) [sssd[be[ipa.test]]] [sdap_op_destructor] (0x2000):
Operation 16 finished
>(Fri Nov 27 09:31:13 2015) [sssd[be[ipa.test]]] [sdap_get_services_process] (0x0400):
Search for services, returned 0 results.
>(Fri Nov 27 09:31:13 2015) [sssd[be[ipa.test]]] [sdap_id_op_done] (0x4000): releasing
operation connection
>(Fri Nov 27 09:31:13 2015) [sssd[be[ipa.test]]] [ldb] (0x4000): start ldb transaction
(nesting: 0)
>(Fri Nov 27 09:31:13 2015) [sssd[be[ipa.test]]] [sysdb_search_services] (0x2000):
Search services with filter:
(&(objectclass=service)(&(serviceProtocol=*)(|(nameAlias=dns)(name=dns))))
>(Fri Nov 27 09:31:13 2015) [sssd[be[ipa.test]]] [ldb] (0x4000): Added timed event
"ltdb_callback": 0xf06ba0
>
>(Fri Nov 27 09:31:13 2015) [sssd[be[ipa.test]]] [ldb] (0x4000): Added timed event
"ltdb_timeout": 0xf06c60
>
>(Fri Nov 27 09:31:13 2015) [sssd[be[ipa.test]]] [ldb] (0x4000): Running timer event
0xf06ba0 "ltdb_callback"
>
>(Fri Nov 27 09:31:13 2015) [sssd[be[ipa.test]]] [ldb] (0x4000): Destroying timer
event 0xf06c60 "ltdb_timeout"
>
>(Fri Nov 27 09:31:13 2015) [sssd[be[ipa.test]]] [ldb] (0x4000): Ending timer event
0xf06ba0 "ltdb_callback"
>
>(Fri Nov 27 09:31:13 2015) [sssd[be[ipa.test]]] [sysdb_search_services] (0x2000): No
such entry
>(Fri Nov 27 09:31:13 2015) [sssd[be[ipa.test]]] [ldb] (0x4000): cancel ldb
transaction (nesting: 0)
If I understand, those lines are misleading:
>(Fri Nov 27 09:31:13 2015) [sssd[be[ipa.test]]] [get_object_from_cache] (0x0020):
Unexpected entry type [5].
>(Fri Nov 27 09:31:13 2015) [sssd[be[ipa.test]]] [ipa_id_get_account_info_orig_done]
(0x0040): get_object_from_cache failed.
>(Fri Nov 27 09:31:13 2015) [sssd[be[ipa.test]]] [ipa_account_info_error_text]
(0x0020): Bug: dp_error is OK on failed request
New attached patch removes them. There are logs:
(Tue Dec 1 16:53:50 2015) [sssd[be[persei.dev]]] [get_object_from_cache]
(0x0040): Services for IPA subdomains aren't handled by SSSD.
(Tue Dec 1 16:53:50 2015) [sssd[be[persei.dev]]]
[ipa_id_get_account_info_orig_done] (0x0080): Object not found, ending
request
(Tue Dec 1 16:53:50 2015) [sssd[be[persei.dev]]] [acctinfo_callback]
(0x0100): Request processed. Returned 3,0,Account info lookup failed
(Tue Dec 1 16:53:50 2015) [sssd[be[persei.dev]]] [sdap_process_result]
(0x2000): Trace: sh[0x89f8d0], connected[1], ops[(nil)], ldap[0x89c340]
(Tue Dec 1 16:53:50 2015) [sssd[be[persei.dev]]] [sdap_process_result]
(0x2000): Trace: ldap_result found nothing!
>The problem is that software that tries to locate service entries via NSS
>might ask SSSD and then we get these confusing error messages..
>
>I think the question we need to ask is if we want to support admins who
>add service records to IPA manually. If we do, then I think we should
>allow service lookups for the IPA domain itself and then don't error out
>in get_object_from_cache. Trusted domain lookups can just end. If we decide
>that service lookups are not supported at all with IPA, then we can always
>just return "not found".
That's the question. I think that better is no support for service lookup.
Because such services were added manually by admins, so there is no check,
standardization.
Hmm, I'm not sure I agree. I mean, is there a downsite to supporting the
service lookups?
The check and standardization should be done on the server side by the
schema, then it's only about a proper client configu.
I am not sure if I have done whole task. If we need another shortcut,
please, write me.
The current patch still marks the request as failed, which is something
I wanted to avoid:
(Thu Dec 3 15:57:33 2015) [sssd[be[ipa.test]]]
[get_object_from_cache] (0x0040): Services for IPA subdomains aren't
handled by SSSD.
(Thu Dec 3 15:57:33 2015) [sssd[be[ipa.test]]]
[ipa_id_get_account_info_orig_done] (0x0080): Object not found,
ending request
(Thu Dec 3 15:57:33 2015) [sssd[be[ipa.test]]] [acctinfo_callback]
(0x0100): Request processed. Returned 3,0,Account info lookup failed
Moreover, even though the debug message states service lookups are not
supported, the lookups runs and the service object would be cached at
that point, so all the work is more or less done.
So we have two options:
1) shortcut the service lookups completely
2) allow service lookups, but don't apply the override magic. I
personally prefer this option (mostly because I don't see any
downside), but I'm fine discussing this.
Implementing 1) would mean that we would check if the request is for
services in ipa_account_info_handler(). If yes, then we would just mark
the request as done with a debug message. This would prevent the search
from running (and note that the search here also includes the cache
save).
Implementing 2) would be a bit more involved. It would require to run
the LDAP search, but not the special IPA-specific override
functionality.
Once the flow arrives to the sssd_be process, the lookup goes like this:
ipa_account_info_handler ->
ipa_id_get_account_info_send ->
ipa_id_get_account_info_get_original_step ->
sdap_handle_acct_req_send ->
ipa_id_get_account_info_orig_done
In ipa_id_get_account_info_orig_done(), after we call
sdap_handle_acct_req_recv() we could check if the object is
"overridable". If yes, we would run the current code. If not, we would
mark the request as done. The function to check for objects that support
overrides might be also useful for starting the request -- in
ipa_id_get_account_info_send() we could use it to decide whether to go
directly to ipa_id_get_account_info_get_original_step() or first check
the overrides with the other branch.
Sorry for the long mail, I hope it makes some sense now :)