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.
Kashif Ali Siddiqui
Tech Lead Folio3
Rich Megginson wrote:
Xu, Qiang (FXSGSC) wrote:
-----Original Message-----
From: Xu, Qiang (FXSGSC)
Sent: Wednesday, November 05, 2008 5:49 PM
To: Xu, Qiang (FXSGSC); Rich Megginson
Cc: Michael Ströder; [email protected]
Subject: RE: SASL authentication
Just found out that the function
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?
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
_______________________________________________
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
