tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robyne Vaughn" <rvau...@lubbockisd.org>
Subject RE: can JNDIRealm connectionPassword be encrypted?
Date Mon, 17 Oct 2005 15:20:55 GMT
I have managed to get my jndi realm to work in tomcat.  I'm not sure I really understand it
well, but basically it goes like this:  Tomcat connects to AD with its own password and userid
because AD will not allow an anonymous connection.  Once tomcat is connected, then you bind
as the user with the user's id and password, and that authenticates the user.

so, you have a jndi realm in the server.xml with tomcat's user-id and password in plain text.
(better secure the server.xml file)
then, your login.jsp uses the user's credentials to bind to AD.

Robyne Vaughn

  _____  



-----Original Message-----
From: Klotz Jr, Dennis [mailto:DKlotz@empirix.com] 
Sent: Monday, October 17, 2005 9:06 AM
To: Tomcat Users List
Subject: RE: can JNDIRealm connectionPassword be encrypted?


David,

Either the documentation is wrong or I am simply being daft, but in one part of the doc (very
beginning of the section), it describes the very feature you are talking about where the user
name and password at login time, is in fact, used to connect with the AD. I am assuming in
that configuration, you must remove the keywords connectionName and connectionPassword from
server.xml. However, when you read the documentation for these two keywords it mentions that
if you don't use these keywords, an anonymous bind is used.

So how does one configure tomcat to use the current user's login and password to connect to
the AD?

If I remove connectionName and connectionPassword I get the following error:

SEVERE: Exception performing authentication
javax.naming.NamingException: [LDAP: error code 1 - 00000000: LdapErr: DSID-0C090627, comment:
In or der to perform this operation a successful bind must be completed on the connection.,
data 0, vece ] ; remaining name 'OU=BedfordRecipients,DC=company,DC=com'
        at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3025)
        at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2931)
        at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2737)
...

So I was left with the impression that I "had" to provide a login and password within server.xml
since AD by default does not support anonymous logins.


-Dennis


-----Original Message-----
From: David Delbecq [mailto:delbd@oma.be] 
Sent: Monday, October 17, 2005 4:56 AM
To: Tomcat Users List
Subject: Re: can JNDIRealm connectionPassword be encrypted?

Klotz Jr, Dennis a écrit :

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

If the tomcat were to be able to send the md5 string and have AD accept the md5 to compare
it with it's own md5 copy, you would have a major security issue in AD (not in tomcat!). Why?
Because Hash storing in any password authentification system is made to prevent people who
have access to database (either by accident or non lawfull administrator) to impersonate any
of the user. Imagine somone put a hand on your AD backup, they get the md5 of sysadmin and
then just ask AD system to accept authentification using the md5? That's why am pretty sure
AD would never accept auth by accepting the password md5.

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

It is quite clear in a security point of view. To access the AD, tomcat need to be recognized
by AD, to do so it needs a password and an id. Now, one configuration you might try is to
not give Tomcat a user account. The JNDI Realm has another configuration possibility. In this
configuration, it takes the username / password send by web client and try to use them to
log in AD. If login is successful, it concludes the users is allowed on system. In this scheme,
no need for a tomcat user account as it is the client account which is used.

>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.
>  
>
Again, if tomcat is able to log in using the md5, any user could on any other system. This
would provide zero security enhancement.

Regards.

>
>-Dennis Klotz
>
>
>
>-----Original Message-----
>From: David Delbecq [mailto:david.delbecq@oma.be]
>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
>>    
>>
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message