☰

Аутентификация приложений Java с использованием Active Directory

tag-icon • tag-icon linux active-directory ldap authentication cas
Аутентификация приложений Java с использованием Active Directory

Я работаю над сторонним 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)

Может кто-нибудь помочь с этой проблемой? Или, возможно, указать правильное направление? Любая помощь будет высоко оценена.

Спасибо.

решение1

Я вижу несколько потенциальных проблем в вашей конфигурации.

ldapContextSource.userDn и .password должны быть учетными данными для учетной записи в AD, которая имеет доступ на чтение всех учетных записей пользователей, которые будут входить в приложение. Они предполагают, что значение .userDn на самом деле будет строкой LDAP DN (похожей на ту, что у вас есть для .searchBase), но для Active Directory вы можете использовать атрибут userPrincipalName (UPN) вместо этого (обычно это[email protected]). Так что ошибка плохих учетных данных может быть просто в том, что вы не квалифицируете имя пользователя ничем. Я всегда предпочитаю использовать UPN для интеграций LDAP, потому что учетную запись можно перемещать в пределах AD, и приложению все равно (в отличие от DN, который изменится).

Если предположить, что это будет работать, ваше значение .filter, скорее всего, также будет проблемой. Хотя атрибут uid существует в Active Directory, он обычно не заполняется по умолчанию. Вам следует изменить его на sAMAccountName, если вы хотите, чтобы пользователи входили в систему только с помощью своего имени пользователя.

Когда вы приступите к включению LDAP через SSL (LDAPS), вам понадобится сертификат TLS на контроллере(ах) домена, которому доверяет приложение Java. Если это самоподписанный сертификат, этот сертификат должен быть отправлен в хранилище ключей, на которое ссылаются его документы. Если это сертификат, сгенерированный из публичной или внутренней инфраструктуры PKI, вам следует вместо этого добавить цепочку сертификатов CA для этой инфраструктуры. Вам также нужно будет изменить URI сервера LDAP на ldapс:// и порт 636 (или 3269 для поиска по глобальному каталогу).

Связанный контент