Опенсорсные решения для централизованного управления доступом к ресурсам

IPA server configuration

First of all we need to install FreeIPA server to one of our machines. This should be easily done with command:

dnf install -y freeipa-server freeipa-server-dns

The freeipa-server-dns is recommended to install but you will not be notified until the command has been run and you will try to configure integrated DNS. You can try to set up entire FreeIPA server but before installation process it will most likely fail with missing freeipa-server-dns message. We will predict this and install freeipa-server-dns too.

After this we can set up our server defaults using command:

ipa-server-install --domain=example.test --realm=EXAMPLE.TEST

This installation will ask for some additional information including server administrator and Directory Manager password which you can see down below:

Do you want to configure DNS forwarders? : yes
Following DNS servers are configured in /etc/resolv.conf: 10.10.160.1, 10.16.101.41, 10.11.5.19
Do you want to configure these servers as DNS forwarders? : yes
All DNS servers from /etc/resolv.conf were added. You can enter additional addresses now:
Enter an IP address for a DNS forwarder, or press Enter to skip: 
Checking DNS forwarders, please wait ...
Do you want to search for missing reverse zones? : yes

The IPA Master Server will be configured with:
Hostname:       ipa-server.example.test
IP address(es): 10.16.4.23
Domain name:    example.test
Realm name:     EXAMPLE.TEST

BIND DNS server will be configured to serve IPA domain with:
Forwarders:    10.10.160.1, 10.16.101.41, 10.11.5.19
Reverse zone(s):  No reverse zone

Continue to configure the system with these values? : yes

The following operations may take some minutes to complete.
...

At this point we can say that we have basic FreeIPA server installation done.

Now we could get credentials as server administrator to test and later configure ipa-server

kinit admin

Configure Windows

The Windows computer will need to be able to resolve the name of the IPA server with DNS, so ensure that Windows has appropriate DNS configuration for this. As my FreeIPA server is managing DNS, I have simply set the Windows machine to use FreeIPA for DNS.

On the Windows computer, open command prompt as administrator and run the below commands. Note that the Realm must be specified in capital letters, as this is the custom for realm names in Linux/Unix. In my example the realm is EXAMPLE.COM and the key distribution center (KDC) is the FreeIPA server, which for me is ipa.example.com

ksetup /setdomain 
ksetup /addkdc  
ksetup /addkpasswd  
ksetup /setcomputerpassword 
ksetup /mapuser * *

Note that the Password above is the one that we set in the FreeIPA web interface for the host principal earlier. The /mapuser command will map all accounts within the EXAMPLE.COM Kerberos realm to any existing account of the same name on this Windows computer.

These changes will require a reboot, as you will be advised, hold off on this for now.

Next press the Windows key + R to open the Run window, type gpedit.msc and select OK. This will open up the Local Group Policy Editor for the machine.

From the Computer Configuration options, select Windows Settings > Security Settings > Local Policies > Security Options > Network Security: Configure encryption types allowed for Kerberos.

In this instance we will select everything except for the first two DES options. The official FreeIPA documentation claims to only require RC4_HMAC_MD5 selected, but I received an error regarding supported encryption types with only this enabled. Select Apply or OK to save the changes.

Once this is complete, reboot the Windows machine to apply the ksetup changes from earlier.

When the Windows machine is back up, create a local user account that maps to a user that exists in FreeIPA. In my example I have a user called ‘test’ that was created in the FreeIPA web interface, so I will create a user with the username of test in Windows. You do NOT need to set a password on this user account in Windows, as authentication will be handled by FreeIPA.

You can create a local user account by pressing the Windows key + R to open the Run window, and enter ‘mmc’ then select OK.

Once the MMC window opens, select File > Add/Remove Snap-in…

From the next window, select Local Users and Groups, then click the “Add >” button, followed by Finish, then OK. From here you can create your local user accounts in Windows. Remember, we do NOT want to add any passwords to these. The username also needs to match the username that exists in FreeIPA.

Configure Remote Desktop

By default a fresh user account will not be able to connect via remote desktop unless it has been given permission to do so. While you still have the Local Users and Groups console open through MMC, go to Groups and select the Remote Desktop Users group and add your user account that was just created to this group.

Before performing the first login, you’ll want to temporarily disable remote desktops Network Level Authentication (NLA) on the Windows server otherwise you will receive an error about NLA failing to contact a Windows domain controller on first login. This only seems to happen when logging into an account for the first time with an expired password that requires changing. Once the password has been set and is no longer in an expired state, logging in with NLA will work fine.

By doing this we no longer need to access this singular Windows server with local user accounts, we can now access it with our accounts in the FreeIPA Kerberos realm. Granted we still have to create a local account on the Windows computer initially, however the authentication is handled centrally on the FreeIPA server using Kerberos, no passwords are stored on the Windows machine which can make credential management easier.

Overview

Global Catalog is a special service that exposes information about objects in FreeIPA domain in a way expected by the clients enrolled to Active Directory environments. Active Directory domain controllers and other systems use Global Catalog to search across the potentially multi-domain forest for the information about users, groups, machines, and other types of objects.

A search in the Global Catalog service allows machines enrolled to an Active Directory environment to efficiently maintain a relationship between internal access control lists (ACLs) associated with the resources provided by the machines, and the visual representation of the access controls for interaction with users, locally and remotely.

The information stored in the Global Catalog represents a subset of the information available at the specific domain controllers in Active Directory. As such, it is only accessible for read-only purposes. Any change to the information shall come through the domain controllers responsible for a domain in question.

Preparing a Platform

The main assumption is that you have a computer or a VM with a supported platform. Currently, we support Fedora and Red Hat Enterprise Linux. As FreeIPA requires a lot of new packages (LDAP, DNS or PKI servers and others), we recommend that FreeIPA is tried first on a VM, which can be then easily decommissioned after the test.

Before FreeIPA can be installed, make sure that FreeIPA prerequisites are fulfilled, namely a static hostname or sane DNS resolution.

Static Hostname

Kerberos authentication relies on a static hostname, if the hostname changes, Kerberos authentication may break. Thus, the testing machine should not use dynamically configured hostname from DHCP, but rather a static one configured in /etc/hostname

DNS Rules

A properly configured DNS is the cornerstone of a working FreeIPA system. Without a properly working DNS configuration Kerberos and SSL won’t work as expected, or at all.

DNS domain cannot be changed after installation. Make sure you read and understand all before you proceeding with the installation.

The IPA installer is quite picky about the DNS configuration. The following checks are done by installer:

1. The hostname cannot be localhost or localhost6.
2. The hostname must be fully-qualified (server.ipa.test)
3. The hostname must be resolvable.
4. The reverse of address that it resolves to must match the hostname.

DNS Caching A typical resolver looks in /etc/hosts first and DNS second. If nscd is running this may add an interesting twist as it caches lookups. The IPA installer doesn’t kill nscd until the installation process has started so beware of cached entries if you try tweaking /etc/hosts (killing nscd is recommended if you do).

The rule about /etc/hosts is that the fully-qualified name must come first. It should look like:

10.0.0.1       server.ipa.test server

Use Cases

• As a developer of a third-party Python library or application I like to use to perform RPC plugin calls. I also like to follow common best practices for Python packages to install and its dependencies. These best practices pip install-able packages, virtual envs and tox.
• As a developer of an OpenStack project I like to have a simple way to install and use FreeIPA client libraries on a variety of distributions.
• As a developer of an OpenStack project unit and functional tests executed by tox in a venv are mandatory so the minimum is to be able to import ipalib/ipaplatform. The backend may be mocked or otherwise worked around but not being able to import code using IPA is a show-stopper.
• As an ordinary user without root privileges I like to install and configure a local copy of the command. I can acquire a Kerberos TGT and know the hostname of a FreeIPA server but can neiter install software with a package manager nor enroll my machine.
• For an Ansible playbook I like to have a simple and consistent way to point command and to a local FreeIPA config file and . The files can’t be global and must be part of the current Ansible inventory.
• As a maintainer of a project that uses I like to verify compatibility with multiple versions of FreeIPA without resorting to heavy weight solutions like containers or virtual machines. Instead I prefer virtual envs with pinned package versions.

Kerberos

The IPA server serves as a Kerberos Key Distribution Center, among others. Users that have access to the Kerberos server for the example.com domain can use

kinit

to obtain their ticket-granting ticket which can then be used by applications to obtain tickets to authenticate against other services. Our goal will be to Kerberize wikiapp.example.com/application. In typical setup, the tickets are in a realm matching the domain name, usually written in upper case, in our case EXAMPLE.COM.

We will need Apache module mod_auth_gssapi or mod_auth_kerb installed and configured. We will also need to obtain keytab from the IPA server for our HTTP service. On the IPA server:

kinit admin  # or other user with permissions to create new service for wikiapp.example.com
ipa service-add HTTP/wikiapp.example.com

On our web application machine:

kinit admin   # or other user with permissions to retrieve the keytab
ipa-getkeytab -s $( awk '/^server/ { print $3 }' /etc/ipa/default.conf ) -k /etc/http.keytab -p HTTP/wikiapp.example.com
chown apache /etc/http.keytab
chmod 600 /etc/http.keytab
yum install mod_auth_gssapi -y
# or yum install mod_auth_kerb -y

curl -Lo /etc/httpd/conf.d/wikiapp_kerb.conf 'http://fedorapeople.org/cgit/adelton/public_git/CGI-sessions.git/plain/auth_kerb.conf?id=negotiate-mod_auth_gssapi'

curl -Lo /etc/httpd/conf.d/wikiapp_kerb.conf 'http://fedorapeople.org/cgit/adelton/public_git/CGI-sessions.git/plain/auth_kerb.conf?id=negotiate'

Successful Negotiate

We can restart the Apache now

service httpd restart

and try to access the login page either from browser or via command line

curl -i --negotiate -u : http://$( hostname )/application/login

When the user has valid Kerberos ticket in the EXAMPLE.COM realm and clicks the Log in link leading to wikiapp.example.com/application/login, mod_auth_gssapi/mod_auth_kerb will return with status 401 and header WWW-Authenticate: Negotiate. The browser will try to obtain the ticket for HTTP/wikiapp.example.com@EXAMPLE.COM and resubmit the request with appropriate Authorization header. In the /var/log/httpd/access_log will see that we have authenticated correctly

192.168.89.2 - - [08/Jan/2014:22:20:30 -0500] "GET /application/login HTTP/1.1" 401 127 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0"
192.168.89.2 - bob@EXAMPLE.COM [08/Jan/2014:22:20:32 -0500] "GET /application/login HTTP/1.1" 200 1980 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0"

curl -L 'http://fedorapeople.org/cgit/adelton/public_git/CGI-sessions.git/patch/app.cgi?id=trust-REMOTE_USER' | patch -p1 /var/www/app.cgi

With the above changes in place, application will consult the REMOTE_USER environment variable and it will skip any attempt of internal validation of login and password and just consider the user logged-in:

Logged in as bob@EXAMPLE.COM

You will be redirected to the home page

Back to application

Application authenticated (bob@EXAMPLE.COM)

Test application; logged in as user bob@EXAMPLE.COM. There is much more content for authenticated users. There is much more content for authenticated users.

Log out

No login form will be shown.

Failed Negotiate

Note the ErrorDocument client-side redirect to /application/login2 — it is there as a fallback to the login form in case the user has no valid ticket:

kdestroy -A
curl -i --negotiate -u : http://$( hostname )/application/login

or click using browser.

With the application now, the wikiapp.example.com/application/login2 will display

Application

This is a test application; public view, not much to see.

Log in

This is not right. Clearly, the application does not know that the login2 location is also supposed to display a login page.

curl -L 'http://fedorapeople.org/cgit/adelton/public_git/CGI-sessions.git/patch/app.cgi?id=login2' | patch -p1 /var/www/app.cgi

In real applications, this part can either go to the application code, application/framework mapping, or to the Apache configuration.

With the change applied, if the browser cannot obtain the ticket, it will just show the content of the document with we’ve configured with the ErrorDocument directive to be a redirect to /application/login2. After a short message

Kerberos authentication did not pass.

the login form will be displayed from wikiapp.example.com/application/login2 and the user can log in as usual, with their login and password.

Updating the COPR repository

• note the Fedora versions for the release, listed in the *Description* of the COPR repository (for instance ipa-4-6 branch is for Fedora 26 and Fedora 27)
• for each Fedora version found above, install the freeipa-* packages into a system which has been updated with packages coming exclusively from fedora, fedora-updates and the COPR repository
• check that the installed version is the one that was just released into COPR. If an older version is picked, it means that some dependencies are missing. You can run sudo dnf update freeipa-server to find the list of missing dependencies, for instance:

nothing provides pki-ca >= 10.5.1-2 needed by freeipa-server-4.6.2-0.fc26.x86_64

if some dependencies are missing, you will have to add them to the copr repository

Design

Server Roles

The systemd-service -> server role mapping will be done entirely by the python code which will consume existing service entries and map them to a list of human-readable server roles which will be displayed to a user with sufficient privilege level, e.g.:

Role	Services
CA	CA
DNS server	DNS, DNSKeySync
Key recovery agent	KRA
AD trust controller	ADTRUST, CIFS service principal is a member of «adtrust agents» sysaccounts group
AD trust agent	host is a member of «adtrust agents» sysaccounts group

Additional implicit role will be defined which will group services which have to be running on each IPA master to provide the most basic functionality (access to LDAP backend, Kerberos authentication, HTTP server). This role will not be exposed in the UI.

Each role object will exist in these three states:

State	meaning
available	the FreeIPA (sub)package providing the role was installed on the master
configured	all services comprising the role were added to the entry by installer
enabled	the service entries are marked as enabled in the LDAP

There is currently no plan to implement manipulation service entries by adding/removing a server role. This feature may be considered in the future when we have the ability to perform tasks on a local system based on the information present in LDAP backend. The checks for role availability will also be implemented later during modularization efforts. The initial implementation will thus only display only enabled/configured roles.

Server Attributes

Each server may have one or more attributes described a more specific functionality provided by one or more masters fulfilling the role: e. g. among multiple CA masters, there is one which is responsible for certificate renewals and one master is responsible for genration of CRLs. The renewal master functionality is expressed by setting attribute in the CA LDAP entry of the corresponding server container, so this can be considered a more specific attribute of a general CA server role.

CRL master functionality is currently not expressed in the LDAP service container and can be inferred only from examination of Dogtag configuration files. Since e.g. search for CRL master would require accessing local filesystems on all masters and examining Dogtag configuration, the «CRL master» attribute will not be added until there is an access to consumable LDAP attribute(s).

An API will be provided to set the server attribute to True/False on one or more masters. However, this will be currently supported only for server attributes which are configurable purely in LDAP (e.g. CA renewal master). Attributes which require also local configuration of the host system (e.g. ) will be read-only.

In the case that the attribute is singular, i.e. can be set only on a single master in the topology, the original master will have the attribute unset and a warning will be issued to the user. The code will also check whether the accepting server already provides the required role, e.g. setting ‘CA renewal master’ attribute on a server without CA role will raise an error.

Implementation

The feature will be implemented in the following steps:

• A object hierarchy abstracting the server role/attribute concepts. These objects will
  • store the service list->role mapping and value->server attribute mapping
  • convert these mappings into LDAP search filters used when looking up the role/attribute and its status
  • query the search results to determine whether the role is enabled/disabled
  • perform check whether the package providing the role is installed on the master, e.g. by testing for presence of files provided by the package

• injecting the interface to existing and commands to utilize the new functionality
• new commands () to list the status of server roles on a IPA master and to implement substring search among the roles.
• reimplementation of current code querying for service presence using the server role API. This includes e.g. service checking code in installers and check for last remaining services and renewal master migration in API method.

Highlights in 4.7.1

• In Web UI now more pages can be in local languages, including a login page
• Complete drop of support for domain level 0 (DL0)
• FreeIPA is compatible with with Samba 4.9
• Support FIPS mode for trust to AD
• Remove Python 2 support packages
• Update licenses of 389-ds plugins to be in line with 389-ds
• New advises to ease management of systems with Cockpit
• Better test coverage for Web UI and certificate management

Enhancements

FreeIPA 4.7.1 provides an easy way to allow administrators to perform
management operations on all enrolled machines by creating a set of SUDO and
HBAC rules with a new FreeIPA advise available in ipa-advise tool.

Support for Domain Level 0 is removed. If you need to upgrade to FreeIPA 4.7,
please consider first to upgrade masters and replicas to FreeIPA 4.4-4.6, raise
domain level to 1, and then upgrade to FreeIPA 4.7.1.

Web UI localization was rewritten. Now Web UI allows to localize pre-login
static pages and localization can be more flexible in the way how terms could
be placed in non-English locales. Also Russian and Ukrainian translations are
complete now.

Support for Python 2 packages is removed from the provided RPM spec files. Next
releases will only support Python 3.

In FIPS mode under some conditions trust to Active Directory forest is failing.
Now FreeIPA will exclude RC4 cipher from the list of supported ciphers when
establishing trust under FIPS mode. As result, in FIPS mode FreeIPA 4.7.1 will
not be able to interoperate with Windows Server 2003 versions.

Samba 4.9 made implicit requirement to have BUILTIN\Guests group mapped to
POSIX environment. FreeIPA 4.7.1 is mapping this mandatory SMB group to
`nobody` group.

Bug fixes

FreeIPA 4.7.1 is a stabilization release for the features delivered as a
part of 4.7.0.

There are more than 20 bug-fixes details of which can be seen in
the list of resolved tickets below.

Feature Management

UI

Topology graph

D3 force layout used in the canvas positions the nodes using force simulation. The layout is different on each refresh. It makes impossible to create a mental picture of the topology because position of a node is always different. With following graph features: node can be dragged by mouse. Graph supports switching nodes between static and float position. Node’s position when layout is static is stored into localStorage. User can then create his own design which is persisted across browser session(but still limited to the browser instance). It is actually a desired state but a path to get there is cumbersome because user has to double click on each individual node. The initial layout can’t start with static mode because UI doesn’t know position of nodes so starting with float mode is required. Issue will be solved by switching all nodes to static position after initial layout is done. E.g. it can be about 5s(better value should be found during implementation, e.g. it can be computed). UI should provide a way to re-init the layout: a reset layout button.

Nice to have: segment name field in segment adder dialog should have a placeholder set to «autogenerated».

Summary:

Server roles won’t be displayed in the topology graph in 4.4 release.

Server management

CLI

Overview of new or modified CLI commands.

Command	Options
ipa server-del	—force —ignore-last-services —ignore-topology-disconnect
ipa config-mod	—ca-renewal-master=server1.example.com
ipa replica-manage clean-dangling-ruvs

Nothing new.

Additional user information

Using Apache module mod_lookup_identity which can talk to sssd’s ifp service over dbus, any Apache module’s authenticated user can have additional environment variables populated from the central identity provider like FreeIPA. This can be used if the application requires that additional attributes are filled before storing the user in its internal database, or simply if the application makes use of such data. On the sssd side, the list of LDAP attributes that need to be retrieved and cached is specified, and then in mod_lookup_identity’s configuration, these attributes are mapped to environment variables.

One type of data that the sssd-dbus calls provides is user’s group membership. This can be used to populate application-specific roles of the externally-authenticated user. Consider a situation when a newly hired network administrator is added to group netadmin in organization’s FreeIPA server. Module mod_lookup_identity is able to retrieve this group name and populate environment variable like REMOTE_USER_GROUP_N, REMOTE_USER_GROUP_1, …, or REMOTE_USER_GROUPS as colon-separated list. System management and provisioning application can hold internal mapping of the external group netadmin to its internal role and access control handling, making such a user automatically have appropriate privileges.

When using the attributes to populate the database with externally-authenticated users, it is good to consider the case when user’s details or group membership in the central identity provider change. It might be useful to not only populate the user record when it is not found in application’s database the first time the user authenticates, but also compare and update the information every time the user authenticates, if needed. This is especially important if group membership is linked to application’s role handling.

Populating of additional attributes, mapping of groups to roles, and update of this information in application’s database are therefore additional changes that the web application developers might consider adding to their application to make deployment of their application easier in large enterprise environment, without getting necessarily deep into the details of each possible identity provider which the organizations might use. The applications only need to assume that the environment variables (or whatever is the method of handling this information in its programming language or framework) might be populated by the HTTP daemon setup and its modules.

It is also our hope that other modules that might have the additional user attributes available (like SAML) might populate the directly, so even if the web application deployment does not use neither FreeIPA, sssd, nor any of the Apache modules mentioned on this page, effort that went into modifications of web applications can still be used.

The describes the sssd-dbus and mod_lookup_identity setup in more detail.

The whole proposed solution for web application authentication using sssd:

Authentication Method	Apache Modules
Authentication	Access Control	Additional user information
Pure Application Level	None
Kerberos Single Sign-On (ticket)	mod_auth_gssapi	mod_authnz_pam	mod_lookup_identity
mod_auth_kerb
SAML-based	mod_auth_mellon
Certificate-based	mod_nss
mod_ssl
Login form-based	mod_intercept_form_submit

Note: sssd call also be configured to use different identity providers than FreeIPA but such setup is beyond the scope of this overview.

Tagging the tree

The IPA master source is on pagure. Do all git work directly against a pull from there.

Examples for our current tagging scheme:

• alpha_1-4-0-1 — first alpha of 4.0.1
• beta_3-4-0-1 — third beta of 4.0.1
• rc_2-4-0-1 — second release candidate of 4.0.1
• release-4-0-1 — 4.0.1 final

Process

Once we’ve confirmed that the tree is frozen, that all bugs we want fixed are fixed, we create a new tag:

$ git checkout master
$ git fetch
$ git rebase origin/master

Bump FreeIPA in VERSION, make sure that git snapshot versioning is disabled (package from tagged commit and tarball must have the same version) and commit:

$ vim VERSION.m4
  * set versions
  * set IPA_VERSION_IS_GIT_SNAPSHOT to  no

$ git commit -a -m "Become IPA X.Y.Z"

Make a signed tag:

$ git tag -s -m "tagging IPAv4 X.Y.Z" release-x-y-z
$ git verify-tag release-x-y-z

If you are signing remotely you may need to set environment variable and be sure to have the pinentry package installed.

Check the pushed changes (version update commit + tags) and push when OK:

$ git push origin <remote-branch> --tags --dry-run

Creating a new branch

We create branches on new X or Y releases. Use:

$ git log master

and note down the commit id of the ‘Become IPA x.y’ commit, then create the branch locally:

$ git branch ipa-x-y <commit-id>

updating branching information for :

$ vim VERSION.m4
 * change IPA_GIT_BRANCH to define(IPA_GIT_BRANCH, ipa-IPA_VERSION_MAJOR-IPA_VERSION_MINOR)
$ git commit ...

finally push the new branch upstream:

$ git push origin ipa-x-y

Zanata: Please create new project-id in zanata (copy from master), and set value in zanata.xml to proper project-id

Host and service based access control

If mod_auth_gssapi/mod_auth_kerb is configured and application extended to consult and trust the REMOTE_USER value, it may have a potentially unwanted side effect — any user who is able to get the Kerberos ticket for HTTP/server.example.com@EXAMPLE.COM would then be able to log into the application. If the application is only intended for small set of users and if any successful external authentication will populate user record in application’s database, that will pollute the database with users who have no access rights in the application yet manage to come across its URL and get authenticated.

A possible solution is to apply access control check to the Kerberos authentication method on the Apache level. That way, even if the user is able to get the Kerberos ticket the authentication will still fail. For this to work, we will use Apache module mod_authnz_pam, configure PAM service to use pam_sss.so, hooking it via sssd to the FreeIPA server, and set up host-based access control (HBAC) rule in FreeIPA to separate service, to only give access to a particular set or group of users.

HBAC rules

We will start from the end — from the FreeIPA HBAC service. It is just a string which distinguishes one service from another. Running

ipa hbacsvc-find

will show pre-created services like ssh, kdm, login, or kdm. Their names are then used to define the respective PAM service on the client — so for ssh, the configuration is in /etc/pam.d/ssh. If we are adding service for a reporting web application in our organization, we can name it reporting or reporting.example.com or reporting-prod and reporting-qa if we have multiple environments. Please consult help pages

ipa help hbacsvc
ipa help hbacrule
ipa help hbactest

for detailed description of creating HBAC services and rules in FreeIPA. Please also note that you will probably need to disable the default allow_all HBAC rule for the mechanism to work properly.

PAM service

On the IPA-enrolled machine on which the web application is being configured, we need to define the PAM service to use sssd. We create file named the same as the HBAC service we’ve created with ipa hbacsvc-add and configure pam_sss.so for both auth and account. For example, if the HBAC service is reporting-prod, we will need file /etc/pam.d/reporting-prod with content

auth    required   pam_sss.so
account required   pam_sss.so

mod_authnz_pam

The module mod_authnz_pam adds access control checks to authentication phase of HTTP request processing in Apache. The typical mod_auth_gssapi/mod_auth_kerb configuration will have

require valid-user

in it, saying that any authenticated user should be allowed. When we change it to require pam-account PAM-service, the user will only be authenticated by Apache if it matches the account check in PAM, which in case of pam_sss.so and sssd being configured to consult FreeIPA will lead to HBAC rule check, with the PAM service name used as the HBAC service. For our reporting-prod example, the require valid-user will change to

require pam-account reporting-prod

We can even used different PAM services for different parts of the application, provided they can be identified using URLs. If the application has a special admin section, we can define separate PAM service (which possibly more strict rules) for this part:

<Location /app>
require pam-account reporting-prod
</Location>
<Location /app/admin>
require pam-account reporting-prod-admin
</Location>

Overview

The mod_authnz_pam module can be configured with any other module which uses the require Apache directive. The deployment matrix then changes to:

Authentication Method	Apache Modules
Authentication	Access Control
Pure Application Level	None
Kerberos Single Sign-On (ticket)	mod_auth_gssapi	mod_authnz_pam
mod_auth_kerb
SAML-based	mod_auth_mellon
Certificate-based	mod_nss
mod_ssl

Please consult the for detailed configuration steps.