Все руководства, которые я смог найти, по настройке единого входа на веб-сайт, размещенный в Apache, с использованием аутентификации Active Directory, делают это путем настройки Kerberos с небезопасными настройками. Некоторое время было лучшей практикой отключить шифрование RC4-HMAC для Kerberos в Active Directory, но многие учебники призывают переопределить значения по умолчанию krb5.conf и заставить все работать с RC4-HMAC.

Я хотел попробовать настроить единый вход с шифрованием AES256, и мне удалось заставить его работать, поэтому я записываю этот вопрос и ответ для всех, кто хочет большей безопасности для своего сайта.

Начиная с RC4-HMAC

Мы начнем с того, что сначала заставим его работать с RC4-HMAC, так как это проще. Стандартные шаги по настройке SSO начинаются с создания учетной записи домена со связанным SPN, которое браузеры будут использовать для получения зашифрованных учетных данных для отправки на сервер. В этом примере мой пользователь REALM \ HostServiceAccount:

• UPN: HostServiceAccount@realm.com (и, следовательно, основное имя Kerberos - HostServiceAccount@REALM.COM)
• атрибут servicePrincipalName (также устанавливается с помощью setspn): HTTP / host.example.com; HTTP / хост (Kerberos: HTTP/host.example.com@REALM.COM)
• Оставьте настройки шифрования в покое; по умолчанию это делает RC4-HMAC самым надежным из разрешенных шифров, поэтому билеты из домена будут иметь это шифрование.

Мы добавляем следующие записи в /etc/krb5.conf на нашем целевом сервере:

[libdefaults]
    default_realm = REALM.COM

[domain_realm]
    .realm.com = REALM.COM
    realm.com = REALM.COM

Мы создаем keytab и позволяем серверу читать его:

# ktutil
ktutil:  add_entry -password -p HTTP/host.example.com@REALM.COM -k 1 -e rc4-hmac
Password for HTTP/host.example.com@REALM.COM: <enter password here>
ktutil:  write_kt /etc/apache2/service.keytab
ktutil:  q
# chown -v www-data:root /etc/apache2/service.keytab
# chmod -v 440 /etc/apache2/service.keytab

(На этом этапе вы, конечно, захотите использовать kinit -kt service.keytab -S HTTP/host.example.com@REALM.COM HostServiceAccount@REALM.COM чтобы проверить keytab.)

Наконец, мы настраиваем Apache для аутентификации пользователей с помощью нашей keytab:

KrbDelegateBasic off
KrbAuthoritative on
KrbMethodK5Passwd off
Krb5Keytab /etc/apache2/service.keytab
KrbAuthRealms REALM.COM

LogLevel debug

После перезапуска Apache, если все пойдет хорошо, мы делаем запрос к серверу с нашего компьютера домена Windows и видим следующее в журнале ошибок Apache:

[debug] src/mod_auth_kerb.c(1641): [client ****] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos, referer: ****
[debug] src/mod_auth_kerb.c(1395): [client ****] Verifying client data using KRB5 GSS-API , referer: ****
[debug] src/mod_auth_kerb.c(1411): [client ****] Client didn't delegate us their credential, referer: ****
[debug] src/mod_auth_kerb.c(1430): [client ****] GSS-API token of length 185 bytes will be sent back, ****

Запустив klist на нашей клиентской машине (или Wireshark, чтобы увидеть билет в запросе), мы видим, что действительно использовали билет RC4-HMAC для аутентификации:

#4>     Client: fluggo @ REALM.COM
        Server: HTTP/host.example.com @ REALM.COM
        KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)

Переход к лучшему шифрованию

Все хорошо, но опять же, это не наша цель. RC4-HMAC считается небезопасным, поэтому давайте отключим его и попробуем заставить ту же настройку работать с AES256.

Во-первых, мы попросим нашего дружелюбного администратора соседнего домена включить расширенное шифрование в REALM \ HostServiceAccount, в котором будут два флажка, помеченных:

• Эта учетная запись поддерживает 128-битное шифрование Kerberos AES.
• Эта учетная запись поддерживает 256-битное шифрование Kerberos AES.

Они появляются в разных местах в зависимости от используемых вами инструментов; Конечным результатом должно быть то, что атрибут msDS-SupportedEncryptionTypes LDAP должен иметь значение 0x18 или десятичное 24, что означает, что поддерживаются только AES128 и AES256.

Чтобы сделать это эффективным, мы уберем наши локальные клиентские билеты:

C:>klist purge

Current LogonId is 0:0xdeadbeef
        Deleting all tickets:
        Ticket(s) purged!

Если мы выполним наш запрос еще раз, мы увидим, что запрос не прошел, но у нас есть обновленный билет:

C:>klist
      ...
#3>     Client: fluggo @ REALM.COM
        Server: HTTP/host.example.com @ REALM.COM
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

Теперь нам просто нужно обновить нашу keytab новыми алгоритмами, и мы должны стать золотыми:

# mv /etc/apache2/service.keytab ~/old.keytab
# ktutil
ktutil:  add_entry -password -p HTTP/host.example.com@REALM.COM -k 1 -e aes256-cts-hmac-sha1-96
Password for HTTP/host.example.com@REALM.COM: <enter password here>
ktutil:  add_entry -password -p HTTP/host.example.com@REALM.COM -k 1 -e aes128-cts-hmac-sha1-96
Password for HTTP/host.example.com@REALM.COM: <enter password here>
ktutil:  write_kt /etc/apache2/service.keytab
ktutil:  q
# chown -v www-data:root /etc/apache2/service.keytab
# chmod -v 440 /etc/apache2/service.keytab

Нам даже не нужно перезапускать Apache. Просто отправьте запрос еще раз.

Упс ... не работает. Если мы посмотрим на журнал ошибок Apache, мы увидим:

[debug] src/mod_auth_kerb.c(1641): [client ****] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[debug] src/mod_auth_kerb.c(1249): [client ****] Acquiring creds for HTTP@host.example.com
[debug] src/mod_auth_kerb.c(1395): [client ****] Verifying client data using KRB5 GSS-API
[debug] src/mod_auth_kerb.c(1411): [client ****] Client didn't delegate us their credential
[debug] src/mod_auth_kerb.c(1430): [client ****] GSS-API token of length 9 bytes will be sent back
[debug] src/mod_auth_kerb.c(1110): [client ****] GSS-API major_status:000d0000, minor_status:000186a5
[error] [client ****] gss_accept_sec_context() failed: Unspecified GSS failure.  Minor code may provide more information (, )

Что ж, это до смешного бесполезное сообщение об ошибке, но что пошло не так? Ответ и одно решение для подражания!