Jump to: navigation, search

Apache Group Based Authorization

Revision as of 08:41, 29 May 2015 by Ab (talk | contribs) (*** DRAFT VERSION - WORK IN PROGRESS TO BE COMPLETED ***)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)


Following on from the previous documentation for an IPA backend to protect Apache it's not unusual to require only a subset of users to have access to a system rather than all valid users.

There's two approaches that will be taken in this document - the first will be PAM based authentication and the second will be extended the previous kerberos configuration with LDAP groups. There are pros and cons to each direction and each are suitable for different scenarios dependant on the use case.

Using PAM authentication

With the EPEL repository enabled installing the mod_auth_pam package will install teh module, add a configuration file to httpd to enable the module and place an httpd file in /etc/pam.d for the PAM configuration.

The default is to use whatever is in /etc/pam.d/password-auth but this may be overkill. To just use SSSD all that is needed is:

 auth        required      pam_env.so
 auth        sufficient    pam_sss.so 
 auth        required      pam_deny.so
 account     sufficient    pam_sss.so
 account     required      pam_deny.so

To allow httpd to talk to PAM with selinux enabled a boolean needs to be set:

 setsebool -P allow_httpd_mod_auth_pam on

With that in place it's simple enough to add user/group behaviour via adding the appropriate entries for the directory or location concerned in the conf files or .htaccess:

 AuthPAM_Enabled on
 AuthType Basic
 AuthName "Group Restricted  Server"
 require valid-user


This will work with the HBAC options/pages in IPA (add httpd as a service) so allow for testing of rules. A user won't be considered 'valid' unless it can pass the HBAC tests. This way controls can be centralized with a standardized httpd config or standard users have very simple copy/paste to go into .htaccess over multiple servers very easily. This also does not require any sort of ldap service user to bind as (and consequently any plain text passwords anywhere) since it is the system carrying out the check via the secure kerberos/ldap mechanism through SSSD. Optionally rather than require valid-user require group can be used - with the downside this wouldn't be visible in the IPA UI and HBAC would still need to be completed so it could confuse in troubleshooting.


Depending on httpd activity this has the potential for being fairly heavy on load - principally due to HBAC having a fairly short cache time. This may or may not be a problem depending on the use case of the httpd server. This only offers basic auth so no single sign on would be available - if that's a desirable feature.

Using LDAP groups alongside Kerberos Authentication

With Kerberos already working we can add LDAP groups via mod_authnz_ldap which is included in the base httpd install. The important lines to look at for basic lockdown via groups are:

 require ldap-group

The bind user and password are only required if anonymous lookups are disabled (which is preferred in general).

First a dedicated system user should be created to use to bind with. To do this create a file (eg httpbind.ldif) containing the following:

 dn: uid=httpbind,cn=sysaccounts,cn=etc,dc=example,dc=com
 changetype: add
 objectclass: account
 objectclass: simplesecurityobject
 uid: httpbind
 userPassword: ohaimakethissimethingtoughtobreak
 passwordExpirationTime: 20380119031407Z
 nsIdleTimeout: 0

This can then be imported by:

 ldapmodify -h ipa01.example.com -p 389 -x -D "cn=Directory  Manager" -w <DM Password> -f httpbind.ldif

Now the configuration can be carried out. Full details can be found here but in brief...

 AuthLDAPURL	ldaps://ipa01.example.com:636/dc=example,dc=com
 AuthLDAPBindDN	uid=httpbind,cn=sysaccounts,cn=etc,dc=example,dc=com
 AuthLDAPBindPassword	ohaimakethissimethingtoughtobreak
 require ldap-group
 LDAPTrustedGlobalCert CA_BASE64 /etc/httpd/certs/ca.crt
 AuthLDAPGroupAttributeIsDN off

Make sure that /etc/ipa/ca.crt has been copied to a location that httpd can read (such as /etc/httpd/certs/ca.crt if following the previous guide).