On 14 Apr 2011, at 18:22, Mark Inaba wrote:

> hello perl-ldap mailing list,
> 
> i'm wondering if i'm trying to do the impossible, even though it seems like 
> this might be a common situation.
> i'm trying to verify a user/password by having the user bind to an ldap 
> server. the problem is that just given a username, i can't guess the DN 
> because the DN's components have values that could be many things:
> example:
> CN=mark,OU=paris,OU=short,...,DC=partA,DC=foo,DC=com
> CN=mike,OU=new york,OU=tall,...,DC=partB,DC=foo,DC=com
> 
> it seems that all of this is necessary for me to bind (i can't just use 
> CN=mark,DC=foo,DC=com and try a password against all matches sigh)
> so if i get another user, i don't know what sort of OU values his/her DN will 
> have. also, the DC's might be different too. 
> 
> here's the wrinkles that make it harder:
> 1) anon bind is turned off, so i can't search around for promising matches 
> and use their DN
> 2) they don't want a generic 'read' account to log in because they don't want 
> the password in a file.
>     but i might be ok if:
>     a) though if script is not called by user i might be able to convince 
> them to use o-r.
>     b) if the final server is sasl aware, i might be able to use an encrypted 
> string in the script
> 
> but here's why i think it MIGHT be possible... using the windows program: 
> ldap.exe
> i noticed that i'm able to bind filling in only the fields:
> USER: mark
> PASSWORD: mypassword
> DOMAIN: parta.foo.com
> 
> so unless the application knows some secret settings...how does it 
> authenticate me without my telling it my full DN?

There's another way to bind in LDAP, using something called SASL. One SASL 
mechanism uses Kerberos, and on Windows this can take advantage of the ticket 
you get from your Windows AD when you log in to your machine.

You could also use other SASL mechanisms - things like "CRAM-MD5", 
"DIGEST-MD5", or "SCRAM-SHA-1". These take a SASL ID instead of a DN, which 
look something like "u...@domain.com", and if you omit the "@domain.com" part 
the LDAP server will often default something.

If you look at your server's logs you might now be able to work out how your 
client is binding.

Chris

Reply via email to