An unsupported mechanism was requested unknown error

A user of ours has an issue where he cannot login using his Safari browser.

He receives the message that authentication failed, while the server logs:

gss_accept_sec_context() failed: [An unsupported mechanism was requested (Unknown error)]

This happens with Safari 8.0.3 on Mac OS X 10.10.2 and iOS 8.2 as well:

"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/600.3.18 (KHTML, like Gecko) Version/8.0.3 Safari/600.3.18"
"Mozilla/5.0 (iPhone; CPU iPhone OS 8_2 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Version/8.0 Mobile/12D508 Safari/600.1.4"

Our config is:

                        AuthType GSSAPI

                        GssapiCredStore keytab:/etc/apache2/http.keytab
                        GssapiCredStore ccache:MEMORY:user_ccache

                        GssapiBasicAuth On

                        GssapiConnectionBound On
                        Header set Persistent-Auth "true"

                        GssapiUseSessions On
                        Session On
                        SessionCookieName gssapi_session path=/;httponly;secure;

The same issue happens with mod-auth-kerb-5.4 (5.4-2.2 on Debian 8 «Jessie»), so this is probably not a bug in mod-auth-gssapi, but a misconfiguration. To fix it, I need your support.

P.S: Other browsers, like Chrome and Firefox on the same operating system (Mac OS X) are unaffected. These browsers are also known to be not affected on Linux (various distributions). I have not tested with IE or on Windows so far.

The service name is a CNAME for the server hostname. That hostname then resolves to an A record, which has a proper PTR reverse record setup.

В прошлой заметке был рассмотрен пример простейшего ограничения доступа к веб-серверу Apache с применением незащищённой Basic-аутентификации и использованием учётных данных из файла. Разумеется такой режим аутентификации нельзя считать безопасным и поэтому в данной заметке мы рассмотрим пример настройки Kerberos-аутентификации и авторизации на веб-сервере Apache c помощью службы SSSD (System Security Services Daemon).

Ранее уже рассматривался пример подобной настройки веб-сервера Apache, однако в том случае для поддержки Kerberos-аутентификации в систему устанавливался пакет krb5-workstation, а для авторизации использовался функционал интеграции oVirt с Active Directory. В этой заметке мы пойдём по несколько иному пути, так как для аутентификации пользователей в домене AD будем использовать модуль Apache mod_auth_gssapi, а для авторизации модуль — mod_authnz_pam, который будет использоваться в связке с SSSD. То есть получать доступ к веб-серверу смогут все те доменные пользователи, что уже имеют доступ на подключение к самому серверу. Такая конфигурация может быть проста в настройке и полезна в тех случаях, когда некоторому кругу администраторов Linux-сервера нужно предоставить возможность прозрачного подключения (Single sign-on) к веб-сайту того или иного сервиса, работающего на этом сервере, как в ранее рассмотренном случае с веб-консолью QUADStor.

Подключаем к веб-серверу модуль mod_authnz_pam

Посмотрим информацию о модуле mod_authnz_pam, который доступен нам в репозиториях CentOS Linux 7.2:

# yum info mod_authnz_pam

...
Available Packages
Name        : mod_authnz_pam
Arch        : x86_64
Version     : 0.9.3
Release     : 5.el7_2
Size        : 14 k
Repo        : updates/7/x86_64
Summary     : PAM authorization checker and PAM Basic Authentication provider
URL         : http://www.adelton.com/apache/mod_authnz_pam/
License     : ASL 2.0
Description : mod_authnz_pam is a PAM authorization module, supplementing
            : authentication done by other modules, for example mod_auth_kerb; it
            : can also be used as full Basic Authentication provider which runs the
            : [login, password] authentication through the PAM stack.

Как видим из описания, этот модуль позволит нам использовать PAM-авторизацию и PAM-аутентификацию (только Basic). В рамках нашей задачи интересна возможность именно PAM авторизации, хотя и пример настройки Basic-аутентификации мы рассмотрим тоже.

Итак, установим в систему модуль:

# yum install mod_authnz_pam

Так как настройка производиться на CentOS 7.2 с включённым SELinux, то нам потребуется разрешить взаимодействие веб-сервера Apache с модулем:

# setsebool -P allow_httpd_mod_auth_pam 1

Откроем на редактирование файл с директивой загрузки модуля:

# nano /etc/httpd/conf.modules.d/55-authnz_pam.conf

и раскомментируем в нём единственную строку, чтобы разрешить автоматическую загрузку нужной библиотеки в процессе запуска веб-сервера:

LoadModule authnz_pam_module modules/mod_authnz_pam.so

Перезапустим службу веб-сервера и убедимся в том, что модуль загружен:

# systemctl restart httpd
# httpd -M | grep pam

authnz_pam_module (shared)

Создаём службу PAM

Создадим в каталоге /etc/pam.d/ файл описания собственной службы PAM, которая для процедур аутентификации и авторизации будет вызывать библиотеку SSSD (имя файла используем то, которое нам удобно):

# nano /etc/pam.d/httpd-quadstor

Наполним файл содержимым (первая строка определяет вызов библиотеки SSSD для аутентификации, вторая строка – для авторизации):

auth    required   pam_sss.so
account required   pam_sss.so

Apache c Basic-аутентификацией и PAM авторизацией

Отредактируем конфигурационный файл веб-сервера Apache (по умолчанию /etc/httpd/conf/httpd.conf) и отредактируем в нём секцию, где описан доступ к нужному нам пути. В нашем примере настраивается ограничение доступа к каталогу с исполняемыми файлами веб-консоли QUADStor Storage Virtualization и соответствующая секция конфигурационного файла веб-сервера примет следующий вид:

<Directory "/var/www/cgi-bin">
 AuthType Basic
 AuthName "QUADStor Private Area"
 AuthBasicProvider PAM
 AuthPAMService httpd-quadstor
 Require valid-user
</Directory>

Здесь задана Basic-аутентификация через провайдер PAM с именем ранее созданной нами PAM службы httpd-quadstor. После внесённых изменений перезапустим службу веб-сервера:

# systemctl restart httpd

Теперь попытаемся с клиентского компьютера получить доступ к веб-консоли QUADStor и увидим соответствующий запрос на ввод учётных данных. Здесь введём учётные данные доменного пользователя, который имеет право на вход на наш Linux-сервер согласно настроенных ранее правил в конфигурации SSSD. 

В момент отправки введённых учётных данных в логе безопасности на нашем Linux-сервере мы сможем отследить результат попытки аутентификации (в нашем примере он успешный):

# tail -f /var/log/secure
...
Oct 24 13:54:52 KOM-AD01-FS03 httpd: pam_sss(httpd-quadstor:auth): authentication success; logname= uid=48 euid=48 tty= ruser= rhost=10.9.1.100 user=petya

Итак, Basic-аутентификация в паре с PAM авторизацией работает, и теперь разрешённые доменные пользователи уже могут использовать привычные им учётные данные для получения доступа к веб-ресурсу. Однако, повторюсь, что с точки зрения информационной безопасности, использовать такой режим аутентификации неправильно, и поэтому мы перейдём к настройке Kerberos-аутентификации.

Apache c Kerberos-аутентификацией и PAM авторизацией

Для работы Kerberos аутентификации в домене AD можно создать отдельную сервисную учётную запись, для которой в дальнейшем зарегистрировать servicePrincipalName (SPN) веб-сервера и сгенерировать keytab-файл, содержащий данную SPN-запись. Повторяться не буду, так как эта процедура пошагово рассмотрена в одной из прошлых заметок (см. пункт «Создание в домене AD сервисной учётной записи» и «Создание keytab-файла для сервисной учётной записи»). Предполагая, что необходимый keytab-файл у нас уже есть, размещаем его в доступном для службы веб-сервера месте и ограничиваем к нему доступ:

# chown apache /etc/httpd/s-FS03-HTTP-Krb.keytab
# chmod 400 /etc/httpd/s-FS03-HTTP-Krb.keytab

Устанавливаем модули необходимые веб-серверу для поддержки Kerberos-аутентификации средствами GSSAPI:

# yum install mod_session mod_auth_gssapi

И меняем настроенную ранее на Basic-аутентификацию секцию конфигурационного файла веб-сервера /etc/httpd/conf/httpd.conf следующим образом:

<Directory "/var/www/cgi-bin">
    AuthType GSSAPI
    AuthName "QUADStor Private Area"
    #GssapiBasicAuth On
    GssapiCredStore keytab:/etc/httpd/s-FS03-HTTP-Krb.keytab
    GssapiUseSessions On
    Session On
    SessionCookieName quadstor_web_gssapi_session path=/private;httponly;secure;
    Require pam-account httpd-quadstor
</Directory>

Как видно здесь уже используется аутентификация GSSAPI c ранее приготовленным keytab-файлом и вызовом ранее созданной PAM службы httpd-quadstor для авторизации пользователей. Обратите внимание на то, что параметр GssapiBasicAuth закомментирован, так как его включение меняет поведение веб-сервера таким образом, что при попытке неудачной прозрачной Kerberos-аутентификации пользователю будет показано окно с запросом на ввод учётных данных. Из некоторых соображений безопасности можно оставить этот параметр в значении по умолчанию, чтобы пользователю не выводилось никаких запросов после неудачной аутентификации.

Опять же, после внесённых изменений перезапустим службу веб-сервера:

# systemctl restart httpd

Теперь попытаемся с клиентского компьютера получить доступ к веб-консоли QUADStor и процедура аутентификации и авторизации должна пройти для пользователя прозрачно без каких либо запросов на ввод учётных данных.

Защита соединений с веб-сервером с помощью SSL-сертификата

В случае если вы решите использовать PAM авторизацию с Basic-аутентификацией, то в целях обеспечения нормального уровня безопасности HTTP-соединений клиентов с веб-сервером, нужно будет включить в конфигурации веб-сервера поддержку SSL. И даже если вы решите использовать Kerberos-аутентификацию, которая имеет свои собственные механизмы защиты, всё равно более правильным будет дополнительное усиление защиты HTTP-соединений с помощью SSL.

Для этого нам потребуется сделать пару несложных вещей – установить модуль веб-сервера для поддержки SSL (mod_ssl) и сгенерировать SSL-сертификат веб-сервера, который в последствии в паре с закрытым ключом от этого сертификата нужно будет привязать к конфигурации веб-сервера.

Устанавливаем модуль веб-сервера:

# yum install mod_ssl

По поводу генерации закрытого ключа и сертификата веб-сервера я повторяться не буду, так как подобная процедура рассматривалась ранее, например в заметке Установка сертификата от Windows Server CA на веб-сервер Apache. Предполагая, что у нас уже есть на руках готовые файлы ключа и сертификата в формате PEM размещаем их на нашем Linux-сервере в каталогах /etc/pki/tls/private/ и /etc/pki/tls/certs/ соответственно.

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

# nano /etc/httpd/conf.d/ssl.conf

В этом файле, как минимум, нам нужно изменить два параметра, указав соответствующие файлы сертификата и его ключа: 

...
SSLCertificateFile "/etc/pki/tls/certs/FS03-HTTPS.pem"
SSLCertificateKeyFile "/etc/pki/tls/private/FS03-HTTPS.key"
...

Дополнительно в основной конфигурационный файл веб-сервера /etc/httpd/conf/httpd.conf можно внести директиву обязательного редиректа всех клиентских соединений на HTTPS, например, добавив секцию описания виртуального хоста:

...
<VirtualHost *:80>
   Redirect permanent "/" "https://kom-ad01-fs03.ad.holding.com/"
</VirtualHost>
...

В качестве последнего штриха можно внести дополнительные параметры в секцию описывающую доступ к каталогу веб-сервера, включив обязательное использование SSL, например:

<Directory "/var/www/cgi-bin">
    SSLRequireSSL
    AuthType GSSAPI
    AuthName "QUADStor Private Area"
    #GssapiBasicAuth On
    GssapiSSLonly On
    GssapiCredStore keytab:/etc/httpd/s-FS03-HTTP-Krb.keytab
    GssapiUseSessions On
    Session On
    SessionCookieName quadstor_web_gssapi_session path=/private;httponly;secure;
    Require pam-account httpd-quadstor
</Directory>

После всех проделанных изменений перезапустим службу веб-сервера:

# systemctl restart httpd

Теперь наш веб-сайт Apache имеет не только возможность безопасной и удобной аутентификации и авторизации доменных пользователей AD, но и имеет защиту всех HTTP-соединений.

Дополнительные источники информации:

• GitHub — GSSAPI Negotiate module for Apache
• Jan Pazdziora  — Apache module mod_authnz_pam
• FreeIPA — Web App Authentication

Подключение осуществляется через веб-браузер, настройка — согласно статье.

После попытки авторизации выдается ошибка вида: «Unauthorized».

Диагностика

Возможные причины

I have configured SSO for Redmine on Apache with Kerberos + GSSAPI.
It works OK for the first time. But I postponed this configuration and when I setup it again SSO auth fails with the following error in httpd error log:

[http:trace4] [pid 29360] http_request.c(316): [client 192.168.0.10:47380]   Authorization: Negotiate TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAKADk4AAAADw==
[rewrite:trace2] [pid 29360] mod_rewrite.c(470): [client 192.168.0.10:47380] 192.168.0.10 - - [redmine.mydomain.com/sid#558a80593c58][rid#558a806408f0/initial] init rewrite engine with requested uri /
[rewrite:trace1] [pid 29360] mod_rewrite.c(470): [client 192.168.0.10:47380] 192.168.0.10 - - [redmine.mydomain.com/sid#558a80593c58][rid#558a806408f0/initial] pass through /
[authz_core:debug] [pid 29360] mod_authz_core.c(809): [client 192.168.0.10:47380] AH01626: authorization result of Require valid-user : denied (no authenticated user yet)
[authz_core:debug] [pid 29360] mod_authz_core.c(809): [client 192.168.0.10:47380] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
[auth_gssapi:debug] [pid 29360] mod_auth_gssapi.c(900): [client 192.168.0.10:47380] URI: /, no main, no prev
[auth_gssapi:error] [pid 29360] [client 192.168.0.10:47380] GSS ERROR In Negotiate Auth: gss_accept_sec_context() failed: [An unsupported mechanism was requested (Unknown error)]

Also I got another error:
[auth_gssapi:info] [pid 8012] [client 127.0.0.1:37910] NO AUTH DATA Client did not send any authentication headers

My krb5.conf

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = MYDOMAIN.COM
 default_keytab_name = /etc/krb5.keytab
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h
 renew_lifetime = 24h
 forwardable = true
 default_tgs_enctypes = aes256-cts-hmac-sha1-96
 default_tkt_enctypes = aes256-cts-hmac-sha1-96

[realms]
 MYDOMAIN.COM = {
  kdc = mydc.mydomain.com
  admin_server = mydc.mydomain.com
  default_domain = mydomain.com
  kpasswd_server = mydc.mydomain.com
 }

[domain_realm]
 .mydomain.com = MYDOMAIN.COM
 mydomain.com = MYDOMAIN.COM

My keytab

# klist -ek /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   4 HTTPS/redmine.mydomain.com@MYDOMAIN.COM (aes256-cts-hmac-sha1-96)

Keytab tests:

# kinit -V -kt /etc/krb5.keytab -p HTTPS/redmine.mydomain.com@MYDOMAIN.COM
Using default cache: /tmp/krb5cc_0
Using principal: HTTPS/redmine.mydomain.com@MYDOMAIN.COM
Using keytab: /etc/krb5.keytab
Authenticated to Kerberos v5
#
# klist -Af
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: HTTPS/redmine.mydomain.com@MYDOMAIN.COM

Valid starting       Expires              Service principal
02/15/2019 16:31:47  02/16/2019 02:31:47  krbtgt/MYDOMAIN.COM@MYDOMAIN.COM
        renew until 02/16/2019 16:31:47, Flags: FPRIA

My keytab was generated by the following commands:

ktpass -princ HTTPS/redmine.mydomain.com@MYDOMAIN.COM -mapuser serviceuser -pass my_password -ptype KRB5_NT_PRINCIPAL -crypto AES256-SHA1 -out redmine.keytab -mapOp set

SPN info

C:>setspn -L serviceuser
Registered ServicePrincipalNames for CN=serviceuser,OU=Pseudo Accounts,OU=Managed Objects,DC=mydomain,DC=com:
        HTTPS/redmine.mydomain.com

C:>setspn -Q HTTPS/redmine.mydomain.com
Checking domain DC=mydomain,DC=com
CN=serviceuser,OU=Pseudo Accounts,OU=Managed Objects,DC=mydomain,DC=com
        HTTPS/redmine.mydomain.com

Existing SPN found!

Looks like my keytab is OK.

My redmine.conf for Apache

<VirtualHost *:80>
    ServerAdmin admin@mydomain.com
    ServerName redmine.mydomain.com
    Redirect "/" "https://redmine.mydomain.com/"
</VirtualHost>

<VirtualHost *:443>
    ServerAdmin admin@mydomain.com
    ServerName redmine.mydomain.com
    DocumentRoot /var/www/redmine/public/


    # SSL
    # Enable SSL with Perfect Forward Secrecy
    SSLEngine on
    SSLProtocol +TLSv1.2 +TLSv1.1 +TLSv1
    SSLCompression off
    SSLCertificateFile /etc/ssl/certs/mydomain.com.crt
    SSLCertificateKeyFile /etc/ssl/private/mydomain.com.key

    ## Passenger Configuration

    RailsBaseURI /
    PassengerAppRoot /var/www/redmine
    PassengerRuby /usr/local/rvm/gems/ruby-2.4.4/wrappers/ruby
    PassengerFriendlyErrorPages on
    RailsSpawnMethod smart
    RailsAppSpawnerIdleTime 3600
    PassengerMaxPreloaderIdleTime 0
    PassengerMaxRequests 5000

    PassengerUser apache
    PassengerGroup apache

    <Directory /var/www/redmine/public>
            Options +Indexes +FollowSymLinks -MultiViews
            AllowOverride All
            <IfVersion < 2.3 >
                    Order allow,deny
                    Allow from all
            </IfVersion>
            <IfVersion >= 2.3>
                    Require all granted
            </IfVersion>
    </Directory>

    # SSO start 

    <Location "/">
        RewriteEngine     On
        RewriteCond       %{IS_SUBREQ} ^false$
        RewriteCond       %{LA-U:REMOTE_USER} (.+)
        RewriteRule       . - [E=RU:%1]
        RequestHeader     add REMOTE_USER %{RU}e

        SSLRequireSSL
        AuthType GSSAPI
        AuthName "login:"
        GssapiSSLonly On
        GssapiAllowedMech krb5
        GssapiCredStore keytab:/etc/krb5.keytab
        GssapiLocalName On
        GssapiBasicAuth On

        Require valid-user
    </Location>

    # SSO end   

    #AddOutputFilter DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css

    #BrowserMatch ^Mozilla/4 gzip-only-text/html
    #BrowserMatch ^Mozilla/4.0[678] no-gzip
    #BrowserMatch bMSIE !no-gzip !gzip-only-text/html

    ErrorLog /var/log/httpd/redmine.error.log
    LogLevel trace8
    CustomLog /var/log/httpd/redmine.access.log combined
    ServerSignature Off

</VirtualHost>

Also I tryied without GssapiAllowedMech krb5 option, but I got same error.

In redmine app I modified app/controllers/application_controller.rb. Added the follwing strings to find_current_user function:

elsif (forwarded_user = request.env["REMOTE_USER"])
    # web server authentication
    user = (User.find_by_login(forwarded_user) rescue nil)

In result:

  def find_current_user
    user = nil
    unless api_request?
      if session[:user_id]
        # existing session
        user = (User.active.find(session[:user_id]) rescue nil)
      # Start custom settings
      elsif (forwarded_user = request.env["REMOTE_USER"])
        # web server authentication
        user = (User.find_by_login(forwarded_user) rescue nil)
      # End custom settings
      elsif autologin_user = try_to_autologin
        user = autologin_user
      elsif params[:format] == 'atom' && params[:key] && request.get? && accept_rss_auth?
        # RSS key authentication does not start a session
        user = User.find_by_rss_key(params[:key])
      end
    end

Browsers configuration.
For Google Chrome, Edge, Opera I have setup Local Intranet and Trusted sites zones in Internet Options to Automatic logon with current user name and password.
For FF:

network.negotiate-auth.delegation-uris = mydomain.com
network.negotiate-auth.trusted-uris = mydomain.com

Any ideas?