Re: SASL authentication

Kashif Ali Siddiqui wrote:
> 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.

> 
> 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
>>
>