- NTLM аутентификация в Firefox
- Mozilla Firefox & NTLM/Kerberos Single Sign-on (SSO)
- Configuring Chrome and Firefox for Windows Integrated Authentication
- Configuring Delegated Security for Mozilla Firefox
- Configuring Delegated Security in Google Chrome
- To use the command line to configure Google Chrome
- To modify the registry to configure Google Chrome
- To use ADM/ADMX templates through Group Policy to configure Google Chrome
- GSSAPI и Firefox/Thunderbird для сквозной авторизации в Windows
NTLM аутентификация в Firefox
Если вы, как и я для работы с web предпочитаете использовать браузер Firefox, вероятно вы уже сталкивались с неудобствами при доступе вашим любимым браузером к различным интернет сервисам, использующих механизм аутентификации Windows — NTLM (это могут быть, например, портал Sharepoint, внутренний сайт с аутентификацией в AD и т.д.). При доступе к таким сайтам Firefox каждый раз предлагает вам ввести пару: имя пользователя windows и пароль (Internet Explorer в таких случаях аутентифицируется на таких сайтах прозрачно, без необходимости ввода пароля). К счастью, Firefox поддерживает сквозную (pass through) аутентификацию на сайтах, поддерживающих авторизацию NTLM (естественно пользователь должен быть залогинен в системе и иметь права доступа на интересующем его сайте.).
- Запустите Firefox и в адресной строке введите about:config и нажмите ENTER
- Согласитесь с тем предупреждением о потенциальной угрозе, которую можно вызвать некорректной настройкой параметров браузера.
- В строке фильтров укажите ключевой слово NTLM, в результате чего перед вами останется три параметра, нас интересует параметр network.automatic-ntlm-auth.trusted-uris.
- Дважды щелкнув по данному параметру, откроется окно с текстовым полем, куда можно внести список URL (через запятую), для которых будет поддерживаться автоматическая сквозная NTLM аутентификация. Формат такой: _http://web.winitpro.ru, _ftp://siteftp.winitpro.ru. Если необходимо добавить все сайты в домене (обычно это внутренний корпоративный домен), нужно указать: .winitpro.ru
Кстати, рекомендую познакомиться со статьей, описывающей проблемы NTLM аутентификации Windows 7 на Squid .
Mozilla Firefox & NTLM/Kerberos Single Sign-on (SSO)
При попытке открыть в Mozilla Firefox внутренние корпоративные сайты на SharePoint Server с включённой аутентификацией Kerberos получил запрос на ввод имени пользователя и пароля. То есть прозрачная передача учетных данных текущего пользователя, как в Internet Explorer, не произошла. Просмотрел все доступные опции в меню навигации Firefox «Инструменты» > «Настройки«, но с к сожалению не нашёл там ничего, касающегося безопасности передачи учетных данных текущего пользователя. После некоторых поисков в Интернете, обнаружил, что способ передачи учётных данных всё-таки имеется.
В адресной строке Firefox набираем about:config и принимаем предупреждение о том, что неправильная настройка параметров может привести к некорректной работе браузера.
Перед нами предстанет внушительный список настроек. В поле «Фильтр» введём negotiate, после чего в окне настроек отобразятся интересующие нас два параметра:
Двойным кликом откроем свойства этих параметров и введём в поле значения имя локального домена, в рамках которого мы хотим прозрачно передавать учетные данные пользователя.
Если необходимо указать несколько доменов, то их имена можно вводить через запятую.
После настройки браузер потребуется перезапустить, чтобы изменения вступили в силу и механизмы SSO заработали.
Если настройка двух указанных выше параметров обязательна в случае использования Kerberos аутентификации, то для NTLM аутентификации нужно настраивать параметр:
network.automatic-ntlm-auth.trusted-uris
Помимо настройки SSO в корпоративных средах для Firefox может оказаться полезным включение возможности использования встроенного в ОС Windows хранилища корневых сертификатов. Эта возможность имеется в браузерах Firefox 49 и выше.
Configuring Chrome and Firefox for Windows Integrated Authentication
Mar 14, 2017 (Last updated on February 5, 2021)
Windows Integrated Authentication allows a users’ Active Directory credentials to pass through their browser to a web server. Windows Integrated Authentication is enabled by default for Internet Explorer but not Google Chrome or Mozilla Firefox. Users who use the non-Microsoft browsers will receive a pop-up box to enter their Active Directory credentials before continuing to the website. This adds additional steps and complexity for users who are using web based applications like self-service password reset solutions Specops uReset and Specops Password Reset. In an effort to make this process as easy as possible for end-users, many IT administrators enable Windows Integrated Authentication for the third party browsers. This can be done with Chrome and Firefox with a few additional steps. This article will show you how to enable Windows Integrated Authentication for Google Chrome and Mozilla Firefox.
Configuring Delegated Security for Mozilla Firefox
To configure Firefox to use Windows Integrated Authentication:
2. In the address bar type about:config
3. You will receive a security warning. To continue, click I’ll be careful, I promise.
4. You will see a list of preferences listed. Find the settings below by browsing through the list or searching for them in the search box. Once you have located each setting, update the value to the following:
Setting | Value |
---|---|
network.automatic-ntlm-auth.trusted-uris | MyIISServer.domain.com |
network.automatic-ntlm-auth.allow-proxies | True |
network.negotiate-auth.allow-proxies | True |
** MyIISServer.domain.com should be the fully qualified name of your IIS server that you are setting up the Windows Integrated Authentication to.
Negotiate authentication is not supported in versions of Firefox prior to 2006.
Configuring Delegated Security in Google Chrome
Note: The latest version of Chrome uses existing Internet Explorer settings. Older version of Chrome require additional configurations (see below).
You can use three methods to enable Chrome to use Windows Integrated Authentication.Your options are the command line, editing the registry, or using ADMX templates through group policy. If you choose to use the command line or edit the registry, you could use Group Policy Preferences to distribute those changes on a broader scale. Below are the steps for the three methods:
To use the command line to configure Google Chrome
Start Chrome with the following command:
Chrome.exe –auth-server-whitelist=”MYIISSERVER.DOMAIN.COM” –auth-negotiate-delegatewhitelist=”MYIISSERVER.DOMAIN.COM” –auth-schemes=”digest,ntlm,negotiate”
To modify the registry to configure Google Chrome
Configure the following registry settings with the corresponding values:
Data type: String (REG_SZ)
Windows registry location: Software\Policies\Google\Chrome\AuthSchemes
Mac/Linux preference name : AuthSchemes
Supported on: Google Chrome (Linux, Mac, Windows) since version 9
Supported features: Dynamic Policy Refresh: No, Per Profile: No
Description: Specifies which HTTP Authentication schemes are supported by Google Chrome. Possible values are ‘basic’, ‘digest’, ‘ntlm’ and ‘negotiate’. Separate multiple values with commas. If this policy is left not set, all four schemes will be used.
Data type: String (REG_SZ)
Windows registry location : Software\Policies\Google\Chrome\AuthServerWhitelist
Mac/Linux preference name : AuthServerWhitelist
Supported on : Google Chrome (Linux, Mac, Windows) since version 9
Supported features : Dynamic Policy Refresh: No, Per Profile: No
Description : Specifies which servers should be whitelisted for integrated authentication. Integrated authentication is only enabled when Google Chrome receives an authentication challenge from a proxy or from a server which is in this permitted list. Separate multiple server names with commas. Wildcards (*) are allowed. If you leave this policy not set Chrome will try to detect if a server is on the Intranet and only then will it respond to IWA requests. If a server is detected as Internet then IWA requests from it will be ignored by Chrome.
Data type: String (REG_SZ)
Windows registry location : Software\Policies\Google\Chrome\AuthNegotiateDelegateWhitelist
Mac/Linux preference name : AuthNegotiateDelegateWhitelist
Supported on : Google Chrome (Linux, Mac, Windows) since version 9
Supported features : Dynamic Policy Refresh: No, Per Profile: No
Description: Servers that Google Chrome may delegate to. Separate multiple server names with commas. Wildcards (*) are allowed. If you leave this policy not set Chrome will not delegate user credentials even if a server is detected as Intranet.
Example Value: ”MYIISSERVER.DOMAIN.COM”
To use ADM/ADMX templates through Group Policy to configure Google Chrome
1. Download Zip file of ADM/ADMX templates and documentation from: http://www.chromium.org/administrators/policy-templates.
2. Add the ADMX template to your central store, if you are using a central store.
3. Configure a GPO with your application server DNS host name with Kerberos Delegation Server Whitelist and Authentication Server Whitelist enabled.
Each of these three methods achieve the same results for configuring Google Chrome for Windows Integrated Authentication. The method that is best for you will depend on how your organization is set up. Personally, I would use the command line or the registry if you are deploying across an enterprise. You can easily distribute a shortcut on the user’s desktop with the command and distribute that with Group Policy preferences. If you choose to use the registry method, that is able to be distributed with Group Policy.
With a variety of third-party browsers available, many users will receive a pop-up box to enter their Active Directory credentials before continuing to an IIS hosted web application. This leads to additional steps, complexity and confusion for many end-users. By setting up Windows Integrated Authentication into Chrome and Firefox, you will be able to give your users the greatest amount of flexibility for their choice of browser as well as ease of use with your web-based applications.
Making everyday IT tasks easier for end users and IT admins is something we specialize in. Our self-service password reset solution Specops uReset guarantees end user adoption thanks to its flexible approach to multi-factor authentication.
GSSAPI и Firefox/Thunderbird для сквозной авторизации в Windows
Ваша машина находиться Windows домене и вы хотите использовать единую авторизацию например на прокси и почтовом сервере. Для того чтобы включить в Firefox использование сквозной авторизации вам нужно отредактировать 2 ключа на странице about:config.
- network.negotiate-auth.delegation-uris = https://,http://
- network.negotiate-auth.trusted-uris = https://,http://
Если вы хотите использовать Kerberos для авторизации на IIS то достаточно включить «интегрированую авторизацию», но т.к. при установке IIS Windows не создает service principal name (SPN), вам его придеться создать самому иначе Firefox будет использовать NTLM через GSSAPI.
Для редактирования principial’ов вам потребуеться Windows Support tools и утилита setspn.exe. Что бы добавить новый SPN вам нужно будет ввести setspn -A HTTP/FQDN имя_машины_для_которой_создаем SPN, где FQDN адресс вашего IIS-сервера.
Вы так же можете посмотреть список всех SPN, setspn -L имя_машины. Стоит обратить внимание, чтобы вы обращались именно по адресу FQDN иначе Kerberos не найдет SPN, регистр букв важен. Или вы можете это сделать вручную используя любой редактор LDAP, adsiedit.msc, AD explorer, ldap admin и т.п. Просто найдите объект компьютера для которого вы хотите создать SPN, CN=SERVER,OU=Domain Controllers,DC=inblock,DC=local и в его атрибутах вы найдете servicePrincipalName.
В случае с Thunderbird’ом вам лишь нужно указать галку «use secure authentication» поле User name не требуеться. На данный момент Firefox и Thunderbird, не показывают никаких ошибок в том случае если Kerberos билет не удалось получить по каким либо причинам, например из-за отсуствия SPN. Поэтому проверить можно только используя снифер, например Wireshark.
Windows использует SSPI закрытый аналог GSSAPI, но смысл имеет одинаковый поэтому я его везде называю GSSAPI.
У вас есть почтовый сервер на UNIX машине? Создайте в AD учетную запись пользователя(пароль не важен) с именем UNIX машины. Используя утилиту ktpass из набора support tools, создадим keytab файл. ktpass -princ imap/debian.inblock.local@inblock.local -mapuser debian +rndpass -ptype KRB5_NT_SRV_HST -out imap.keytab. На UNIX машине не забываем указать DNS сервер домен контроллера. В /etc/krb5.conf
[libdefaults]
default_realm = INBLOCK.LOCAL
И проверерим что у нас корректное FQDN имя у машины — hostname -f. Остаеться только настроить сам сервер на использование GSSAPI вот например инструкция для Dovecot, она заключаеться только во включении этого режима.
GSSAPI, WTF?!
GSSAPI это набор интерфейсов которые задают стандартный набор функции — запросить билет, продлить билет и т.п. GSSAPI являеться посредником между Программой и KDC сервером ну или kerberos протоколом проще говоря.
Он был разработан, чтобы навести порядок т.к. когда он появился существовали разные реализации Kerberos (как и сейчас, MIT и Heimdal) они были несовместимы с друг другом. GSSAPI может использован не только для Kerberos, хотя это самое популярное использование его. Допустим Microsoft разработает новый UltraMegaMSsecure protocol и добавляет ему механизмы вызова через GSSAPI(SSPI), любая программа которая умеет работать с GSSAPI сможет использовать этот новый протокол. Это позволяет избавить разработчика программы во первых понимать как работет авторизация, а во вторых его программа будет работать даже если выйдет новая версия Kerberos10 ;).
К примеру именно через GSSAPI(SSPI) Firefox использует NTLM авторизацию.