Multi- authentication scenario for a public internet service using Kerberos
Posted
by
StrangeLoop
on Server Fault
See other posts from Server Fault
or by StrangeLoop
Published on 2012-12-01T20:51:37Z
Indexed on
2012/12/01
23:06 UTC
Read the original article
Hit count: 239
I have a public web server which has users coming from internet (via HTTPS) and from a corporate intranet.
I wish to use Kerberos authentication for the intranet users so that they would be automatically logged in the web application without the need to provide any login/password (assuming they are already logged to the Windows domain).
For the users coming from internet I want to provide traditional basic/form- based authentication. User/password data for these users would be stored internally in a database used by the application.
Web application will be configured to use Kerberos authentication for users coming from specific intranet ip networks and basic/form- based authentication will be used for the rest of the users.
From a security perspective, are there some risks involved in this kind of setup or is this a generally accepted solution?
My understanding is that server doesn't need access to KDC (see Kerberos authentication, service host and access to KDC) and it can be completely isolated from AD and corporate intranet. The server has a keytab file stored locally that is used to decrypt tickets sent by the users coming from intranet. The tickets only contain username and domain of the incoming user. Server never sees the passwords of authenticated users.
If the server would be hacked and the keytab file compromised, it would mean that attacker could forge tickets for any domain user and get access to the web application as any user. But typically this is the case anyway if hacker gains access to the keytab file on the local filesystem.
The encryption key contained in the keytab file is based on the service account password in AD and is in hashed form, I guess it is very difficult to brute force this password if strong Kerberos encryption like AES-256-SHA1 is used. As the server has no network access to intranet, even the compromised service account couldn't be directly used for anything.
© Server Fault or respective owner