Jeffrey Janner wrote:
..


Not sure exactly what Windows does once you've entered a verified user/pw 
combination for a service.  I'm guessing that it stores the password somehow, 
because if you change the password, the service won't start next time.


It is stored in whatever format, encrypted or not or hashed or not, in whatever store the Domain Controller uses to store user credentials.
It doesn't matter.
NTLM authentication afterward works using "tokens" which somehow encode the information needed by a server to verify that the client is who it says it is, and the server is who it says it is. The point is that the password is not stored in clear on the client, when "client" means whatever host is trying to authenticate itself. It is of coursee fleetingly in memory at some point, to construct the authentication tokens, but is not kept. Only the token is kept.


However, this is a "nice" (?) feature of using SQL Server.  Already validated 
user credentials can be passed by the OS to SQL Server to be validated for database 
logon.  It's their version of SSO for the database. (Note: I don't find it an 
overwhelming advantage for determining to use that specific database software.)

No it isn't, not in this case.

in the current scenario, the "user" for which there is SSO is the user-id under which the Tomcat process itself is running. It is /not/ the users which connect to Tomcat and run the applications. All these users connect to Tomcat, and are or not authenticated using whatever method Tomcat implements. But then, the credentials used to connect to the database are the credentials of the Tomcat process, not the ones of the users.
That is why is was questioning how much in fact of a security this brings.
The problem is merely moved, to the level of how users authenticate with the Tomcat application. Once they have done that, they can access any information which is accessible by this Tomcat user.


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

Reply via email to