On Wed, 23 Jun 2010 09:35:42 -0400
Stephen Gallagher <stephen(a)gallagherhome.com> wrote:
> I don't think we ever tested GSSAPI over LDAPS. I'm not sure if that
> works. Can you try over straight LDAP? The GSSAPI SASL mechanism
> provides an encrypted tunnel, so LDAPS would be overkill as well.
>
> If that works, please file a bug at
https://fedorahosted.org/sssd and
> we'll look into fixing it to work with LDAPS.
Thanks for the quick answer!
Just tried it over plain LDAP: everything is the same:
Jun 23 17:57:31 authvm slapd[9304]: conn=4 fd=22 ACCEPT from IP=192.168.0.13:35678
(IP=0.0.0.0:389)
Jun 23 17:57:31 authvm slapd[9304]: conn=4 op=0 SRCH base="" scope=0 deref=0
filter="(objectClass=*)"
Jun 23 17:57:31 authvm slapd[9304]: conn=4 op=0 SEARCH RESULT tag=101 err=0 nentries=1
text=
Jun 23 17:57:31 authvm slapd[9304]: conn=4 op=1 UNBIND
Jun 23 17:57:31 authvm slapd[9304]: conn=4 fd=22 closed
and
(Wed Jun 23 18:01:22 2010) [sssd[nss]] [get_client_cred] (9): Client creds: euid[0]
egid[0] pid[26401].
(Wed Jun 23 18:01:22 2010) [sssd[nss]] [accept_fd_handler] (4): Client connected!
(Wed Jun 23 18:01:22 2010) [sssd[nss]] [sss_cmd_get_version] (5): Received client version
[1].
(Wed Jun 23 18:01:22 2010) [sssd[nss]] [sss_cmd_get_version] (5): Offered version [1].
(Wed Jun 23 18:01:22 2010) [sssd[nss]] [nss_cmd_getpwnam] (4): Requesting info for [alex]
from [<ALL>]
(Wed Jun 23 18:01:22 2010) [sssd[nss]] [nss_cmd_getpwnam] (4): Requesting info for
[alex@GNET]
(Wed Jun 23 18:01:22 2010) [sssd[nss]] [sss_dp_send_acct_req_create] (4): Sending request
for [GNET][4097][1][name=alex]
(Wed Jun 23 18:01:22 2010) [sssd[nss]] [sbus_add_timeout] (8): 0x80993c0
(Wed Jun 23 18:01:22 2010) [sssd[be[GNET]]] [sbus_dispatch] (9): dbus conn: 80A96F8
(Wed Jun 23 18:01:22 2010) [sssd[be[GNET]]] [sbus_dispatch] (9): Dispatching.
(Wed Jun 23 18:01:22 2010) [sssd[be[GNET]]] [sbus_message_handler] (9): Received SBUS
method [getAccountInfo]
(Wed Jun 23 18:01:22 2010) [sssd[be[GNET]]] [be_get_account_info] (4): Got request for
[4097][1][name=alex]
(Wed Jun 23 18:01:22 2010) [sssd[be[GNET]]] [fo_resolve_service_send] (4): Trying to
resolve service 'LDAP'
(Wed Jun 23 18:01:22 2010) [sssd[be[GNET]]] [get_server_status] (7): Status of server
'authvm.gnet' is 'name not resolved'
(Wed Jun 23 18:01:22 2010) [sssd[be[GNET]]] [get_port_status] (7): Port status of port
389 for server 'authvm.gnet' is 'neutral'
(Wed Jun 23 18:01:22 2010) [sssd[be[GNET]]] [get_server_status] (7): Status of server
'authvm.gnet' is 'name not resolved'
(Wed Jun 23 18:01:22 2010) [sssd[be[GNET]]] [resolv_gethostbyname_send] (4): Trying to
resolve A record of 'authvm.gnet'
(Wed Jun 23 18:01:22 2010) [sssd[be[GNET]]] [schedule_timeout_watcher] (9): Scheduling
DNS timeout watcher
(Wed Jun 23 18:01:22 2010) [sssd[be[GNET]]] [set_server_common_status] (4): Marking
server 'authvm.gnet' as 'resolving name'
(Wed Jun 23 18:01:22 2010) [sssd[be[GNET]]] [unschedule_timeout_watcher] (9):
Unscheduling DNS timeout watcher
(Wed Jun 23 18:01:22 2010) [sssd[be[GNET]]] [set_server_common_status] (4): Marking
server 'authvm.gnet' as 'name resolved'
(Wed Jun 23 18:01:22 2010) [sssd[be[GNET]]] [be_resolve_server_done] (4): Found address
for server authvm.gnet: [192.168.0.14]
(Wed Jun 23 18:01:22 2010) [sssd[be[GNET]]] [sdap_uri_callback] (6): Constructed uri
'ldap://authvm.gnet'
(Wed Jun 23 18:01:22 2010) [sssd[be[GNET]]] [sdap_get_rootdse_send] (9): Getting rootdse
(Wed Jun 23 18:01:22 2010) [sssd[be[GNET]]] [sdap_get_generic_send] (6): calling
ldap_search_ext with [(objectclass=*)][].
(Wed Jun 23 18:01:22 2010) [sssd[be[GNET]]] [sdap_ldap_connect_callback_add] (9): New
LDAP connection to [ldap://authvm.gnet:389] with fd [19].
(Wed Jun 23 18:01:22 2010) [sssd[be[GNET]]] [sdap_get_generic_send] (8): ldap_search_ext
called, msgid = 1
(Wed Jun 23 18:01:22 2010) [sssd[be[GNET]]] [sdap_process_result] (8): Trace:
sh[0x80ade40], connected[1], ops[0x80b72c8], ldap[0x80ade58]
(Wed Jun 23 18:01:22 2010) [sssd[be[GNET]]] [sdap_parse_entry] (9): OriginalDN: [].
(Wed Jun 23 18:01:22 2010) [sssd[be[GNET]]] [sdap_process_result] (8): Trace:
sh[0x80ade40], connected[1], ops[0x80b72c8], ldap[0x80ade58]
(Wed Jun 23 18:01:22 2010) [sssd[be[GNET]]] [sdap_get_generic_done] (6): Search result:
Success(0), (null)
(Wed Jun 23 18:01:22 2010) [sssd[be[GNET]]] [sdap_get_rootdse_done] (9): Got rootdse
(Wed Jun 23 18:01:22 2010) [sssd[be[GNET]]] [fo_set_port_status] (4): Marking port 389 of
server 'authvm.gnet' as 'not working'
(Wed Jun 23 18:01:22 2010) [sssd[be[GNET]]] [sdap_handle_release] (8): Trace:
sh[0x80ade40], connected[1], ops[(nil)], ldap[0x80ade58], destructor_lock[0],
release_memory[0]
(Wed Jun 23 18:01:22 2010) [sssd[be[GNET]]] [remove_connection_callback] (9):
Successfully removed connection callback.
(Wed Jun 23 18:01:22 2010) [sssd[be[GNET]]] [users_get_connect_done] (0): Authentication
mechanism not Supported by server(Wed Jun 23 18:01:22 2010) [sssd[be[GNET]]]
[acctinfo_callback] (4): Request processed. Returned 3,95,User lookup failed
This message is generated if there is not matching SASL mech entry
('gssapi' in your case) in the 'supportedSASLMechanisms' of the rootdse.
Can you check if your client can read the rootdse and if you can find
the gssapi entry there?
bye,
Sumit