[SSSD] can't connect to openldap using GSSAPI

Alexander Gordeev lasaine at lvk.cs.msu.su
Fri Jun 25 08:55:02 UTC 2010


On Fri, 25 Jun 2010 09:33:36 +0200
Sumit Bose <sbose at redhat.com> wrote:

> On Thu, Jun 24, 2010 at 12:52:32PM +0400, Alexander Gordeev wrote:
> > В Thu, 24 Jun 2010 09:48:16 +0200
> > Sumit Bose <sbose at redhat.com> пишет:
> > 
> > > On Thu, Jun 24, 2010 at 02:43:49AM +0400, Alexander Gordeev wrote:
> > > > В Wed, 23 Jun 2010 20:57:10 +0400
> > > > Alexander Gordeev <lasaine at lvk.cs.msu.su> пишет:
> > > > 
> > > > > On Wed, 23 Jun 2010 16:33:17 +0200
> > > > > Sumit Bose <sbose at redhat.com> wrote:
> > > > > 
> > > > > > 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?
> > > > > 
> > > > > Thanks, I think I've found out what's going on!
> > > > > 
> > > > [snip]
> > > > > 
> > > > > I've looked at the code and found that sssd doesn't add any explicit
> > > > > attribute requests indeed, so I made a quick patch, which I'll post in
> > > > > reply to this letter. Please note that I haven't tested it yet, will
> > > > > do that later.
> > > > 
> > > > I've just tested the patch and it works. I only had to add const
> > > > qualifier to eliminate warning. But while getting supported SASL
> > > > mechanisms works good now I'm stuck with the next issue: GSSAPI auth
> > > > fails. Here is the log:
> > > > 
> > > > (Wed Jun 23 22:56:00 2010) [sssd[be[GNET]]] [sasl_bind_send] (4): Executing sasl bind mech: gssapi, user: host/desktopvm.gnet at GNET
> > > > (Wed Jun 23 22:56:00 2010) [sssd[be[GNET]]] [sasl_bind_send] (1): ldap_sasl_bind failed (50)[Insufficient access]
> > > 
> > > Can you check what happens on the server?
> > 
> > Sure, here is the debug log from slapd for sssd:
> > 
> > Jun 24 12:30:09 authvm slapd[9304]: conn=175 fd=23 ACCEPT from IP=192.168.0.153:41918 (IP=0.0.0.0:636)
> > Jun 24 12:30:09 authvm slapd[9304]: conn=175 fd=23 TLS established tls_ssf=128 ssf=128
> > Jun 24 12:30:09 authvm slapd[9304]: conn=175 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
> > Jun 24 12:30:09 authvm slapd[9304]: conn=175 op=0 SRCH attr=* supportedSASLMechanisms
> > Jun 24 12:30:09 authvm slapd[9304]: conn=175 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text=
> > Jun 24 12:30:10 authvm slapd[9304]: conn=175 op=1 BIND dn="" method=163
> > Jun 24 12:30:10 authvm slapd[9304]: conn=175 op=1 RESULT tag=97 err=14 text=SASL(0): successful result: 
> > Jun 24 12:30:10 authvm slapd[9304]: conn=175 op=2 BIND dn="" method=163
> > Jun 24 12:30:10 authvm slapd[9304]: conn=175 op=2 RESULT tag=97 err=14 text=SASL(0): successful result: 
> > Jun 24 12:30:10 authvm slapd[9304]: conn=175 op=3 BIND dn="" method=163
> > Jun 24 12:30:10 authvm slapd[9304]: SASL [conn=175] Failure: Inappropriate authentication
> > Jun 24 12:30:10 authvm slapd[9304]: conn=175 op=3 RESULT tag=97 err=50 text=SASL(-14): authorization failure: Inappropriate authentication
> > Jun 24 12:30:10 authvm slapd[9304]: conn=175 op=4 UNBIND
> > Jun 24 12:30:10 authvm slapd[9304]: conn=175 fd=23 closed
> > 
> > And for plain ldapsearch:
> > 
> > Jun 24 12:48:19 authvm slapd[11332]: conn=2 fd=17 ACCEPT from IP=192.168.0.153:46597 (IP=0.0.0.0:636)
> > Jun 24 12:48:19 authvm slapd[11332]: conn=2 fd=17 TLS established tls_ssf=128 ssf=128
> > Jun 24 12:48:19 authvm slapd[11332]: conn=2 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
> > Jun 24 12:48:19 authvm slapd[11332]: conn=2 op=0 SRCH attr=supportedSASLMechanisms
> > Jun 24 12:48:19 authvm slapd[11332]: conn=2 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text=
> > Jun 24 12:48:19 authvm slapd[11332]: conn=2 op=1 BIND dn="" method=163
> > Jun 24 12:48:19 authvm slapd[11332]: conn=2 op=1 RESULT tag=97 err=14 text=SASL(0): successful result: 
> > Jun 24 12:48:19 authvm slapd[11332]: conn=2 op=2 BIND dn="" method=163
> > Jun 24 12:48:19 authvm slapd[11332]: conn=2 op=2 RESULT tag=97 err=14 text=SASL(0): successful result: 
> > Jun 24 12:48:19 authvm slapd[11332]: conn=2 op=3 BIND dn="" method=163
> > Jun 24 12:48:19 authvm slapd[11332]: conn=2 op=3 BIND authcid="host/apollo.gnet at GNET" authzid="host/apollo.gnet at GNET"
> > Jun 24 12:48:19 authvm slapd[11332]: conn=2 op=3 BIND dn="uid=host/apollo.gnet,cn=gnet,cn=gssapi,cn=auth" mech=GSSAPI sasl_ssf=56 ssf=128
> 
> Your sssd.conf says:
> 
> ldap_sasl_authid = host/desktopvm.gnet at GNET
> 
> can you check if it will work with
> 
> ldap_sasl_authid = host/apollo.gnet at GNET

Sorry, I didn't tell you that this log was from another machine, with
it's own key, and therefore I changed ldap_sasl_authid appropriately.
On desktopvm everything is the same i.e. auth fails in the same way.

Seems I'll have to dive into debugging SASL... But maybe you have some
hints for me? :)

> > Jun 24 12:48:19 authvm slapd[11332]: conn=2 op=3 RESULT tag=97 err=0 text=
> > Jun 24 12:48:19 authvm slapd[11332]: conn=2 op=4 SRCH base="dc=gnet" scope=2 deref=0 filter="(objectClass=*)"
> > Jun 24 12:48:19 authvm slapd[11332]: conn=2 op=4 SEARCH RESULT tag=101 err=0 nentries=9 text=
> > Jun 24 12:48:19 authvm slapd[11332]: conn=2 op=5 UNBIND
> > Jun 24 12:48:19 authvm slapd[11332]: conn=2 fd=17 closed
> > 
> > So the last step of SASL auth is failing.
> > 
> > -- 
> >   Alexander
> 
> 
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/sssd-devel


-- 
  Alexander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20100625/772e459c/attachment.sig>


More information about the sssd-devel mailing list