Differences between revisions 18 and 19

Deletions are marked like this. Additions are marked like this.
Line 139: Line 139:
 * На текущий момент для реализации NTLM аутентификации используется библиотека jcifs http://jcifs.samba.org. Библиотека JCIFS предназначена для реализации файлового обмена по протоколам CIFS и SMB  * На текущий момент для реализации NTLMv1 аутентификации используется библиотека jcifs http://jcifs.samba.org. Библиотека JCIFS предназначена для реализации файлового обмена по протоколам CIFS и SMB
Line 143: Line 143:
 * Библиотека JCIFS, которой мы пользуемся для NTLM аутентификации заявила, что NTLM в новых версиях поддерживаться не будем. Выяснено, что с версии jcifs-1.3.12 не работает. Вот что пишут на сайте http://jcifs.samba.org/src/docs/ntlmhttpauth.html  * Библиотека JCIFS, которой мы пользуемся для NTLM аутентификации заявила, что NTLMv1 в новых версиях поддерживаться не будет. Выяснено, что с версии jcifs-1.3.12 не работает. Поэтому не стоит ее обновлять. Вот что пишут на сайте http://jcifs.samba.org/src/docs/ntlmhttpauth.html

NTLM HTTP Аутентификатор

В данный момент не поддерживает NTLMv2. Только сессионную безопаность NTLMv2 (NTLMv2 Session security). Это не одно и то же.

NTLMHTTPAuthenticator - это HTTP аутентификатор. Это значит, что он не требует от пользователя ввода логина и пароля на форме при входе в систему. Необходимая информация передаётся в заголовках http-запроса.

Актуальная реализация - в классе ru.naumen.core.authentication.NtlmHttpAuthenticator2

Примечание: в SD версии 2007_07_10 используйте класс ru.naumen.core.authentication.ext.NtlmHttpAuthenticator2 из модуля kernel/bk.ldapauth

Принцип работы

NTLM - это протокол аутентификации Microsoft для windows-сетей.

Описание NTLM-аутентификации в MSDN

Более полное описание

Самое подробное описание

Если коротко и по-русски:

  1. Пользователь входит в ОС, вводя логин и пароль. ОС вычисляет хэш от пароля и сохраняет его. Хэш - это результат необратимого преобразования, т.е. даже зная функцию, по которой из пароля получается хэш, получить из хэша пароль невозможно иначе, как прямым перебором.
  2. Пользователь набирает в браузере адрес приложения, браузер запрашивает страницу.
  3. Приложение ищет в заголовках заголовок "Authorization", не находит, отказывает в получении страницы и просит аутентифицироваться, выставляя в ответе заголовок "WWW-Authenticate: NTLM".
  4. Клиент (браузер) снова запрашивает страницу, но уже с заголовком "Authorization", в котором передаёт имя пользователя.
  5. Приложение генерирует случайную строку - challenge - и отсылает её клиенту.
  6. Клиент шифрует challenge при помощи хэша пароля пользователя и отправляет результат f(hash, challenge) приложению.
  7. Приложение отправляет имя пользователя, challenge и хэш пароля домен-контроллеру.
  8. Домен-контроллер по имени пользователя находит у себя хэш его пароля, выполняет преобразование f(hash, challenge) и сравнивает с переданным клиентом через приложение. Если результаты совпадают, то всё хорошо и пользователь прошёл проверку.

Все эти сложности нужны для того, чтобы не передавать пароль в открытом виде по сети и не доверять его приложению.

Есть и проблемы. Кажется, что challenge может быть любым. На самом деле, приложение получает его у домен-контроллера, т.к. домен-контроллер отказывает в аутентификации, если challenge был выдан не им. Поэтому домен-контроллер должен быть определён уже на шаге 5.

Порядок определения домен-контроллера:

  • По параметру ru.naumen.core.authentication.ntlm-http-authenticator.default-domain в файле bk-auth-config.properties.

  • По параметру ru.naumen.core.authentication.ntlm-http-authenticator.domain-controller в файле bk-auth-config.properties.


Настройка IE

Для работы требуется настроить браузер.

Главное меню IE

  • Сервис
  • Свойства обозревателя
  • Безопасность
  • Надежные узлы
  • Узлы...
  • Добавить узел в зону (заполнить адресом сервера с продуктом Naumen)
  • Добавить
  • OK
  • Уровень безопасности для этой зоны
  • Другой...
  • Проверка подлинности пользователя
  • Вход
  • Автоматический вход в сеть с текущим именем ползователя и паролем
  • OK


Настройка продукта

В файле bk-auth-config.properties.

# Http authenticator class name (some implementation of IHttpAuthenticator)
# e.g. "ru.naumen.core.authentication.BasicHttpAuthenticator" | "ru.naumen.core.authentication.NtlmHttpAuthenticator"
ru.naumen.core.authentication.http-authenticator=ru.naumen.core.authentication.NtlmHttpAuthenticator2

...

####################
# NTLM Authenticator settings
#

# Default domain' name
# Если указать полное имя домена, то домен-контроллер будет определяться автоматически
ru.naumen.core.authentication.ntlm-http-authenticator.default-domain=office1.naumen.ru

# Domain controller, ip address of domain controller
ru.naumen.core.authentication.ntlm-http-authenticator.domain-controller=192.168.210.6

# Default domain user, uses to create one session for all authentifications.
# see jcifs.smb.client.username / jcifs.smb.client.password properties

#ru.naumen.core.authentication.ntlm-http-authenticator.username=<default session username>
#ru.naumen.core.authentication.ntlm-http-authenticator.password=<default session password>

Домен пользователя в приложение может передаваться либо полным именем, либо коротким. Как это настраивается - выяснить пока не удалось. Желательно, чтобы пользователи в системе должны быть заведены с доменами в том виде, в котором они передаются при NTLM аутентификации. При необходимости, может быть проведена дополнительная настройка соответствия передаваемых имен доменов хранимым в базе данных системы.

В файле ntlm-rules-config.xml (kernel/bk/config/ntlm-rules-config.xml) есть возможность указать соответствия названий доменов. Например:

<ntlm-rules xmlns="http://naumen.ru/xmlschema/core/ntlm-rules-config/">
    <!-- правила соответствия доменов, поступающих с клиентских мест и учитываемых в системе -->
     <domain-accordance-rule userDomain="MYDOMAIN" systemDomain="my.domain.local" />
</ntlm-rules>

В данном примере: если в системе происходит попытка авторизации пользователя username@MYDOMAIN , то при положительном ответе контроллера домена будет сделана попытка найти в системе не только пользователя username@MYDOMAIN , но и username@my.domain.local . Кроме того, будет сделана попытка найти данного пользователя дефолтным доменом (указан в файле bk-auth-config.properties в параметре ru.naumen.core.authentication.ntlm-http-authenticator.default-domain) Заметим, что в данный момент эти правила распространяются ТОЛЬКО на поиск пользователя внутри нашей системы по логину и домену, т.е. на процедуру идентификации пользователя. Процедура аутентификации (проверка пароля) не изменялась и происходит целиком по данным из ntlm-сообщения.

Сейчас мы знаем несколько вариантов, которые приводят к подобным несоответствиям:

  1. сокращение полного имени домена. Например, может быть передано username@my вместо username@my.domain.local

  2. передача NetBIOS имени вместо DNS-имени или наоборот. Например, username@MYDOMAIN вместо username@my.domain.local

  3. передача неверного NetBIOS имени. username@SOMEDOMAIN вместо username@MYDOMAIN

Параметры ru.naumen.core.authentication.ntlm-http-authenticator.username и ru.naumen.core.authentication.ntlm-http-authenticator.password позволяют указать логин/пароль пользователя, который будет использоваться для т.н. preauthentification. См. использование параметров jcifs.smb.client.username / jcifs.smb.client.password библиотеки jCIFS. Например, тут. Установка этих параметром может помочь при возникновении сетевых ошибок при работе аутентификатора (невозможность установить соединение с AD сервером, например).

Для входа в систему с идентификацией через NTLM необходимо заходить через следующий URL: <адрес:порт сервера>/fx/bk/ru.naumen.core.ui.start_jsp

Чтобы ссылки на объекты системы открывались с прозрачной идентификацией пользователя через NTLM, необходимо в активаторе клиентского бандла запускать следующую команду:

//change login page for ntlm authentication works
String loginPagePath = "$bk/ru.naumen.core.ui.start_jsp";
ru.naumen.guic.logincheck.LoginCheckFacade.setPathToLoginPage(loginPagePath);

либо в файле sd-ldapsync-config.properties (только для клиентов с модулем sd.ldapsync) задать параметр sd.ldapsync.start-page (эта настройка должна быть перенесена в bk).

Тогда, в случае, если пользователь еще не залогинился в систему и запрашивает карточку какого-то объекта, он будет перенаправляться на страницу $bk/ru.naumen.core.ui.start_jsp, где произойдет его идентификация и отсыл обратно на запрашиваемую карточку.

achernin: добавлена возможность входа в систему с ntlm-аутентификацией через традиционную login.jsp

NTLMv1, NTLMv2 - способы реализации

  • На текущий момент для реализации NTLMv1 аутентификации используется библиотека jcifs http://jcifs.samba.org. Библиотека JCIFS предназначена для реализации файлового обмена по протоколам CIFS и SMB

JCIFS is an Open Source client library that implements the CIFS/SMB networking protocol in 100% Java
  • Библиотека JCIFS, которой мы пользуемся для NTLM аутентификации заявила, что NTLMv1 в новых версиях поддерживаться не будет. Выяснено, что с версии jcifs-1.3.12 не работает. Поэтому не стоит ее обновлять. Вот что пишут на сайте http://jcifs.samba.org/src/docs/ntlmhttpauth.html

IMPORTANT: All HTTP related code and corresponding documentation in JCIFS is not supported, no longer maintained and will be removed because it is broken and obsolete (and because HTTP has nothing to do with CIFS).

Jespa is a Java software library that provides advanced integration between Microsoft Active Directory and Java applications.

Если по каким то причинам клиентов не будет устраивать Kerberos можнож вернуться к теме NTLM2 и реализовать аутентификатор на базе Jespa

Реализация

  • На текущий момент NTLM авторизация реализована внутри нашего приложения
  • Существуют Open Source библиотеки, которые реализуют авторизацию с момощью Filter Tomcat. Фильтры указываются в web.xml. В request уже будет приходить имя пользователя. Примером такой библиотеки является spnego http://spnego.sourceforge.net/index.html

NTLM и Windows Vista

По умолчанию в Висте включено использование только NTLMv2, который не поддерживается.

Решение, которое помогло:

Control Panel -> System Maintenance -> Administrative Tools (run as administrator) -> Local Security Policies -> Local Policies -> Security Options

  1. Find the Policy Key named Network Security : LAN Manager Authentication Level
  2. Set the value to "Send LM and NTLM responses" or - and it seems to make the most sense -"Send LM & NTLM - use NTLMv2 session security if negotiated"

This also can be done by making a change in the Windows Vista registry

  1. Run the registry editor and open this key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa
  2. If it doesn't already exist, create a DWORD value named LmCompatibilityLevel

  3. Set the value to 1
  4. Reboot

Naumen Kernel Doc/bk/Authentication/NTLMHTTPAuthenticator (last edited 2009-11-10 07:10:21 by alikulin)