Can I use LDAP server's authentication mechanism rather than comparing password ?

Question

Hi All,
The weblogic security and adminguide says that the user authencation can be of
the following 3 types:
1. Bind specifies that the LDAP security realm
retrieves user data, including the password for
the LDAP server, and checks the password in
WebLogic Server.
2. External specifies that the LDAP security
realm authenticates a User by attempting to
bind to the LDAP server with the username
and password supplied by theWebLogic
Server client. If you choose the External
setting, you must also use the SSL protocol.
3. Local specifies that the LDAP security realm
authenticates a User by looking up the
UserPassword property in the LDAP directory
and checking it against the passwords in
WebLogic Server.
But say I want that my users should be authenticated by the LDAP server rather
than picking up the password from LDAP and comparing at weblogic end. Then what
should I do ?
Because no. 2 is applicable only for ssl certificates, no.1 and no.3 picks up
password using the login dn and password provided at the time of configuration
of realm and compare with password given by user.
And once gain there some issues on having picking up password and comparing it:
1. Netscape directory server can store the password in oneway hashed form(and
that is preferred , too). So when userpassword attribute is read , it's in one
way hashed form. So how the comparison will go on ?
2. Creating a user who has the access to user data along with userpassword attribute
itself is a security threat, as if someone can crack that user's dn and password
then he/she can do anything as userdata can be read.
Any suggestion is welcome.
TIA,
Sudarson

Answer 1

Thanks a lot Jerry.
I got these stuff from weblogic 6.1 docs sets security.pdf and adminguide.pdf.
I have another question, if that is the case (in Case of BIND), then why do we
a require a dn of user and password who has the access to read the entire directory
And at the same time, u specified this for Bind, what are the cases for other
two-local and external ? And then what is actually difference between Bind and
Local ?
Pls help me.
Thanks,
Sudarson
Jerry <[email protected]> wrote:
Hi Sudarson,
Whatever doc you were reading is at least partially incorrect, unfortunately...
I know for sure that when you specify BIND, weblogic sends the username/password
to your
LDAP server in an attempt to bind to it.
If the bind is successful, WLS determines that the username/password
pair were correct.
If the bind was unsuccessful, WLS determines that the username/password
pairing is not
valid.
At all times, WebLogic is letting the LDAP server do the actual compare
of
username/password. WLS does not, at any time, retrieve a password from
the LDAP server.
I hope this helps,
Joe Jerry
sudarson wrote:
Hi All,
The weblogic security and adminguide says that the user authencationcan be of
the following 3 types:
1. Bind specifies that the LDAP security realm
retrieves user data, including the password for
the LDAP server, and checks the password in
WebLogic Server.
2. External specifies that the LDAP security
realm authenticates a User by attempting to
bind to the LDAP server with the username
and password supplied by theWebLogic
Server client. If you choose the External
setting, you must also use the SSL protocol.
3. Local specifies that the LDAP security realm
authenticates a User by looking up the
UserPassword property in the LDAP directory
and checking it against the passwords in
WebLogic Server.
But say I want that my users should be authenticated by the LDAP serverrather
than picking up the password from LDAP and comparing at weblogic end.Then what
should I do ?
Because no. 2 is applicable only for ssl certificates, no.1 and no.3picks up
password using the login dn and password provided at the time of configuration
of realm and compare with password given by user.
And once gain there some issues on having picking up password and comparingit:
1. Netscape directory server can store the password in oneway hashedform(and
that is preferred , too). So when userpassword attribute is read ,it's in one
way hashed form. So how the comparison will go on ?
2. Creating a user who has the access to user data along with userpasswordattribute
itself is a security threat, as if someone can crack that user's dnand password
then he/she can do anything as userdata can be read.
Any suggestion is welcome.
TIA,
Sudarson