tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From הילה <hilavalen...@gmail.com>
Subject Re: Tomcat NTLM Authentication
Date Mon, 07 Mar 2011 07:06:55 GMT
Hey,

The tomcat is running on windows server 2008 R2 STD
I don't now if using windows authentication is less secure and affects all
network's security, since this user have permissions only on the DB. you
can't even perform login to servers with this user.
anyway, I appreciate your comments and discussion of why it's less secure or
not, but I need to perform this (task I've been given from guys in high
above positions), so please help with what I'm trying to do :]

If I can't use spnego and other stuff of the list i've found, what can I do?

Thanks
Hila


2011/3/6 André Warnier <aw@ice-sa.com>

> ???? wrote:
>
>> Hey,
>>
>> I want to change the way that tomcat authenticates to the DB of our
>> application, from SQL authentication to Windows authentication.
>> We use Tomcat 6.0.29 , and the user and password to connect to the DB is
>> specified in clear text in the xml configuration file under the folder
>> conf/catalina/localhost.
>> My goal is to remove the user and password from the xml file, and letting
>> the tomcat windows service run with a domain user that has permissions to
>> the DB.
>>
>> when I searched for a solutions for what i'm trying to do, i got to this
>> page-
>> http://wiki.apache.org/tomcat/FAQ/Windows#Q4
>>
>> Which suggest these methods:
>> -Waffle/JNA
>> -Tomcat SPNEGO
>> -SPNEGO SF
>> -Jespa (commercial)
>> -Tomcat IIS Connector
>> -Samba JCIFs (obsolete, no NTLMv2)
>>
>> Are one of these methods suit for what I'm trying to do?
>> When reading about Tomcat SPNEGO, it says that users working on a windows
>> client OS and IE or Firefox, can be silently authenticated (SSO) to a
>> Tomcat
>> running on a windows server via NTLM or kerberos. It doesn't seem to be
>> what
>> I aim for, since tomcat users are not interest me, only the tomcat windows
>> service and how it connects to the DB
>>
>>  Exactly. Now you have the issue correctly framed.
> And you are right above : all these methods indeed identify/authenticate
> the client of the Tomcat application to Tomcat, not Tomcat itself to
> something else. (**)
>
> The one thing missing in your description above, is that your Tomcat server
> is running on a Windows machine.
> And also that your back-end database system is able itself to perform user
> authentication either in clear-text (user-id + password), or via Windows
> NTLM authentication.
>
> (And, if the back-end database server is set to do NTLM authentication,
> then it can only do so for Domain user-id's; NTLM authentication will not
> work with a "server-local" user-id).
>
>
> So now you have to make one additional effort of thinking rationally, and
> answer the following fundamental question : why ?
>
> I mean, what exactly is the problem with having a user-id and a password
> for the database, in clear in a Tomcat configuration file ?  Are there users
> that can connect to the Tomcat server, and read those configuration files,
> and which should not be able to do so ?
>
> And if that is the case, can you not do something like :
>
> a) either block these users from accessing the Tomcat server (the best
> solution)
> OR
> b)
> - start Tomcat under some Windows user-id (with password)
> - set the permissions of the Tomcat configuration files, so that *only*
> this user-id can read them ?
>
>
> Various people have previously tried to point out different aspects which
> remain true, among which :
> 1) encrypting something is often a chicken-and-egg kind of problem : if you
> encrypt something, then you need to decrypt it somewhere else; and the key
> to decrypt it has to be stored somewhere also. And so on..
> 2) in terms of security, it is much better to run Tomcat under a "server
> local" user-id than as a Domain user-id.  That is because the local user-id
> only gives access to the local machine, while a domain user-id gives access
> to the whole domain.
> By running Tomcat as a domain user, you decrease the security of the whole
> network.
> 3) security is always a matter of multiple layers of defense.  In this
> case, your first line is to prevent unauthorised people to access the Tomcat
> configuration files.
> Because if they can do that, then they can break through any other security
> that you would put in place.  Think about it : no matter how, Tomcat needs
> access to the DB. If Tomcat has access to the the DB, then any user who can
> control Tomcat can access the DB. (*)
> 4) your second line of defense, would be that the DB server only accepts
> connections from Tomcat.  This way, if someone can get hold of the user-id
> of Tomcat, at least they cannot use it to access the DB directly.
>
>
> (*) Suppose Tomcat runs under domain user-id XYZ, with a very secret
> password.
> If I can get access to the Tomcat configuration files, then I can also
> install any Tomcat application somewhere, and make Tomcat run it.
> And this application will run under the Tomcat user-id, even if I do not
> know what this user-id is.  So this application could for example dump the
> whole database in some network directory of my choice (and then, if I am
> really a bad guy, delete the database too).
>
>
> (**) unless you want real security of access to the DB, and have the Tomcat
> application make its own connection to the DB, and authenticate to the DB as
> the final user of the application.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message