Я работаю над сторонним Java-приложением, для которого мне нужно аутентифицировать пользователей с помощью Active Directory.
Это приложение размещено на RHEL 6.5 и использует LDAP для аутентификации в Windows Active Directory. Сервер AD настроен и отлично работает с более ранней версией приложения (которая была настроена для включения интеграции).
Для более новой версии поставщик изложил некоторые шаги по изменению / настройке файлов приложения для подключения к серверу AD, которые, как ожидается, помогут нам аутентифицироваться.
Приложение имеет один из своих компонентов как CAS, который в настоящее время настроен на использование базы данных в качестве обработчика аутентификации. Когда мы вводим учетные данные - имя пользователя: abcd, пароль: samplepswd, мы можем успешно войти в систему.
Поскольку бизнес-требование заключается в аутентификации в Active Directory с использованием LDAP, мы должны изменить файл свойств CAS. В соответствии с инструкциями поставщика продукта мы изменили следующие свойства, чтобы использовать ldap:
authenticationHandler.type=ldap
ldapSSLConfig.enabled=false
ldapContextSource.url=ldap://sample.ADserver.example.net:389
ldapContextSource.userDn=abcd
ldapContextSource.password=samplepswd
ldapAuthenticationHandler.filter=uid=%u
ldapAuthenticationHandler.searchBase=OU=DEF,OU=PQR,OU=XYZ,DC=ADserver,DC=example,DC=net
Нам также необходимо внести изменения в xml-файл casAuthConfig для следующих свойств (поскольку анонимный поиск не поддерживается): 1. anonymousReadOnly, значение установлено на false 2. java.naming.security.authentication, значение установлено на simple
Также предусмотрено использование ldap через SSL, но в настоящее время мы его не используем. Однако, если мы все же используем SSL, необходимо внести дополнительные изменения в следующие свойства:
ldapSSLConfig.enabled=true
ldapSSLConfig.trustStorePath=/home/dir1/subdir1/subdir2/keystorename.keystore
ldapSSLConfig.trustStoreType=jceks
Это единственные изменения конфигурации, сделанные на нашей (клиентской) стороне; и собственно только изменения сделаны. На сервере (сервере AD) ничего не было добавлено / изменено, кроме другого пользователя, но это не повлияло на существующие настройки.
После перезапуска cas для отражения изменений мы обнаруживаем ошибку неверных учетных данных, хотя введенные значения верны:
2015-09-16 12:12:30,558 INFO [com.pqr.cas.authentication.support.DelegatingAuthenticationHandler] - Authenticating credential using handler
com.pqr.cas.adaptors.ldappwd.BindLdapAuthenticationHandler
2015-09-16 12:12:30,558 DEBUG [com.pqr.cas.authentication.support.DelegatingAuthenticationHandler] - credentials.getUsername() = abcd
2015-09-16 12:12:30,672 INFO [com.pqr.cas.adaptors.ldappwd.BindLdapAuthenticationHandler] - Search for cn=abcd returned 0 results.
2015-09-16 12:12:30,672 INFO [org.jasig.cas.authentication.AuthenticationManagerImpl] - AuthenticationHandler:
com.pqr.cas.authentication.support.DelegatingAuthenticationHandler failed to authenticate the user which provided the following credentials:
[username: abcd]
2015-09-16 12:12:30,676 ERROR [org.jasig.cas.integration.restlet.TicketResource] - error.authentication.credentials.bad
org.jasig.cas.ticket.TicketCreationException: error.authentication.credentials.bad
at org.jasig.cas.CentralAuthenticationServiceImpl.createTicketGrantingTicket_aroundBody10(CentralAuthenticationServiceImpl.java:423)
Кто-нибудь может помочь с этой проблемой? Или, возможно, указать в правильном направлении? Любая помощь будет принята с благодарностью.
Спасибо.
Я вижу несколько потенциальных проблем в вашей конфигурации.
ldapContextSource.userDn и .password должны быть учетными данными для учетной записи в AD, которая имеет доступ для чтения всех учетных записей пользователей, которые будут входить в приложение. Они предполагают, что значение .userDn на самом деле будет строкой DN LDAP (аналогично тому, что у вас есть для .searchBase), но для Active Directory вместо этого вы можете использовать атрибут userPrincipalName (UPN) (обычно это username@example.net). Таким образом, ошибка неверных учетных данных может заключаться в том, что вы ничего не квалифицируете для имени пользователя. Я всегда предпочитаю использовать UPN для интеграции LDAP, потому что учетную запись можно перемещать в AD, а приложение не заботится (в отличие от DN, которое может измениться).
Предполагая, что это сработает, ваше значение .filter, вероятно, также будет проблемой. Хотя атрибут uid существует в Active Directory, он обычно не заполняется по умолчанию. Вам следует изменить его на sAMAccountName, если вы хотите, чтобы пользователи входили в систему только со своим именем пользователя.
Когда вы дойдете до включения LDAP через SSL (LDAPS), вам понадобится сертификат TLS на контроллере (ах) домена, которому доверяет приложение Java. Если это самозаверяющий сертификат, этот сертификат нужно будет поместить в хранилище ключей, на которое ссылаются их документы. Если это сертификат, созданный из общедоступной или внутренней инфраструктуры PKI, вам следует вместо этого добавить цепочку сертификатов CA для этой инфраструктуры. Вам также необходимо изменить URI сервера LDAP на ldap.s: // и порт 636 (или 3269 для поиска в глобальном каталоге).