Как настроить Ubuntu + Apache + Active Directory?

Kerberos is your friend! (its what AD actually uses for Auth)

How to use Kerberos with PHP

Soureforge Source & How to install Kerberos module into Apache

You will probably need: libapache2-mod-auth-kerb first, as per:

http://www.microhowto.info/howto/configure_apache_to_use_kerberos_authentication.html

---

Full text:

To configure Apache to use Kerberos authentication Предпосылки

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

В случае HTTP поддержка Kerberos обычно предоставляется с использованием механизма аутентификации SPNEGO (простое и защищенное согласование GSS-API). Это также известно как «интегрированная аутентификация» или «согласованная аутентификация». Сам Apache не поддерживает SPNEGO, но поддержку можно добавить с помощью модуля аутентификации mod_auth_kerb. Scenario

Suppose you wish to restrict access to the web site http://www.example.com/. Authentication is to be performed using Kerberos and SPNEGO. The web site need not be accessible to non-SPNEGO-enabled web browsers.

The users to be given access are members of the Kerberos realm EXAMPLE.COM and are named dougal, brian, ermintrude and dylan. The realm can be administered using the principal bofh/admin. Prerequisites

The description below assumes that you have already installed both Apache and Kerberos on the web server.

Apache should be in a state where you can request at least one page from the relevant web site for testing purposes. It need not contain any real content (and if it does then you will probably want to take steps to isolate the server from unauthorised users until it has been properly secured).

Kerberos should be in a state where EXAMPLE.COM has been configured as the default realm and it is possible to obtain a ticket for that realm on the web server. Method Overview

The method described here has six steps:

Install the mod_auth_kerb authentication module. Create a service principal for the web server. Create a keytab for the service principal. Specify the authentication method to be used. Specify a list of authorised users. Reload the Apache configuration.

Note that in addition to enabling SPNEGO on the web server, it may also be necessary to explicitly enable it within the web browser. This is known to be the case for Mozilla Firefox. See:

Configure Firefox to authenticate using SPNEGO and Kerberos

Install the mod_auth_kerb authentication module

As noted above, Apache does not itself provide support for SPNEGO but it can be added using the module mod_auth_kerb. This is included in most major GNU/Linux distributions, but because it is a third-party module it is usually packaged separately from Apache. On Debian-based systems it is provided by the package libapache2-mod-auth-kerb:

apt-get install libapache2-mod-auth-kerb

and on Red Hat-based systems by the package mod_auth_kerb:

yum install mod_auth_kerb

Apache modules must be loaded before they can be used, but both of the above packages arrange for this to happen automatically. If for any reason you need to do this manually then the appropriate configuration directive is:

LoadModule auth_kerb_module /usr/lib/apache2/modules/mod_auth_kerb.so

(where the pathname of the module should be replaced with whatever is appropriate for your system). Создание субъекта-службы для веб-сервера

SPNEGO требует, чтобы субъект службы Kerberos был создан для веб-сервера. Имя службы определено как HTTP, поэтому для сервера www.example.com требуемое имя участника службы - HTTP / www.example.com@EXAMPLE.COM.

Если вы используете MIT Kerberos, то субъект-службу можно создать с помощью команды kadmin:

kadmin -p bofh/admin -q "addprinc -randkey HTTP/www.example.com"

См. MicroHOWTO Создание субъекта-службы с использованием MIT Kerberos для получения дополнительной информации о том, как можно создать субъект-службу и зачем он нужен. . Create a keytab for the service principal

A keytab is a file for storing the encryption keys corresponding to one or more Kerberos principals. mod_auth_kerb needs one in order to make use of the service principal created above. If you are using MIT Kerberos then the keytab (like the service principal) can be created using the kadmin command. Its ownership must be such that it is readable by the Apache process.

On Debian-based systems a suitable location for the keytab would be /etc/apache2/http.keytab and the appropriate owner is www-data:

kadmin -p bofh/admin -q "ktadd -k /etc/apache2/http.keytab HTTP/www.example.com"
chown www-data /etc/apache2/http.keytab

On Red Hat-based systems a suitable location would be /etc/httpd/http.keytab and the appropriate owner is apache:

kadmin -p bofh/admin -q "ktadd -k /etc/httpd/http.keytab HTTP/www.example.com"
chown apache /etc/httpd/http.keytab

The -k option specifies the pathname to the keytab, which will be created if it does not already exist.

See the microHOWTO Add a host or service principal to a keytab using MIT Kerberos for further information about the creation of keytabs, their purpose, and why the default keytab (typically /etc/krb5.keytab) is not suitable for use by network services that do not run as root.

If you wish to check that the key has been correctly added to the keytab then you can attempt to use it to authenticate as the service principal, then view the resulting ticket-granting ticket using klist:

kinit -k -t /etc/apache2/http.keytab HTTP/www.example.com
klist

Specify the authentication method to be used

Apache must be told which parts of which web sites are to use authentication provided by mod_auth_kerb. This is done using the AuthType directive with a value of Kerberos. Some further directives are then needed to configure how mod_auth_kerb should behave.

If the intent is to apply these directive to the whole of a given web site then they can be placed in a container with a path corresponding to the root of the site:

<Location />
 AuthType Kerberos
 AuthName "Acme Corporation"
 KrbMethodNegotiate on
 KrbMethodK5Passwd off
 Krb5Keytab /etc/apache2/http.keytab
</Location>

The AuthName directive specifies the HTTP authorisation realm. Its purpose is to indicate to the user which of the various passwords he might know is needed to gain access to a particular web site. With true Kerberos authentication there should be no password prompt, and mod_auth_kerb appears to work perfectly well without an AuthName having been specified; however the Apache documentation states that it is required, so it would seem prudent to supply one anyway. A suitable value might be the domain name, the name of the Kerberos realm, or the name of the organisation to which the web site belongs.

In addition to the SPNEGO protocol, mod_auth_kerb has the ability to ask the user for a password using basic authentication then validate that password by attempting to authenticate to the KDC. This can be useful if there is a need for the web site to be accessible to its authorised users from machines that are not part of the Kerberos realm, however it is significantly less secure than true Kerberos authentication. Both SPNEGO and password authentication are enabled by default. In this example there is no requirement for the site to be accessible to non-SPNEGO-enabled web browsers, therefore password authentication has been disabled using the KrbMethodK5Passwd directive. For completeness, SPNEGO has been explicitly enabled using the KrbMethodNegotiate directive.

The Krb5Keytab directive specifies the pathname of the keytab to which the HTTP service principal has been added. It should match whatever was passed to the ktadd command of kadmin earlier in this procedure.

Although a container has been used in this example, it would be equally acceptable for the above directives to be placed within a , or container or within an .htaccess file. Задайте список авторизованных пользователей

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

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

<Location />
 # ...
 Require user dougal@EXAMPLE.COM brian@EXAMPLE.COM ermintrude@EXAMPLE.COM dylan@EXAMPLE.COM
</Location>

Обратите внимание, что каждое имя квалифицируется областью Kerberos, членом которой оно является.

Для серверов с большим количеством пользователей это, очевидно, не масштабируемое решение. , однако у Apache есть другие методы авторизации, которые могут эффективно обрабатывать большое количество пользователей, включая mod_authz_dbd и mod_authnz_ldap. Reload the Apache configuration

See Cause a system service to reload its configuration. On recent Debian-based systems the required command is:

service apache2 force-reload

Security considerations Password authentication

As noted above, mod_auth_kerb has the ability to request a username and password from the web browser using HTTP Basic Authentication, then check whether that username and password are valid using Kerberos. This approach has three serious drawbacks compared to true Kerberos authentication:

The password is sent unencrypted as part of the HTTP stream.
The password is exposed to the Apache server.
The password must be entered mid-session.

The first of these points can be addressed by enabling access via TLS (SSL) and disabling plain HTTP. The second and third points are less tractable, and undermine many of the security benefits provided by the Single Sign-on model generally and by Kerberos in particular.

In practice it is sometimes necessary to allow access from hosts that are not part of the Kerberos realm or from user agents that do not support SPNEGO. For this reason it is unrealistic to recommend that password authentication should never be used as a fallback, however it is best avoided if you can and should not be permitted merely because it is enabled by default. SPNEGO

Authentication using SPNEGO addresses the concerns listed above but the manner in which it is integrated with HTTP is far from ideal. When a client authenticates to a Kerberos network service one of the products of the authentication process is an encryption key that the client and server can use to secure any further communication between them. This is not used when an HTTP connection is authenticated using SPNEGO, which means that if a connection is hijacked after authentication has completed then there is nothing to prevent an attacker from issuing unauthorised HTTP commands.

This risk can be greatly reduced by using TLS (SSL) to secure the connection. This prevents a connection from being hijacked once it has been established, and prevents a server from accepting connections to a web site for which it does not have a valid certificate. It is not a perfect solution because of the large number of organisations that can issue certificates. There is a solution which uses channel binding to link the TLS key to Kerberos, however at the time of writing it had not been widely implemented (and is not supported by mod_auth_kerb).