Устранение неполадок Apache с аутентификацией прокси-сервера GSS и авторизацией LDAP

Я настраиваю внутренний веб-сервер на сервере RHEL, присоединенном к домену, с аутентификацией Kerberos через прокси-сервер GSS и многоуровневой авторизацией с помощью LDAP, где Active Directory является источником истины. Kerberos и часть аутентификации работают нормально, но я не могу заставить работать авторизацию, и у меня нет идей.

Вот конфигурация каталога:

      <Directory /var/www/nietools.elsinor.net/html/>
        AuthType GSSAPI
        AuthName "GSSAPI Login"
        Require valid-user
</Directory>

<Directory /var/www/nietools.elsinor.net/html/tools/config_grep/>
        AuthType GSSAPI
        AuthName "GSSAPI Login"
        #GssapiConnectionBound On
        #GssapiSignalPersistentAuth On
        #GssapiUseSessions On
        #Session On
        #SessionCookieName gssapi_session path=/private;httponly;secure;
        AuthLDAPUrl "ldaps://ad.elsinor.net:636/OU=People,DC=ad,DC=elsinor,DC=net/?sAMAccountName?sub"
        AuthLDAPBindDN "CN=nietools,OU=Services,DC=ad,DC=elsinor,DC=net"
        AuthLDAPBindPassword "exec:/bin/cat /etc/httpd/conf.d/pw"
        Require ldap-group "CN=NIE,OU=Groups,DC=ad,DC=elsinor,DC=net"
</Directory>

Первая конфигурация каталога работает точно так, как ожидалось. Если вы подключаетесь с доменного ноутбука, он проходит прозрачную аутентификацию. Если нет, то запросит логин. Все хорошо.

Второй каталог никого не авторизует. Закомментированные параметры — это все, с чем я возился, пытаясь решить проблему. Я сосредоточил внимание на этих параметрах из-за сообщений в журнале ошибок Apache. Попытки аутентифицированного пользователя получить доступ ко второму каталогу приводят к следующим ошибкам:

      2023-08-07 15:40:27.893785 clientip=10.61.3.159:41364, hdr_referer="https://nietools.elsinor.net/", servername=nietools.elsinor.net, pid=45071, tid=140289914160704, module=authz_core, loglevel=error, message="AH01631: user testuser@AD.ELSINOR.NET: authorization failure for "/tools/config_grep": "

2023-08-07 15:40:27.992661 clientip=10.61.3.159:41364, hdr_referer="https://nietools.elsinor.net/", servername=nietools.elsinor.net, pid=45071, tid=140289905768000, module=auth_gssapi, loglevel=error, message="INTERNAL ERROR Mechanism needs continuation but neither GssapiConnectionBound nor GssapiUseSessions are configured"

Эти сообщения об ошибках появляются постоянно, по-видимому, независимо от того, как я настраиваю GssapiConnectionBound и GssapiUseSessions — ни одно из них не появляется ни в одной из найденных мной ссылок на конфигурацию, относящихся к такой настройке.

И, кстати, аутентификация будет работать так, как и ожидалось, если я удалю LDAP из уравнения и помещу пользователей в группу, определяемую вручную, вот так:

      <Directory /var/www/nietools.elsinor.net/html/tools/config_grep/>
        AuthType GSSAPI
        AuthName "GSSAPI Login"
        AuthGroupFile "/etc/httpd/conf.d/groups"
        Require group nie
</Directory>

Возможно ли, что сообщение INTERNAL ERROR является безопасным, а реальная проблема более обыденна — например, использование атрибута, отличного от SamAccountName? (Я уже пробовал UserPrincipalName.)

Это, кстати, RHEL 9 и Apache 2.4.

РЕДАКТИРОВАТЬ: я заметил кое-что в журналах отладки Apache: модуль Kerberos передает в модуль LDAP, но UserPrincipalName — [email protected][email protected] . Возможно, в этом проблема. Я подозреваю, что мне придется каким-то образом использовать атрибут UserPrincipalName и псевдоним «AD.ELSINOR.NET» для «elsinor.net».

РЕДАКТИРОВАТЬ 2: Не то. Я реализовал предложение пользователя user1686, и журналы Apache теперь показывают, что идентификаторы пользователей должны соответствовать имени sAMAccountName. К сожалению, они до сих пор не авторизованы. Я подозреваю одно из двух:

1. Происходит что-то более фундаментальное, и я просто не могу этого найти. Я проверил значения AuthLDAPUrl, AuthLDAPBindDN и Require примерно по 20 раз каждое.

2. Ошибка «требуется продолжение» на самом деле актуальна, и я не устранил ее должным образом, потому что понятия не имею, что это значит.

Мне следует добавить то, что я уже выполнилsudo setsebool -P httpd_can_connect_ldap 1и аудит SELinux чист, даже после отключения неприятных молчаливых отказов с помощьюsemodule -DB.

РЕДАКТИРОВАТЬ 3: Конфигурация gssproxy:

      [service/HTTP]
  mechs = krb5
  cred_store = keytab:/etc/krb5.keytab
  cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U
  euid = 48
  krb5_principal = HTTP

[service/ldap]
  mechs = krb5
  cred_store = keytab:/etc/krb5.keytab
  cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U
  euid = 55
  krb5_principal = ldap

[service/imap]
  mechs = krb5
  cred_store = keytab:/etc/krb5.keytab
  cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U
  euid = 76
  krb5_principal = imap