David,

Thanks for the reply. 

Maybe this will help. The user name and password are stored as plain text 
within the server.xml file. That is how it is today. The documentation 
recommends that AD be setup with a very limited Read Only user account that has 
privileges for scanning just AD. 

To me and my co-workers that login still represents a large security risk if 
someone can gain access to the file server.xml. There is a lot of personal 
information stored within the LDAP directory itself.

My thoughts / request for having the plain text password being replaced by an 
MD5 hash has nothing to do with the interaction / what is passed back to AD 
itself. In our case, our AD is setup with Kerberos v5 which I assume is some 
complex key passing encryption protocol that I doubt even uses MD5. 

Now, if someone could gain access to the MD5 version of the password what could 
they do with it, really? 

After talking with a few people here at work and brainstorming on this issue, 
the current theory is that since I am binding with AD, instead of using 
'Comparison Mode' there is no way for the local MD5 hash (from server.xml) to 
be compared to a MD5 hash from AD (the users real password).  It isn't ever 
passed back to the client (for obvious security reasons).

http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html#JNDIRealm

So now I think I better understand why it hasn't been done in the first place. 

My reasoning for having the MD5 hash was simply to make it harder for someone 
to use the same username and password on other systems within the same company.


-Dennis Klotz



-----Original Message-----
From: David Delbecq [mailto:[EMAIL PROTECTED] 
Sent: Friday, October 14, 2005 1:13 PM
To: Tomcat Users List
Subject: Re: can JNDIRealm connectionPassword be encrypted?

First i don't know active directory.

However, in a global security point of view, your request
is surprising, specially if the intend was to prevent publicity
of password to people accessing the context.xml. If the 
AD protocol would accept that client send an md5 hash 
of password instead of plain password, i can't see the interest of
it, as then the md5 hash becomes the password. Anyone who can get
access to the md5 could connect to active directory and request
md5 authentification, no need to to reverse md5, so md5 does in that
case provide 0 security improvement. 

So am curious to know the interest of storing md5 pass in connectionPassword.

Regards,
David Delbecq
Le Vendredi 14 Octobre 2005 17:12, Klotz Jr, Dennis a écrit :
>Greetings,
>
>
>
>I have a working JNDIRealm setup that connects with our local Active
>Directory using the following Realm statement:
>
>
>
>      <Realm className="org.apache.catalina.realm.JNDIRealm"
>
>            debug="99"
>
>            connectionName="CN=Last\,
>First,OU=BedfordRecipients,DC=company,DC=com"
>
>            connectionPassword="myPlainTextPassword"
>
>            connectionURL="ldap://23.82.0.101:389";
>
>            alternateURL="ldap://23.82.0.100:389";
>
>            referrals="follow"
>
>            userBase="OU=BedfordRecipients,DC=company,DC=com"
>
>            userSearch="(sAMAccountName={0})"
>
>            userSubtree="true"
>
>            userRoleName="anAtribute"
>
>      />
>
>
>
>After the usual searching and investigation it appears there isn't a way
>to use an MD5 (or something similar) version of connectionPassword. In
>other words, I wish to replace the clear text password stored in the
>server.xml with the MD5 equivalent.
>
>
>
>Is it indeed the case that you cannot use and encrypted version of the
>password and if so are there any plans of enhancing it? Is there some
>aspect of the problem I'm overlooking?
>
>
>
>Dennis Klotz, Senior Software Engineer
>EMPIRIX | Communications Infrastructure Group | 20 Crosby Drive |
>Bedford, MA. USA | 01730

-- 

David Delbecq
Royal Meteorological Institute of Belgium

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to