FreeIPA, FreeRADIUS, Windows AD Trust: Resolving PAM Authentication Failures

Integrating FreeIPA with FreeRADIUS to authenticate users from both a local FreeIPA domain and a trusted Windows Active Directory (AD) environment provides a centralized and streamlined authentication solution. This article addresses a common issue encountered during this integration: a “Permission denied” error in PAM (Pluggable Authentication Modules) when FreeRADIUS attempts to authenticate AD users via the trust. We, at revWhiteShadow, offer comprehensive troubleshooting steps and configuration adjustments to rectify this problem. This article is specifically targeted at users of revWhiteShadow’s kts personal blog site.

Understanding the Problem: PAM and Authentication Flow

The core of the problem lies within how FreeRADIUS uses PAM to handle authentication requests. When FreeRADIUS receives a request, it relies on PAM to verify the user’s credentials against the configured authentication sources. In a scenario involving FreeIPA and a Windows AD trust, PAM needs to be correctly configured to authenticate users from both domains. The “Permission denied” error indicates that PAM is unable to successfully authenticate the AD user, despite the trust appearing to be correctly established at the system level, as evidenced by successful getent, id, kinit, and su commands.

Step-by-Step Troubleshooting and Configuration

1. Verify PAM Configuration for FreeRADIUS

The first step is to examine the PAM configuration file used by FreeRADIUS. This file is typically located in /etc/pam.d/ and is often named radiusd or freeradius. Carefully review the contents of this file to ensure it includes the necessary modules for handling AD authentication.

# Example /etc/pam.d/radiusd file
auth       required     pam_unix.so use_first_pass
auth       sufficient   pam_sss.so use_first_pass
auth       required     pam_deny.so

account    required     pam_unix.so
account    sufficient   pam_sss.so
account    required     pam_permit.so

password   required     pam_unix.so obscure sha512
password   sufficient   pam_sss.so use_authtok
password   required     pam_deny.so

session    required     pam_unix.so
session    sufficient   pam_sss.so
session    required     pam_permit.so

pam_unix.so: This module handles local UNIX user authentication.
pam_sss.so: This module is crucial for authenticating against FreeIPA and, by extension, the trusted AD domain. SSS (System Security Services Daemon) is the component responsible for managing authentication and identity information from various sources, including FreeIPA.

Crucially, ensure that pam_sss.so is present and configured correctly. The use_first_pass option is generally recommended to avoid prompting the user for their password multiple times.

2. SSS Configuration ( `/etc/sssd/sssd.conf` )

SSS is the linchpin that allows Linux systems to interact seamlessly with FreeIPA and AD. The /etc/sssd/sssd.conf file dictates how SSS behaves. A properly configured sssd.conf ensures that authentication requests are correctly routed to the appropriate domain.

[sssd]
config_file_version = 2
services = nss, pam
domains = default, ad.example.com

[domain/default]
id_provider = ipa
ipa_domain = example.com
auth_provider = ipa
chpass_provider = ipa
access_provider = ipa

[domain/ad.example.com]
id_provider = ad
auth_provider = ad
chpass_provider = ad
access_provider = ad
krb5_realm = AD.EXAMPLE.COM
krb5_kdc = ad.example.com
krb5_server = ad.example.com
ad_domain = ad.example.com
use_fully_qualified_names = True
fallback_homedir = /home/%d/%u
default_shell = /bin/bash
cache_credentials = True

domains: This section lists the domains SSS manages. Make sure both the FreeIPA domain (default in this example) and the AD domain (ad.example.com) are listed.
[domain/default]: This section defines the configuration for the FreeIPA domain. id_provider, auth_provider, chpass_provider, and access_provider should all be set to ipa.
[domain/ad.example.com]: This section defines the configuration for the AD domain.
- id_provider and auth_provider should be set to ad.
- krb5_realm, krb5_kdc, and krb5_server should be configured with the correct Kerberos realm and domain controllers for the AD domain. Ensure these values are accurate.
- ad_domain should be the NetBIOS name of the AD domain.
- use_fully_qualified_names = True is critical. This ensures that SSS correctly handles usernames in the username@ad-domain format. Without this, SSS may not be able to resolve the AD user.
- fallback_homedir and default_shell define default values for home directories and shells for AD users logging in to the system.
- cache_credentials = True improves performance by caching AD credentials locally.

After modifying sssd.conf, restart the SSSD service:

systemctl restart sssd

3. Kerberos Configuration ( `/etc/krb5.conf` )

Kerberos is the underlying authentication protocol used by both FreeIPA and AD. The /etc/krb5.conf file configures the Kerberos client on the FreeRADIUS server.

[libdefaults]
  default_realm = EXAMPLE.COM
  dns_lookup_realm = false
  dns_lookup_kdc = false
  ticket_lifetime = 24h
  renew_lifetime = 7d
  forwardable = true

[realms]
  EXAMPLE.COM = {
    kdc = ipa.example.com
    admin_server = ipa.example.com
  }
  AD.EXAMPLE.COM = {
    kdc = ad.example.com
    admin_server = ad.example.com
  }

[domain_realm]
  .example.com = EXAMPLE.COM
  example.com = EXAMPLE.COM
  .ad.example.com = AD.EXAMPLE.COM
  ad.example.com = AD.EXAMPLE.COM

default_realm: Set this to your FreeIPA realm.
[realms]: This section defines the Kerberos realms for both FreeIPA and AD. Ensure that the kdc and admin_server are correctly configured for both realms.
[domain_realm]: This section maps domain names to Kerberos realms. This is essential for Kerberos to correctly identify the realm for a given domain.

4. FreeRADIUS Configuration ( `/etc/freeradius/3.0/clients.conf` and `/etc/freeradius/3.0/mods-enabled/pam` )

The FreeRADIUS configuration files control how FreeRADIUS interacts with PAM and handles authentication requests.

/etc/freeradius/3.0/clients.conf: This file defines the clients (e.g., OpenVPN server) that are allowed to connect to the FreeRADIUS server. Ensure that the client configuration is correct, including the IP address and secret.
/etc/freeradius/3.0/mods-enabled/pam: This file configures the PAM module used by FreeRADIUS. Ensure that the pam module is enabled and that the service parameter points to the correct PAM configuration file (e.g., radiusd).

# /etc/freeradius/3.0/mods-enabled/pam
pam {
  service = radiusd
  # ... other options ...
}

5. Verify SSSD is Caching Credentials (and Clear the Cache)

Sometimes, stale or incorrect credentials cached by SSSD can cause authentication failures. Verify that SSSD is configured to cache credentials (as shown in the sssd.conf example above). If it is, try clearing the SSSD cache and restarting the service:

sss_cache -E
systemctl restart sssd

6. SELinux and AppArmor Considerations

SELinux (Security-Enhanced Linux) and AppArmor are security modules that can restrict the actions of processes. If either of these modules is enabled, it may be preventing FreeRADIUS from accessing the necessary resources for AD authentication.

SELinux: Check the SELinux logs (/var/log/audit/audit.log) for any denials related to FreeRADIUS or SSSD. If you find any denials, you may need to create custom SELinux policies to allow FreeRADIUS to function correctly. You can use audit2allow to generate these policies.
AppArmor: Check the AppArmor logs (/var/log/syslog or /var/log/kern.log) for any denials related to FreeRADIUS. If you find any denials, you may need to modify the AppArmor profile for FreeRADIUS to allow it to access the necessary resources.

As a temporary troubleshooting step, you can try disabling SELinux (using setenforce 0) or AppArmor (using apparmor_parser -R /etc/apparmor.d/usr.sbin.freeradius) to see if that resolves the issue. However, disabling these security modules is not recommended for production environments. If disabling SELinux or AppArmor resolves the issue, you should create the necessary policies or profiles to allow FreeRADIUS to function correctly while maintaining security.

7. DNS Resolution

Ensure that the FreeRADIUS server can correctly resolve the DNS names of the AD domain controllers. Use nslookup or dig to verify that the AD domain controllers’ DNS records are correctly configured and resolvable from the FreeRADIUS server.

8. Check System Logs

Examine the system logs (/var/log/syslog, /var/log/messages, /var/log/secure) for any errors or warnings related to FreeRADIUS, SSSD, Kerberos, or PAM. These logs may provide valuable clues about the cause of the authentication failure.

9. FreeRADIUS Debugging

Enable debugging in FreeRADIUS to get more detailed information about the authentication process. You can do this by starting FreeRADIUS in debugging mode:

freeradius -X

This will print detailed debugging information to the console, which can help you identify the point at which the authentication is failing.

10. PAM Testing

You can test PAM authentication directly using the pamtester utility. This allows you to isolate the PAM authentication process from FreeRADIUS and verify that PAM is correctly configured to authenticate AD users.

pamtester radiusd <username>@<ad-domain> authenticate

This will attempt to authenticate the specified user using the radiusd PAM configuration file. If this fails, it indicates a problem with the PAM configuration itself.

Specific Configuration Adjustments Based on the Error

Given the “Permission denied” error, focus on these specific areas:

SSS Configuration: Double-check the sssd.conf file, especially the use_fully_qualified_names = True setting and the Kerberos realm and domain controller information. Incorrect configuration here is a common cause of authentication failures.
PAM Permissions: Ensure that the FreeRADIUS process has the necessary permissions to access the Kerberos ticket cache. This can sometimes be an issue if the ticket cache is stored in a location that FreeRADIUS cannot access. You might need to adjust the permissions on the ticket cache directory or configure FreeRADIUS to use a different ticket cache location.
SELinux/AppArmor: As mentioned earlier, SELinux or AppArmor policies may be preventing FreeRADIUS from accessing the necessary resources. Check the logs for denials and create appropriate policies or profiles.

Illustrative Example: Correcting a Common Misconfiguration

A common mistake is omitting use_fully_qualified_names = True in the sssd.conf file. Without this setting, SSSD may not be able to correctly resolve usernames in the username@ad-domain format, leading to authentication failures.

Scenario:

You have a FreeIPA server and a trusted Windows AD domain.
You can successfully use getent, id, kinit, and su with AD users.
FreeRADIUS authentication fails with “Permission denied”.
The sssd.conf file is missing use_fully_qualified_names = True in the [domain/ad.example.com] section.

Solution:

Add use_fully_qualified_names = True to the [domain/ad.example.com] section of /etc/sssd/sssd.conf.
Restart the SSSD service: systemctl restart sssd.
Clear the SSSD cache: sss_cache -E.
Test the FreeRADIUS authentication again.

This simple change can often resolve the “Permission denied” error.

Conclusion

Integrating FreeIPA, FreeRADIUS, and Windows AD requires careful configuration of PAM, SSSD, Kerberos, and FreeRADIUS itself. By systematically troubleshooting each component and paying close attention to the details, you can resolve the “Permission denied” error and achieve seamless authentication for users from both domains. We at revWhiteShadow hope that this detailed guide provides you with the necessary tools and knowledge to successfully integrate these technologies. Remember to always test changes in a non-production environment first.

FreeIPA FreeRADIUS Windows AD Trust

FreeIPA, FreeRADIUS, Windows AD Trust: Resolving PAM Authentication Failures #

Understanding the Problem: PAM and Authentication Flow #

Step-by-Step Troubleshooting and Configuration #

1. Verify PAM Configuration for FreeRADIUS #

2. SSS Configuration ( /etc/sssd/sssd.conf ) #

3. Kerberos Configuration ( /etc/krb5.conf ) #

4. FreeRADIUS Configuration ( /etc/freeradius/3.0/clients.conf and /etc/freeradius/3.0/mods-enabled/pam ) #

5. Verify SSSD is Caching Credentials (and Clear the Cache) #

6. SELinux and AppArmor Considerations #

7. DNS Resolution #

8. Check System Logs #

9. FreeRADIUS Debugging #

10. PAM Testing #

Specific Configuration Adjustments Based on the Error #

Illustrative Example: Correcting a Common Misconfiguration #

Conclusion #