[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: SASL_SUCCESS_DATA should be set (ITS#2202)

Have you already verified that this works? Since I have no GSS-SPNEGO mech to
test with, I can't check it myself. Why does slapd need to be changed, if
slapd doesn't use a mechanism with server-send-last functionality? Or are you
testing a GSS-SPNEGO implementation for slapd? (As opposed to testing the
client side, using a MS AD as the server.)

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

> -----Original Message-----
> From: owner-openldap-bugs@OpenLDAP.org
> [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of lukeh@padl.com
> Sent: Tuesday, November 26, 2002 2:39 AM
> To: openldap-its@OpenLDAP.org
> Subject: SASL_SUCCESS_DATA should be set (ITS#2202)
> Full_Name: Luke Howard
> Version: HEAD
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (
> In servers/slapd/sasl.c, when calling sasl_server_new(), you
> should pass
> SASL_SUCCESS_DATA as the second-last argument.
> Why? Some SASL mechanisms appear to send a final response
> with the last token.
> For example, Microsoft's GSS-SPNEGO mechanism appears not to
> do the SASL SSF
> negotiation, and so the final SPNEGO "accept completed" token
> is returned in a
> successful LDAP BindResponse PDU.