HOWTO Configure Apache with an IPA Server

HOWTO Configure Apache with an IPA Server

From Consultancy.EdVoncken.NET

Jump to: navigation, search

Many business applications today are web-based. Think of time tracking, groupware and collaboration software such as Wikis.

Managing separate Identity stores for each application is not a scalable option. Integration with you Identity Management environment, for example Red Hat Enterprise IPA or FreeIPA, is a good way to achieve scalability and manageability for your web-based applications.

The Apache webserver can authenticate users against an LDAP/Kerberos directory such as IPA.

Contents

Shared Authentication schemes

Shared Authentication schemes help reduce complexity in today's business; user support and systems management overhead is minimized.

For the user, Single Sign-On provides a seamless experience. This is most practically implemented in an enterprise or Intranet network, since the client needs access to the centralized Authentication Service (for example, Kerberos).

In most configurations, "Same Sign-On" is a more practical goal. The user may have to authenticate to each application separately, but he/she can use the same account credentials for all applications.

Same Sign-On with LDAP

In this configuration, authentication and authorization will be based on LDAP alone. This configuration is suitable for Internet and Intranet applications; users interact only with the Apache server.

Multiple applications can use these same credentials, providing a Same Sign-On experience to the user.

The Apache configuration below has three main ways of authorizing users:

  • The user can be any authenticated user (valid-user)
  • The user must be a specific LDAP user
  • The user must be member of a specific LDAP group

In this example, uncomment only one of the sections:

 <Location /protected>
   # This example demonstrates LDAP integration with FreeIPA.
 
   # Make sure you're using HTTPS, or anyone can read your LDAP password.
   SSLRequireSSL
 
   # ################
   # ### Any User ###
   # ################
   # Order deny,allow
   # Deny from All
   # AuthName "LDAP Login - Any User"
   # AuthType Basic
   # AuthBasicProvider ldap
   # AuthzLDAPAuthoritative off
   # AuthLDAPUrl "ldap://zeus.example.local apollo.example.local/dc=example,dc=local?uid"
   # Require valid-user
   # Satisfy any
 
   #################
   ### LDAP User ###
   #################
   # AuthType Basic
   # AuthBasicProvider ldap
   # AuthName "LDAP Login - LDAP User"
   # AuthLDAPUrl "ldap://zeus.example.local apollo.example.local/dc=example,dc=local?uid"
   # AuthzLDAPAuthoritative on
   # require ldap-user evoncken
   # # Note: list multiple users, separated by spaces
 
   ##################
   ### LDAP Group ###
   ##################
   AuthType Basic
   AuthBasicProvider ldap
   AuthName "LDAP Login - LDAP Group"
   AuthLDAPUrl "ldap://zeus.example.local apollo.example.local/dc=example,dc=local?uid"
   AuthzLDAPAuthoritative on
   require ldap-group cn=webusers,cn=groups,cn=accounts,dc=example,dc=local
   # Note: the ldap-group entry should just be the dn of the group allowed access,
   # add extra lines to permit multiple groups.
 
 </Location>

Single Sign-On with LDAP + Kerberos

In this configuration, authentication is performed by Kerberos. Authorization is handled by LDAP. This configuration is more suited towards Intranet applications where the users can access the Kerberos / IPA Servers.

The LDAP + Kerberos approach provides a Single Sign-On experience to the user.

  • Install the mod_auth_kerb package.
  • Create a Kerberos service principal HTTP/webserver.example.local on the IPA server
  • Store the keytab on the webserver using ipa-getkeytab
  • Make sure /etc/httpd/conf.d/http.keytab is readable by user apache

Preparing the webserver (already an IPA client):

 # yum install mod_auth_kerb
 # kinit admin
 # ipa-getkeytab -s zeus.example.local -p HTTP/webserver.example.local -k /etc/httpd/conf.d/http.keytab
 # chown apache /etc/httpd/conf.d/http.keytab

Step 1: Kerberos authentication only

First, we will set up a and test the simplest case, without LDAP authorization. This is used to test our Kerberos settings.

Users should authenticate either using a compatible browser (Firefox) that has been configured for Kerberos, or by basic username/password authentication. Note that in the latter case, cleartext passwords are sent across the line. The use of a Kerberos-enabled browser is preferred for security reasons.

The Apache configuration for the /protected section on the website looks like this (/etc/httpd/conf.d/zz-webserver.conf):

 <Location /protected>
   # This example demonstrates Kerberos authentication with FreeIPA.
 
   # Make sure you're using HTTPS, or anyone can read your Kerberos password.
   SSLRequireSSL
 
   # Authentication settings
   AuthType Kerberos
   AuthName "Kerberos Login"
   KrbServiceName HTTP
   Krb5KeyTab /etc/httpd/conf.d/http.keytab
   KrbAuthRealms EXAMPLE.LOCAL
 
   # Authorization settings
   require valid-user
 </Location>

Step 2: Add LDAP authorization

Once our Kerberos settings are correct, we will add LDAP authorization based on group membership. In this example, a group "webusers" should be created on the IPA management interface, containing all users that need to access the protected webpages.

 <Location /protected>
   # This example demonstrates Kerberos authentication plus LDAP authorization with FreeIPA.
 
   # Make sure you're using HTTPS, or anyone can read your Kerberos password.
   SSLRequireSSL
 
   # Authentication settings
   AuthType Kerberos
   AuthName "Kerberos Login"
   KrbServiceName HTTP
   Krb5KeyTab /etc/httpd/conf.d/http.keytab
   KrbAuthRealms EXAMPLE.LOCAL
 
   # Authorization settings (redundant LDAP/IPA servers)
   AuthLDAPUrl ldap://zeus.example.local apollo.example.local/dc=example,dc=local?krbPrincipalName
   require ldap-group cn=webusers,cn=groups,cn=accounts,dc=example,dc=local
 </Location>

Step 3: Improve security

There are several issues with the standard configuration:

  1. Cleartext passwords
  2. Cleartext LDAP queries

Cleartext passwords

If Kerberos password authentication is enabled (either KrbMethodK4Passwd or KrbMethodK5Passwd set to 'on'), the cleartext password is made available to the web application (for example, a PHP-based website). This may not be desirable, especially when running third-party web applications.

Solution: Disable both KrbMethodK*Passwd methods; use KrbMethodNegotiate only. This implies that the user obtains a Kerberos ticket before starting a compatible web-browser such as Firefox.

 <Location /protected>
   # This example demonstrates Kerberos authentication plus LDAP authorization with FreeIPA.
 
   # Make sure you're using HTTPS, or anyone can read your Kerberos password.
   SSLRequireSSL
 
   # Authentication settings
   AuthType Kerberos
   AuthName "Kerberos Login"
   KrbServiceName HTTP
   Krb5KeyTab /etc/httpd/conf.d/http.keytab
   KrbAuthRealms EXAMPLE.LOCAL
   # KrbMethodK4Passwd off (results in error - no longer supported?)
   KrbMethodK5Passwd off
 
   # Authorization settings (redundant LDAP/IPA servers)
   AuthLDAPUrl ldap://zeus.example.local apollo.example.local/dc=example,dc=local?krbPrincipalName
   require ldap-group cn=webusers,cn=groups,cn=accounts,dc=example,dc=local
 </Location>

Cleartext LDAP queries

In the above configuration, LDAP queries are made in cleartext. Any credentials, including passwords, are sent across the network without encryption. The risk is limited here since we are only looking up group memberships using anonymous bind. Normally, it is better to use LDAP with StartTLS, or SSL.

See Also

References

Navigation