Hi Jeremy, Sorry to muddy the waters but here's my $0.02
It is possible to improve things a tiny bit without changing Tomcat (apologies if you already know this). It is not necessary for Tomcat to bind to your OpenLDAP server as OpenLDAP's rootdn. You can provide a dn and password for a regular entity but they must have read access to the userPassword attribute in all the objects that Tomcat is going to look at. This is just a matter of setting the correct permissions in slapd.conf. Obviously, this wouldn't prevent an attacker from snooping your plaintext password, using this to look at the digested passwords in the server and then performing dictionary/brute force attacks on them. However, it does prevent an attacker from snooping your password and using it to delete everything in your LDAP directory or messing around with it in another way. If you are worried about passive attacks on the network then the new 'bind as user' functionality available in CVS is perhaps better but it doesn't solve the problem completely. Everytime a user is authenticated and Tomcat binds as that user, their password will fly across the network in plaintext because Tomcat uses simple binds. An attacker just has to listen on the network for long enough and they could pick up all the passwords they wanted. If you would like to be really paranoid, and this takes effort, you could change the way Tomcat binds to the directory. You would just write a custom realm for your needs which would be based upon JNDIRealm. If you have a look in org.apache.catalina.realm.JNDIRealm, you could change the open() method to use a different authentication mechanism. JDK1.4 allows the use of SASL. OpenLDAP can do it if you bolt Cyrus on to the side of it, although I should warn you that its not a fun job and the best you're likely to get right now is DIGEST-MD5 authentication, which doesn't prevent active attacks, and another database of users. Perhaps a simpler change would be to make Tomcat use SSL for all its operations on the directory. Its expensive on the Tomcat and LDAP servers but the code change is tiny, its fairly easy to setup ldap + ssl and it would ensure that those passwords can't be read in transit. I guess it depends upon your personal requirements. Richard Jeremy Prellwitz wrote on Tuesday 09 April 2002: > hmmmm, ......what do you think about a solution that would > prompt for the password on startup? Maybe put a certain > string into the connectionPassword (e.g. "PROMPT"), and then > that would trigger Tomcat to request this input interactively? > > Does this sound reasonable? I've not really stepped into > core project code before, but i'm willing to give it a go. > Could you help me get started by pointing me in the general > direction of the appropriate source? > > Thanks. ---- Original message ---- >Date: Tue, 09 Apr 2002 17:24:04 +0100 >From: John Holman <[EMAIL PROTECTED]> >Subject: Re: Tomcat4 / OpenLDAP - Encrypted connectionPassword in JNDI Realm (server.xml) - Please Help >To: Tomcat Users List <[EMAIL PROTECTED]> > >Hi Jeremy. > >For the JNDI realm to connect to the directory server with administrator >privileges it needs to know the plaintext password. Having a digest in >the config file isn't possible because the realm can't reconstruct the >plaintext password from it. I suppose some other encryption would be >possible, but you'd still need to have the plaintext key for *that* in >some file somewhere, so I doubt it would make much difference. As you >say, having the admin password in the config file is certainly a >security issue, and is one of the disadvantages of the way that the >realm currently included in Tomcat 4.0 operates. > >The new JNDI realm in the CVS HEAD authenticates by binding to the >directory as the user rather than connecting as an administrator and >retrieving the user's password. This normally needs no special >privileges, so no password need be given in the config file. The new >realm is not included in the Tomcat 4.0 releases (so far at least) but I >could send you a jar file to install in server/lib giving the same >functionality for Tomcat 4.0.x if that would help. > >John. -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
