Alias /students /var/www/students
<Location /students>
KrbServiceName HTTP
KrbMethodNegotiate On
KrbMethodK5Passwd On
KrbSaveCredentials off
KrbAuthRealms DOMAIN.LOCAL
Krb5KeyTab /etc/httpd/keytab
KrbAuthoritative off
AuthType Kerberos
AuthName "Please Login"
AuthBasicProvider ldap
AuthzLDAPAuthoritative on
AuthLDAPURL "ldap://dc.domain.local:389/OU=Domain Users,DC=domain,DC=local?userPrincipalName?sub?(objectClass=*)"
AuthLDAPBindDN "CN=ldapsearchuser,CN=Users,DC=domain,DC=local"
AuthLDAPBindPassword ldapsearchuserpass
require ldap-group CN=Students,CN=Users,DC=domain,DC=local
require ldap-group CN=Staff,CN=Users,DC=domain,DC=local
</Location>
This allows all users who are members of either the Students/Staff AD groups access to pages behind http://intranetsite/students without needing to specify login credentials provided their IE/Firefox are configured properly.
The userPrincipalName was used instead of sAMAccountName because the kerberos module was passing the username@REALM to the ldap module.
Now I have the problem where if someone isn't authorized they are presented with:
Authorization Required This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required.
Does anyone know how to have it pop up a username/password dialog box so they could try alternate credentials? After unsuccessfully gaining authorization, the only way I can get it to ask for credentials is to clear out my cache. If I am logged in to the PC as an authenticated user but one that isn't authorized to this resource I have no way of suppying alternate credentials (which may be a good thing).
Best Answer
We faced a very similar problem. We eventually concluded that while integrated NTLM logon support in Internet Explorer and Firefox is convenient, there are so many exception cases which result in failure that we changed our approach.
The problem with integrated authentication is that it works only when the currently logged on username and password are still correct and properly authorized to access the resource.
There are more circumstances where it doesn't work however:
The approach we standardized on was to put up a username/password logon web page (in front of the application) which accepts the credentials. When the credentials are submitted, the application would in turn validate those credentials against the directory and then respond accordingly (in a .NET world you could use Forms Authentication http://msdn.microsoft.com/en-us/library/aa480476.aspx to force access to the application via this login page). Since the application is doing the credential validation, you get rich information as to the nature of the login failure. In addition, even if the login succeeds but there's relevant information to display to the user, e.g. their password will expire shortly, etc., this provides an opportunity to do so.
UPDATE: I forgot to mention that if you adopt this approach, you'll need to allow anonymous access to the IIS application root. This will allow access to the login web page without first attempting the automatic NTLM authentication. It's up to you whether you leave NTLM authentication enabled; perhaps you do want some clients to still automatically log in.