Проверка подлинности Kerberos останавливается до получения кредитов без ошибок - PullRequest
Новая
       26

Проверка подлинности Kerberos останавливается до получения кредитов без ошибок

0 голосов
/ 18 марта 2020
  • Цель: пользователи из двух областей Microsoft Active Directory могут получить доступ к веб-серверу linux через SSO
    • INTR ANET .LOCAL - веб-сервер, доступ к которому осуществляется через SSO, имеет домен intr anet .local
    • OTHER.COM - пользователи из этого Царства получают доступ к веб-серверу через intr anet .com
  • Текущая ситуация: SSO работает только для пользователей с INTR ANET .LOCAL
  • веб-сервер: Ubuntu 16.04.6 LTS, Apache2 2.4.18

  • Журнал для успешного доступа с INTR ANET .LOCAL 

    [authz_core:debug] [pid 19362] mod_authz_core.c(809): [client 192.168.2.140:65350] AH01626: authorization result of Require valid-user : denied (no authenticated user yet)
[authz_core:debug] [pid 19362] mod_authz_core.c(809): [client 192.168.2.140:65350] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
[auth_kerb:debug] [pid 19362] src/mod_auth_kerb.c(1971): [client 192.168.2.140:65350] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[auth_kerb:debug] [pid 19362] src/mod_auth_kerb.c(1299): [client 192.168.2.140:65350] Acquiring creds for HTTP@intranet.com
[auth_kerb:debug] [pid 19362] src/mod_auth_kerb.c(1722): [client 192.168.2.140:65350] Verifying client data using KRB5 GSS-API with our SPNEGO lib
[auth_kerb:debug] [pid 19362] src/mod_auth_kerb.c(1738): [client 192.168.2.140:65350] Client didn't delegate us their credential
[auth_kerb:debug] [pid 19362] src/mod_auth_kerb.c(1757): [client 192.168.2.140:65350] GSS-API token of length 181 bytes will be sent back
[authz_core:debug] [pid 19362] mod_authz_core.c(809): [client 192.168.2.140:65350] AH01626: authorization result of Require valid-user : granted
[authz_core:debug] [pid 19362] mod_authz_core.c(809): [client 192.168.2.140:65350] AH01626: authorization result of <RequireAny>: granted

  • Журнал для сбоя доступа из OTHER.COM 

    [authz_core:debug] [pid 19279] mod_authz_core.c(809): [client xxx.xxx.xxx.xxx:50235] AH01626: authorization result of Require valid-user : denied (no authenticated user yet)
[authz_core:debug] [pid 19279] mod_authz_core.c(809): [client xxx.xxx.xxx.xxx:50235] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
[auth_kerb:debug] [pid 19279] src/mod_auth_kerb.c(1971): [client xxx.xxx.xxx.xxx:50235] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos

=> Вопрос в том, почему процесс останавливается, прежде чем mod_auth_kerb пытается получить учетные данные.

  • Если аутентификация в конфигурации vhost деактивирована, пользователи из OTHER.COM могут получить доступ к intr anet .com
  • Если для KrbMethodK5Passwd установлено значение пользователи OTHER.COM могут войти в систему, указав свои учетные данные

SSO Конфигурация: * 103 6 *

  • keytab: 

    $ klist -e -k -t kerb.keytab
Keytab name: FILE:kerb.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   3 06/07/2017 08:44:32 HTTP/intraserver@INTRANET.LOCAL (arcfour-hmac)
   3 06/07/2017 08:44:32 HTTP/intranet.com@OTHER.COM (arcfour-hmac)

  • клавиатура работает, хотя: 

    $ kinit -k -t kerb.keytab -p HTTP/intranet.com@OTHER.COM
$ klist -e
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: HTTP/intranet.com@OTHER.COM

Valid starting       Expires              Service principal
03/18/2020 14:25:23  03/19/2020 00:25:23  krbtgt/OTHER.COM@OTHER.COM
        renew until 03/19/2020 14:25:23, Etype (skey, tkt): arcfour-hmac, aes256-cts-hmac-sha1-96
03/18/2020 14:25:30  03/19/2020 00:25:23  HTTP/intranet.com@OTHER.COM
        renew until 03/19/2020 14:25:23, Etype (skey, tkt): arcfour-hmac, arcfour-hmac

  • vhost conf: 

    <Location />
        AuthType Kerberos
        AuthName "Kerberos Login "
        KrbAuthoritative off
        KrbAuthRealms INTRANET.LOCAL OTHER.COM
        KrbServiceName HTTP
        KrbMethodNegotiate on
        KrbMethodK5Passwd off
        KrbSaveCredentials off
        KrbVerifyKDC off
        KrbLocalUserMapping on
        Krb5Keytab /etc/apache2/kerb.keytab
        Require valid-user
</Location>

  • krb5.conf: 

    [libdefaults]
        default_realm = INTRANET.LOCAL
        # The following krb5.conf variables are only for MIT Kerberos.
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true
[realms]
        INTRANET.LOCAL = {
                kdc = 192.168.2.5
                admin_server = 192.168.2.5
                default_domain = intranet.local
                auth_to_local = RULE:[1:$1@$0](^.*@OTHER\.COM)s/@.*//
                auth_to_local = DEFAULT
        }
        OTHER.COM = {
                kdc = xxx.xxx.xxx.xxx
                admin_server = xxx.xxx.xxx.xxx
                default_domain = other.com
        }
[domain_realm]
        .intranet.local = INTRANET.LOCAL
        intranet.local = INTRANET.LOCAL
        .other.com = OTHER.COM
        other.com = OTHER.COM
[login]
        krb4_convert = false
        krb4_get_tickets = false

ОБНОВЛЕНИЕ

Я понял, что в ошибочных запросах отсутствует заголовок авторизации HTTP:

  • успешный запрос от INTR ANET .LOCAL: 

    [Thu Mar 19 14:05:37.333383 2020] [core:trace5] [pid 12424] protocol.c(653): [client 192.168.2.142:63462] Request received from client: GET /test.php HTTP/1.1
[Thu Mar 19 14:05:37.333511 2020] [setenvif:trace2] [pid 12424] mod_setenvif.c(622): [client 192.168.2.142:63462] Setting HTTP_AUTHORIZATION
[Thu Mar 19 14:05:37.333522 2020] [http:trace4] [pid 12424] http_request.c(394): [client 192.168.2.142:63462] Headers received from client:
...
[Thu Mar 19 14:05:37.333576 2020] [http:trace4] [pid 12424] http_request.c(398): [client 192.168.2.142:63462]   Authorization: Negotiate ...encrypted string...
[Thu Mar 19 14:05:37.333642 2020] [authz_core:debug] [pid 12424] mod_authz_core.c(809): [client 192.168.2.142:63462] AH01626: authorization result of Require valid-user : denied (no authenticated user yet)
[Thu Mar 19 14:05:37.333649 2020] [authz_core:debug] [pid 12424] mod_authz_core.c(809): [client 192.168.2.142:63462] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
[Thu Mar 19 14:05:37.333668 2020] [auth_kerb:debug] [pid 12424] src/mod_auth_kerb.c(1971): [client 192.168.2.142:63462] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[Thu Mar 19 14:05:37.333719 2020] [auth_kerb:debug] [pid 12424] src/mod_auth_kerb.c(1299): [client 192.168.2.142:63462] Acquiring creds for HTTP@intranet.com
[Thu Mar 19 14:05:37.337553 2020] [auth_kerb:debug] [pid 12424] src/mod_auth_kerb.c(1722): [client 192.168.2.142:63462] Verifying client data using KRB5 GSS-API with our SPNEGO lib
[Thu Mar 19 14:05:37.337987 2020] [auth_kerb:debug] [pid 12424] src/mod_auth_kerb.c(1738): [client 192.168.2.142:63462] Client didn't delegate us their credential
[Thu Mar 19 14:05:37.338015 2020] [auth_kerb:debug] [pid 12424] src/mod_auth_kerb.c(1757): [client 192.168.2.142:63462] GSS-API token of length 181 bytes will be sent back
[Thu Mar 19 14:05:37.338645 2020] [auth_kerb:debug] [pid 12424] src/mod_auth_kerb.c(1872): [client 192.168.2.142:63462] kerb_authenticate_a_name_to_local_name user@INTRANET.LOCAL -> user
[Thu Mar 19 14:05:37.338675 2020] [authz_core:debug] [pid 12424] mod_authz_core.c(809): [client 192.168.2.142:63462] AH01626: authorization result of Require valid-user : granted
[Thu Mar 19 14:05:37.338681 2020] [authz_core:debug] [pid 12424] mod_authz_core.c(809): [client 192.168.2.142:63462] AH01626: authorization result of <RequireAny>: granted

  • Следующие две строки из вышеуказанного журнала отсутствуют в ошибочном запросе от OTHER.COM:

    [Thu Mar 19 14:05:37.333511 2020] [setenvif:trace2] [pid 12424] mod_setenvif.c(622): [client 192.168.2.142:63462] Setting HTTP_AUTHORIZATION
[Thu Mar 19 14:05:37.333576 2020] [http:trace4] [pid 12424] http_request.c(398): [client 192.168.2.142:63462]   Authorization: Negotiate ...encrypted string...

  • В инструменте проверки / разработки браузера в OTHER .COM, я не вижу заголовка авторизации, но для INTR ANET .LOCAL я вижу его.

=> Может ли отсутствующий заголовок авторизации HTTP быть причиной для сбой единого входа для OTHER.COM?

...