SASL authentication
Xu, Qiang (FXSGSC)
Recently, I am tasked with implementing an SASL LDAP client in our printers. But I have little SASL knowledge so far, and hope you guys can help me with some questions.
1. Does SASL mechanism only affect the binding process? Or both the binding process and the searching process? My understanding is it only affects the binding stage. Please correct me if I am wrong.
2. Although simple binding is just one-round process, it seems SASL authentication takes one or more round trips between your LDAP client and the server. (The server may send a number of "challenges" to the client.) What are the challeges from the server? Can I furnish them with the request in just one round?
3. SASL binding/authentication usually needs a Kerberos ticket that comes afer a successeful Kerberos authentication. Before my LDAP client tries to do SALS binding with GSSAPI, How I can get the ticket and merge it into the request? Can the function ldap_sasl_bind_s() automatically retrieve it from GSSAPI library if it discovers that there is a ticket, or it need a manual retrieval?
4. Finally, if someone can provide some network traces that use SASL authentication, it would be greatly useful. If there is any code example to show how to use SASL binding with GSSAPI mechism, that will be invaluable.
Looking forword to your help,
Xu Qiang
Kashif Ali Siddiqui
Welcome aboard. Here are the answers to your questions.
Ans 1) SASL mechanism can effect the searching process. It depends on
the SASL mechanisms. There are mechanisms that only meant for secure
authentication, and hence they do not do anything with the rest of the
data communication, thus these mechanisms only effect the BIND process.
But like GSSAPI mechanism, besides secure authentication, it also
provides data confidentiality and integrity services, and hence change
the internal data communications. But whether SASL mechanism effects the
searching process or not, the LDAP API shields the SASL processes from
the developer. The only difference that appears to the developers is the
BIND call. For SASL, the LDAP API provides special API calls and
different LDAP implementations (like Mozilla, OpenLDAP, Novells, etc)
also give non-standard calls to give more and/or special support for
SASL BIND.
Ans 2) Well a SASL BIND can comprise of multiple passes (round-trips),
and it totally depends on the SASL mechanism itself. We cannot avoid
these passes and we have to make them all to enable successful BIND.
However various LDAP implementators provide non-standard LDAP APIs that
can help developers to make SASL multi-pass BIND a simpler process. Like
in Mozilla LDAP one can use API call ldap_sasl_interactive_bind to make
its SASL BIND a more manageable process.
Ans 3) The Kerberos ticket is only concern with the GSSAPI SASL
mechanism. For GSSAPI to work, the client environment MUST have the user
ticket in its credential cache either externally using kinit or
internally using Kerberos native libraries. After that the SASL GSSAPI
mechanism will acquire the LDAP service ticket by using the previously
acquired user ticket, and after successful retrieval of service ticket,
the actual LDAP communication commences in a secure session. Mozilla
provides ldap_sasl_interactive_bind(), a API call specially for SASL
bind. It requires you to specify the SASL mechanism and a function
handler that will be called on each BIND pass and in each pass the
handler provider has to provide data required in that pass. The
ldap_sasl_interactive_bind() call frees the developer from service
ticket management, and hence it is taken care off internally without any
help from the developer. Although before SASL bind, the client
environment MUST acquire the user ticket in its credential cache.
Ans 4) I do not have a traffic TRACE right now, but I have a working
client whose code is pasted in the following thread. You are free to use
it.
http://groups.google.com/group/mozilla.dev.tech.ldap/browse_thread/thread/cd73867a6a56eabf?tvc=2
Kashif Ali Siddiqui
Software Architect Folio3
> _______________________________________________
> dev-tech-ldap mailing list
> dev-te...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-ldap
>
>
Michael Ströder
>
> Recently, I am tasked with implementing an SASL LDAP client in our printers.
Since there are several very different SASL mechanisms it would help if
you'd explain what you want to achieve by using SASL bind.
Ciao, Michael.
Xu, Qiang (FXSGSC)
> Michale wrote:
>
> Since there are several very different SASL mechanisms it
> would help if you'd explain what you want to achieve by using
> SASL bind.
It is GSSAPI. The scenario is, the user logs in (against a Kerberos server), then LDAP query will be initiated to find the user's detail in the LDAP server. It is required that the binding now be in SASL mode, and a ticket be acquired from Kerberos authentication via GSSAPI dynamic library, to be used in binding to the LDAP server.
I know something about LDAP but it is almost completely dark for me on SASL + GSSAPI. Therefore, my previous mail.
Thank you, Mike.
Xu Qiang
Michael Ströder
>> -----Original Message-----
>> Michale wrote:
>>
>> Since there are several very different SASL mechanisms it
>> would help if you'd explain what you want to achieve by using
>> SASL bind.
>
> It is GSSAPI. The scenario is, the user logs in (against a Kerberos
> server),
First the client has to obtain a ticket granting ticket (TGT) from the
Kerberos KDC (e.g. via GSSAPI).
> then LDAP query will be initiated to find the user's detail
> in the LDAP server.
This can get tricky since there is no standardized way how the LDAP
server maps the SASL authc-ID to the authz-ID. And how to query the
authz-ID is also not supported the same way on all LDAP servers. Which
LDAP server do you plan to use?
> I know something about LDAP but it is almost completely dark for me on SASL + GSSAPI.
I'd recommend to 1. play with the Kerberos utils on your platform
(obtaining TGT with command-line tool kinit, then using command-line
tool ldapsearch with SASL). Note that your DNS has to be set up correctly!
Ciao, Michael.
Xu, Qiang (FXSGSC)
> Michale wrote:
>
> First the client has to obtain a ticket granting ticket (TGT)
> from the Kerberos KDC (e.g. via GSSAPI).
Just want to know whether this process can be automatic for LDAP client? Or I need to manually write some routines to fetch this key for GSSAPI?
> This can get tricky since there is no standardized way how
> the LDAP server maps the SASL authc-ID to the authz-ID. And
> how to query the authz-ID is also not supported the same way
> on all LDAP servers. Which LDAP server do you plan to use?
I plan to test it against ADS LDAP server that resides in a Windows 2003 OS first, because ADS also provides Kerberos authentication at the same time. It is bad news that different LDAP servers handle SASL differently. By the way, what is authc-ID and authz-ID? What do they refer to? Would you please elaborate on these, Mike?
> I'd recommend to 1. play with the Kerberos utils on your
> platform (obtaining TGT with command-line tool kinit, then
> using command-line tool ldapsearch with SASL). Note that your
> DNS has to be set up correctly!
I have the same thought as you these days. I want to have a Kerberos client that can work together with the command-line tool of ldapsearch (which works great for simple binding and search). With these two at hand, I can use them to do testings first, and use the testing result as a benchmark to be used in my coding later. But although I have ldapsearch utility in our Linux environment, I can't find a working Kerberos utility that works for Linux, or is it my ignorance? If there is some Kerberos client that can be used in RedHat Linux, please refer me to the location.
By the way, do you have some LDAP traces with SASL binding in it? That will be helpful, too.
Thank you,
Xu Qiang
Michael Ströder
>> -----Original Message-----
>> Michale wrote:
>>
>> First the client has to obtain a ticket granting ticket (TGT)
>> from the Kerberos KDC (e.g. via GSSAPI).
>
> Just want to know whether this process can be automatic for LDAP
> client? Or I need to manually write some routines to fetch this key
> for GSSAPI?
Obtaining the TGT involves the client's shared secret (derived from the
password). So you mainly need a password at the client-side.
You should make yourself a little bit comfortable with the Kerberos
protocol.
>> This can get tricky since there is no standardized way how
>> the LDAP server maps the SASL authc-ID to the authz-ID. And
>> how to query the authz-ID is also not supported the same way
>> on all LDAP servers. Which LDAP server do you plan to use?
>
> I plan to test it against ADS LDAP server that resides in a Windows
> 2003 OS first, because ADS also provides Kerberos authentication at
> the same time. It is bad news that different LDAP servers handle SASL
> differently.
The LDAP servers do not handle the SASL bind differently. Server-side
identity mapping is handled differently.
> By the way, what is authc-ID and authz-ID? What do they
> refer to? Would you please elaborate on these, Mike?
The authc-ID is e.g. what the user types in as user name during
authentication. The authz-ID is what the server uses as ID for
authorization. There has to be a mapping there. Since you want to query
some user profile data you have to find out to which LDAP entry the
authc-ID is mapped. With Kerberos the authc-ID is the user's Kerberos
principal name.
With AD and SASL/Kerberos the mapping is simply the user's principal
name found in attribute 'userPrincipalName' in the user's entry. You can
use this for searching the user's entry.
Other servers implement extended operations/controls for finding out to
which authz-ID the LDAP server mapped the authc-ID.
http://tools.ietf.org/html/rfc4532
http://tools.ietf.org/html/rfc3829
>> I'd recommend to 1. play with the Kerberos utils on your
>> platform (obtaining TGT with command-line tool kinit, then
>> using command-line tool ldapsearch with SASL). Note that your
>> DNS has to be set up correctly!
>
> I have the same thought as you these days. I want to have a Kerberos
> client that can work together with the command-line tool of
> ldapsearch (which works great for simple binding and search). With
> these two at hand, I can use them to do testings first, and use the
> testing result as a benchmark to be used in my coding later. But
> although I have ldapsearch utility in our Linux environment, I can't
> find a working Kerberos utility that works for Linux, or is it my
> ignorance? If there is some Kerberos client that can be used in
> RedHat Linux, please refer me to the location.
You could use the MIT Kerberos and cyrus-sasl packages provided with
your Linux distribution. Since you're asking here I guess you want to
use the Mozilla LDAP C API.
> By the way, do you have some LDAP traces with SASL binding in it?
> That will be helpful, too.
I'm not sure this would help you. You should play with a test
configuration yourself.
Ciao, Michael.
Rich Megginson
> Xu, Qiang (FXSGSC) wrote:
>>> -----Original Message-----
>>> Michale wrote:
>>>
>>> First the client has to obtain a ticket granting ticket (TGT)
>>> from the Kerberos KDC (e.g. via GSSAPI).
>> Just want to know whether this process can be automatic for LDAP
>> client? Or I need to manually write some routines to fetch this key
>> for GSSAPI?
>
> Obtaining the TGT involves the client's shared secret (derived from the
> password). So you mainly need a password at the client-side.
In general, and by default, you use the kinit command to get your TGT -
/usr/bin/kinit or /usr/kerberos/bin/kinit - some operating systems have
a GUI for this, but the command line works like this:
kinit username@REALM e.g. kinit m...@EXAMPLE.COM
kinit will prompt you for your kerberos password, acquire the TGT, and
cache it. This of course assumes your kerberos configuration is set up
correctly (e.g. /etc/krb5.conf) - by default, this will create a
credentials cache (cc or ccache) under /tmp like this: /tmp/krb5cc_UID
where UID is your numeric user id.
Use the klist command to see the status of your TGT
When you use something like ldapsearch -Y GSSAPI, the kerberos
implementation will see if you have a cc, and by default it will look in
/tmp/krb5cc_UID to get them, and use them to authenticate. After you
successfully authenticate, you can use klist to see your ldap ticket
(which will also be cached in the same ccache). The ldap service
principal will usually be named ldap/fqdn@REALM
You can specify a different krb5.conf to use with the env. var.
KRB5_CONFIG e.g.
KRB5_CONFIG=/tmp/mykrb5.conf kinit ....
You can specify a different ccache to use with KRB5CCNAME e.g.
KRB5CCNAME=/tmp/myccache kinit ....
KRB5CCNAME=/tmp/myccache ldapsearch -Y GSSAPI ....
I'm not sure what you mean by "I can't find a working Kerberos utility
that works for Linux" - every modern linux distribution has all of the
pieces you need - kerberos, gssapi, sasl. The mozldap provided by RHEL
and Fedora have all of these - they should just work.
What version of RedHat Linux are you using?
Xu, Qiang (FXSGSC)
Thank you for the detailed explanation, Rich.
From your description, it sounds that LDAP client such as ldapsearch can pick up the Kerberos TGT automatically, right? If the answer is yes, then I would not have to worry about how to fetch the ticket from Kerberos authentication.
Another question is, to get a ticket to be used later by LDAP client, must the kinit command run with "-f" option? It is a flag to request a "forwardable" ticket. I am not sure whether this will make a difference and necessary.
> I'm not sure what you mean by "I can't find a working
> Kerberos utility that works for Linux" - every modern linux
> distribution has all of the pieces you need - kerberos,
> gssapi, sasl. The mozldap provided by RHEL and Fedora have
> all of these - they should just work.
>
> What version of RedHat Linux are you using?
Here is my finding of kinit and OS version:
==============================================
qxu@gso-linuxcom-01(pts/17):/[8]> whereis kinit
kinit:
qxu@gso-linuxcom-01(pts/17):/[9]> which kinit
kinit: Command not found.
qxu@gso-linuxcom-01(pts/17):/[10]> uname -a
Linux gso-linuxcom-01 2.4.21-52.ELsmp #1 SMP Tue Sep 25 15:13:04 EDT 2007 i686 i686 i386 GNU/Linux
==============================================
It seems kinit does exist .
On the other hand, ldapsearch is available:
==============================================
qxu@gso-linuxcom-01(pts/17):/[11]> whereis ldapsearch
ldapsearch: /usr/bin/ldapsearch /usr/share/man/man1/ldapsearch.1.gz
qxu@gso-linuxcom-01(pts/17):/[12]> which ldapsearch
/usr/bin/ldapsearch
==============================================
So I am stuck here.
Thanks,
Xu Qiang
Rich Megginson
Yes.
>
> Another question is, to get a ticket to be used later by LDAP client, must the kinit command run with "-f" option?
No.
> It is a flag to request a "forwardable" ticket. I am not sure whether this will make a difference and necessary.
You'll have to investigate more about forwarding. But I suggest don't
use forwarding unless you find out you need it.
>
>> I'm not sure what you mean by "I can't find a working
>> Kerberos utility that works for Linux" - every modern linux
>> distribution has all of the pieces you need - kerberos,
>> gssapi, sasl. The mozldap provided by RHEL and Fedora have
>> all of these - they should just work.
>>
>> What version of RedHat Linux are you using?
>
> Here is my finding of kinit and OS version:
> ==============================================
> qxu@gso-linuxcom-01(pts/17):/[8]> whereis kinit
> kinit:
> qxu@gso-linuxcom-01(pts/17):/[9]> which kinit
> kinit: Command not found.
> qxu@gso-linuxcom-01(pts/17):/[10]> uname -a
> Linux gso-linuxcom-01 2.4.21-52.ELsmp #1 SMP Tue Sep 25 15:13:04 EDT 2007 i686 i686 i386 GNU/Linux
> ==============================================
> It seems kinit does exist .
In EL4 and EL5 /usr/kerberos/bin/kinit is provided by the
krb5-workstation package. You appear to be running EL3 or older. Try
up2date krb5-workstation
or
yum install krb5-workstation
mozldap is not provided with EL4 or older, so if you want to use it,
you'll have to compile it.
>
> On the other hand, ldapsearch is available:
> ==============================================
> qxu@gso-linuxcom-01(pts/17):/[11]> whereis ldapsearch
> ldapsearch: /usr/bin/ldapsearch /usr/share/man/man1/ldapsearch.1.gz
> qxu@gso-linuxcom-01(pts/17):/[12]> which ldapsearch
> /usr/bin/ldapsearch
> ==============================================
This is the openldap ldapsearch, which should also work with SASL/GSSAPI
auth.
Michael Ströder
> Xu, Qiang (FXSGSC) wrote:
>>> When you use something like ldapsearch -Y GSSAPI, the
>>> kerberos implementation will see if you have a cc, and by
>>> default it will look in /tmp/krb5cc_UID to get them, and use
>>> them to authenticate.
>>
>> can pick up the Kerberos TGT automatically, right? If the answer is
>> yes, then I would not have to worry about how to fetch the ticket from
>> Kerberos authentication.
>
> Yes.
mozldap's ldapsearch obtains a TGT without a kinit invoked before? For
sure it will obtain a session ticket (ST). But does it also something
like kinit internally?
Ciao, Michael.
Xu, Qiang (FXSGSC)
> mozldap's ldapsearch obtains a TGT without a kinit invoked
> before? For sure it will obtain a session ticket (ST). But
> does it also something like kinit internally?
Probably mozldap's ldapsearch cannot internally run some command like kinit. I guess Richard means if kinit has been run before ldapsearch, the later will go into Kerberos cache to fetch the ticket automatically, eliminating the need to code manually to fetch the Kerberos ticket when we use SASL APIs to bind to the LDAP server.
Richard, correct me if I am wrong, please.
Thank you, guys!
Xu Qiang
Rich Megginson
> Michael wrote:
>
>> mozldap's ldapsearch obtains a TGT without a kinit invoked
>> before? For sure it will obtain a session ticket (ST). But
>> does it also something like kinit internally?
>>
>
>
>
You are correct. mozldap ldapsearch will use the TGT acquired with
kinit. mozldap ldapsearch will not do a kinit.
> Thank you, guys!
> Xu Qiang
Xu, Qiang (FXSGSC)
The following is from MozLDAP document (http://www.mozilla.org/directory/csdk-docs/sasl.htm):
=========================================
Code Example 13-1 - Authenticating over SASL
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
#include "ldap.h"
int
main( int argc, char **argv )
{
LDAP *ld;
LDAPMod mod0;
LDAPMod mod1;
LDAPMod *mods[ 3 ];
char *vals0[ 2 ];
char *vals1[ 2 ];
time_t now;
char buf[ 128 ];
struct berval cred;
struct berval *servcred;
int version;
/* get a handle to an LDAP connection */
......
/* Set the LDAP protocol version supported by the client
to 3. (By default, this is set to 2. SASL authentication
is part of version 3 of the LDAP protocol.) */
......
/* authenticate */
cred.bv_val = "magic";
cred.bv_len = sizeof( "magic" ) - 1;
if ( ldap_sasl_bind_s( ld, "uid=bjensen,ou=people,dc=example,dc=com", \
"babsmechanism", &cred, NULL, NULL, &servcred ) != LDAP_SUCCESS ) {
ldap_perror( ld, "ldap_sasl_bind_s" );
return( 1 );
}
......
}
=========================================
My questions are:
1. The variable "cred" is set to "magic" in this example. What should it be in the real world? The user to be authenticated is already provided through the second parameter. So what is this "cred" for? Can I leave it as "magic", just like what is used in the example?
2. If I want to use GSSAPI to bind to the server, is the 3rd parameter to be passed as "GSSAPI"?
Thanks,
Xu Qiang
Rich Megginson
This is a very bad example for using SASL/GSSAPI. Please refer to the
actual source code. There is an example file -
http://mxr.mozilla.org/mozilla/source/directory/c-sdk/ldap/examples/saslsearch.c
>
> 1. The variable "cred" is set to "magic" in this example. What should it be in the real world? The user to be authenticated is already provided through the second parameter. So what is this "cred" for? Can I leave it as "magic", just like what is used in the example?
For GSSAPI, it doesn't matter, because the real credentials will come
from the TGT
>
> 2. If I want to use GSSAPI to bind to the server, is the 3rd parameter to be passed as "GSSAPI"?
Yes, but no, because you should not use ldap_sasl_bind_s, you should use
ldap_sasl_interactive_bind_ext_s instead - see saslsearch.c above.
>
> Thanks,
> Xu Qiang
Rich Megginson
This is a very bad example for using SASL/GSSAPI. Please refer to the
actual source code. There is an example file -
http://mxr.mozilla.org/mozilla/source/directory/c-sdk/ldap/examples/saslsearch.c
>
> 1. The variable "cred" is set to "magic" in this example. What should it be in the real world? The user to be authenticated is already provided through the second parameter. So what is this "cred" for? Can I leave it as "magic", just like what is used in the example?
For GSSAPI, it doesn't matter, because the real credentials will come
from the TGT
>
> 2. If I want to use GSSAPI to bind to the server, is the 3rd parameter to be passed as "GSSAPI"?
Yes, but no, because you should not use ldap_sasl_bind_s, you should use
Xu, Qiang (FXSGSC)
> From: Rich Megginson [mailto:rich.me...@gmail.com] On
> Behalf Of Rich Megginson
> Sent: Tuesday, November 04, 2008 11:27 PM
> To: Xu, Qiang (FXSGSC)
> Cc: dev-te...@lists.mozilla.org; Michael Ströder
> Subject: Re: SASL authentication
>
> This is a very bad example for using SASL/GSSAPI. Please
> refer to the actual source code. There is an example file -
> http://mxr.mozilla.org/mozilla/source/directory/c-sdk/ldap/exa
> mples/saslsearch.c
Got it. Previously, I want to use ldap_sasl_bind_s() to avoid the hassle in dealing with asynchronous SASL binding with ldap_sasl_bind(), that is, to avoid the challenges sent back from the server with LDAP_SASL_BIND_IN_PROGRESS.
> For GSSAPI, it doesn't matter, because the real credentials
> will come from the TGT.
Good to hear this.
> Yes, but no, because you should not use ldap_sasl_bind_s, you
> should use ldap_sasl_interactive_bind_ext_s instead - see
> saslsearch.c above.
Why can't I find the reference to the function ldap_sasl_interactive_bind_ext_s() in MozLDAP C SDK document page (http://www.mozilla.org/directory/csdk-docs/function.htm)? Is this document outdated? And what benefit does it have, compared to ldap_sasl_bind_s()? In other words, what potential risk does ldap_sasl_bind() have?
Thanks a lot,
Xu Qiang
Xu, Qiang (FXSGSC)
Using ldap_sasl_interactive_bind_ext_s(), I've come up with an implementation of SASL binding. The main idea is as follows:
=======================================================
#include <sasl/sasl.h>
...
static int sasl_flags = LDAP_SASL_QUIET;
static char *sasl_mech = "GSSAPI";
...
/* warning! - the following requires intimate knowledge of sasl.h */
static char *default_values[] = {
"", /* SASL_CB_USER 0x4001 */
"", /* SASL_CB_AUTHNAME 0x4002 */
"", /* SASL_CB_LANGUAGE 0x4003 */ /* not used */
"", /* SASL_CB_PASS 0x4004 */
"", /* SASL_CB_ECHOPROMPT 0x4005 */
"", /* SASL_CB_NOECHOPROMPT 0x4006 */
"", /* SASL_CB_CNONCE 0x4007 */
"" /* SASL_CB_GETREALM 0x4008 */
};
/* this is so we can use SASL_CB_USER etc. to index into default_values */
#define VALIDVAL(n) ((n >= SASL_CB_USER) && (n <= SASL_CB_GETREALM))
#define VAL(n) default_values[n-0x4001]
...
static int example_sasl_interact(LDAP *ld, unsigned flags, void *defaults, void *prompts);
...
static int example_sasl_interact(LDAP *ld, unsigned flags, void *defaults, void *prompts)
{
sasl_interact_t *interact = NULL;
if (prompts == NULL)
{
return (LDAP_PARAM_ERROR);
}
for (interact = prompts; interact->id != SASL_CB_LIST_END; interact++)
{
if (VALIDVAL(interact->id))
{
interact->result = VAL(interact->id);
interact->len = strlen((char *)interact->result);
}
}
return (LDAP_SUCCESS);
}
...
int ldapStatus = LDAP_SUCCESS;
LDAP *ldapHandle = (LDAP *)NULL;
LDAPControl **responseControls = NULL;
...
if ((ldapHandle = prldap_init((ldapServerConfigData.hostnames),
LDAP_PORT, 0)) == NULL)
{
LOGERROR("prldap_init failed");
return(ABA_LDAP_INIT_CALL_FAILED);
}
LOGINFO("prldap_init succeeded");
...
version = LDAP_VERSION3;
if (ldap_set_option(ldapHandle,LDAP_OPT_PROTOCOL_VERSION,&version)
!= LDAP_SUCCESS)
{
LOGERROR("Setting Version Failed");
/*
** unbind ldap handle.
*/
if (ldapHandle != (LDAP *)NULL)
{
LOGINFO("ldap_unbind_s2");
ldap_unbind_s(ldapHandle);
ldapHandle = (LDAP *)NULL;
}
return(ABA_LDAP_SET_UNABLE_TO_SET_PREFS);
}
...
/* no need for dn and password in case of SASL binding */
ldapStatus = ldap_sasl_interactive_bind_ext_s(ldapHandle, "", sasl_mech,
NULL, NULL, sasl_flags,
example_sasl_interact, NULL, &responseControls);
if (responseControls != NULL)
{
LOGINFO("SASL binding finished, will destroy responseControls");
ldap_controls_free(responseControls);
}
LOGINFO("SASL LDAP BIND with GSSAPI: Value of ldapStatus %d", ldapStatus);
=======================================================
The core part is almost a direct copy from http://mxr.mozilla.org/mozilla/source/directory/c-sdk/ldap/examples/saslsearch.c or http://mxr.mozilla.org/mozilla/source/directory/c-sdk/ldap/examples/sasl.c.
It looks straightforward. And after an operation of "kinit..." followed by the above SASL binding, the log gives me LDAP_SUCCESS.
However, the network trace doesn't shows the SASL packets between the printer and the ADS. No wonder the failure of the following LDAP search, with the error message reminding me to bind to the server before doing any query.
Yes, I know binding is prerequisite to a query. But how come the function ldap_sasl_interactive_bind_ext_s() returns 0 when it actually doesn't contact the server? I am really bewildered.
Hope someone can shed some light on this,
Xu Qiang
Xu, Qiang (FXSGSC)
For me, the implementation is to be used in the printer, which cannot be interactively and repeatedly request so many parameters. Maybe the function ldap_sasl_bind_s() is more appropriate?
> -----Original Message-----
> From:
> dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.mozilla.org
>
> [mailto:dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.moz
> illa.org] On Behalf Of Xu, Qiang (FXSGSC)
> Sent: Wednesday, November 05, 2008 5:18 PM
> To: Rich Megginson
> Cc: Michael Ströder; dev-te...@lists.mozilla.org
> Subject: RE: SASL authentication
Xu, Qiang (FXSGSC)
> From: Xu, Qiang (FXSGSC)
> Sent: Wednesday, November 05, 2008 5:49 PM
> To: Xu, Qiang (FXSGSC); Rich Megginson
> Cc: Michael Ströder; dev-te...@lists.mozilla.org
> Subject: RE: SASL authentication
>
> ldap_sasl_interactive_bind_ext_s() may be intended for a
> stand-alone application used in command-line, thus the name
> "interactive". So I guess when the function is executed, some
> prompt appears in the console to wait for my input. And it
> can explain the callback function "example_sasl_interact()".
>
> For me, the implementation is to be used in the printer,
> which cannot be interactively and repeatedly request so many
> parameters. Maybe the function ldap_sasl_bind_s() is more appropriate?
On second thoughts, it seems still OK if I insist on using ldap_sasl_interactive_bind_ext_s(). If the flag is LDAP_SASL_QUIET, actually I can provide the values in the array default_values[] in a batch mode.
An example is:
===========================
static char *default_values[] = {
"xuan", /* SASL_CB_USER 0x4001 */
"CN=xuan,CN=Users,DC=sesswin2003,DC=com", /* SASL_CB_AUTHNAME 0x4002 */
"", /* SASL_CB_LANGUAGE 0x4003 */ /* not used */
"Fair123", /* SASL_CB_PASS 0x4004 */
"", /* SASL_CB_ECHOPROMPT 0x4005 */
"", /* SASL_CB_NOECHOPROMPT 0x4006 */
"", /* SASL_CB_CNONCE 0x4007 */
"" /* SASL_CB_GETREALM 0x4008 */
};
===========================
My questions are:
1. What is the difference between SASL_CB_USER and SASL_CB_AUTHNAME? Which one corresponds to the user's dn in the server? And the other one?
2. What is SASL_CB_AUTHNAME for? Shall I fill it with the Kerberos realm I am authenticated against? Or just leave it blank?
3. Still, I am not sure whether I should use ldap_sasl_interactive_bind_ext_s() or ldap_sasl_bind_s()? After all, the usage of the later seems simpler. But as Richard recommends the former, what defect does the later have?
Thanks,
Xu Qiang
Rich Megginson
I'm not sure. You should refer to the SASL documentation. However, if
you are using SASL/GSSAPI, it should use the principal from your cached
credentials. So you should use "" in your interact function.
Also note that SASL/GSSAPI does not use the password - you have already
supplied the password externally when you did the kinit. SASL/GSSAPI
just needs the credentials from your cache file. So just use "" as the
password.
>
> 2. What is SASL_CB_AUTHNAME for? Shall I fill it with the Kerberos realm I am authenticated against? Or just leave it blank?
For SASL/GSSAPI, you should use "". For more information, see the SASL
docs.
>
> 3. Still, I am not sure whether I should use ldap_sasl_interactive_bind_ext_s() or ldap_sasl_bind_s()? After all, the usage of the later seems simpler. But as Richard recommends the former, what defect does the later have?
SASL mechanisms are by nature interactive, with challenges and responses
sent back and forth between the client and server.
ldap_sasl_interactive_bind_ext_s() handles that for you. If you still
feel for some reason you must use ldap_sasl_bind_s, you should look at
the source code for saslbind.c to see how
ldap_sasl_interactive_bind_ext_s() uses the lower level ldap_sasl_bind
functions in conjunction with the sasl api.
>
> Thanks,
> Xu Qiang
Kashif Ali Siddiqui
ldap_sasl_interactive_bind_ext_s() will only ask for the authname,
whereas the user name is taken from the kerberos credential cache. The
authorization name is required to tell the SASL layer that which user's
authorization you required for this LDAP session. It can be the same as
the kerberos user in credential cache. If you supplied "" (NULL) to the
authname, then this means that you asking authorization of an anonymous
user (which can be none in most of the cases). Thus in order to have an
definite authorization, you do need to supplied a correct distinguished
name of the user in ADS. The format for the authname value is
dn:<distinguishedName of the user in ADS)
Kindly confirm that whether we can use UPN in place of the DN in the
authname value.
Kashif Ali Siddiqui
Tech Lead Folio3
Rich Megginson
> With GSSAPI, after a successful kinit execution, the
> ldap_sasl_interactive_bind_ext_s() will only ask for the authname,
> whereas the user name is taken from the kerberos credential cache. The
> authorization name is required to tell the SASL layer that which user's
> authorization you required for this LDAP session. It can be the same as
> the kerberos user in credential cache. If you supplied "" (NULL) to the
> authname, then this means that you asking authorization of an anonymous
> user (which can be none in most of the cases). Thus in order to have an
> definite authorization, you do need to supplied a correct distinguished
> name of the user in ADS. The format for the authname value is
>
> dn:<distinguishedName of the user in ADS)
>
> Kindly confirm that whether we can use UPN in place of the DN in the
> authname value.
I have no idea. I have not tried SASL/GSSAPI auth with AD.
Rich Megginson
> With GSSAPI, after a successful kinit execution, the
> ldap_sasl_interactive_bind_ext_s() will only ask for the authname,
> whereas the user name is taken from the kerberos credential cache. The
> authorization name is required to tell the SASL layer that which user's
> authorization you required for this LDAP session. It can be the same as
> the kerberos user in credential cache. If you supplied "" (NULL) to the
> authname, then this means that you asking authorization of an anonymous
> user (which can be none in most of the cases). Thus in order to have an
> definite authorization, you do need to supplied a correct distinguished
> name of the user in ADS. The format for the authname value is
>
> dn:<distinguishedName of the user in ADS)
>
> Kindly confirm that whether we can use UPN in place of the DN in the
> authname value.
I have no idea. I have not tried SASL/GSSAPI auth with AD.
>
Xu, Qiang (FXSGSC)
> From:
> dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.mozilla.org
>
> [mailto:dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.moz
> Sent: Wednesday, November 05, 2008 11:34 PM
> To: Rich Megginson
> Cc: dev-te...@lists.mozilla.org
> Subject: Re: SASL authentication
>
> With GSSAPI, after a successful kinit execution, the
> ldap_sasl_interactive_bind_ext_s() will only ask for the
> authname, whereas the user name is taken from the kerberos
> credential cache. The authorization name is required to tell
> the SASL layer that which user's authorization you required
> for this LDAP session. It can be the same as the kerberos
> user in credential cache. If you supplied "" (NULL) to the
> authname, then this means that you asking authorization of an
> anonymous user (which can be none in most of the cases). Thus
> in order to have an definite authorization, you do need to
> supplied a correct distinguished name of the user in ADS. The
> format for the authname value is
>
> dn:<distinguishedName of the user in ADS)
You mean if I put "" for authname, it will do an anonymous binding? I put it as "" yesterday in my testing, and no outward LDAP traffic to the server. But the return value is 0 (LDAP_SUCCES). Very weird. Even as I change the second value of the array to the user's dn, as you suggested, I still can't see any LDAP packet from the client to the server.
Would you kindly have a look of my code?
==========================================
static int sasl_flags = LDAP_SASL_QUIET;
static char *sasl_mech = "GSSAPI";
/* warning! - the following requires intimate knowledge of sasl.h */
static char *default_values[] = {
"", /* SASL_CB_USER 0x4001 */
"dn:CN=xuan,CN=Users,DC=sesswin2003,DC=com", /* SASL_CB_AUTHNAME 0x4002 */
"", /* SASL_CB_LANGUAGE 0x4003 */ /* not used */
"", /* SASL_CB_PASS 0x4004 */
"", /* SASL_CB_ECHOPROMPT 0x4005 */
"", /* SASL_CB_NOECHOPROMPT 0x4006 */
"", /* SASL_CB_CNONCE 0x4007 */
"" /* SASL_CB_GETREALM 0x4008 */
};
/* this is so we can use SASL_CB_USER etc. to index into default_values */
#define VALIDVAL(n) ((n >= SASL_CB_USER) && (n <= SASL_CB_GETREALM))
#define VAL(n) default_values[n-0x4001]
...
static int example_sasl_interact(LDAP *ld, unsigned flags, void *defaults, void *prompts)
{
sasl_interact_t *interact = NULL;
if (prompts == NULL)
{
return (LDAP_PARAM_ERROR);
}
for (interact = prompts; interact->id != SASL_CB_LIST_END; interact++)
{
if (VALIDVAL(interact->id))
{
interact->result = VAL(interact->id);
interact->len = strlen((char *)interact->result);
}
}
return (LDAP_SUCCESS);
}
...
ldapStatus = ldap_sasl_interactive_bind_ext_s(ldapHandle, "", sasl_mech,
NULL, NULL, sasl_flags,
example_sasl_interact, NULL, &responseControls);
if (responseControls != NULL)
{
LOGINFO("SASL binding finished, will destroy responseControls");
ldap_controls_free(responseControls);
responseControls = NULL;
}
LOGINFO("SASL LDAP BIND with GSSAPI: Value of ldapStatus %d", ldapStatus);
==========================================
I just can't understand why it can return 0 when it does not send the binding request to the server.
And Richard, do you have any idea on my code above? I am sort of stuck here.
> Kindly confirm that whether we can use UPN in place of the DN
> in the authname value.
>
Anton Bobrov
i hate to ask the silly question but do you actually have SASL builtin?
https://wiki.mozilla.org/LDAP_C_SDK#Building_using_autoconf_.28preferred_method.29
see "Build with SASL support" section there. otherwise you might be
hitting a stub which does nothing but returns LDAP_SUCCESS [ i have
no idea why do we actually return success in those stubs but we do ].
Kashif Ali Siddiqui
call, and its clearly there that if you configure Mozilla LDAP without
the Cyrus SASL flag, then the ldap_sasl_interactive_bind call always
returns 0. Hence if you are using the recompiled version, then it is not
there. However you have to rebuild the Mozilla LDAP library using the
following configure statement as
> ./configure --with-sasl <other arguments>
You can also define the Cyrus SASL library and include paths if they are
at the different directories.
Kashif.
Xu, Qiang (FXSGSC)
> From: Anton....@Sun.COM [mailto:Anton....@Sun.COM]
> Sent: Thursday, November 06, 2008 6:36 PM
> To: Xu, Qiang (FXSGSC)
> dev-te...@lists.mozilla.org
> Subject: Re: SASL authentication
>
>
> SASL builtin?
> https://wiki.mozilla.org/LDAP_C_SDK#Building_using_autoconf_.2
> 8preferred_method.29
> see "Build with SASL support" section there. otherwise you
> might be hitting a stub which does nothing but returns
> LDAP_SUCCESS [ i have no idea why do we actually return
> success in those stubs but we do ].
Thank you, Anton. I missed this point before your highlighting.
I guess our MozLDAP was not compiled with Cyrus SASL support. A side proof is that I didn't found any dynamic library file related to this:
===============================================
denalic01:/ <121> find . -name "*sasl*"
denalic01:/ <122>
===============================================
I will consult OS team about this issue.
By the way, could you point to me the location in the source code that ldap_sasl_interactive_bind_ext_s() returns LDAP_SUCCESS when it can't find any SASL library?
Thanks,
Xu Qiang
Anton Bobrov
Xu, Qiang (FXSGSC) wrote:
> I guess our MozLDAP was not compiled with Cyrus SASL support. A side proof is that I didn't found any dynamic library file related to this:
> ===============================================
> denalic01:/ <121> find . -name "*sasl*"
> denalic01:/ <122>
> ===============================================
> I will consult OS team about this issue.
>
> By the way, could you point to me the location in the source code that ldap_sasl_interactive_bind_ext_s() returns LDAP_SUCCESS when it can't find any SASL library?
http://mxr.mozilla.org/mozilla/source/directory/c-sdk/ldap/libraries/libldap/saslbind.c#792
Xu, Qiang (FXSGSC)
> From:
> dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.mozilla.org
>
> [mailto:dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.moz
> Sent: Thursday, November 06, 2008 6:57 PM
> To: Xu, Qiang (FXSGSC)
> Cc: Rich Megginson; Kashif Ali Siddiqui;
> http://mxr.mozilla.org/mozilla/source/directory/c-sdk/ldap/lib
> raries/libldap/saslbind.c#792
Thanks for pointing to the location.
Just want to ask another silly question:
I couldn't find where the macro LDAP_SASLIO_HOOKS is defined in the source code and its Makefile.
Could you do me another favor to help me locate it?
Thanks,
Xu Qiang
Anton Bobrov
http://mxr.mozilla.org/mozilla/source/directory/c-sdk/configure#6485
i'm not why you need this tho. just follow the instructions in that
wiki link i sent to build with SASL support. if you just curious or
wanna make changes to the build process or related code you can find
all that stuff via http://mxr.mozilla.org/mozilla/ cross reference.
Xu, Qiang (FXSGSC)
> To: Xu, Qiang (FXSGSC)
> dev-te...@lists.mozilla.org
> Subject: Re: SASL authentication
>
>
> i'm not why you need this tho. just follow the instructions
> in that wiki link i sent to build with SASL support. if you
> just curious or wanna make changes to the build process or
> related code you can find all that stuff via
> http://mxr.mozilla.org/mozilla/ cross reference.
Got it. Thanks.
It should be OS team that rebuilt the library with SASL support. I am just curious. :-)
Thank you,
Xu Qiang
Xu, Qiang (FXSGSC)
Recently I hit a strange problem.
If referral is disabled, our printer can do LDAP queries without any problem. However, if the referral option is enabled, and the server is pointed to some ADS, which at the same time is a domain server, the search will fail.
Looking at the network trace, I found the initial search is successful, and the result is bounced back from the server. However, in the result packet, there are three pieces of referral information:
=================
ldap://ForestDnsZones.otsg.crmt.801/DC=ForestDnsZones,DC=otsg,DC=crmt,DC=801
ldap://DomainDnsZones.otsg.crmt.801/DC=DomainDnsZones,DC=otsg,DC=crmt,DC=801
ldap://otsg.crmt.801/CN=Configuration,DC=otsg,DC=crmt,DC=801
=================
This will lead to 3 following anonymous searches, which will fail. The error is "000004DC: LdapErr: DSID-0C0906DD, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1771". However, the error code is 85 in the log, meaning LDAP_TIMEOUT.
A side note is that the failure is not constant. Intermittently, the query will be successful:
=================
<distribution> (Thu Dec 11 2008 07:09:56.653) <p11044,t830493920,aba_ldap_interface.c,5684>
INFO>> Value of referalsEnabled 1
......
<distribution> (Thu Dec 11 2008 07:09:56.653) <p11044,t830493920,aba_ldap_interface.c,1272>
INFO>> ENABLING REFERALS
......
<distribution> (Thu Dec 11 2008 07:09:57.246) <p11044,t830493920,aba_ldap_interface.c,1765>
INFO>> value of search string in LDAPLIB (cn=earl*)
......
<distribution> (Thu Dec 11 2008 07:09:57.616) <p11044,t830493920,aba_ldap_interface.c,2691>
INFO>> Found 1 Entries and 3 References
......
<distribution> (Thu Dec 11 2008 07:09:57.632) <p11044,t830493920,aba_ldap_interface.c,3496>
enter>> add_ldap_results_record
<distribution> (Thu Dec 11 2008 07:09:57.632) <p11044,t830493920,aba_ldap_interface.c,3509>
INFO>> Size of list 1
<distribution> (Thu Dec 11 2008 07:09:57.632) <p11044,t830493920,aba_ldap_interface.c,3510>
return>> add_ldap_results_record
<distribution> (Thu Dec 11 2008 07:09:57.632) <p11044,t830493920,aba_ldap_interface.c,3176>
INFO>> successfully added ldap record
=================
This is expected correct behavior, but only intermittent.
It seems less likely that the server is doing something wrong, coz it is all right when I use the thirdpty tool "LDAP Admin" with referral enabled. And, if the server is pointed to another ADS which is not DNS server, it works well with the option enabled.
Anyone has had the same experience as I? And any suggestions?
Looking forward to help,
Xu Qiang
Michael Ströder
>
> If referral is disabled, our printer can do LDAP queries without any
> problem. However, if the referral option is enabled, and the server
> is pointed to some ADS, which at the same time is a domain server,
> the search will fail.
Why do you want to enable referral chasing?
> Looking at the network trace, I found the initial search is successful, and the result is bounced back from the server. However, in the result packet, there are three pieces of referral information:
> =================
> ldap://ForestDnsZones.otsg.crmt.801/DC=ForestDnsZones,DC=otsg,DC=crmt,DC=801
> ldap://DomainDnsZones.otsg.crmt.801/DC=DomainDnsZones,DC=otsg,DC=crmt,DC=801
> ldap://otsg.crmt.801/CN=Configuration,DC=otsg,DC=crmt,DC=801
> =================
> This will lead to 3 following anonymous searches, which will fail. The error is "000004DC: LdapErr: DSID-0C0906DD, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1771". However, the error code is 85 in the log, meaning LDAP_TIMEOUT.
Yes, that's the default behaviour of most LDAP client libs for automatic
referral chasing. Obviously it's wrong.
Letting the LDAP client chase referrals is a fundamentally broken
concept in LDAPv3 anyway because there is no clear definition at all
which credentials the client should use when chasing the referral.
Speaking of AD as a LDAPv3 implementation with a certain profile or
additional assumptions the client could use the same credentials he used
to bind to the originating server. I think that's the way the AD
developers thought about it in the light of domain trusts etc. But again
that's not a valid assumption in general for a LDAP client application.
In general the application has to be configured with a-priori knowledge
how to bind to the referral's target.
Ciao, Michael.
Xu, Qiang (FXSGSC)
> Why do you want to enable referral chasing?
I didn't want. But our printer provides the option to be enabled or disabled, and the customer found it doesn't work in an ADS, which is at the same time a DNS server.
> Yes, that's the default behaviour of most LDAP client libs
> for automatic referral chasing. Obviously it's wrong.
>
> Letting the LDAP client chase referrals is a fundamentally
> broken concept in LDAPv3 anyway because there is no clear
> definition at all which credentials the client should use
> when chasing the referral.
Yes, it seems in chasing the referral, the printer doesn't know which credential to be used to bind to the referred servers (therefore the binding was anonymous in the trace). Hence, the error indicates a successful binding must be done beforehand.
But I can't explain the intermittent success in LDAP search. Is it due to that sometimes, the DNS server can't find out the IP Address of the host name used in the referral URI?
> Speaking of AD as a LDAPv3 implementation with a certain
> profile or additional assumptions the client could use the
> same credentials he used to bind to the originating server. I
> think that's the way the AD developers thought about it in
> the light of domain trusts etc. But again that's not a valid
> assumption in general for a LDAP client application.
>
> In general the application has to be configured with a-priori
> knowledge how to bind to the referral's target.
So, can I say that this referral is not recommended in LDAPv3 implementation?
Thanks a lot for your detailed explanation, Michael!
Xu Qiang
Michael Ströder
> Michael wrote:
>> Why do you want to enable referral chasing?
>
> I didn't want. But our printer provides the option to be enabled or
> disabled, and the customer found it doesn't work in an ADS, which is
> at the same time a DNS server.
And why did the customer want to have it enabled?
>> Yes, that's the default behaviour of most LDAP client libs
>> for automatic referral chasing. Obviously it's wrong.
>>
>> Letting the LDAP client chase referrals is a fundamentally
>> broken concept in LDAPv3 anyway because there is no clear
>> definition at all which credentials the client should use
>> when chasing the referral.
>
> Yes, it seems in chasing the referral, the printer doesn't know which
> credential to be used to bind to the referred servers (therefore the
> binding was anonymous in the trace). Hence, the error indicates a
> successful binding must be done beforehand.
Yes, that's because AD does not allow searching for data for anonymous
access.
> But I can't explain the intermittent success in LDAP search. Is it
> due to that sometimes, the DNS server can't find out the IP Address
> of the host name used in the referral URI?
I don't understand exactly what you mean here. When the client chases a
referral the client trys to resolve the hostname in the referral LDAP URL.
>> Speaking of AD as a LDAPv3 implementation with a certain
>> profile or additional assumptions the client could use the
>> same credentials he used to bind to the originating server. I
>> think that's the way the AD developers thought about it in
>> the light of domain trusts etc. But again that's not a valid
>> assumption in general for a LDAP client application.
>>
>> In general the application has to be configured with a-priori
>> knowledge how to bind to the referral's target.
>
> So, can I say that this referral is not recommended in LDAPv3 implementation?
Short: Yes.
Long: To get this right you have to provide some user interaction for
asking the user to provide the right credentials when chasing the
referral (obviously not suitable for a printer or similar
non-interactive system) or implement a configurable look-up table of
possible referral targets and the accompanying credentials. Most times
this is not worth the effort. (So we're back asking the question why the
customer enabled referral chasing.)
Ciao, Michael.
Xu, Qiang (FXSGSC)
> SASL builtin?
> https://wiki.mozilla.org/LDAP_C_SDK#Building_using_autoconf_.2
> 8preferred_method.29
> see "Build with SASL support" section there. otherwise you
> might be hitting a stub which does nothing but returns
> LDAP_SUCCESS [ i have no idea why do we actually return
> success in those stubs but we do ].
Finally, OS team sent over a new package of MozLDAP library built with SASL support. It doesn't return LDAP_SUCCESS any more. However, a new error pops up:
=========================================
<apManager> (Fri Feb 27 2009 14:14:15.223) <p23847,t3079044000,aba_ldap_interface.c,2373>
INFO>> SASL Login
<apManager> (Fri Feb 27 2009 14:14:15.224) <p23847,t3079044000,aba_ldap_interface.c,2388>
INFO>> SASL LDAP BIND with GSSAPI: Value of ldapStatus 86
<apManager> (Fri Feb 27 2009 14:14:15.224) <p23847,t3079044000,aba_ldap_interface.c,2459>
ERROR>> LDAP BIND: Value of ldap failure status and text 86 Unknown authentication method
<apManager> (Fri Feb 27 2009 14:14:15.225) <p23847,t3079044000,aba_ldap_interface.c,2500>
ERROR>> ABA_LDAP_UNKNOWN_BIND_FAILURE
=========================================
In the network trace captured, I didn't see the binding request be sent to the server.
The core part of the code is as follows:
=========================================
static int sasl_flags = LDAP_SASL_QUIET;
static char *sasl_mech = "GSSAPI";
/* warning! - the following requires intimate knowledge of sasl.h */ static char *default_values[] = {
"", /* SASL_CB_USER 0x4001 */
"", /* SASL_CB_AUTHNAME 0x4002 */
"", /* SASL_CB_LANGUAGE 0x4003 */ /* not used */
"", /* SASL_CB_PASS 0x4004 */
"", /* SASL_CB_ECHOPROMPT 0x4005 */
"", /* SASL_CB_NOECHOPROMPT 0x4006 */
"", /* SASL_CB_CNONCE 0x4007 */
"" /* SASL_CB_GETREALM 0x4008 */
};
/* this is so we can use SASL_CB_USER etc. to index into default_values */
#define VALIDVAL(n) ((n >= SASL_CB_USER) && (n <= SASL_CB_GETREALM))
#define VAL(n) default_values[n-0x4001]
...
static int example_sasl_interact(LDAP *ld, unsigned flags, void *defaults, void *prompts) {
sasl_interact_t *interact = NULL;
if (prompts == NULL)
{
return (LDAP_PARAM_ERROR);
}
for (interact = prompts; interact->id != SASL_CB_LIST_END; interact++)
{
if (VALIDVAL(interact->id))
{
interact->result = VAL(interact->id);
interact->len = strlen((char *)interact->result);
}
}
return (LDAP_SUCCESS);
}
...
ldapStatus = ldap_sasl_interactive_bind_ext_s(ldapHandle, "", sasl_mech,
NULL, NULL, sasl_flags,
example_sasl_interact, NULL, &responseControls);
if (responseControls != NULL)
{
LOGINFO("SASL binding finished, will destroy responseControls");
ldap_controls_free(responseControls);
responseControls = NULL;
}
LOGINFO("SASL LDAP BIND with GSSAPI: Value of ldapStatus %d", ldapStatus);
=========================================
Is it a problem of SASL library? I already have cyrus-sasl-2.1.22 in place.
Any help is appreciated,
Xu Qiang
Rich Megginson
Probably. It probably cannot find the mechanism plugins. The
cyrus-sasl library is in two pieces - the main libsasl, and the plugins
for the various mechanisms. For example, on my RHEL5 system, libsasl2
is installed in $libdir, and the mechanism plugins are installed in
$libdir/sasl2. The sasl on RHEL5 has been compiled so that libsasl
looks in $libdir/sasl2 for the mechanism plugins. You can also set the
env. var. SASL_PATH to point to the directory containing the mechanism
plugins.
Rich Megginson
Probably. It probably cannot find the mechanism plugins. The
cyrus-sasl library is in two pieces - the main libsasl, and the plugins
for the various mechanisms. For example, on my RHEL5 system, libsasl2
is installed in $libdir, and the mechanism plugins are installed in
$libdir/sasl2. The sasl on RHEL5 has been compiled so that libsasl
looks in $libdir/sasl2 for the mechanism plugins. You can also set the
env. var. SASL_PATH to point to the directory containing the mechanism
plugins.
I already have cyrus-sasl-2.1.22 in place.
Xu, Qiang (FXSGSC)
> From: Rich Megginson [mailto:rich.me...@gmail.com] On
> Behalf Of Rich Megginson
> To: Xu, Qiang (FXSGSC)
> dev-te...@lists.mozilla.org
> Subject: Re: SASL authentication
>
> The cyrus-sasl library is in two pieces - the main libsasl,
> and the plugins for the various mechanisms. For example, on
> my RHEL5 system, libsasl2 is installed in $libdir, and the
> mechanism plugins are installed in $libdir/sasl2. The sasl
> on RHEL5 has been compiled so that libsasl looks in
> $libdir/sasl2 for the mechanism plugins. You can also set
> the env. var. SASL_PATH to point to the directory containing
> the mechanism plugins.
I have recompiled cyrus library, and grab both "libsasl2.so" and its plugins.
For my case, the most important plugin seems to be "libgssapiv2.so". Originally, I put them into the same path, i.e. "/opt/nc/lib/" (this is the path of our own libraries, instead of system libraries). It didn't work. Then I created a folder called "sasl2" under "/opt/nc/lib", and put the gssapi plugin into it. It still didn't work.
The error message is the same: "86 Unknown authentication method".
I am at a loss. Is there anything I missed? Is there a possibility that "libldap60.so" has some requirement on where to find SASL2 plugins?
Anton Bobrov
do a truss(1) [or similar] on it to see where libsasl looks for its
plugins and exactly which plugins its trying to find. libldap does
not have any requirements on where those sasl plugins should reside
in fact it doesnt know about them at all. it knows sasl mech names
and its up to libsasl to map them mech names to its plugins and to
take care of locating and loading related plugins. you should also
try SASL_PATH trick Rich suggested to you.
Xu, Qiang (FXSGSC) wrote:
>> -----Original Message-----
>> From: Rich Megginson [mailto:rich.me...@gmail.com] On
>> Behalf Of Rich Megginson
>> Sent: Friday, February 27, 2009 11:26 PM
>> To: Xu, Qiang (FXSGSC)
>> Cc: Anton....@Sun.COM; Kashif Ali Siddiqui;
>> dev-te...@lists.mozilla.org
>> Subject: Re: SASL authentication
>>
>> Probably. It probably cannot find the mechanism plugins.
>> The cyrus-sasl library is in two pieces - the main libsasl,
>> and the plugins for the various mechanisms. For example, on
>> my RHEL5 system, libsasl2 is installed in $libdir, and the
>> mechanism plugins are installed in $libdir/sasl2. The sasl
>> on RHEL5 has been compiled so that libsasl looks in
>> $libdir/sasl2 for the mechanism plugins. You can also set
>> the env. var. SASL_PATH to point to the directory containing
>> the mechanism plugins.
>
> I have recompiled cyrus library, and grab both "libsasl2.so" and its plugins.
>
> For my case, the most important plugin seems to be "libgssapiv2.so". Originally, I put them into the same path, i.e. "/opt/nc/lib/" (this is the path of our own libraries, instead of system libraries). It didn't work. Then I created a folder called "sasl2" under "/opt/nc/lib", and put the gssapi plugin into it. It still didn't work.
>
> The error message is the same: "86 Unknown authentication method".
>
> I am at a loss. Is there anything I missed? Is there a possibility that "libldap60.so" has some requirement on where to find SASL2 plugins?
>
> Looking forward to help,
> Xu Qiang
Xu, Qiang (FXSGSC)
> To: Xu, Qiang (FXSGSC)
> for its plugins and exactly which plugins its trying to find.
> libldap does not have any requirements on where those sasl
> plugins should reside in fact it doesnt know about them at
> all. it knows sasl mech names and its up to libsasl to map
> them mech names to its plugins and to take care of locating
> and loading related plugins. you should also try SASL_PATH
> trick Rich suggested to you.
Unfortunately, our printer is an embedded system, and the OS in it is a simplied Wind River Linux system. There is no "truss" command available in it. Even the command "env" is not available. So I don't know how to set this SASL_PATH into the environment.
However, when I use "ldd" to the library, it displays:
====================================
mbc80:/opt/nc/lib <207> ldd libsasl2.so
linux-gate.so.1 => (0xffffe000)
libdl.so.2 => /lib/libdl.so.2 (0xb7eed000)
libresolv.so.2 => /lib/libresolv.so.2 (0xb7edb000)
libc.so.6 => /lib/libc.so.6 (0xb7dca000)
/lib/ld-linux.so.2 (0x80000000)
====================================
Shouldn't the libraries for plugins also appear in the list?
Thanks,
Xu Qiang
Anton Bobrov
Xu, Qiang (FXSGSC) wrote:
> Unfortunately, our printer is an embedded system, and the OS in it is a simplied Wind River Linux system. There is no "truss" command available in it. Even the command "env" is not available. So I don't know how to set this SASL_PATH into the environment.
surely it has something like setenv(3). if so can you try that ?
> However, when I use "ldd" to the library, it displays:
> ====================================
> mbc80:/opt/nc/lib <207> ldd libsasl2.so
> linux-gate.so.1 => (0xffffe000)
> libdl.so.2 => /lib/libdl.so.2 (0xb7eed000)
> libresolv.so.2 => /lib/libresolv.so.2 (0xb7edb000)
> libc.so.6 => /lib/libc.so.6 (0xb7dca000)
> /lib/ld-linux.so.2 (0x80000000)
> ====================================
> Shouldn't the libraries for plugins also appear in the list?
i dont think any of them are explicitly linked. afaik they get
loaded dynamically by libSASL based on mech name requested. it
is kinda the whole point of having them as plugins really.
Rich Megginson
Correct. They get loaded dynamically. When you do sasl_client_init()
it will call the getpath callback in the provided sasl_callbacks list.
(NOTE that mozldap does not allow you to pass in or otherwise override
the getpath callback - it should - as well as allow you to
provide/override the other sasl_callbacks). The fallback if there is no
getpath is to look in SASL_PATH or the path built into libsasl2.so when
it was compiled. It will then assume every shared lib in that directory
is a sasl mech plugin and attempt to dynamically load it.
Xu, Qiang (FXSGSC)
Now the error of "86 Unknown authentication method" is gone. But a new error pops up:
==============================================
<apManager> (Fri Mar 13 2009 13:34:19.846) <p8124,t3078597536,aba_ldap_interface.c,2373>
INFO>> SASL Login
<apManager> (Fri Mar 13 2009 13:35:07.089) <p8124,t3078597536,aba_ldap_interface.c,2388>
INFO>> SASL LDAP BIND with GSSAPI: Value of ldapStatus 82
<apManager> (Fri Mar 13 2009 13:35:07.089) <p8124,t3078597536,aba_ldap_interface.c,2459>
ERROR>> LDAP BIND: Value of ldap failure status and text 82 Local error
==============================================
What does this "local error" with the function ldap_sasl_interactive_bind_ext_s() mean?
Fortunately, I found some info about this error at http://aput.net/~jheiss/krbldap/howto.html:
==============================================
ldap_sasl_interactive_bind_s: Local error
ldap/hostname service principal not set up
or your Kerberos ticket is expired
==============================================
Using klist, it is verified that a Kerberos ticket exists and has not expired. So does it mean the service principal is not set up? What is a service principle? I don't have any knowledge about it at all. Please shed some light on it, and give me some suggestions to set it up.
And how come it taks nearly 1 min to get this error from SASL2 library? Incredibly long.
Rich Megginson
> Hi, all:
>
> Now the error of "86 Unknown authentication method" is gone. But a new error pops up:
> ==============================================
> <apManager> (Fri Mar 13 2009 13:34:19.846) <p8124,t3078597536,aba_ldap_interface.c,2373>
> INFO>> SASL Login
> <apManager> (Fri Mar 13 2009 13:35:07.089) <p8124,t3078597536,aba_ldap_interface.c,2388>
> INFO>> SASL LDAP BIND with GSSAPI: Value of ldapStatus 82
> <apManager> (Fri Mar 13 2009 13:35:07.089) <p8124,t3078597536,aba_ldap_interface.c,2459>
> ERROR>> LDAP BIND: Value of ldap failure status and text 82 Local error
> ==============================================
> What does this "local error" with the function ldap_sasl_interactive_bind_ext_s() mean?
I'm not really sure.
>
> Fortunately, I found some info about this error at http://aput.net/~jheiss/krbldap/howto.html:
> ==============================================
> ldap_sasl_interactive_bind_s: Local error
> ldap/hostname service principal not set up
> or your Kerberos ticket is expired
> ==============================================
> Using klist, it is verified that a Kerberos ticket exists and has not expired. So does it mean the service principal is not set up? What is a service principle? I don't have any knowledge about it at all. Please shed some light on it, and give me some suggestions to set it up.
Well, your ldap server must have assigned a keytab from your kerberos KDC.
>
> And how come it taks nearly 1 min to get this error from SASL2 library? Incredibly long.
I don't know.
Xu, Qiang (FXSGSC)
> From: Rich Megginson [mailto:rich.me...@gmail.com] On
> Behalf Of Rich Megginson
> To: Xu, Qiang (FXSGSC)
>
> Well, your ldap server must have assigned a keytab from your
> kerberos KDC.
Just think it twice and from http://docs.hp.com/en/J4269-90049/ch04s03.html, it seems a keytab file is not necessary:
=========================================================
Service/Host Principal
A Kerberos keytab file contains service or host principals and associated keys information. Users can choose to bind using the service or host keys. The keytab file may contain multiple principals and keys. Users may configure which service key to use. For example, the following /etc/krb5.keytab file contains two principal:
$ klist -k
Keytab name: FILE:/etc/krb5.keytab
Principal
--------------------------------------------
1 ldapux/hpntc10.c...@HP.COM
1 host/hpntc10.c...@HP.COM
=========================================================
It seems to me that if the feedback from klist command is not empty, then there exists a service principal.
After I authenticate against the Kerberos server, I get:
=========================================================
MBC113:/ <515> /tmp/dlms/kerberos/apps/klist -k
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: q...@SESSWIN2003.COM
Valid starting Expires Service principal
03/17/09 17:36:50 03/18/09 03:37:35 krbtgt/SESSWIN...@SESSWIN2003.COM
renew until 03/18/09 17:36:50
=========================================================
So I do have a service principal or ticket. And it has not expired, yet.
Looking back at the tutorial at http://aput.net/~jheiss/krbldap/howto.html:
=========================================================
ldap_sasl_interactive_bind_s: Local error
ldap/hostname service principal not set up
or your Kerberos ticket is expired
=========================================================
It may just mean either there is not any ticket available, or the ticket has expired. From the feedback of klist command, it looks my error is not due to this.
In short, I think the keytab file is not necessary, provided that my kinit is successful and klist does not give an empty result. Am I right?
Thanks,
Xu Qiang
Xu, Qiang (FXSGSC)
> From:
> dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.mozilla.org
>
> [mailto:dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.moz
> Sent: Wednesday, November 05, 2008 11:34 PM
> To: Rich Megginson
> Subject: Re: SASL authentication
>
> ldap_sasl_interactive_bind_ext_s() will only ask for the
> authname, whereas the user name is taken from the kerberos
> credential cache. The authorization name is required to tell
> the SASL layer that which user's authorization you required
> for this LDAP session. It can be the same as the kerberos
> user in credential cache. If you supplied "" (NULL) to the
> authname, then this means that you asking authorization of an
> anonymous user (which can be none in most of the cases). Thus
> in order to have an definite authorization, you do need to
> supplied a correct distinguished name of the user in ADS. The
> format for the authname value is
>
> dn:<distinguishedName of the user in ADS)
Kashif and all:
Using kinit, I have done the authentication against the Kerberos server successfully, and have a ticket or "service principal":
=========================================
MBC113:/ <515> /tmp/dlms/kerberos/apps/klist -k
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: q...@SESSWIN2003.COM
Valid starting Expires Service principal
03/17/09 17:36:50 03/18/09 03:37:35 krbtgt/SESSWIN...@SESSWIN2003.COM
renew until 03/18/09 17:36:50
=========================================
Up to now, it seems all is OK.
But, ldap_sasl_interactive_bind_ext_s() gives me a "82 Local error":
=========================================
<apManager> (Tue Mar 17 2009 17:37:15.641) <p387,t3078495136,aba_ldap_interface.c,2373>
INFO>> SASL Login
<apManager> (Tue Mar 17 2009 17:38:02.375) <p387,t3078495136,aba_ldap_interface.c,2388>
INFO>> SASL LDAP BIND with GSSAPI: Value of ldapStatus 82
<apManager> (Tue Mar 17 2009 17:38:02.375) <p387,t3078495136,aba_ldap_interface.c,2459>
ERROR>> LDAP BIND: Value of ldap failure status and text 82 Local error
=========================================
As long as I have a ticket, and the ticket hasn't expired (shown by the feedback of klist command), what else can cause this problem?
The core part of the code is as follows:
=========================================
static int sasl_flags = LDAP_SASL_QUIET;
static char *sasl_mech = "GSSAPI";
/* warning! - the following requires intimate knowledge of sasl.h */ static char *default_values[] = {
"", /* SASL_CB_USER 0x4001 */
"dn:CN=qxu,CN=Users,DC=sesswin2003,DC=com", /* SASL_CB_AUTHNAME 0x4002 */
LOGINFO("SASL LDAP BIND with GSSAPI: Value of ldapStatus %d", ldapStatus);
=========================================
Please note that I have changed the authname as you suggested.
Would you go over the code and point out what I have missed?
Thanks,
Xu Qiang
Rich Megginson
>> -----Original Message-----
>> From: Rich Megginson [mailto:rich.me...@gmail.com] On
>> Behalf Of Rich Megginson
>> Sent: Friday, March 13, 2009 10:50 PM
>> To: Xu, Qiang (FXSGSC)
>> Subject: Re: SASL authentication
>>
>> Well, your ldap server must have assigned a keytab from your
>> kerberos KDC.
>
> Just think it twice and from http://docs.hp.com/en/J4269-90049/ch04s03.html, it seems a keytab file is not necessary:
Not for users/clients, but for servers/services - your LDAP server needs
a keytab.
> =========================================================
> Service/Host Principal
> A Kerberos keytab file contains service or host principals and associated keys information. Users can choose to bind using the service or host keys. The keytab file may contain multiple principals and keys. Users may configure which service key to use. For example, the following /etc/krb5.keytab file contains two principal:
>
> $ klist -k
>
>
> Keytab name: FILE:/etc/krb5.keytab
> Principal
> --------------------------------------------
> 1 ldapux/hpntc10.c...@HP.COM
> 1 host/hpntc10.c...@HP.COM
> =========================================================
> It seems to me that if the feedback from klist command is not empty, then there exists a service principal.
Yes. There is the host principal (host/hpntc10.c...@HP.COM) which
is probably used for things like login/ssh. I'm not sure what
ldapux/hpntc10.c...@HP.COM is used for - could be an LDAP server
service principal, or could be the host LDAP client principal (e.g. for
nss_ldap, pam_ldap, etc.)
Your LDAP server needs a Kerberos service principal which is specified
in its keytab. If you don't know, you need to ask your Kerberos and
LDAP server administrator.
>
> After I authenticate against the Kerberos server, I get:
> =========================================================
> MBC113:/ <515> /tmp/dlms/kerberos/apps/klist -k
> Ticket cache: FILE:/tmp/krb5cc_0
> Default principal: q...@SESSWIN2003.COM
>
> Valid starting Expires Service principal
> 03/17/09 17:36:50 03/18/09 03:37:35 krbtgt/SESSWIN...@SESSWIN2003.COM
> renew until 03/18/09 17:36:50
> =========================================================
> So I do have a service principal or ticket. And it has not expired, yet.
No, you have a TGT, not a service principal.
>
> Looking back at the tutorial at http://aput.net/~jheiss/krbldap/howto.html:
> =========================================================
> ldap_sasl_interactive_bind_s: Local error
> ldap/hostname service principal not set up
> or your Kerberos ticket is expired
> =========================================================
> It may just mean either there is not any ticket available, or the ticket has expired. From the feedback of klist command, it looks my error is not due to this.
>
> In short, I think the keytab file is not necessary, provided that my kinit is successful and klist does not give an empty result. Am I right?
Not exactly.
>
> Thanks,
> Xu Qiang
Xu, Qiang (FXSGSC)
Now I am able to use ldapsearch (the OpenLDAP utility) to do SASL binding after a successful kinit operation. The previous error 82 (ldap_sasl_interactive_bind_s: Local error) is due to two reasons.
1. SASL binding should use LDAP server's hostname, instead of IP address.
2. DNS servers should be correctly set up to resolve the hostname to its IP address.
Now I turn back to use MozLDAP library to code SASL support, but it doesn't work. The error is still this "82 Local error". In the network trace captured between the client printer and the server, I found the following interesting packets:
========================================
32 3.141158 13.198.98.107 13.198.98.35 DNS Standard query A sesswin2003:389 .sesswin2003.com
33 3.141400 13.198.98.35 13.198.98.107 DNS Standard query response, No such name
34 3.141981 13.198.98.107 13.198.98.35 DNS Standard query AAAA sesswin2003:389 .sesswin2003.com
35 3.142071 13.198.98.35 13.198.98.107 DNS Standard query response, No such name
36 3.142287 13.198.98.107 13.198.98.35 DNS Standard query A sesswin2003:389 .sesswin2003.com
37 3.142373 13.198.98.35 13.198.98.107 DNS Standard query response, No such name
38 3.158268 13.198.98.107 13.198.98.35 DNS Standard query A sesswin2003.sesswin2003.com
39 3.158482 13.198.98.35 13.198.98.107 DNS Standard query response A 13.198.98.35
...... /* simple binding/search follows */
========================================
The server is "13.198.98.35", while the client is "13.198.98.107". Packet 32~37 are all related to SASL binding, while packet 38~39 onwards are for simple binding and search (and they are successful, coz the IP address is correctly resolved out). The code is arranged in such a manner that if SASL binding fails, it will turn to simple binding.
In the enrionment setup, the server is an AD in Windows 2003 Server Enterprise Edition. It's hostname is "sesswin2003". The server is also a primary domain controller, with the domain name "sesswin2003.com". In the printer's LDAP setup WebUI page, the server's hostname is set to "sesswin2003". And the printer is placed in the domain of "sesswin2003.com". This domain is set in the printer's TCP/IP WebUI page.
In simple binding, we can see the DNS request from the client is in the correct format, i.e. with LDAP server's hostname suffixed with the domain name. And the server can resolve correctly, and sends the IP address back to the client.
But, in SASL binding, the DNS request from the printer seems incorrect. It inserted the port number 389 and a space character between the hostname and the domain name. Thus, it is not a correct FQDN, and the server can't resolve it.
Is the insersion a defect of MozLDAP library, or SASL library?
The caller seems innocent:
========================================
<apManager> (Tue Mar 31 2009 16:39:02.518) <p27931,t3079396256,aba_ldap_interface.c,6666>
INFO>> Value of hostname sesswin2003:389
<apManager> (Tue Mar 31 2009 16:39:02.518) <p27931,t3079396256,aba_ldap_interface.c,6667>
INFO>> Value of loginName xu...@sesswin2003.com
<apManager> (Tue Mar 31 2009 16:39:02.518) <p27931,t3079396256,aba_ldap_interface.c,6668>
INFO>> Value of loginPassword Fair123
<apManager> (Tue Mar 31 2009 16:39:02.518) <p27931,t3079396256,aba_ldap_interface.c,6669>
INFO>> Value of referalsEnabled 0
<apManager> (Tue Mar 31 2009 16:39:02.518) <p27931,t3079396256,aba_ldap_interface.c,6670>
INFO>> Value of ldapVersion3 1
<apManager> (Tue Mar 31 2009 16:39:02.518) <p27931,t3079396256,aba_ldap_interface.c,6671>
INFO>> Value of maxNames 25
<apManager> (Tue Mar 31 2009 16:39:02.518) <p27931,t3079396256,aba_ldap_interface.c,6672>
INFO>> Value of timeOut 30
<apManager> (Tue Mar 31 2009 16:39:02.518) <p27931,t3079396256,aba_ldap_interface.c,1446>
INFO>> Calling ldap init
<apManager> (Tue Mar 31 2009 16:39:02.519) <p27931,t3079396256,aba_ldap_interface.c,1533>
INFO>> prldap_init succeeded
<apManager> (Tue Mar 31 2009 16:39:02.519) <p27931,t3079396256,aba_ldap_interface.c,1602>
INFO>> DISABLING REFERALS
<apManager> (Tue Mar 31 2009 16:39:02.519) <p27931,t3079396256,aba_ldap_interface.c,1620>
INFO>> SASL Login
<apManager> (Tue Mar 31 2009 16:39:02.538) <p27931,t3079396256,aba_ldap_interface.c,1634>
INFO>> SASL LDAP BIND with GSSAPI: Value of ldapStatus 82
<apManager> (Tue Mar 31 2009 16:39:02.538) <p27931,t3079396256,aba_ldap_interface.c,1641>
ERROR>> LDAP BIND: Value of ldap failure status and text 82 Local error
......
<apManager> (Tue Mar 31 2009 16:39:02.544) <p27931,t3079396256,aba_ldap_interface.c,6666>
INFO>> Value of hostname sesswin2003:389
<apManager> (Tue Mar 31 2009 16:39:02.544) <p27931,t3079396256,aba_ldap_interface.c,6667>
INFO>> Value of loginName xu...@sesswin2003.com
<apManager> (Tue Mar 31 2009 16:39:02.544) <p27931,t3079396256,aba_ldap_interface.c,6668>
INFO>> Value of loginPassword Fair123
<apManager> (Tue Mar 31 2009 16:39:02.544) <p27931,t3079396256,aba_ldap_interface.c,6669>
INFO>> Value of referalsEnabled 0
<apManager> (Tue Mar 31 2009 16:39:02.544) <p27931,t3079396256,aba_ldap_interface.c,6670>
INFO>> Value of ldapVersion3 1
<apManager> (Tue Mar 31 2009 16:39:02.544) <p27931,t3079396256,aba_ldap_interface.c,6671>
INFO>> Value of maxNames 25
<apManager> (Tue Mar 31 2009 16:39:02.544) <p27931,t3079396256,aba_ldap_interface.c,6672>
INFO>> Value of timeOut 30
<apManager> (Tue Mar 31 2009 16:39:02.544) <p27931,t3079396256,aba_ldap_interface.c,1981>
INFO>> Calling ldap init
<apManager> (Tue Mar 31 2009 16:39:02.544) <p27931,t3079396256,aba_ldap_interface.c,2080>
INFO>> prldap_init succeeded
<apManager> (Tue Mar 31 2009 16:39:02.544) <p27931,t3079396256,aba_ldap_interface.c,2149>
INFO>> DISABLING REFERALS
<apManager> (Tue Mar 31 2009 16:39:02.544) <p27931,t3079396256,aba_ldap_interface.c,2169>
INFO>> Value of the Login Password Fair123
<apManager> (Tue Mar 31 2009 16:39:02.544) <p27931,t3079396256,aba_ldap_interface.c,2190>
INFO>> Secure Login
<apManager> (Tue Mar 31 2009 16:39:02.761) <p27931,t3079396256,aba_ldap_interface.c,2196>
INFO>> LDAP BIND: Value of ldapStatus 0
========================================
The parameters passed to MozLDAP are all the same. But the binding results are different.
Rich Megginson
> Hi, all:
>
> Now I am able to use ldapsearch (the OpenLDAP utility) to do SASL binding after a successful kinit operation. The previous error 82 (ldap_sasl_interactive_bind_s: Local error) is due to two reasons.
> 1. SASL binding should use LDAP server's hostname, instead of IP address.
> 2. DNS servers should be correctly set up to resolve the hostname to its IP address.
>
> Now I turn back to use MozLDAP library to code SASL support, but it doesn't work. The error is still this "82 Local error". In the network trace captured between the client printer and the server, I found the following interesting packets:
> ========================================
> 32 3.141158 13.198.98.107 13.198.98.35 DNS Standard query A sesswin2003:389 .sesswin2003.com
> 33 3.141400 13.198.98.35 13.198.98.107 DNS Standard query response, No such name
> 34 3.141981 13.198.98.107 13.198.98.35 DNS Standard query AAAA sesswin2003:389 .sesswin2003.com
> 35 3.142071 13.198.98.35 13.198.98.107 DNS Standard query response, No such name
> 36 3.142287 13.198.98.107 13.198.98.35 DNS Standard query A sesswin2003:389 .sesswin2003.com
> 37 3.142373 13.198.98.35 13.198.98.107 DNS Standard query response, No such name
> 38 3.158268 13.198.98.107 13.198.98.35 DNS Standard query A sesswin2003.sesswin2003.com
> 39 3.158482 13.198.98.35 13.198.98.107 DNS Standard query response A 13.198.98.35
> ...... /* simple binding/search follows */
> ========================================
> The server is "13.198.98.35", while the client is "13.198.98.107". Packet 32~37 are all related to SASL binding, while packet 38~39 onwards are for simple binding and search (and they are successful, coz the IP address is correctly resolved out). The code is arranged in such a manner that if SASL binding fails, it will turn to simple binding.
>
> In the enrionment setup, the server is an AD in Windows 2003 Server Enterprise Edition. It's hostname is "sesswin2003". The server is also a primary domain controller, with the domain name "sesswin2003.com". In the printer's LDAP setup WebUI page, the server's hostname is set to "sesswin2003". And the printer is placed in the domain of "sesswin2003.com". This domain is set in the printer's TCP/IP WebUI page.
>
> In simple binding, we can see the DNS request from the client is in the correct format, i.e. with LDAP server's hostname suffixed with the domain name. And the server can resolve correctly, and sends the IP address back to the client.
>
> But, in SASL binding, the DNS request from the printer seems incorrect. It inserted the port number 389 and a space character between the hostname and the domain name. Thus, it is not a correct FQDN, and the server can't resolve it.
>
> Is the insersion a defect of MozLDAP library, or SASL library?
I have no idea. In order to figure out what is going on, I suggest
compiling both mozldap and sasl with full debugging support, and tracing
the execution all the way through to where the hostname is used and
looked up.
Markus Moeller
wrong arguments to the ldap function. e.g. where the hostname goes you put
hostname:port.
Markus
"Xu, Qiang (FXSGSC)" <Qian...@fujixerox.com> wrote in message
news:mailman.1733.12384917...@lists.mozilla.org...
Hi, all:
Looking forward to help,
Xu Qiang=
Xu, Qiang (FXSGSC)
> From:
> dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.mozilla.org
>
> [mailto:dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.moz
> Sent: Wednesday, April 01, 2009 3:10 AM
> To: dev-te...@lists.mozilla.org
> Subject: Re: SASL authentication
>
> that you give wrong arguments to the ldap function. e.g.
> where the hostname goes you put hostname:port.
Marcus, the source code to do SASL binding is as follows:
=========================================
static int sasl_flags = LDAP_SASL_QUIET;
static char *sasl_mech = "GSSAPI";
/* warning! - the following requires intimate knowledge of sasl.h */
static char *default_values[] = {
"", /* SASL_CB_USER 0x4001 */
"", /* SASL_CB_AUTHNAME 0x4002 */
"", /* SASL_CB_LANGUAGE 0x4003 */ /* not used */
"", /* SASL_CB_PASS 0x4004 */
"", /* SASL_CB_ECHOPROMPT 0x4005 */
"", /* SASL_CB_NOECHOPROMPT 0x4006 */
"", /* SASL_CB_CNONCE 0x4007 */
"" /* SASL_CB_GETREALM 0x4008 */
};
/* this is so we can use SASL_CB_USER etc. to index into default_values */
#define VALIDVAL(n) ((n >= SASL_CB_USER) && (n <= SASL_CB_GETREALM))
#define VAL(n) default_values[n-0x4001]
...
static int example_sasl_interact(LDAP *ld, unsigned flags, void *defaults, void *prompts) {
sasl_interact_t *interact = NULL;
if (prompts == NULL)
{
return (LDAP_PARAM_ERROR);
}
for (interact = prompts; interact->id != SASL_CB_LIST_END; interact++)
{
if (VALIDVAL(interact->id))
{
interact->result = VAL(interact->id);
interact->len = strlen((char *)interact->result);
}
}
return (LDAP_SUCCESS);
}
...
status = aba_ldap_retrieve_config_data(sessionInformation);
...
if ((ldapHandle = prldap_init((ldapServerConfigData.hostnames),
LDAP_PORT, 0)) == NULL)
{
LOGERROR("prldap_init failed");
return(ABA_LDAP_INIT_CALL_FAILED);
}
LOGINFO("prldap_init succeeded");
...
ldapStatus = ldap_sasl_interactive_bind_ext_s(ldapHandle, "", sasl_mech,
NULL, NULL, sasl_flags,
example_sasl_interact, NULL, &responseControls);
if (responseControls != NULL)
{
LOGINFO("SASL binding finished, will destroy responseControls");
ldap_controls_free(responseControls);
responseControls = NULL;
}
LOGINFO("SASL LDAP BIND with GSSAPI: Value of ldapStatus %d", ldapStatus);
=========================================
The binding function ldap_sasl_interactive_bind_ext_s() doesn't explicitly have an argument for server's hostname.
However, the simple binding interface doesn't need this parameter, either:
=========================================
ldapStatus = ldap_simple_bind_s(ldapHandle,
ldapServerConfigData.loginName,
ldapServerConfigData.loginPassword);
=========================================
The code to retrieve LDAP server's hostname is called by function aba_ldap_retrieve_config_data() -> aba_ldap_retrieve_server_info(). In the function, the server's hostname is extracted and combined in form of "hostname:port". After that, it is copied into the data structure "ldapServerConfigData.hostnames".
The data structures for ldapServerConfigData is here:
=========================================
typedef struct {
char hostnames[HOSTNAME_CAT_STRING+2];
char loginName[FIELD_MAX_SIZE+1];
char loginPassword[FIELD_MAX_SIZE+1];
bool_t referalsEnabled;
bool_t ldapVersion3;
int hopCount;
char base[FIELD_MAX_SIZE+1];
int timeOut;
int maxNames;
} LdapServerConfigData;
=========================================
It seems in simple binding, MozLDAP (or SASL2) library can handle this format and correctly sends out the DNS request. On the other hand, in case of SASL binding, the DNS request is formed incorrectly.
Is this helpful?
Thanks,
Xu Qiang
Xu, Qiang (FXSGSC)
> From:
> dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.mozilla.org
>
> [mailto:dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.moz
> illa.org] On Behalf Of Markus Moeller
> Sent: Wednesday, April 01, 2009 3:10 AM
> To: dev-te...@lists.mozilla.org
> Subject: Re: SASL authentication
>
> that you give wrong arguments to the ldap function. e.g.
> where the hostname goes you put hostname:port.
Good news, Marcus.
The original code is like this:
========================================
if ((ldapHandle = prldap_init((ldapServerConfigData.hostnames),
LDAP_PORT, 0)) == NULL)
{
LOGERROR("prldap_init failed");
return(ABA_LDAP_INIT_CALL_FAILED);
}
LOGINFO("prldap_init succeeded");
========================================
As you have noticed, the value of the variable "ldapServerConfigData.hostnames" is actually in a format of "host:port", which is incorrect. The reason that simple binding can succeed may be due to the high tolerance of the function "ldap_simple_bind_s()", whereas "ldap_sasl_interactive_bind_ext_s()" is more sensitive. It is strange that the function "prldap_init()" doesn't report any error when the hostname comes in the form of "host:port". The log entry "prldap_init succeeded" is always visible, even in the case of SASL binding failure.
According to your advice, I modifed the code as follows:
========================================
char *pSemicolon = NULL;
char serverHost[PRIMARY_HOSTNAME+1] = {0};
int serverPort = 0;
......
pSemicolon = strchr(ldapServerConfigData.hostnames, ':');
strncpy(serverHost, ldapServerConfigData.hostnames, pSemicolon - ldapServerConfigData.hostnames);
serverPort = atoi(pSemicolon + 1);
LOGINFO("serverHost is [%s]", serverHost);
LOGINFO("serverPort is [%d]", serverPort);
if ((ldapHandle = prldap_init(serverHost,
serverPort, 0)) == NULL)
{
LOGERROR("prldap_init failed");
return(ABA_LDAP_INIT_CALL_FAILED);
}
LOGINFO("prldap_init succeeded");
========================================
Now SASL LDAP binding with "ldap_sasl_interactive_bind_ext_s()" returns LDAP_SUCCESS now. I am greatly relieved. Many thanks about it.
Still, I have seen some strange packets:
========================================
32 17.839052 13.198.98.107 13.198.98.35 LDAP bindRequest(1) "<ROOT>" sasl
33 17.917608 13.198.98.35 13.198.98.107 LDAP bindResponse(1) saslBindInProgress
35 17.919333 13.198.98.107 13.198.98.35 LDAP bindRequest(2) "<ROOT>" [Malformed Packet]
36 17.919637 13.198.98.35 13.198.98.107 LDAP bindResponse(2) saslBindInProgress
37 17.920316 13.198.98.107 13.198.98.35 LDAP bindRequest(3) "<ROOT>" sasl
38 17.920691 13.198.98.35 13.198.98.107 LDAP bindResponse(3) success
========================================
I am not sure if packet 35 is normal or not? After all, it says the packet is malformed.
In contrast, a trace captured with OpenLDAP ldapsearch utility does not have this malformat packet:
========================================
22 24.805633 13.198.98.35 13.198.98.190 LDAP bindResponse(1) saslBindInProgress
28 26.616093 13.198.98.190 13.198.98.35 LDAP bindRequest(2) "<ROOT>" sasl
29 26.616459 13.198.98.35 13.198.98.190 LDAP bindResponse(2) saslBindInProgress
31 26.616705 13.198.98.190 13.198.98.35 LDAP bindRequest(3) "<ROOT>" sasl
32 26.633134 13.198.98.35 13.198.98.190 LDAP bindResponse(3) success
========================================
Packet 29 is normal, compared to Packet 35 in the last trace.
Another question: In SASL LDAP binding, I can't see explicit unbinding request and response, while I can see them in simple binding. Is this normal?
Thanks a million,
Xu Qiang
Xu, Qiang (FXSGSC)
> From:
> dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.mozilla.org
>
> [mailto:dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.moz
> Sent: Wednesday, November 05, 2008 11:34 PM
> To: Rich Megginson
> Subject: Re: SASL authentication
>
> ldap_sasl_interactive_bind_ext_s() will only ask for the
> authname, whereas the user name is taken from the kerberos
> credential cache. The authorization name is required to tell
> the SASL layer that which user's authorization you required
> for this LDAP session. It can be the same as the kerberos
> user in credential cache. If you supplied "" (NULL) to the
> authname, then this means that you asking authorization of an
> anonymous user (which can be none in most of the cases). Thus
> in order to have an definite authorization, you do need to
> supplied a correct distinguished name of the user in ADS. The
> format for the authname value is
>
> dn:<distinguishedName of the user in ADS)
>
> in the authname value.
From my experience, Rich is right on that we should leave it blank for the authorization name.
=============================================
static int sasl_flags = LDAP_SASL_QUIET;
static char *sasl_mech = "GSSAPI";
......
static char *default_values[] = {
"", /* SASL_CB_USER 0x4001 */
"", /* SASL_CB_AUTHNAME 0x4002 */
"", /* SASL_CB_LANGUAGE 0x4003 */ /* not used */
"", /* SASL_CB_PASS 0x4004 */
"", /* SASL_CB_ECHOPROMPT 0x4005 */
"", /* SASL_CB_NOECHOPROMPT 0x4006 */
"", /* SASL_CB_CNONCE 0x4007 */
"" /* SASL_CB_GETREALM 0x4008 */
};
=============================================
This is the correct set, and ldap sasl binding succeeds.
If we supply a value to the authname parameter, that will not do good:
=============================================
static int sasl_flags = LDAP_SASL_QUIET;
static char *sasl_mech = "GSSAPI";
......
static char *default_values[] = {
"", /* SASL_CB_USER 0x4001 */
"dn:CN=xuan,CN=Users,DC=sesswin2003,DC=com", /* SASL_CB_AUTHNAME 0x4002 */
"", /* SASL_CB_LANGUAGE 0x4003 */ /* not used */
"", /* SASL_CB_PASS 0x4004 */
"", /* SASL_CB_ECHOPROMPT 0x4005 */
"", /* SASL_CB_NOECHOPROMPT 0x4006 */
"", /* SASL_CB_CNONCE 0x4007 */
"" /* SASL_CB_GETREALM 0x4008 */
};
=============================================
It will fail.
Regards,
Xu Qiang
Xu, Qiang (FXSGSC)
Now my LDAP SASL is successful, thanks to all the help provided. I am really grateful to all of you.
Still, I have seen some strange packets in MozLDAP traffic:
========================================
32 17.839052 13.198.98.107 13.198.98.35 LDAP bindRequest(1) "<ROOT>" sasl
33 17.917608 13.198.98.35 13.198.98.107 LDAP bindResponse(1) saslBindInProgress
35 17.919333 13.198.98.107 13.198.98.35 LDAP bindRequest(2) "<ROOT>" [Malformed Packet]
36 17.919637 13.198.98.35 13.198.98.107 LDAP bindResponse(2) saslBindInProgress
37 17.920316 13.198.98.107 13.198.98.35 LDAP bindRequest(3) "<ROOT>" sasl
38 17.920691 13.198.98.35 13.198.98.107 LDAP bindResponse(3) success
========================================
I am not sure if packet 35 is normal or not? After all, it says the packet is malformed.
In contrast, a trace captured with OpenLDAP ldapsearch utility does not have this malformat packet:
========================================
22 24.805633 13.198.98.35 13.198.98.190 LDAP bindResponse(1) saslBindInProgress
28 26.616093 13.198.98.190 13.198.98.35 LDAP bindRequest(2) "<ROOT>" sasl
29 26.616459 13.198.98.35 13.198.98.190 LDAP bindResponse(2) saslBindInProgress
31 26.616705 13.198.98.190 13.198.98.35 LDAP bindRequest(3) "<ROOT>" sasl
32 26.633134 13.198.98.35 13.198.98.190 LDAP bindResponse(3) success
========================================
Packet 29 is normal, compared to Packet 35 in the last trace.
Will this Malformed Packet bring any side effect? Have you guys ever see this kind of packet in your own MozLDAP network trace?
Thanks,
Xu Qiang
Xu, Qiang (FXSGSC)
> From:
> dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.mozilla.org
>
> [mailto:dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.moz
> Sent: Thursday, April 09, 2009 10:29 AM
> To: Rich Megginson; Markus Moeller
> Cc: dev-te...@lists.mozilla.org
> Subject: RE: SASL authentication
>
> Will this Malformed Packet bring any side effect? Have you
> guys ever see this kind of packet in your own MozLDAP network trace?
Just to let you know that this Malformed Packet is observed with WireShark 1.0.6, while the trace was captured with Ethereal 0.99.0. And through examination of both MozLDAP trace and OpenLDAP trace, packet 35 in MozLDAP trace is no different from packet 28 in OpenLDAP trace. Among the three binding requests in both traces, the first and the third ones are with Kerberos blob information, while the second (packet 35 in MozLDAP trace and Packet 28 in OpenLDAP trace) ones only indicate sasl mechanism in use is GSSAPI.
But I still don't know why they look different in WireShark. Any suggestions?
Thanks,
Xu Qiang
Xu, Qiang (FXSGSC)
Sorry to bother you guys again. Yes, I have new troubles.
Now ldap works well with sasl binding in non-SSL mode. Yet, it does not look good in SSL connection:
=========================================
<apManager> (Thu Apr 09 2009 16:45:55.215) <p8395,t3079326624,aba_ldap_interface.c,1451>
INFO>> serverHost is [13.198.98.35]
<apManager> (Thu Apr 09 2009 16:45:55.215) <p8395,t3079326624,aba_ldap_interface.c,1452>
INFO>> serverPort is [636]
......
<apManager> (Thu Apr 09 2009 16:45:55.215) <p8395,t3079326624,aba_ldap_interface.c,1533>
INFO>> LDAP SSL CONNECTION SUCCESSFUL to 13.198.98.35:636
......
<apManager> (Thu Apr 09 2009 16:45:55.215) <p8395,t3079326624,aba_ldap_interface.c,1641>
INFO>> SASL Login
<apManager> (Thu Apr 09 2009 16:45:55.686) <p8395,t3079326624,aba_ldap_interface.c,1655>
INFO>> SASL LDAP BIND with GSSAPI: Value of ldapStatus 48
<apManager> (Thu Apr 09 2009 16:45:55.686) <p8395,t3079326624,aba_ldap_interface.c,1662>
ERROR>> LDAP BIND: Value of ldap failure status and text 48 Inappropriate authentication
=========================================
Any possible reason for this kind of error? In contrast, SSL mode works well when simple ldap binding is used.
Markus Moeller
maxssf = 56 ? I don't remember the default for the Mozilla SDK, if it
sets maxssf > 0 as default you need ot set it to 0 whenm using SSL otherwise
you have a conflict of requesting two encryption methods GSSAPI and SSL.
Regards
Markus
"Xu, Qiang (FXSGSC)" <Qian...@fujixerox.com> wrote in message
news:mailman.384.123926851...@lists.mozilla.org...
Hi, all:
Looking forward to help,
Xu Qiang=
Xu, Qiang (FXSGSC)
> From:
> dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.mozilla.org
>
> [mailto:dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.moz
> Sent: Friday, April 10, 2009 3:13 AM
> To: dev-te...@lists.mozilla.org
> Subject: Re: SASL authentication
>
> sasl secprops maxssf = 56 ? I don't remember the default
> for the Mozilla SDK, if it sets maxssf > 0 as default you
Hi, Marcus:
Do you mean GSSAPI binding can't work with SSL? I tried with OpenLDAP utitily, to get the same result.
Firstly, I did an SSL binding to verify it works:
==============================================
qxu@durian(pts/1):/[39]$ ldapsearch -H 'ldaps://13.198.98.35:636' -b 'dc=sesswin2003,dc=com' -s base -x -D 'cn=xuan,cn=users,dc=sesswin2003,dc=com' -w 'Fair123' -s sub -LLL 'cn=qxu' mail
dn: CN=qxu,CN=Users,DC=sesswin2003,DC=com
mail: Qian...@fujixerox.com
# refldaps://ForestDnsZones.sesswin2003.com/DC=ForestDnsZones,DC=sesswin2003,
DC=com
# refldaps://DomainDnsZones.sesswin2003.com/DC=DomainDnsZones,DC=sesswin2003,
DC=com
# refldaps://sesswin2003.com/CN=Configuration,DC=sesswin2003,DC=com
==============================================
Before this operation, I have added the line "TLS_REQCERT never" into the file "/etc/openldap/ldap.conf".
Then an SASL binding:
==============================================
qxu@durian(pts/1):/[40]$ kinit q...@SESSWIN2003.COM
Password for q...@SESSWIN2003.COM:
qxu@durian(pts/1):/[41]$ klist
Ticket cache: FILE:/tmp/krb5cc_20153
Default principal: q...@SESSWIN2003.COM
Valid starting Expires Service principal
04/13/09 11:00:52 04/13/09 21:03:18 krbtgt/SESSWIN...@SESSWIN2003.COM
renew until 04/14/09 11:00:52
Kerberos 4 ticket cache: /tmp/tkt20153
klist: You have no tickets cached
qxu@durian(pts/1):/[42]$ ldapsearch -Y GSSAPI -H 'ldap://13.198.98.35' -b 'dc=sesswin2003,dc=com' -s sub -LLL 'cn=qxu' mail
SASL/GSSAPI authentication started
SASL username: q...@SESSWIN2003.COM
SASL SSF: 56
SASL installing layers
dn: CN=qxu,CN=Users,DC=sesswin2003,DC=com
mail: Qian...@fujixerox.com
# refldap://ForestDnsZones.sesswin2003.com/DC=ForestDnsZones,DC=sesswin2003,D
C=com
# refldap://DomainDnsZones.sesswin2003.com/DC=DomainDnsZones,DC=sesswin2003,D
C=com
# refldap://sesswin2003.com/CN=Configuration,DC=sesswin2003,DC=com
==============================================
It works as expected.
Finally, I did a combination of SSL + SASL:
==============================================
qxu@durian(pts/1):/[44]$ ldapsearch -Y GSSAPI -H 'ldaps://13.198.98.35:636' -b 'dc=sesswin2003,dc=com' -s sub -LLL 'cn=qxu' mail
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Inappropriate authentication (48)
additional info: 00002029: LdapErr: DSID-0C09016D, comment: Cannot start kerberos signing/sealing when using TLS/SSL, data 0, vece
==============================================
The error is the same as when I use MozLDAP.
So, can I say SASL can't work together with SSL?
Thanks,
Xu Qiang
Xu, Qiang (FXSGSC)
> From:
> dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.mozilla.org
>
> [mailto:dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.moz
> illa.org] On Behalf Of Markus Moeller
> Sent: Friday, April 10, 2009 3:13 AM
> To: dev-te...@lists.mozilla.org
> Subject: Re: SASL authentication
>
> sasl secprops maxssf = 56 ? I don't remember the default
> for the Mozilla SDK, if it sets maxssf > 0 as default you
It seems that since both SSL and SASL are methods of encrypting the LDAP traffic, one is redundant if the other is used. Is it the case? If I can set sasl secprops maxssf to 0, does it mean I am not using SASL at that time?
By the way, I haven't found an easy way to set this parameter in MozLDAP distribution.
Thanks,
Xu Qiang
Markus Moeller
>
>Hi, Marcus:
>
>Do you mean GSSAPI binding can't work with SSL? I tried with OpenLDAP
>utitily, to get the same result.
>
No GSSAPI can be used for authentication AND encryption. maxssf controls the
encryption portion.
Markus
Markus Moeller
> traffic, one is redundant if the other is used. Is it the case? If I can
> set sasl secprops maxssf to > 0, does it mean I am not using SASL at that
> time?
No you use SASL for authentication and SSL for encryption
>
> By the way, I haven't found an easy way to set this parameter in MozLDAP
> distribution.
>
> Thanks,
> Xu Qiang=
Markus Moeller
> By the way, I haven't found an easy way to set this parameter in MozLDAP
> distribution.
>
sasl_secprops = (char *)"maxssf=0";
ldap_set_option( ld, LDAP_OPT_X_SASL_SECPROPS, (void *) sasl_secprops );
> Thanks,
> Xu Qiang=
Markus Moeller
> Finally, I did a combination of SSL + SASL:
>
>'ldaps://13.198.98.35:636' -b 'dc=sesswin2003,dc=com' -s sub -LLL 'cn=qxu'
> SASL/GSSAPI authentication started
> ldap_sasl_interactive_bind_s: Inappropriate authentication (48)
> additional info: 00002029: LdapErr: DSID-0C09016D, comment: Cannot
> start kerberos signing/sealing when using TLS/SSL, data 0, vece
> ==============================================
> The error is the same as when I use MozLDAP.
>
Try to add an option -o secprop="maxssf=0" or similar.
>
> So, can I say SASL can't work together with SSL?
>
> Thanks,
> Xu Qiang=
Markus
Xu, Qiang (FXSGSC)
> From:
> dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.mozilla.org
>
> [mailto:dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.moz
> illa.org] On Behalf Of Markus Moeller
Although this option does not work for ldapsearch directly, you give me the hint.
The working one seems to be -O "maxssf=0".
==================================
qxu@durian(pts/1):~[13]$ ldapsearch -Y GSSAPI -O "maxssf=0" -H 'ldaps://13.198.98.35:636' -b 'dc=sesswin2003,dc=com' -s sub -LLL 'cn=qxu' mail
SASL/GSSAPI authentication started
SASL username: q...@SESSWIN2003.COM
SASL SSF: 0
dn: CN=qxu,CN=Users,DC=sesswin2003,DC=com
mail: Qian...@fujixerox.com
# refldaps://ForestDnsZones.sesswin2003.com/DC=ForestDnsZones,DC=sesswin2003,
DC=com
# refldaps://DomainDnsZones.sesswin2003.com/DC=DomainDnsZones,DC=sesswin2003,
DC=com
# refldaps://sesswin2003.com/CN=Configuration,DC=sesswin2003,DC=com
==================================
You can see the feedback is "SASL SSF: 0".
By the way, when maxssf is set to 56 by default, what is the encryption method it is using? Why will it be in conflict with SSL/TLS?
Xu, Qiang (FXSGSC)
> From:
> dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.mozilla.org
>
> [mailto:dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.moz
> illa.org] On Behalf Of Markus Moeller
>
> sasl_secprops = (char *)"maxssf=0";
> ldap_set_option( ld, LDAP_OPT_X_SASL_SECPROPS, (void *)
> sasl_secprops );
This works, but only partially. The first binding is successful, the later ones all fail, citing the reason "81 Can't contact LDAP server". :-(
The code is like this:
==============================================
static char *sasl_secprops = "maxssf=0";
.....
if(sslEnabled)
{
if (ldap_set_option(ldapHandle, LDAP_OPT_X_SASL_SECPROPS, (void *)sasl_secprops) != 0)
{
/*
** unbind ldap handle.
*/
if (ldapHandle != (LDAP *)NULL)
{
LOGINFO("ldap_unbind_s3");
ldap_unbind_s(ldapHandle);
ldapHandle = (LDAP *)NULL;
}
LOGERROR("Failed to set maxssf to 0");
return(ABA_LDAP_SET_UNABLE_TO_SET_PREFS);
}
if ( (ldapHandle = ldapssl_init(serverHost,
serverPort, 1 )) == NULL)
{
LOGERROR("Failed to do ldapssl_init...");
return(ABA_LDAP_INIT_CALL_FAILED);
}
LOGINFO("LDAP SSL CONNECTION SUCCESSFUL to %s",
ldapServerConfigData.hostnames);
}
else
{
if ((ldapHandle = prldap_init(serverHost,
serverPort, 0)) == NULL)
{
LOGERROR("prldap_init failed");
return(ABA_LDAP_INIT_CALL_FAILED);
}
LOGINFO("prldap_init succeeded");
}
......
ldapStatus = ldap_sasl_interactive_bind_ext_s(ldapHandle, "", sasl_mech,
NULL, NULL, sasl_flags,
example_sasl_interact, NULL, &responseControls);
if (responseControls != NULL)
{
LOGINFO("SASL binding finished, will destroy responseControls");
ldap_controls_free(responseControls);
responseControls = NULL;
}
LOGINFO("SASL LDAP BIND with GSSAPI: Value of ldapStatus %d", ldapStatus);
==============================================
You can see that, compared to non-SSL binding with SASL/GSSAPI, there are only two differences. One is to set the option of maxssf to be 0, the other is ldapssl_init() versus prldap_init(). But the log shows ldapssl_init() is always successful.
The log tells me:
==============================================
<apManager> (Tue Apr 14 2009 11:04:22.587) <p25348,t3078937504,aba_ldap_interface.c,1625>
INFO>> SASL Login
<apManager> (Tue Apr 14 2009 11:04:23.186) <p25348,t3078937504,aba_ldap_interface.c,1639>
INFO>> SASL LDAP BIND with GSSAPI: Value of ldapStatus 0
<apManager> (Tue Apr 14 2009 11:04:23.186) <p25348,t3078937504,aba_ldap_interface.c,1702>
INFO>> ldap_unbind_s6
......
INFO>> SASL Login
<apManager> (Tue Apr 14 2009 11:04:23.223) <p25348,t3078937504,aba_ldap_interface.c,1639>
INFO>> SASL LDAP BIND with GSSAPI: Value of ldapStatus 81
<apManager> (Tue Apr 14 2009 11:04:23.223) <p25348,t3078937504,aba_ldap_interface.c,1646>
ERROR>> LDAP BIND: Value of ldap failure status and text 81 Can't contact LDAP server
<apManager> (Tue Apr 14 2009 11:04:23.223) <p25348,t3078937504,aba_ldap_interface.c,1659>
ERROR>> ABA_LDAP_BIND_SERVER_DOWN
==============================================
The server is confirmed to be alive all the time. In contrast, if SSL is not enabled, then SASL binding is always successful, no matter how many bindings are tried.
Any suggestions on this issue?
Thanks,
Xu Qiang
Markus Moeller
> By the way, when maxssf is set to 56 by default, what is the encryption
> method it is using? Why will it be in conflict with SSL/TLS?
>
You need to read about GSSAPI. There are C reference guides from Sun on how
to encrypt communications with gssapi.
> Thanks a million,
> Xu Qiang=
Markus Moeller
389 and ssl on port 636.
Markus
"Xu, Qiang (FXSGSC)" <Qian...@fujixerox.com> wrote in message
news:mailman.821.123968057...@lists.mozilla.org...
Thanks,
Xu Qiang=
Xu, Qiang (FXSGSC)
> From:
> dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.mozilla.org
>
> [mailto:dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.moz
> illa.org] On Behalf Of Markus Moeller
> starttls on port
> 389 and ssl on port 636.
Yes, I am using 636. And I understand that if I use port 389 on ssl connection, the error "81 Can't contact LDAP server" is expected. But it seems not to be the case.
Previously I made a mistake:
==============================================
static char *sasl_secprops = "maxssf=0";
......
if(sslEnabled)
{
if (ldap_set_option(ldapHandle, LDAP_OPT_X_SASL_SECPROPS, (void *)sasl_secprops) != 0)
{
/*
** unbind ldap handle.
*/
if (ldapHandle != (LDAP *)NULL)
{
LOGINFO("ldap_unbind_s3");
ldap_unbind_s(ldapHandle);
ldapHandle = (LDAP *)NULL;
}
LOGERROR("Failed to set maxssf to 0");
return(ABA_LDAP_SET_UNABLE_TO_SET_PREFS);
}
if ( (ldapHandle = ldapssl_init(serverHost,
serverPort, 1 )) == NULL)
{
LOGERROR("Failed to do ldapssl_init...");
return(ABA_LDAP_INIT_CALL_FAILED);
}
LOGINFO("LDAP SSL CONNECTION SUCCESSFUL to %s",
ldapServerConfigData.hostnames);
}
......
ldapStatus = ldap_sasl_interactive_bind_ext_s(ldapHandle, "", sasl_mech,
NULL, NULL, sasl_flags,
example_sasl_interact, NULL, &responseControls);
==============================================
As you can see, I set the option's value before the handle is created. That is ridiculous.
It has been corrected as:
==============================================
static char *sasl_secprops = "maxssf=0";
......
if(sslEnabled)
{
if ( (ldapHandle = ldapssl_init(serverHost,
serverPort, 1 )) == NULL)
{
LOGERROR("Failed to do ldapssl_init...");
return(ABA_LDAP_INIT_CALL_FAILED);
}
LOGINFO("LDAP SSL CONNECTION SUCCESSFUL to %s",
ldapServerConfigData.hostnames);
if (ldap_set_option(ldapHandle, LDAP_OPT_X_SASL_SECPROPS, (void *)sasl_secprops) != 0)
{
/*
** unbind ldap handle.
*/
if (ldapHandle != (LDAP *)NULL)
{
LOGINFO("ldap_unbind_s3");
ldap_unbind_s(ldapHandle);
ldapHandle = (LDAP *)NULL;
}
LOGERROR("Failed to set maxssf to 0");
return(ABA_LDAP_SET_UNABLE_TO_SET_PREFS);
}
}
......
ldapStatus = ldap_sasl_interactive_bind_ext_s(ldapHandle, "", sasl_mech,
NULL, NULL, sasl_flags,
example_sasl_interact, NULL, &responseControls);
==============================================
The change is just to swap the locations of ldapssl_init() and ldap_set_option().
To my dismay, I still get the error "81 Can't contact LDAP server":
==============================================
<apManager> (Tue Apr 14 2009 17:02:08.484) <p11077,t3079416736,aba_ldap_interface.c,1453>
INFO>> serverHost is [13.198.98.35]
<apManager> (Tue Apr 14 2009 17:02:08.484) <p11077,t3079416736,aba_ldap_interface.c,1454>
INFO>> serverPort is [636]
......
<apManager> (Tue Apr 14 2009 17:02:08.902) <p11077,t3079416736,aba_ldap_interface.c,1664>
INFO>> SASL LDAP BIND with GSSAPI: Value of ldapStatus 0
<apManager> (Tue Apr 14 2009 17:02:08.902) <p11077,t3079416736,aba_ldap_interface.c,1727>
INFO>> ldap_unbind_s6
......
<apManager> (Tue Apr 14 2009 17:02:08.910) <p11077,t3079416736,aba_ldap_interface.c,1650>
INFO>> SASL Login
<apManager> (Tue Apr 14 2009 17:02:08.916) <p11077,t3079416736,aba_ldap_interface.c,1664>
INFO>> SASL LDAP BIND with GSSAPI: Value of ldapStatus 81
<apManager> (Tue Apr 14 2009 17:02:08.916) <p11077,t3079416736,aba_ldap_interface.c,1671>
ERROR>> LDAP BIND: Value of ldap failure status and text 81 Can't contact LDAP server
==============================================
The same pattern can repeat many times. I am really confused why the first binding is successful, while the second fails. And then the 3rd succeeds, while the 4th fails. Hmmm, I have a feeling that the core part has nothing wrong. Maybe something is not quite right in the caller (in the module "apManager") of LDAP interface.
I will look into the code more carefully, and keep you posted.
Thanks,
Xu Qiang
Xu, Qiang (FXSGSC)
> From:
> dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.mozilla.org
>
> [mailto:dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.moz
> illa.org] On Behalf Of Markus Moeller
> ldap_set_option( ld, LDAP_OPT_X_SASL_SECPROPS, (void *)
> sasl_secprops );
Very strange. After this expression is added into the code, its behavior looks like pingpong style:
===================================================
<apManager> (Tue Apr 14 2009 17:54:24.215) <p7800,t3078957984,aba_ldap_interface.c,1650>
INFO>> SASL Login
<apManager> (Tue Apr 14 2009 17:54:24.382) <p7800,t3078957984,aba_ldap_interface.c,1664>
INFO>> SASL LDAP BIND with GSSAPI: Value of ldapStatus 0
......
<apManager> (Tue Apr 14 2009 17:54:24.390) <p7800,t3078957984,aba_ldap_interface.c,1650>
INFO>> SASL Login
<apManager> (Tue Apr 14 2009 17:54:24.395) <p7800,t3078957984,aba_ldap_interface.c,1664>
INFO>> SASL LDAP BIND with GSSAPI: Value of ldapStatus 81
<apManager> (Tue Apr 14 2009 17:54:24.395) <p7800,t3078957984,aba_ldap_interface.c,1671>
ERROR>> LDAP BIND: Value of ldap failure status and text 81 Can't contact LDAP server
......
<apManager> (Tue Apr 14 2009 17:54:40.943) <p7800,t3078957984,aba_ldap_interface.c,1650>
INFO>> SASL Login
<apManager> (Tue Apr 14 2009 17:54:41.030) <p7800,t3078957984,aba_ldap_interface.c,1664>
INFO>> SASL LDAP BIND with GSSAPI: Value of ldapStatus 0
......
<apManager> (Tue Apr 14 2009 17:54:41.038) <p7800,t3078957984,aba_ldap_interface.c,1650>
INFO>> SASL Login
<apManager> (Tue Apr 14 2009 17:54:41.043) <p7800,t3078957984,aba_ldap_interface.c,1664>
INFO>> SASL LDAP BIND with GSSAPI: Value of ldapStatus 81
<apManager> (Tue Apr 14 2009 17:54:41.043) <p7800,t3078957984,aba_ldap_interface.c,1671>
ERROR>> LDAP BIND: Value of ldap failure status and text 81 Can't contact LDAP server
......
<apManager> (Tue Apr 14 2009 17:54:57.444) <p7800,t3078957984,aba_ldap_interface.c,1650>
INFO>> SASL Login
<apManager> (Tue Apr 14 2009 17:55:00.450) <p7800,t3078957984,aba_ldap_interface.c,1664>
INFO>> SASL LDAP BIND with GSSAPI: Value of ldapStatus 0
......
<apManager> (Tue Apr 14 2009 17:55:00.458) <p7800,t3078957984,aba_ldap_interface.c,1650>
INFO>> SASL Login
<apManager> (Tue Apr 14 2009 17:55:00.463) <p7800,t3078957984,aba_ldap_interface.c,1664>
INFO>> SASL LDAP BIND with GSSAPI: Value of ldapStatus 81
<apManager> (Tue Apr 14 2009 17:55:00.463) <p7800,t3078957984,aba_ldap_interface.c,1671>
ERROR>> LDAP BIND: Value of ldap failure status and text 81 Can't contact LDAP server
===================================================
Such pattern really confuses me. After examining the code, I found nothing is wrong with the caller in apManager. I am at a loss now.
Could you give me any more suggestions, Marcus? And anyone has had the same experience before?
Thanks,
Xu Qiang
Xu, Qiang (FXSGSC)
Just wonder if this is a bug in MozLDAP library? Is there any developer of this library in this mailist?
The problem here is, to use ldap_sasl_interactive_bind_ext_s() do sasl binding over ssl connection, while set maxssf=0 using ldap_set_option(), the binding result is not stable. The result is good and bad alternatively. The odd numbered tryings are successful, while the even numbered all fail.
Any developer can look into this problem?
Thanks,
Xu Qiang
Xu, Qiang (FXSGSC)
> From:
> dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.mozilla.org
>
> [mailto:dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.moz
> Sent: Wednesday, April 15, 2009 10:32 AM
> To: Markus Moeller; dev-te...@lists.mozilla.org
> Subject: RE: SASL authentication
>
I can't solve the problem. Now, I am trying to find a walk-around:
===============================================
static char *sasl_secprops = "maxssf=0";
...
if(sslEnabled)
{
if (ldap_set_option(ldapHandle, LDAP_OPT_X_SASL_SECPROPS, (void *)sasl_secprops) != 0)
{
/*
** unbind ldap handle.
*/
if (ldapHandle != (LDAP *)NULL)
{
LOGINFO("ldap_unbind_s3");
ldap_unbind_s(ldapHandle);
ldapHandle = (LDAP *)NULL;
}
LOGERROR("Failed to set maxssf to 0");
return(ABA_LDAP_SET_UNABLE_TO_SET_PREFS);
}
if ( (ldapHandle = ldapssl_init(serverHost,
serverPort, 1 )) == NULL)
{
LOGERROR("Failed to do ldapssl_init...");
return(ABA_LDAP_INIT_CALL_FAILED);
}
LOGINFO("LDAP SSL CONNECTION SUCCESSFUL to %s",
ldapServerConfigData.hostnames);
}
......
ldapStatus = ldap_sasl_interactive_bind_ext_s(ldapHandle, "", sasl_mech,
NULL, NULL, sasl_flags,
example_sasl_interact, NULL, &responseControls);
if (TRUE == sslEnabled && LDAP_SUCCESS != ldapStatus)
{
LOGINFO("SASL binding over SSL failed, try again");
ldapStatus = ldap_sasl_interactive_bind_ext_s(ldapHandle, "", sasl_mech,
NULL, NULL, sasl_flags,
example_sasl_interact, NULL, &responseControls);
}
if (responseControls != NULL)
{
LOGINFO("SASL binding finished, will destroy responseControls");
ldap_controls_free(responseControls);
responseControls = NULL;
}
LOGINFO("SASL LDAP BIND with GSSAPI: Value of ldapStatus %d", ldapStatus);
===============================================
Since SASL binding over SSL encryption shows a pingpong style, the strategy here is to make another binding try if it has failed once. The log shows it works. But the application crashes.
The core file shows it occured in unbind operation:
===============================================
MBC107:/var/log/nc/archive/save_20090415_115450 <90> gdb /usr/mart/bin/apManager apManager-17120-1239767584.core
...
Core was generated by `apManager'.
Program terminated with signal 11, Segmentation fault.
#0 0x080bc530 in ?? ()
(gdb) bt
#0 0x080bc530 in ?? ()
#1 0xb7db196a in ldapssl_close (s=1, socketarg=0x80bc448) at ldapsinit.c:235
#2 0xb7dd32d4 in nsldapi_close_connection (ld=0x1, sb=0x80ab130)
at os-ip.c:770
#3 0xb7dd79fa in nsldapi_free_connection (ld=0x80a34a8, lc=0x80ab7d8,
serverctrls=0x1, clientctrls=0x1, force=1, unbind=1) at request.c:808
#4 0xb7de7f99 in ldap_ld_free (ld=0x80a34a8, serverctrls=0x0,
clientctrls=0x0, close=1) at unbind.c:109
#5 0xb7de8290 in ldap_unbind_s (ld=0x1) at unbind.c:68
#6 0xb7f2a916 in aba_ldap_init_sasl_p (ldapSearchHandle=0x1, testFlag=1,
username=0x0, password=0x0, sessionInformation=0x0)
at aba_ldap_interface.c:1738
#7 0xb7f2a9ab in aba_ldap_init (ldapSearchHandle=0x80ab130, testFlag=1)
at aba_ldap_interface.c:1777
#8 0xb7f23233 in ABA_Initialization (type=ABA_LDAP_SEARCH) at aba.c:144
#9 0x0804a8ef in doPersonalization (return_struct=0x80595c0,
username=0x80591d0 "qxu") at apManagerRequestThread.c:832
#10 0x08049e46 in readQueue () at apManagerRequestThread.c:414
#11 0x080499e6 in _internal_thread_start (arg=0x0)
at apManagerRequestThread.c:183
#12 0xb7cbd439 in start_thread (arg=0xb78a9ba0) at pthread_create.c:274
#13 0x42d5307e in clone () from /lib/libc.so.6
===============================================
Besides this, the log also shows the crash occurs after ldap_unbind_s(). I don't know what the question marks stand for. Is it because my MozLDAP library is not compiled with debug support?
Any way to avoid the crash?
Thanks,
Xu Qiang
Xu, Qiang (FXSGSC)
> From:
> dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.mozilla.org
>
> [mailto:dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.moz
> style, the strategy here is to make another binding try if it
> has failed once. The log shows it works. But the application crashes.
It was found that the crash is due to the immediate re-binding after the first failure.
Originally, my walk-around is:
===============================================
static char *sasl_secprops = "maxssf=0";
......
if(sslEnabled)
{
......
ldapHandle = ldapssl_init(serverHost, serverPort, 1);
ldap_set_option(ldapHandle, LDAP_OPT_X_SASL_SECPROPS, (void *)sasl_secprops);
}
......
ldapStatus = ldap_sasl_interactive_bind_ext_s(ldapHandle, "", sasl_mech,
NULL, NULL, sasl_flags,
example_sasl_interact, NULL, &responseControls);
if (TRUE == sslEnabled && LDAP_SUCCESS != ldapStatus)
{
LOGINFO("SASL binding over SSL failed, try again");
ldapStatus = ldap_sasl_interactive_bind_ext_s(ldapHandle, "", sasl_mech,
NULL, NULL, sasl_flags,
example_sasl_interact, NULL, &responseControls);
}
===============================================
Compared with the behavior and log before this walk-around was added (i.e. there is no crash when there is no this re-binding immediately after the failure), it seems after the binding failure, the init operation ldapssl_init() should be called again before the next binding.
The is the revised version:
===============================================
static char *sasl_secprops = "maxssf=0";
......
if(sslEnabled)
{
......
ldapHandle = ldapssl_init(serverHost, serverPort, 1);
ldap_set_option(ldapHandle, LDAP_OPT_X_SASL_SECPROPS, (void *)sasl_secprops);
}
......
ldapStatus = ldap_sasl_interactive_bind_ext_s(ldapHandle, "", sasl_mech,
NULL, NULL, sasl_flags,
example_sasl_interact, NULL, &responseControls);
if (TRUE == sslEnabled && LDAP_SUCCESS != ldapStatus)
{
LOGINFO("SASL binding over SSL failed, try again");
ldapHandle = ldapssl_init(serverHost, serverPort, 1);
ldap_set_option(ldapHandle, LDAP_OPT_X_SASL_SECPROPS, (void *)sasl_secprops);
......
ldapStatus = ldap_sasl_interactive_bind_ext_s(ldapHandle, "", sasl_mech,
NULL, NULL, sasl_flags,
example_sasl_interact, NULL, &responseControls);
}
===============================================
Now it works. There is no crash anymore.
Based on these findings, I am almost sure the pingpong style of sasl binding over ssl encryption is a bug in MozLDAP library. Any developer wants to have a look into this problem?
Thanks,
Xu Qiang
Xu, Qiang (FXSGSC)
> From:
> dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.mozilla.org
>
> [mailto:dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.moz
> developer of this library in this mailist?
>
> The problem here is, to use
> ldap_sasl_interactive_bind_ext_s() do sasl binding over ssl
> connection, while set maxssf=0 using ldap_set_option(), the
> binding result is not stable. The result is good and bad
> alternatively. The odd numbered tryings are successful, while
> the even numbered all fail.
>
> Any developer can look into this problem?
I am amazed that there is no place to report bugs for MozLDAP Library. There is no such product in Mozilla's Bugzilla system. It seems a dark corner ignored by Mozilla community.
Anyone knows who develops this library?
Thanks,
Xu Qiang
Nelson Bolyard
> I am amazed that there is no place to report bugs for MozLDAP Library.
> There is no such product in Mozilla's Bugzilla system. It seems a dark
> corner ignored by Mozilla community.
I am amazed that people can't figure this easy stuff out.
https://bugzilla.mozilla.org/enter_bug.cgi?product=Directory
Xu, Qiang (FXSGSC)
> From:
> dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.mozilla.org
>
> [mailto:dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.moz
> Sent: Wednesday, April 15, 2009 5:08 PM
>
>
> https://bugzilla.mozilla.org/enter_bug.cgi?product=Directory
Oh, oh! My eye sight was so bad.
Thanks, Nelson!
Xu Qiang
Rich Megginson
> Hi, all:
> Just wonder if this is a bug in MozLDAP library? Is there any developer of this library in this mailist?
>
> The problem here is, to use ldap_sasl_interactive_bind_ext_s() do sasl binding over ssl connection, while set maxssf=0 using ldap_set_option(), the binding result is not stable. The result is good and bad alternatively. The odd numbered tryings are successful, while the even numbered all fail.
>
> Any developer can look into this problem?
>
> Thanks,
> Xu Qiang
> _______________________________________________
> dev-tech-ldap mailing list
> dev-te...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-ldap
>
>
>
Anton Bobrov
please also make sure to attach a reproducible testcase to the
bug report. it is not exactly clear what are you trying to do.
Xu, Qiang (FXSGSC)
> From: Rich Megginson [mailto:rich.me...@gmail.com]
> Sent: Wednesday, April 15, 2009 9:55 PM
> To: Xu, Qiang (FXSGSC)
> Cc: Markus Moeller; dev-te...@lists.mozilla.org
> Subject: Re: SASL authentication
>
Yes, Rich. I have done this the day before. Hopefully, some developer can look into this problem.
Thanks,
Xu Qiang
Xu, Qiang (FXSGSC)
> From: Anton....@Sun.COM [mailto:Anton....@Sun.COM]
> Sent: Thursday, April 16, 2009 6:56 AM
> To: Xu, Qiang (FXSGSC)
> the bug report. it is not exactly clear what are you trying to do.
I've filed a report at https://bugzilla.mozilla.org/show_bug.cgi?id=488449. If you feel anything is missing, pls let me know.
Thanks,
Xu Qiang
Xu, Qiang (FXSGSC)
> From: Rich Megginson [mailto:rich.me...@gmail.com]
> Sent: Wednesday, April 15, 2009 9:55 PM
> Cc: Markus Moeller; dev-te...@lists.mozilla.org
> Subject: Re: SASL authentication
>
I've filed a report at https://bugzilla.mozilla.org/show_bug.cgi?id=488449. If you find something is missing, pls let me know.
Thanks,
Xu Qiang
Xu, Qiang (FXSGSC)
> From:
> dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.mozilla.org
>
> [mailto:dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.moz
> Sent: Wednesday, April 15, 2009 10:32 AM
> To: Markus Moeller; dev-te...@lists.mozilla.org
> Subject: RE: SASL authentication
>
> ldap_sasl_interactive_bind_ext_s() do sasl binding over ssl
> connection, while set maxssf=0 using ldap_set_option(), the
> binding result is not stable. The result is good and bad
> alternatively. The odd numbered tryings are successful, while
> the even numbered all fail.
Just want you guys know that, if maxssf is set to 0 in sasl binding with non-ssl connection, the result is constantly good. No pingpong style observed in logs and network traces. Maybe this is another proof that it is a defect in MozLDAP library's ssl part.
Regards,
Xu Qiang
Nelson Bolyard
Does maxssf disable the use of SSL?
I wonder if this could be another manifestation of failure to specify the
client's identity to libSSL (that is, to name a client session cache to be
used with each connection).
If a process is trying to act as multiple client identities, and doesn't
identify each of those identities separately to libSSL through a call to
SSL_SetSockPeerID, then libSSL will attempt to use a single common SSL
session for all of them.
Perhaps this leads to failures with the following scenario:
- identity 1 establishes an SSL session with the server and binds his
identity to it with SASL.
- identity 2 connects to the same server, and reuses the SSL session
established by identity 1. Things fail because of the identity mismatch.
- identity 2 retries, creating a new session, bound to identity 2, and
succeeds.
- identity 1 connects to that server, reusing the session of identity 2,
... etc.
Is that the behavior described as "ping pong style" ?
Xu, Qiang (FXSGSC)
> From:
> dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.mozilla.org
>
> [mailto:dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.moz
> Sent: Monday, April 27, 2009 6:34 AM
By default, maxssf is set to 56 when sasl binding is in use. So yes, it disables SSL encryption. That is why SSL only works when maxssf is set to zero.
> I wonder if this could be another manifestation of failure to
> specify the client's identity to libSSL (that is, to name a
> client session cache to be used with each connection).
You used the word "another", so does it mean you have come across the similar scenario before?
> If a process is trying to act as multiple client identities,
> and doesn't identify each of those identities separately to
> libSSL through a call to SSL_SetSockPeerID, then libSSL will
> attempt to use a single common SSL session for all of them.
>
> Perhaps this leads to failures with the following scenario:
>
> - identity 1 establishes an SSL session with the server and
> binds his identity to it with SASL.
> - identity 2 connects to the same server, and reuses the SSL
> session established by identity 1. Things fail because of
> the identity mismatch.
> - identity 2 retries, creating a new session, bound to
> identity 2, and succeeds.
> - identity 1 connects to that server, reusing the session of
> identity 2, ... etc.
>
> Is that the behavior described as "ping pong style" ?
Yes, your description is the same as the problem observed here.
But a question: You mentioned "identity". Is it referring to the username/credential associated with a user? If it is, then some problem here. The "ping pong" style is visible even with the same user in multiple binding tries:
All this happens with the same user over multiple tries. On the other hand, if your identity means something other than the user, then your analysis should be correct. By the way, is there any way for me to prove what you described with logs?
Could you come up with some kind of fix? I can convey the fix to OS team to help me build a new MozLDAP library, and I will test the fix with the new library.
Thanks a lot,
Xu Qiang
Xu, Qiang (FXSGSC)
Although I filed the bug of sasl binding over ssl connection (when maxssf is set to 0), I forgot to notify you the bug id, so that you can keep track of it.
Here is it:
https://bugzilla.mozilla.org/show_bug.cgi?id=488449
Thanks for your attention,
Xu Qiang
Xu, Qiang (FXSGSC)
Sorry to trouble you again, but this time, I have some new findings with Malformed Packet in MozLDAP network trace.
As you can see, the Malformed Packet is in the 2nd round of binding interaction with the server:
========================================
32 17.839052 13.198.98.107 13.198.98.35 LDAP bindRequest(1) "<ROOT>" sasl
33 17.917608 13.198.98.35 13.198.98.107 LDAP bindResponse(1) saslBindInProgress
35 17.919333 13.198.98.107 13.198.98.35 LDAP bindRequest(2) "<ROOT>" [Malformed Packet]
36 17.919637 13.198.98.35 13.198.98.107 LDAP bindResponse(2) saslBindInProgress
37 17.920316 13.198.98.107 13.198.98.35 LDAP bindRequest(3) "<ROOT>" sasl
38 17.920691 13.198.98.35 13.198.98.107 LDAP bindResponse(3) success
========================================
I am not sure if packet 35 is normal or not? After all, it says the packet is malformed.
In contrast, a trace captured with OpenLDAP ldapsearch utility does not have this malformat packet:
========================================
22 24.805633 13.198.98.35 13.198.98.190 LDAP bindResponse(1) saslBindInProgress
28 26.616093 13.198.98.190 13.198.98.35 LDAP bindRequest(2) "<ROOT>" sasl
29 26.616459 13.198.98.35 13.198.98.190 LDAP bindResponse(2) saslBindInProgress
31 26.616705 13.198.98.190 13.198.98.35 LDAP bindRequest(3) "<ROOT>" sasl
32 26.633134 13.198.98.35 13.198.98.190 LDAP bindResponse(3) success
========================================
As you know, SASL connection relies on SASL library like libsasl2.so, which depends on OpenLDAP libraries such as libldap-2.3.so and liblber-2.3.so (this can be verfified by "ldd libsasl2.so"). And I am not sure whether there is some conflict between MozLDAP and OpenLDAP when MozLDAP calls SASL interfaces in libsasl2.so to do SASL binding.
This aside, when I compare the content of packet 35 in MozLDAP trace and packet 29 in OpenLDAP trace, it is noted that the MozLDAP packet has extra bytes "04 00" after "mechanism: GSSAPI". These extra bytes are interpreted as "<MISSING> credentials" by WireShark. In contrast, although the OpenLDAP packet doesn't have any credential information as well, it doesn't have these extra bytes. That's why packet 35 in MozLDAP trace is marked as Malformed Packet, while packet 29 in OpenLDAP trace is not.
Anyone can look into this matter? If you try some sasl connection and capture a network trace while doing sasl binding, you'll easily find the problem.
I myself have captured the traces, but it is understood that mailist doesn't welcome attachments. So if anybody wants to have a look at my trace, just let me know, and I'll send you in separate mail.
Thanks,
Xu Qiang
Rich Megginson
> Hi, all:
>
> Sorry to trouble you again, but this time, I have some new findings with Malformed Packet in MozLDAP network trace.
>
> As you can see, the Malformed Packet is in the 2nd round of binding interaction with the server:
> ========================================
> 32 17.839052 13.198.98.107 13.198.98.35 LDAP bindRequest(1) "<ROOT>" sasl
> 33 17.917608 13.198.98.35 13.198.98.107 LDAP bindResponse(1) saslBindInProgress
> 35 17.919333 13.198.98.107 13.198.98.35 LDAP bindRequest(2) "<ROOT>" [Malformed Packet]
> 36 17.919637 13.198.98.35 13.198.98.107 LDAP bindResponse(2) saslBindInProgress
> 37 17.920316 13.198.98.107 13.198.98.35 LDAP bindRequest(3) "<ROOT>" sasl
> 38 17.920691 13.198.98.35 13.198.98.107 LDAP bindResponse(3) success
> ========================================
> I am not sure if packet 35 is normal or not? After all, it says the packet is malformed.
>
> In contrast, a trace captured with OpenLDAP ldapsearch utility does not have this malformat packet:
> ========================================
> 22 24.805633 13.198.98.35 13.198.98.190 LDAP bindResponse(1) saslBindInProgress
> 28 26.616093 13.198.98.190 13.198.98.35 LDAP bindRequest(2) "<ROOT>" sasl
> 29 26.616459 13.198.98.35 13.198.98.190 LDAP bindResponse(2) saslBindInProgress
> 31 26.616705 13.198.98.190 13.198.98.35 LDAP bindRequest(3) "<ROOT>" sasl
> 32 26.633134 13.198.98.35 13.198.98.190 LDAP bindResponse(3) success
> ========================================
> As you know, SASL connection relies on SASL library like libsasl2.so, which depends on OpenLDAP libraries such as libldap-2.3.so and liblber-2.3.so (this can be verfified by "ldd libsasl2.so"). And I am not sure whether there is some conflict between MozLDAP and OpenLDAP when MozLDAP calls SASL interfaces in libsasl2.so to do SASL binding.
>
> This aside, when I compare the content of packet 35 in MozLDAP trace and packet 29 in OpenLDAP trace, it is noted that the MozLDAP packet has extra bytes "04 00" after "mechanism: GSSAPI". These extra bytes are interpreted as "<MISSING> credentials" by WireShark. In contrast, although the OpenLDAP packet doesn't have any credential information as well, it doesn't have these extra bytes. That's why packet 35 in MozLDAP trace is marked as Malformed Packet, while packet 29 in OpenLDAP trace is not.
>
credentials (4 is the BER tag for Octet String, the next byte is the
length which is zero). I would have to read the specs to see what it
says about that, but it appears at least that Wireshark does not like
it, and OpenLDAP does not do it, it just omits the credentials field
entirely. So I would say this is likely a bug in MozLDAP.
> Anyone can look into this matter? If you try some sasl connection and capture a network trace while doing sasl binding, you'll easily find the problem.
>
> I myself have captured the traces, but it is understood that mailist doesn't welcome attachments. So if anybody wants to have a look at my trace, just let me know, and I'll send you in separate mail.
>
your traces, then just email a link to the traces. Mozilla has a
pastebin at http://pastebin.mozilla.org/
> Thanks,
> Xu Qiang
Xu, Qiang (FXSGSC)
> From: Rich Megginson [mailto:rich.me...@gmail.com]
> Sent: Tuesday, June 02, 2009 2:30 AM
> To: Xu, Qiang (FXSGSC)
> dev-te...@lists.mozilla.org
> Subject: Re: SASL authentication
>
> to paste your traces, then just email a link to the traces.
> Mozilla has a pastebin at http://pastebin.mozilla.org/
Just went there to have a look. It is a place to paste code snippet, not file attachments. :-(
Anyway, thanks for your info.
Xu Qiang
Xu, Qiang (FXSGSC)
SASL binding is successful, but only for a fixed specific LDAP server. :-(
If the hostname is used for LDAP server, and the hostname is resolved by DNS server to a series of IP address (usually serving as backup servers for the primary one), then there is a possibility of using a TGT for host A to bind to host B.
For example, I have come across the following situation:
==========================================================
1610 43.995272 157.55.143.63 157.54.14.162 DNS Standard query A ntdev.corp.test.com
1611 43.996618 157.54.14.162 157.55.143.63 DNS Standard query response A 157.54.80.10 A 172.31.79.153
A 172.31.79.151 A 172.31.79.155 A 172.31.79.156 A 157.54.104.75 A 172.31.79.154
A 172.31.79.144 A 172.31.79.140 A 172.31.79.142 A 172.31.79.146 A 10.192.150.46
A 172.31.79.150 A 172.31.79.143
...
1615 43.999395 157.55.143.63 157.54.14.162 DNS Standard query A ntdev.corp.test.com
1617 44.001772 157.54.14.162 157.55.143.63 DNS Standard query response A 172.31.79.153 A 172.31.79.151
A 172.31.79.155 A 172.31.79.156 A 157.54.104.75 A 172.31.79.154 A 172.31.79.144
A 172.31.79.140 A 172.31.79.142 A 172.31.79.146 A 10.192.150.46 A 172.31.79.150
A 172.31.79.143 A 157.54.80.10
1618 44.002698 157.55.143.63 157.54.14.162 DNS Standard query PTR 75.104.54.157.in-addr.arpa
1619 44.004056 157.54.14.162 157.55.143.63 DNS Standard query response PTR ntdev-dc-04.ntdev.corp.test.com
...
1636 44.017783 157.55.143.63 157.54.80.10 LDAP bindRequest(1) "<ROOT>" sasl
sasl
Ticket
Server Name (Service and Host): ldap/ntdev-dc-04.ntdev.corp.test.com
==========================================================
In the configuration, the hostname "ntdev.corp.test.com" is set as the LDAP server. But both 157.54.80.10 (ntdev-dc-01.ntdev.corp.test.com) and 157.54.104.75 (ntdev-dc-04.ntdev.corp.test.com) are in the list of resolved IP addresses. Then, it uses the ticket acquired from 104.75 to bind to 80.10, which generates an error KRB5KRB_AP_ERR_MODIFIED.
I guess the first DNS query is to get the IP address mapped to by LDAP server hostname "ntdev.corp.test.com" and it gets 157.54.80.10 in front of 157.54.104.75, while the second DNS query (and the later reverse DNS query) is to get TGT for use in SASL binding and it gets 157.54.104.75 in front of 157.54.80.10.
The madness is due to the unique environment in the customer's company that a large list of servers are mapped to the same host name and the dynamic DNS query results. The good trace happened when the DNS query results were consistent. The customer doesn't want to use IP address or specific hostname (like "ntdev-dc-01.ntdev.corp.test.com" or "ntdev-dc-04.ntdev.corp.test.com") to configure their LDAP server, coz they are not fixed.
Is there any solution to this problem? I am at a loss at what to do, since Mozilla LDAP library calls dealing with SASL binding doesn't directly involve DNS stuff.
Looking forward to help,
Xu Qiang
Xu, Qiang (FXSGSC)
Overall, my implementation of SASL binding is OK, but it doesn't work in dealing with IPv6:
====================================================================
<apManager> (Thu Jun 04 2009 15:04:32.847) <p3593,t824878304,aba_ldap_interface.c,1470>
INFO>> primary server IP address is 2001:4898:e0:f04b:21f:29ff:fee2:b390
......
<apManager> (Thu Jun 04 2009 15:04:32.851) <p3593,t824878304,aba_ldap_interface.c,1717>
INFO>> SASL Login
<apManager> (Thu Jun 04 2009 15:04:32.852) <p3593,t824878304,aba_ldap_interface.c,1833>
INFO>> SASL LDAP BIND with GSSAPI: Value of ldapStatus 91
<apManager> (Thu Jun 04 2009 15:04:32.852) <p3593,t824878304,aba_ldap_interface.c,1840>
ERROR>> LDAP BIND: Value of ldap failure status and text 91 Can't connect to the LDAP server
====================================================================
From what I can gather from googling, this error 91 is mainly about certificates in TLS/SSL connection. But I am not using either of them now.
And there is no outward SASL traffic. In contrast, if I am using simple binding to the same server with IPv6 address, everthing looks good.
Is there anything worthy of note when IPv6 is used in SASL binding?
Xu, Qiang (FXSGSC)
> From:
> dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.mozilla.org
>
> [mailto:dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.moz
> Sent: Monday, June 08, 2009 3:29 PM
> To: dev-te...@lists.mozilla.org
> Subject: RE: SASL authentication
>
>
> Overall, my implementation of SASL binding is OK, but it
> doesn't work in dealing with IPv6:
> ====================================================================
> <apManager> (Thu Jun 04 2009 15:04:32.847)
> <p3593,t824878304,aba_ldap_interface.c,1470>
> INFO>> primary server IP address is
> 2001:4898:e0:f04b:21f:29ff:fee2:b390
> ......
> <apManager> (Thu Jun 04 2009 15:04:32.851)
> <p3593,t824878304,aba_ldap_interface.c,1717>
> INFO>> SASL Login
> <apManager> (Thu Jun 04 2009 15:04:32.852)
> <p3593,t824878304,aba_ldap_interface.c,1833>
> INFO>> SASL LDAP BIND with GSSAPI: Value of ldapStatus 91
> <apManager> (Thu Jun 04 2009 15:04:32.852)
> <p3593,t824878304,aba_ldap_interface.c,1840>
> ERROR>> LDAP BIND: Value of ldap failure status and text
> 91 Can't connect to the LDAP server
> ====================================================================
Just to let you guys know I have found the cause of the failure.
Previously, we have hit a problem when doing SASL bindings over hostnames. For large organizations, one hostname may be associated with many IP addresses, many of which server as backup servers for the main one.
Suppose we configure the LDAP server to use hostname, then during SASL binding, at least two forward DNS queries (to get IP address from hostname) will be performed. The first one is to get the IP address of the LDAP server so that we know the destination of our LDAP request, while the second one is to be immediately followed by a reverse lookup to find the FQDN of the server, which will be used to determine Kerberos TGT. In the process, if these two rounds of forward DNS queries get different IP addresses, then we may run into a situation that we are using the ticket from one host to contact another.
It's a serious problem. And we don't have much control in it, coz the two DNS queries happen in low level libraries, such as Mozilla LDAP, Cyrus SASL and possibly GSSAPI.
Fortunately, we also found that if the LDAP server is configured to use IP address, the problem doesn't occur (Of couse, since the problem arises from two inconsistent forward DNS query results). Based on this, the solution is that we don't pass down the hostname directly to prldap_init(). Instead, we do a DNS query to get the server's IP address first and then pass this acquired address to prldap_init().
The code is like this:
=====================================================================
/* convert primary server hostname to IP address */
if (is_it_an_IP_address(primaryServerHost) == FALSE)
{
strncpy(primaryIP, primaryServerHost, PRIMARY_HOSTNAME);
if (get_ip_from_hostname(primaryServerHost, primaryIP))
{
LOGINFO("primary server IP address is %s", primaryIP);
}
else
{
LOGERROR("get_ip_from_hostname() failed for primary server, still using hostname!");
strncpy(primaryIP, primaryServerHost, PRIMARY_HOSTNAME);
}
}
else
{
LOGINFO("primary server is already in IP address form");
strncpy(primaryIP, primaryServerHost, PRIMARY_HOSTNAME);
}
...
if ((ldapHandle = prldap_init(primaryIP, primaryServerPort, 1)) == NULL)
{
LOGERROR("Failed to do prldap_init for Primary Server...");
return(ABA_LDAP_INIT_CALL_FAILED);
}
else
{
LOGINFO("prldap_init SUCCESSFUL to [%s:%d]", primaryIP, primaryServerPort);
}
...
ldapStatus = ldap_sasl_interactive_bind_ext_s(ldapHandle, "", sasl_mech,
NULL, NULL, sasl_flags,
example_sasl_interact, NULL, &responseControls);
=====================================================================
It works for IPv4 address. But it doesn't in dealing with IPv6 address.
After removing the above code converting hostname to ipaddress (core of which is get_ip_from_hostname()), it works for IPv6 server now! So happy...
On second thoughts, the convert code can't be removed so easily, coz we still face the problem of inconsistent forward DNS query results. The solution I can think of is to create some flag, and when the flag is on, do the conversion from hostname to IP address. When it is off, we just directly pass hostname down to prldap_init().
Last but not least, I must thank Rich for his direct help all along. And although Howard is not in this list, I still need to thank him for he reminded me that in dealing with IPv6, we'd better stick to hostname.
Regards,
Xu Qiang
Rich Megginson
terminate the buffer- if you want to use strncpy, you must ensure that
the string is properly null terminated.
Xu, Qiang (FXSGSC)
> From: Rich Megginson [mailto:rich.me...@gmail.com]
> Sent: Friday, June 12, 2009 11:13 PM
> To: Xu, Qiang (FXSGSC)
> Subject: Re: SASL authentication
>
> This is a very dangerous use of strncpy - strncpy does not null
> terminate the buffer- if you want to use strncpy, you must
> ensure that the string is properly null terminated.
Actually, the code snippet is part of a function:
=======================================================
static AbaInitStatus
aba_ldap_init_sasl_p(LDAP **ldapSearchHandle, bool_t testFlag,
char* username, char* password,
SM_Session_Information_Type *sessionInformation)
{
int ldapStatus = LDAP_SUCCESS;
AbaInitStatus status = ABA_OK;
LDAP *ldapHandle = (LDAP *)NULL;
...
LDAPControl **responseControls = NULL;
char primaryIP[PRIMARY_HOSTNAME+1] = {0};
...
/* convert primary server hostname to IP address */
if (is_it_an_IP_address(primaryServerHost) == FALSE)
{
strncpy(primaryIP, primaryServerHost, PRIMARY_HOSTNAME);
if (get_ip_from_hostname(primaryServerHost, primaryIP))
{
LOGINFO("primary server IP address is %s", primaryIP);
}
else
{
LOGERROR("get_ip_from_hostname() failed for primary server, still using hostname!");
strncpy(primaryIP, primaryServerHost, PRIMARY_HOSTNAME);
}
}
else
{
LOGINFO("primary server is already in IP address form");
strncpy(primaryIP, primaryServerHost, PRIMARY_HOSTNAME);
}
...
if ((ldapHandle = prldap_init(primaryIP,
primaryServerPort, 1 )) == NULL)
{
LOGERROR("Failed to do prldap_init for Primary Server...");
return(ABA_LDAP_INIT_CALL_FAILED);
}
else
{
LOGINFO("prldap_init SUCCESSFUL to [%s:%d]",
primaryIP, primaryServerPort);
}
...
ldapStatus = ldap_sasl_interactive_bind_ext_s(ldapHandle, "", sasl_mech,
NULL, NULL, sasl_flags,
example_sasl_interact, NULL, &responseControls);
if (responseControls != NULL)
{
LOGINFO("SASL binding finished, will destroy responseControls");
ldap_controls_free(responseControls);
responseControls = NULL;
}
LOGINFO("SASL LDAP BIND with GSSAPI: Value of ldapStatus %d", ldapStatus);
...
}
=======================================================
As you can see, the char array primaryIP[] is a local variable, and it would be initialized to 0 blocks every time the function is called. Therefore, strncpy() here is safe. :-)
Thanks for reminding, Rich!
Xu Qiang
Xu, Qiang (FXSGSC)
I am just thinking of a question.
If the first parameter to be passed into prldap_init() is a hostname, when will DNS resolve it to IP address? Will DNS query happens in ldap_simple_bind_s() in case of simple binding, and in ldap_sasl_interactive_bind_ext_s() in case of sasl binding, or it just happens in prldap_init()?
Thanks,
Xu Qiang
Rich Megginson
I think prldap_init doesn't actually do very much. The usual LDAP
semantics are to wait until an actual network connection is required
before doing any network stuff, including DNS lookups.
Xu, Qiang (FXSGSC)
Usually, before sasl binding, GSSAPI library will initiate a reverse DNS lookup (PTR query) to find the server's FQDN, then issue a request for TGT (TGS-REQ) to get the service ticket. After that, sasl binding will begin.
On some occasion, I find a network trace (captured during sasl binding) that doesn't do the reverse DNS lookup. Instead, it does a simple binding first, to get the attribute "ldapServiceName". Then, after some DNS lookups (but without PTR query), TGS-REQ is sent out and TGS_REP is received. After that, sasl binding begins. It seems with this attribute passed in, the reserse DNS lookup is not necessary any more.
But, in MozLDAP, the sasl interface is "ldap_sasl_interactive_bind_ext_s()", with the prototype:
======================================================================
ldap_sasl_interactive_bind_ext_s( LDAP *ld, const char *dn,
const char *saslMechanism,
LDAPControl **sctrl, LDAPControl **cctrl, unsigned flags,
LDAP_SASL_INTERACT_PROC *callback, void *defaults, LDAPControl ***rctrl )
======================================================================
I can't find any argument associated with the service ticket. Or, is there any other interface to use?
Thanks,
Xu Qiang
Xu, Qiang (FXSGSC)
Just found the latest Mozilla LDAP version is 6.0.6, while all along I was using 6.0.4.
But, after downloading the tar ball of source and extract it, I can't find anything like ChangeLog or some equivalent. Can anyone tell me what fix are contained in 6.0.6 version since 6.0.4?
Thanks,
Xu Qiang
Xu, Qiang (FXSGSC)
In the "configure" file of MozLDAP distribution, I found the option to enable IPv6:
=============================================================
# Check whether --enable-ipv6 or --disable-ipv6 was given.
if test "${enable_ipv6+set}" = set; then
enableval="$enable_ipv6"
if test "$enableval" = "yes"; then
USE_IPV6=1
fi
fi
=============================================================
I understand that if the source is configured like "./configure ... --enable-ipv6=yes", then USE_IPV6 would be set to 1.
But where should this flag be used?
=============================================================
ifdef USE_AUTOCONF
...
ifeq ($(USE_IPV6),1)
DEFINES += -D_PR_INET6
endif
else # ! USE_AUTOCONF
...
####################################################################
#
# The NSPR-specific configuration
#
####################################################################
...
ifeq ($(USE_IPV6),1)
OS_CFLAGS += -D_PR_INET6
endif
...
endif # USE_AUTOCONF
=============================================================
This is the only place the flag USE_IPV6 is used. I gather that it will add -D_PR_INET6 to DEFINES or OS_CFLAGS. But I can't seek any futher beyond this. In the source code, I didn't find the location of -D_PR_INET6 at all. How this flag should be used?
I am quite confused now...
Xu, Qiang (FXSGSC)
SASL LDAP binding will fail if Kerberos authentication server is configured with IPv6 address. It just can't recognize the IPv6 address, and would take it as a hostname. Note: authentication has no problem. The user is given access, but the onward LDAP binding fails.
The same problem happens when Kerberos authentication server is configured with hostname, while DNS server resolves this hostname to IPv6 address if the option "Prefer IPv6 over IPv4" is checked in the printer's WebUI.
For example, the IPv6 address of the Kerberos server is "3ffe:2000:0:1:e0be:1872:d4f8:6b2c", and the authentication domain is "xcipv6.com". When MozLDAP (or SASL and its GSSAPI plugin) receives this IPv6 address, it would think the address is in a form of "hostname:port", and split the address at the first colon, and combine it with the domain name, to form an FQDN "3ffe.xcipv6.com". Then it would try to resolve this FQDN to get the IPv4 address. Of course, the resolving would lead to an error. The server to retrieve Kerberos TGT from can't be located, so TGS-REQ is never initiated and SASL binding can't go through.
When I configure the printer to use IPv4 address of the Kerberos server, SASL LDAP binding works well.
Anybody has seen this problem before? Any potential solution?
I am not sure about which software goes wrong, e.g. MozLDAP, SASL (libsasl2.so), or GSSAPI plugin (libgssapiv2.so)? To begin with, I want to start from the Mozilla interface "ldap_sasl_interactive_bind_ext_s()". But I don't know to to debug.
There are some log info like this:
===================================================
LDAPDebug( LDAP_DEBUG_TRACE, "ldap_sasl_interactive_bind_s\n", 0, 0, 0 );
===================================================
But how to enable the debug switch? And where I should look into for the log file? What's the file's physical location?
Thanks,
Xu Qiang