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.
I am not sure if I have done whole task. If we need another shortcut,
please, write me.
Regards
Petr