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>
Это позволяет всем пользователям, которые являются членами групп AD учащихся / сотрудников, получать доступ к страницам позади http: // интранет / студенты без необходимости указывать учетные данные для входа при условии, что их IE / Firefox настроены правильно.
UserPrincipalName использовалось вместо sAMAccountName, потому что модуль kerberos передавал имя пользователя @ REALM модулю ldap.
Теперь у меня проблема, когда кто-то не авторизован, ему предоставляют:
Требуется авторизация. Этот сервер не смог проверить, есть ли у вас право доступа к запрошенному документу. Либо вы ввели неправильные учетные данные (например, неверный пароль), либо ваш браузер не понимает, как предоставить необходимые учетные данные.
Кто-нибудь знает, как вызвать диалоговое окно имени пользователя / пароля, чтобы они могли попробовать альтернативные учетные данные? После неудачного получения авторизации единственный способ заставить его запросить учетные данные - это очистить мой кеш. Если я вошел в систему как авторизованный пользователь, но не авторизованный для этого ресурса, у меня нет возможности предоставить альтернативные учетные данные (что может быть хорошо).
Мы столкнулись с очень похожей проблемой. В конце концов мы пришли к выводу, что, хотя интегрированная поддержка входа NTLM в Internet Explorer и Firefox удобна, существует так много исключительных случаев, которые приводят к сбоям, что мы изменили свой подход.
Проблема со встроенной аутентификацией заключается в том, что она работает только в том случае, если текущее имя пользователя и пароль для входа в систему все еще верны и должным образом авторизованы для доступа к ресурсу.
Однако есть и другие обстоятельства, при которых это не работает:
Подход, который мы стандартизировали, заключался в создании веб-страницы для входа в систему с именем пользователя и паролем (перед приложением), которая принимает учетные данные. Когда учетные данные отправлены, приложение, в свою очередь, проверит эти учетные данные в каталоге, а затем ответит соответствующим образом (в мире .NET вы можете использовать проверку подлинности с помощью форм http://msdn.microsoft.com/en-us/library/aa480476.aspx для принудительного доступа к приложению через эту страницу входа). Поскольку приложение выполняет проверку учетных данных, вы получаете обширную информацию о характере ошибки входа в систему. Кроме того, даже если вход в систему прошел успешно, но есть соответствующая информация для отображения пользователю, например их пароль скоро истечет и т. д., это дает возможность сделать это.
ОБНОВЛЕНИЕ: я забыл упомянуть, что если вы примете этот подход, вам нужно будет разрешить анонимный доступ к корню приложения IIS. Это позволит получить доступ к веб-странице входа в систему без предварительной попытки автоматической аутентификации NTLM. Вам решать, оставлять ли вы NTLM-аутентификацию включенной; возможно, вы хотите, чтобы некоторые клиенты продолжали автоматически входить в систему.