Chapter 9. Security hardening of IdM in RHEL
Apply recommended practices to harden your Identity Management (IdM) deployment against common threats. Secure identities, harden access control, ensure system integrity, and implement security monitoring and detection. Follow a priority guide that sequences the controls by risk and urgency.
9.1. Identity protection in IdM
Protect Identity Management (IdM) identities against credential theft.
- Require MFA for all users, administrative and non-administrative ones
- First, eliminate the risk of credential theft for privileged accounts. This ensures that even if a password is leaked, an attacker cannot authenticate without the second physical or temporal factor. Administrative accounts are the highest-value targets in any IdM deployment and must be protected first. After that, consider extending this protection to the entire user base.
- Rotate the Directory Manager password and restrict its use
The Directory Manager DN (
cn=Directory Manager) authenticates directly against the underlying 389 Directory Server via a simple LDAP bind, bypassing Kerberos, MFA policies, HBAC rules, and all access controls. It is not an IdM user account and cannot benefit from any MFA policy configured in IdM.NoteTreat it as a break-glass credential, that is an emergency-access account used only when normal access paths are unavailable: store it in a secrets vault or sealed procedure, prohibit routine use, log every use, and rotate on a defined schedule. Day-to-day administration should always use a named admin account.
- Limit
admingroup membership - Reduces the blast radius. Fewer users with full privileges means a smaller statistical chance of a high-value account being compromised. Review membership periodically and remove accounts that no longer require it.
To implement the above-mentioned recommendations, see the following table:
| Recommendation | Documentation |
|---|---|
| Require MFA for all users, administrative and non-administrative ones | |
| Rotate the Directory Manager password and restrict its use | |
|
Limit |
9.2. Access control hardening in IdM
Restrict access in your Identity Management (IdM) deployment to enforce a Zero Trust model.
- Disable the
allow_allHBAC rule -
Shifts the environment to a Zero Trust model. The default
allow_allrule grants every enrolled user login access to every enrolled host — a direct violation of least-privilege. Disable it immediately and replace it with specific, scoped host-based access control (HBAC) rules that permit only the access each role genuinely requires.
- Verify that TLS is used when IdM clients communicate with IdM servers through LDAP
Plain LDAP on port 389 transmits credentials and directory data in cleartext, making it interceptable on the network. Check that trying to initiate StartTLS results in an error because an SSL/TLS connection is already established:
$ ldapsearch -x -ZZ '(uid=admin)'ldap_start_tls: Operations error (1) additional info: SSL connection already established
- Keep SELinux enforcing on all IdM servers and map users to SELinux contexts
-
SELinux must remain in enforcing mode on all IdM servers — disabling it removes mandatory access controls for the server itself and all enrolled hosts. Beyond keeping SELinux enforcing, map IdM users to confined SELinux users (for example,
staff_u,user_u) to ensure the Linux kernel restricts what files or processes a user can interact with, even if their account is compromised. Ensure all enrolled users are explicitly mapped and restrictunconfined_uto accounts that genuinely require it.
- Define custom RBAC roles
- Enforces least privilege. The built-in IdM roles (User Administrator, Group Administrator, etc.) are intentionally broad — designed to be usable by all RHEL IdM customers and will not match the specific permission boundaries of your deployment. Use them as a reference, then create custom roles that grant only the privileges each administrative function requires.
- Disable anonymous LDAP binds
Set the
nsslapd-allow-anonymous-accessattribute torootdseto prevent user enumeration and thereby reduce the risk of brute-force or phishing attacks.Do not set the attribute to
off, because this blocks external clients from checking the server configuration. LDAP and web clients are not necessarily domain clients, so they connect anonymously to read therootDirectory Server Entry (DSE) file to get connection information.
- Restrict
adminlogin locations - Prevents remote exploitation. Requiring administrators to authenticate from a designated Jump Host or secure console stops attackers from using stolen credentials over the general network, even if MFA is bypassed through a client-side compromise. In addition, you can use Kerberos authentication indicators to secure access to the jump hosts.
- Disable the Schema Compatibility (
compat) plugin when not needed -
The compat plugin creates a virtual NIS/RFC 2307-compatible subtree at
cn=compat,dc=…that is enabled by default. It was designed for backward compatibility with legacy clients that cannot speak the native FreeIPA LDAP schema. The security risk is that this subtree exposes user and group information in a broadly readable form and can remain accessible even after anonymous binds are disabled on the main directory tree. If all enrolled clients use SSSD with the ipa provider, the compat tree serves no purpose. Disable it withipa-compat-manage disableand restart the directory service. If legacy NIS clients still depend on it, isolate those clients at the network level so the compat tree is not reachable from general network segments.
- Review
sudorules regularly -
sudorules are a common and often overlooked privilege escalation vector. An overly broadsudorule can grant a regular user effectiverootaccess on enrolled hosts without that access appearing in HBAC or RBAC reviews. Runipa sudorule-find --allperiodically and audit each rule: confirm the scope of hosts and commands is intentional, remove rules that are no longer needed, and ensure no rules grant unrestricted (ALL) command access without a documented justification.
To implement the above-mentioned recommendations, see the following table:
| Recommendation | Documentation |
|---|---|
|
Disable the | |
| Keep SELinux enforcing on all IdM servers and map users to SELinux contexts | |
| Define custom RBAC roles | |
| Disable anonymous LDAP binds | |
|
Restrict | |
|
Review |
9.3. System integrity in IdM
Protect the infrastructure that Identity Management (IdM) depends on.
- Dedicated IdM servers (no co-located services)
- Reduces the attack surface. IdM servers hold the Kerberos KDC, LDAP directory, and CA, which are the most sensitive components in your identity infrastructure. Co-locating web servers, databases, or other workloads introduces unrelated vulnerabilities that could be used to pivot directly into the identity store.
- Enable FIPS mode during RHEL installation (regulated environments)
If operating in a regulated environment (for example, FedRAMP, NIST 800-53, PCI-DSS, or government/defence contexts), enable FIPS 140-2/140-3 mode on the underlying OS before deploying IdM. FIPS mode restricts the system to approved cryptographic algorithms system-wide, covering Kerberos, TLS, and all OpenSSL consumers.
NoteFIPS mode must be enabled before IdM installation. Enabling it post-deployment requires reinstallation. Therefore, verify that all clients and integrated services support FIPS-compliant cipher suites before enabling.
- Back up IdM data securely (
ipa-backup) -
A backup of an IdM server is as sensitive as the live server as it contains every password hash, Kerberos key, and certificate private key in your environment. Use the native
ipa-backuputility to produce consistent, application-aware backups. Store them encrypted and in an off-site or air-gapped location, with access strictly limited to personnel who would legitimately perform a restore.
- Use OpenSCAP regularly
Ensures continuous compliance. Automatically detects if security settings have drifted from the intended baseline due to error or unauthorized changes. Integrate into a scheduled job and treat failures as incidents.
NoteThis audits the operating system configuration only and does not evaluate internal IdM data, such as user accounts or HBAC rules.
- Use
ipa-healthcheck - Provides operational security monitoring. Detects technical failures, such as replication lag, expiring certificates, and misconfigured services, that could result in a denial of service or undetected configuration drift. Run regularly and forward output to a monitoring system.
- Audit and clean up replication topology
-
Stale replication agreements left over from decommissioned replicas are a persistent risk. Each replica holds a full copy of every password hash, Kerberos key, and group membership. When decommissioning a replica, always use
ipa server-del, not just a power-off, so that agreements and service principals are cleanly removed. Periodically runipa topologysegment-findand compare output against your known infrastructure inventory.
- Certificate and CA lifecycle management
The
ipa-healthchecktool flags certificate expiry, but additional controls are needed:- Audit which services have certificates issued by the IdM CA and verify no unexpected certificates exist.
- Restrict sub-CA issuance if lightweight sub-CAs are in use.
- Review CRL and OCSP configuration to ensure revocation is functional.
To implement the above-mentioned recommendations, see the following table:
| Recommendation | Documentation |
|---|---|
| Enable FIPS mode during RHEL installation (regulated environments) | |
|
Back up IdM data securely ( | |
| Use OpenSCAP regularly | |
|
Use | |
| Audit and clean up replication topology | |
| Certificate and CA lifecycle management |
9.4. Security monitoring and detection in IdM
Detect and respond to security incidents in your Identity Management (IdM) deployment.
- Enable audit logging and forward logs off-host
Hardening controls reduce the likelihood of a breach, but do not eliminate it. Audit logs provide the evidence needed to detect a control bypass after the fact. Enable IdM’s LDAP audit log, collect Kerberos authentication events, and forward all logs to a centralized security information and event management (SIEM) before they can be tampered with on the IdM host itself.
NoteKey signals to alert on: repeated failed LDAP binds, unexpected changes to admin group membership, Kerberos ticket requests for sensitive service principals, and Directory Manager bind events.
- Audit and detect security configuration drift
-
Security posture degrades over time through configuration drift, staff changes, and new enrolments. Schedule a periodic review, at minimum quarterly, that re-checks
admingroup membership, active HBAC rules, custom RBAC role assignments, replication topology, and certificate inventory. Treat deviations from the baseline as incidents.
To implement the above-mentioned recommendations, see the following table:
| Recommendation | Documentation |
|---|---|
| Enable audit logging and forward logs off-host |
9.5. IdM security hardening implementation phases
The following table summarizes recommended security controls by implementation phase.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}