Hello Xu,

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

Xu, Qiang (FXSGSC) wrote:
Hi, all:

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
_______________________________________________
dev-tech-ldap mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-ldap


_______________________________________________
dev-tech-ldap mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-ldap

Reply via email to