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
and
we'll look into fixing it to work with LDAPS.
On Jun 23, 2010, at 8:24 AM, Alexander Gordeev <lasaine(a)lvk.cs.msu.su> wrote:
Hi All!
Sorry if I've chosen the wrong place to write. If there is a better
place to ask for support, please tell me.
I have problems retrieving user and group data from ldap using sssd. I
use openldap as ldap server. The only allowed authentication mechanism
is GSSAPI. All other are turned off explicitly. I've read all sssd's
man pages and I'm quite sure that this is one of use cases that sssd
should be able to handle. But it can't. :(
BTW, I use Debian testing and installed it from Debian's repositories.
The version is 1.2.0-1 which is actually 1.2.0 unmodified.
Here are some appropriate pieces from slapd's debug log:
1. running 'id user' when sssd is enabled through nsswitch.conf
Jun 18 13:58:17 authvm slapd[11723]: conn=1950 fd=23 ACCEPT from IP=192.168.0.13:53362
(IP=0.0.0.0:636)
Jun 18 13:58:17 authvm slapd[11723]: conn=1950 fd=23 TLS established tls_ssf=128 ssf=128
Jun 18 13:58:17 authvm slapd[11723]: conn=1950 op=0 SRCH base="" scope=0
deref=0 filter="(objectClass=*)"
Jun 18 13:58:17 authvm slapd[11723]: conn=1950 op=0 SEARCH RESULT tag=101 err=0
nentries=1 text=
Jun 18 13:58:17 authvm slapd[11723]: conn=1950 op=1 UNBIND
Jun 18 13:58:17 authvm slapd[11723]: conn=1950 fd=23 closed
2. kinit -k -t /etc/krb5.keytab && ldapsearch
Jun 18 14:07:03 authvm slapd[29021]: conn=2 fd=15 ACCEPT from IP=192.168.0.13:42560
(IP=0.0.0.0:636)
Jun 18 14:07:03 authvm slapd[29021]: conn=2 fd=15 TLS established tls_ssf=128 ssf=128
Jun 18 14:07:03 authvm slapd[29021]: conn=2 op=0 SRCH base="" scope=0 deref=0
filter="(objectClass=*)"
Jun 18 14:07:03 authvm slapd[29021]: conn=2 op=0 SRCH attr=supportedSASLMechanisms
Jun 18 14:07:03 authvm slapd[29021]: conn=2 op=0 SEARCH RESULT tag=101 err=0 nentries=1
text=
Jun 18 14:07:03 authvm slapd[29021]: conn=2 op=1 BIND dn="" method=163
Jun 18 14:07:03 authvm slapd[29021]: conn=2 op=1 RESULT tag=97 err=14 text=SASL(0):
successful result:
Jun 18 14:07:03 authvm slapd[29021]: conn=2 op=2 BIND dn="" method=163
Jun 18 14:07:03 authvm slapd[29021]: conn=2 op=2 RESULT tag=97 err=14 text=SASL(0):
successful result:
Jun 18 14:07:03 authvm slapd[29021]: conn=2 op=3 BIND dn="" method=163
Jun 18 14:07:03 authvm slapd[29021]: conn=2 op=3 BIND
authcid="host/desktopvm.gnet@GNET" authzid="host/desktopvm.gnet@GNET"
Jun 18 14:07:03 authvm slapd[29021]: conn=2 op=3 BIND
dn="uid=host/desktopvm.gnet,cn=gnet,cn=gssapi,cn=auth" mech=GSSAPI sasl_ssf=56
ssf=128
Jun 18 14:07:03 authvm slapd[29021]: conn=2 op=3 RESULT tag=97 err=0 text=
Jun 18 14:07:03 authvm slapd[29021]: conn=2 op=4 SRCH base="dc=gnet" scope=2
deref=0 filter="(objectClass=*)"
Jun 18 14:07:03 authvm slapd[29021]: conn=2 op=4 SEARCH RESULT tag=101 err=0 nentries=9
text=
Jun 18 14:07:03 authvm slapd[29021]: conn=2 op=5 UNBIND
Jun 18 14:07:03 authvm slapd[29021]: conn=2 fd=15 closed
You can clearly see the difference. sssd doesn't even try to
authenticate using SASL. Here is sssd's debug log at the same time
(debug level = 10):
(Fri Jun 18 13:58:17 2010) [sssd[nss]] [get_client_cred] (9): Client creds: euid[0]
egid[0] pid[24567].
(Fri Jun 18 13:58:17 2010) [sssd[nss]] [accept_fd_handler] (4): Client connected!
(Fri Jun 18 13:58:17 2010) [sssd[nss]] [sss_cmd_get_version] (5): Received client version
[1].
(Fri Jun 18 13:58:17 2010) [sssd[nss]] [sss_cmd_get_version] (5): Offered version [1].
(Fri Jun 18 13:58:17 2010) [sssd[nss]] [nss_cmd_getpwnam] (4): Requesting info for [alex]
from [<ALL>]
(Fri Jun 18 13:58:17 2010) [sssd[nss]] [nss_cmd_getpwnam] (4): Requesting info for
[alex@GNET]
(Fri Jun 18 13:58:17 2010) [sssd[nss]] [sss_dp_send_acct_req_create] (4): Sending request
for [GNET][4097][1][name=alex]
(Fri Jun 18 13:58:17 2010) [sssd[nss]] [sbus_add_timeout] (8): 0x80998d8
(Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [sbus_dispatch] (9): dbus conn: 80A7088
(Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [sbus_dispatch] (9): Dispatching.
(Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [sbus_message_handler] (9): Received SBUS
method [getAccountInfo]
(Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [be_get_account_info] (4): Got request for
[4097][1][name=alex]
(Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [fo_resolve_service_send] (4): Trying to
resolve service 'LDAP'
(Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [get_server_status] (7): Status of server
'authvm.gnet' is 'name resolved'
(Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [get_port_status] (7): Port status of port
636 for server 'authvm.gnet' is 'not working'
(Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [get_port_status] (4): Reseting the status of
port 636 for server 'authvm.gnet'
(Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [get_server_status] (7): Status of server
'authvm.gnet' is 'name resolved'
(Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [be_resolve_server_done] (4): Found address
for server authvm.gnet: [192.168.0.14]
(Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [sdap_get_rootdse_send] (9): Getting rootdse
(Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [sdap_get_generic_send] (6): calling
ldap_search_ext with [(objectclass=*)][].
(Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [sdap_ldap_connect_callback_add] (9): New
LDAP connection to [ldaps://authvm.gnet:636] with fd [19].
(Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [sdap_get_generic_send] (8): ldap_search_ext
called, msgid = 1
(Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [sdap_process_result] (8): Trace:
sh[0x80acfb0], connected[1], ops[0x80c6a00], ldap[0x80acd50]
(Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [sdap_parse_entry] (9): OriginalDN: [].
(Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [sdap_process_result] (8): Trace:
sh[0x80acfb0], connected[1], ops[0x80c6a00], ldap[0x80acd50]
(Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [sdap_get_generic_done] (6): Search result:
Success(0), (null)
(Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [sdap_get_rootdse_done] (9): Got rootdse
(Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [fo_set_port_status] (4): Marking port 636 of
server 'authvm.gnet' as 'not working'
(Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [sdap_handle_release] (8): Trace:
sh[0x80acfb0], connected[1], ops[(nil)], ldap[0x80acd50], destructor_lock[0],
release_memory[0]
(Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [remove_connection_callback] (9):
Successfully removed connection callback.
(Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [users_get_connect_done] (0): Authentication
mechanism not Supported by server(Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]]
[acctinfo_callback] (4): Request processed. Returned 3,95,User lookup failed
(Fri Jun 18 13:58:17 2010) [sssd[nss]] [sbus_remove_timeout] (8): 0x80998d8
(Fri Jun 18 13:58:17 2010) [sssd[nss]] [sbus_dispatch] (9): dbus conn: 80999E8
(Fri Jun 18 13:58:17 2010) [sssd[nss]] [sbus_dispatch] (9): Dispatching.
(Fri Jun 18 13:58:17 2010) [sssd[nss]] [sss_dp_get_reply] (4): Got reply (3, 95, User
lookup failed) from Data Provider
(Fri Jun 18 13:58:17 2010) [sssd[nss]] [nss_cmd_getpwnam_dp_callback] (2): Unable to get
information from Data Provider
Error: 3, 95, User lookup failed
Will try to return what we have in cache
(Fri Jun 18 13:58:17 2010) [sssd[nss]] [nss_cmd_getpwnam_callback] (2): No matching
domain found for [alex], fail!
(Fri Jun 18 13:58:17 2010) [sssd[nss]] [nss_cmd_getpwnam_callback] (2): No results for
getpwnam call
(Fri Jun 18 13:58:17 2010) [sssd[nss]] [client_recv] (5): Client disconnected!
Please help me to get this working. I've searched the net but didn't
found anything alike.
I've also attached my sssd.conf and ldap.conf for reference.
--
Alexander
<ldap.conf>
<sssd.conf>
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel