Учетные данные Kerberos не пересылаются в openldap с помощью mod_auth_kerb/Apache2, Authen::SASL/perl

Я пишу веб-интерфейс для управления сервером OpenLDAP нашей компании. Я использую Perl, Apache2, OpenLDAP, Cyrus SASL.

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

Credentials cache file '/tmp/krb5cc_33' not found

где "33" - это uidNumber для Apache. Что имеет смысл, но не решает проблему. По иронии судьбы, все это работает за пределами области, потому что тогда mod_auth_kerb запрашивает имя пользователя и пароль, аутентифицирует, кэширует билеты, и все это работает.

Я использую mod_auth_kerb для аутентификации в Apache2, и он работает нормально: пароль не запрашивается, защищенная страница отображается для аутентифицированного пользователя (и отклоняется в противном случае). Соответствующий фрагмент конфига:

<Directory "/usr/lib/cgi-bin">
            AllowOverride None
            Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
            Order allow,deny
            Allow from all 
            AuthType Kerberos
            AuthName "Kerberos Login"
            KrbAuthRealms EXAMPLE.COM
            Krb5Keytab /etc/apache2/HTTP.keytab
            KrbServiceName HTTP
            KrbSaveCredentials on
            require valid-user
    </Directory>

Kerberos / GSSAPI / SASL-аутентификация также работает нормально, поэтому этот код дает ОК при запуске из командной строки:

1 #!perl
  2 use strict;
  3 use warnings;
  4 use Net::LDAP;
  5 use Authen::SASL;
  6 
  7 my $l = Net::LDAP->new( 'ldap.example.com', onerror=>'die', );
  8 my $sasl = Authen::SASL->new(mechanism=>'GSSAPI');
  9 $l->bind( sasl=>$sasl );
 10 
 11 print "OK\n";

Итак, что может быть решением?

Источник

1 ответ

По умолчанию веб-браузеры не пересылают билеты Kerberos. (К счастью! Это было бы огромной проблемой безопасности, так как браузер просто раздавал бы ваши билеты на любой веб-сайт в вашем местном царстве, который их запрашивал.)

К сожалению, чтобы заставить браузер сделать это, требуются некоторые усилия. Например, в Firefox вы должны перейти к: config и настроить network.negotiate-auth.delegation-uris, чтобы добавить URL-адреса, на которые вы хотите делегировать билеты. (Я думаю, что в IE есть аналогичная процедура, чтобы пометить веб-сайт как часть доверенного домена.)

Если у вас нет большого контроля над средой браузера, это обычно тупик. У большинства людей веб-приложение аутентифицируется как само по себе (а не как пользователь) и предоставляет ему общий доступ для чтения. В качестве альтернативы вы можете использовать более полную систему веб-аутентификации на уровне сайта, которая поддерживает делегирование полномочий, но это может быть излишним для вашей ситуации.

Две реализации, которые поддерживают это:

Это обе системы веб-аутентификации клиент / сервер, которые требуют настройки некоторой инфраструктуры.

Источник
Другие вопросы по тегам