How FreeIPA supports ISO 27001 secure authentication and access rights
FreeIPA helps with three Annex A controls in ISO/IEC 27001:2022: A.8.5 Secure authentication, A.5.17 Authentication information and A.8.2 Privileged access rights. It does not satisfy them on its own, and it does not cover the policy, risk assessment and awareness work an information security management system (ISMS) also needs. An ISMS owner or Linux platform lead preparing for an audit usually finds access spread across local accounts, hand-maintained sudoers files and per-host settings that nobody can review as a whole. DeployOpen prepares systems, configuration and evidence for that assessment. Only accredited certification bodies certify an organization, and ISO does not certify organizations itself.
The 2022 edition reorganized the control set. Annex A lists 93 controls in four themes, down from 114 controls in the 2013 edition, with 11 new controls, 24 merged controls and 58 updated ones, according to IAF MD 26:2023. A.5.17 merges three 2013 controls covering user secret authentication information, its use and password management systems. Under ISO/IEC 27001:2022, A.5.17 asks for a managed process for allocating and handling authentication information, so the auditor will look for an owner and a procedure, not only a password setting. The ISO/IEC 27002:2022 correspondence table traces A.8.5 and A.8.2 to the 2013 controls A.9.4.2 and A.9.2.3. Certificates issued against the 2013 edition had to expire or be withdrawn by 31 October 2025, so an audit now tests the 2022 wording.
Turn each control into a FreeIPA setting and a piece of evidence. For A.8.5, document the global and group password policies, account lockout settings and OTP enrollment for users who need MFA, using HOTP or TOTP tokens. For A.8.2, use HBAC rules to limit which users reach which hosts, sudo rules to scope privileged commands, and delegation roles so that identity administrators and host administrators hold different rights. Keep exports of these rules, their change history and OTP enrollment and revocation records. Ask your certification body which samples it will take, and confirm with your vendor that your FreeIPA release includes the 4.13.4 security fixes before you present configuration as current.
Mapping ISO 27001 controls to FreeIPA capabilities and configuration
This table maps three Annex A controls to the FreeIPA features that support them and the configuration an assessor will expect to see. Read each row as a starting point for your own control design, since mapped controls are not always equivalent and the final judgment rests with your certification body. The main takeaway is that FreeIPA covers much of the technical authentication and privileged access work, while the management process around authentication information stays with your organization.
| Control requirement | FreeIPA capability | Configuration needed |
|---|---|---|
| A.8.5 Secure authentication: secure log-on technologies and procedures, based on access restrictions and the access control policy | Password policy, OTP for HOTP and TOTP tokens, Kerberos single sign-on, HBAC rules and account lockout settings | Set password policy per group, enroll OTP tokens for interactive users, enable HBAC rules that restrict which hosts and services each identity can reach, and confirm lockout thresholds in your environment |
| A.5.17 Authentication information: allocation and management of authentication information under a controlled management process, with staff advice on handling | Password policy objects, OTP token administration, self-service password change and Kerberos key management | Document who may reset credentials and token issuance, set password policy objects, define token enrollment and revocation steps, and record staff guidance on handling secrets |
| A.8.2 Privileged access rights: allocation and use restricted to authorized users, software and services | Sudo rules, HBAC rules for administrative hosts, and RBAC delegation through roles and privileges | Limit sudo rules to named groups, use delegation roles for administrators instead of shared accounts, require MFA for privileged groups where your design allows it, and review membership regularly |
| Mapping caution: NIST's crosswalk from SP 800-53 Rev. 5 relates A.8.5 to AC-7, AC-8, AC-9 and IA-6, and notes mapped controls are not always equivalent | Lockout, login notification and authentication feedback depend on the services and PAM configuration around FreeIPA | Confirm with your assessor which controls the crosswalk covers in your scope and test each mapped behavior on the actual Linux services you run |
| 2013 correspondence: A.8.5 traces to A.9.4.2 secure log-on, and A.8.2 traces to A.9.2.3 privileged access management | Same FreeIPA features as the 2022 rows above, now mapped to earlier control numbers | Keep the 2013 numbers in your evidence index only if your prior certificate or audit history uses them |
| 2013 correspondence: A.5.17 merges A.9.2.4, A.9.3.1 and A.9.4.3 from the 2013 edition | Password management and secret handling features cover parts of all three earlier controls | Map old evidence to the merged control in your statement of applicability and confirm the merge with your certification body |
Where FreeIPA password policy and OTP meet A.5.17 and A.8.5
A.5.17 asks for a managed process over authentication information, and in FreeIPA that process is largely a set of configured objects you own. The 2022 control merges three 2013 controls covering user secret information, its use, and password management systems, so an auditor will expect to see who sets the rules, how users are told to handle their credentials, and how issuance and reset are controlled. In FreeIPA, the global password policy and any group-specific policies define complexity, history and expiry, and token enrollment for OTP is an explicit step that can be documented as an allocation process. Confirm in your environment which policy applies to which user group, because a default policy alone may not match the rules you have written down. Pair the configuration with written user guidance on handling passwords and OTP tokens, since A.5.17 also asks for personnel advice that FreeIPA does not write for you.
A.8.5 secure log-on is where Kerberos single sign-on, second factors and lockout behavior have to be designed together. FreeIPA issues Kerberos tickets through its MIT Kerberos KDC, so the log-on decision happens at the KDC and the policy you set there governs every service that trusts it. HOTP and TOTP tokens can add a second factor, and the OTP design page notes that checks can be proxied to an existing RADIUS server if that is where your second factor lives. The NIST crosswalk links A.8.5 to AC-7 unsuccessful logon attempts, along with AC-8 and AC-9, and treats those mappings as approximate. Lockout thresholds and reset intervals must be set and tested in your deployment, and you should confirm how failed OTP attempts and failed password attempts are counted, because the two may not behave the same way.
What evidence FreeIPA produces for ISO 27001 auditors
Auditors assessing A.5.17, A.8.5 and A.8.2 will ask to see what the authentication and access settings are, who approved them and that they stayed the same over the period. The cards below cover the records a FreeIPA deployment can export or retain, and how to put each one under change control before the audit period begins.
Exported password and lockout policy
Export the global password policy and each group password policy with the IPA command line tools, then store the output as a dated file in version control. Compare each export against the password and lockout settings your authentication information procedure describes. Note who changed a policy, when, and whether a change request backs it. Confirm which settings your team maps to A.5.17 and A.8.5 before you select the evidence set.
HBAC and sudo rule listings
Export host-based access control rules and sudo rules as listings showing which user groups can reach which host groups, and which privileges sudo grants. These listings are the main proof for A.8.2 that privileged access is restricted to authorized users. Review each listing against the approved access matrix and record the reviewer's sign-off. Check that rules for systems in scope are not left as allow-all defaults.
RBAC roles and delegation records
Export the roles, privileges and permissions that define who may administer users, hosts and policies, along with the delegation rules that grant administrators their rights. Auditors use these records to confirm that administrative rights follow the least-privilege model in your access control policy. Keep a register that maps each role to an owner and an approving manager. Verify the register against group membership at each review.
OTP token inventory
Produce an inventory of enrolled OTP tokens, showing the owner, token type, enrollment date and status. Tokens that are disabled, lost or belonging to departed staff must be visible in this inventory, not only removed. Reconcile the list with the HR leaver feed and with the MFA scope set for privileged and remote access. This inventory supports the A.5.17 requirement that authentication information is controlled through a managed process.
Audit and access logs
Collect the authentication and administrative activity recorded by the directory, Kerberos and sudo components, and forward it to a log store that your team controls. Auditors will look for failed logon bursts, lockouts, changes to policy objects and privileged command use. Confirm that log time sources are synchronized and that log access is itself restricted. Set retention with the compliance owner, since the retention period is an organizational decision you must document.
Backup records from ipa-backup
Keep a record of each ipa-backup run, including the type of backup, the server it ran on, the time and the storage location, and periodic test restores into a non-production environment. The FreeIPA backup guidance warns that the first server handles certificate renewal and CRL publication by default, so the backup record should name that server. Treat backup files as sensitive, since they contain identity and key material, and control their access accordingly.
Restricting privileged access rights with HBAC, sudo and delegation
Host-based access control (HBAC) in FreeIPA decides which users and groups may log in to which hosts and services. It is the first gate for privileged access rights, because a person who cannot reach a host cannot use a sudo right on it. ISO/IEC 27001:2022 Annex A control 8.2 (Privileged access rights) asks that the allocation and use of these rights are restricted and managed, so that only authorized users, software components and services receive them. The correspondence table in ISO/IEC 27002:2022 Annex B traces 8.2 to control A.9.2.3 (Management of privileged access rights) of the 2013 edition.
- Rule scope: Group rules by host group and service, such as a production database host group and an SSH service, rather than attaching users to individual machines.
- Default deny: Remove the default allow-all HBAC rule only after every legitimate login path has a named rule, and test each path first.
- Group membership: Base rules on groups that map to a documented role, so that a joiner, mover or leaver change updates access without editing hosts.
- Service coverage: Confirm which PAM services (for example, sshd, su and console logins) each rule covers, since a rule written for one service does not cover another.
- Manual migration: Rules migrated from another directory need manual LDIF migration, so review each migrated HBAC rule against the current host list before go-live.
Check that every privileged host has at least one documented HBAC rule, and keep an exported list of rules as evidence of who may reach each host.
sudo rules in FreeIPA define which commands a user or group may run as another user on a given host. They govern what privileged access allows once a person has logged in. For A.8.2, the aim is that privileged commands are granted only to authorized users, software components and services, and that each grant is narrow enough to justify. The sudo rules in FreeIPA are stored centrally and applied on enrolled hosts through SSSD, which keeps the rule set consistent across machines.
- Command lists: Use explicit command lists or sudo command groups instead of ALL, and record the business reason for each list.
- Run-as identity: Set the run-as user and group deliberately, so that a rule for a database administrator does not also grant root.
- Authentication requirement: Decide where a sudo rule requires the user to authenticate again, and document the exception for any automation account.
- Service accounts: Grant software components and services their own rules with named accounts, not shared administrator logins.
- Manual migration: sudo rules are not carried over by the standard LDIF path in the migration guidance, so migrate and re-test them by hand.
As a check, run sudo -l -U for sample users on target hosts and compare the output with the approved rule list.
Role-based access control (RBAC) delegation in FreeIPA controls who may administer identities, such as creating accounts, resetting passwords or changing group membership. This is a separate privilege from logging in or running root commands, and it should be designed as its own access model. Delegation usually limits a helpdesk group to specific user groups and attributes, so that administrators of one team cannot change the accounts of another. This matches the control expectation that privileged rights are restricted and managed, and it gives auditors a clear answer to who can change identities.
- Separate roles: Keep identity administration, host enrollment and certificate administration in distinct roles and groups.
- Scope by attribute: Delegate only the attributes a role needs, such as password reset for a named user group, and not full edit rights.
- Administrator accounts: Require a separate administrative identity for privileged work, so day-to-day accounts do not hold delegated rights.
- Change review: Record who holds each delegated role and review membership on a fixed schedule set by your own policy.
- Verification: Test each role with a non-administrative test account and confirm that out-of-scope changes fail.
Confirm the exact role and permission names in your FreeIPA version before writing them into a control record.
Auditors testing A.8.2 usually want to see how privileged rights are granted, who holds them now, and how changes are approved and removed. In FreeIPA, the evidence comes from exported configuration and from sampled changes, so the rules should be built with that in mind. The mapping in this topic is an internal design aid, not a certification. Independent auditors decide conformity, and the NIST crosswalk notes that mapped controls are not always equivalent.
- Rule inventory: Export HBAC, sudo and delegated role definitions on a schedule, and store them with dates and change records.
- Membership reports: Keep a list of users in each privileged group and role, with the approver for each addition.
- Change samples: Retain tickets showing a request, approval, the FreeIPA change and the removal date for a sample of grants.
- Test results: Keep the results of login and sudo tests on privileged hosts after each rule change.
- Scope statement: Document which hosts and services each rule covers, so the auditor can match the evidence to the scope of the ISMS.
Ask your auditor which sample sizes and evidence formats they accept before you design the reports.
What FreeIPA does not cover for ISO 27001
FreeIPA can enforce authentication and privileged access on Linux and UNIX systems, but it does not make an organization conform to ISO/IEC 27001:2022. The cards below list what remains with the organization, the ISMS, its processes and its people, and what to confirm before an assessment.
The ISMS itself
FreeIPA is a technical control source, not an information security management system. The organization must still define the scope, establish the policies that FreeIPA settings implement, assign owners for each control and run management review and continual improvement. Before you rely on any FreeIPA setting as evidence, confirm that a documented policy approves it, names who reviews it and records when it was last checked.
Risk assessment and treatment
Choosing a password length, lockout threshold or MFA requirement is a risk decision. FreeIPA applies whatever values you configure, but it does not identify which systems hold sensitive information or which threats matter most. Your risk assessment should record why each authentication setting was chosen, who accepted any residual risk, and when the decision will be revisited, including exceptions for legacy hosts that cannot use OTP.
Authentication information policy and user guidance
A.5.17 expects authentication information to be managed through a controlled process, including advice to personnel on handling it. FreeIPA stores credentials and enforces policy, but it cannot write the rules staff follow, train users on phishing, or explain what to do with lost OTP tokens. Prepare a written policy, user guidance on token and password handling, and records showing that users received it.
Joiner, mover and leaver processes
FreeIPA removes or disables accounts only when someone or something tells it to. The trigger for hiring, role changes and departures usually lives in HR systems, ticketing or an identity governance tool outside FreeIPA. Define who requests access, who approves it, how a leaver's Kerberos principals, OTP tokens and sudo rights are revoked, and how quickly that happens. Confirm that these steps produce tickets or logs an auditor can sample.
Periodic access reviews
FreeIPA shows group membership, HBAC rules and sudo rules at a point in time, but it does not decide whether those rights are still justified. Access review is a management activity: owners confirm each privileged user and group, record the decision and remove what is no longer needed. Plan the review frequency, the reviewers and the output format before the first assessment, and keep the signed results.
Certification and non-Linux or SaaS applications
FreeIPA cannot certify the organization, and ISO does not certify organizations either. Accredited certification bodies perform that audit. FreeIPA also manages only enrolled Linux and UNIX hosts and the services that integrate with Kerberos or LDAP. Cloud SaaS, Windows endpoints and vendor appliances need their own identity integration or a documented compensating control, and that scope boundary must appear in your Statement of Applicability.
Configuring FreeIPA for an ISO 27001 authentication review
This sequence turns FreeIPA settings into the policies, rules and logs that an auditor can trace back to A.5.17, A.8.5 and A.8.2. Each step ends with an artifact you can show, so the review starts from evidence rather than reconstruction.
Write the authentication information policy
Your security or identity owner writes the rules that govern passwords, OTP tokens, certificates and Kerberos keytabs, including how users are advised to handle them. This is the management process A.5.17 asks you to control, so the policy must name who approves changes and how exceptions are recorded. Done means the approved policy is versioned and each FreeIPA setting in the next steps can be traced to a clause in it.
Set password policy and OTP enrollment
The IdM administrator sets global and group password policies (length, history, lockout and expiry) and enrolls OTP tokens for users and administrators using the HOTP or TOTP options FreeIPA supports, including hardware tokens where your policy requires them. Confirm with your own environment which lockout and authentication settings your assessor will test, since the supplied facts do not fix them. Done means a test account shows the configured behavior and the token inventory matches the enrollment records.
Build HBAC and sudo rules from the access model
Map each access decision in your access model to a host-based access control rule and a sudo rule, granting access by user group to host group rather than to individuals. Remove the default allow-all HBAC rule only after the replacement rules are tested from every client type you run. Done means a documented matrix of users, hosts and sudo commands matches the exported rule set, and a test login is denied for every user outside the matrix.
Delegate administration by role
Use FreeIPA role-based access control to give help desk, service owners and auditors only the privileges their job requires, instead of sharing the admin account. Each role should be a named group with a documented owner and a reviewed membership list. Done means each role's privileges are exported and reviewed against the access model, and no one outside the approved roles can change user or policy objects.
Restrict privileged groups
Keep the admins and other privileged groups small, record each membership change, and require the separate privileged account pattern your policy defines for A.8.2. Confirm whether your environment needs additional controls on these groups, because the supplied facts do not describe them in detail. Done means the privileged group membership list is short, every member has a documented reason, and a membership change produces a log entry that can be found.
Enable audit logging and confirm replication coverage
Confirm that the audit logs for authentication, rule changes and administrative actions are kept and forwarded to your log store. Before you rely on these records, check the replica topology against the deployment recommendations, which advise replicas in each datacenter and dedicated servers, and confirm that backups follow the backup documentation, including the warning about restoring an outdated backup into an active replica topology. Done means a sample of administrative actions appears in the central log, and the backup and topology records are on file.
Export evidence for the auditor
Produce a dated evidence pack from the running configuration: the password and OTP policy exports, HBAC and sudo rule lists, role and privileged group memberships, a sample of audit log entries and the backup and topology records. Map each artifact to A.5.17, A.8.5 and A.8.2 in your own words and state which exports are generated on demand. Done means an auditor can select any control and find the matching exported file, and the same export can be reproduced from the system later.
Questions buyers ask before hiring help for ISO 27001 and FreeIPA
Does installing FreeIPA make our company ISO 27001 compliant?
No. ISO does not certify organizations, and no software product makes an organization compliant on its own. FreeIPA can provide technical controls that support Annex A 8.5 secure authentication, 5.17 authentication information and 8.2 privileged access rights, such as password policy, OTP tokens and host-based access control. The management system around those controls, including the policy, risk treatment, ownership and records, is the organization's responsibility. Certification is issued by an accredited certification body after an independent audit. DeployOpen prepares systems, controls and evidence for that assessment but does not issue audit reports or certifications.
What drives the cost and effort of configuration, evidence and migration?
The largest drivers are the number of Linux hosts and the number of existing access rules to be reviewed, migrated or retired. Effort also rises with the number of identity sources (other LDAP directories, Active Directory, local accounts), the depth of OTP or RADIUS integration, and how much evidence must be collected from existing systems. Migration of users and groups can use the ipa migrate-ds command, but sudo and HBAC rules need manual migration through LDIF, which adds review time. Ask for a quote that separates one-time work (design, configuration, migration, evidence templates) from recurring work (access reviews, upgrades, support). DeployOpen does not publish prices, so the quote follows from the written scope.
How long does a FreeIPA access control project take?
Duration depends on scope rather than on a fixed template, so ask for a timeline in the written scope rather than a generic estimate. The main factors are the size of the Linux estate, how clean the current access rules are, whether migration from another directory is involved, and how many approvers must sign off on policy. Replica layout also matters: the deployment recommendations call for at least two to three replicas in each datacenter, which affects how many servers are built and tested. Certification timing is separate. Under ISO/IEC 17021-1, a three-year certification cycle includes at least one audit in each calendar year, so evidence must be kept current across the whole cycle, not only before the first audit.
What must our internal team provide before the work starts?
Internal teams usually need to supply four things:
- Named policy owners who can approve password, MFA and privileged access rules.
- A Linux access inventory: hosts, service accounts, existing sudo rules, SSH key practices and any shared accounts.
- Approvers for access requests, privileged role grants and exceptions, with defined response expectations.
- Access to existing directories, DNS, certificate records and the current identity provider so migration and trust decisions can be made.
The quality of these inputs strongly affects the effort. Ask the partner to list the exact inputs in the written scope so gaps are visible before build starts.
Can our own engineers implement this without outside help?
Yes, if they have Linux, Kerberos, DNS and PKI skills and time to test. FreeIPA is GPL-3.0-or-later community software, so there is no license fee for the product itself, but the work still needs people. Your team would own design decisions such as replica topology, password policy values, OTP enrollment, and sudo and HBAC rules, plus backup and restore testing. The backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so restore procedures need careful rehearsal. Many organizations split the work: internal staff own operations and evidence, while a partner handles design, hardening and documentation. Confirm which parts your auditor will expect the organization to perform itself.
How do certification and surveillance audits relate to this work?
Certification and surveillance audits are performed by an accredited certification body, not by DeployOpen. Under ISO/IEC 17021-1, a certification cycle lasts three years, with at least one audit, either surveillance or recertification, in every calendar year. This means the authentication controls need stable records across the whole cycle: policy approvals, access review results, OTP enrollment and retirement records, privileged access grants and log extracts. The transition from ISO/IEC 27001:2013 to the 2022 edition required organizations to move to the new certification by 31 October 2025. Ask your certification body which evidence samples it expects and how it applies ISO/IEC 27006-1:2024 to your scope.
How DeployOpen scopes and delivers ISO 27001 authentication configuration
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including FreeIPA. For ISO 27001 authentication work, we start from the controls you have chosen to evidence, configure FreeIPA to produce that evidence, and hand over the records your team and external auditors will need.
How we scope
- Map your in-scope Linux hosts, services and user populations to ISO/IEC 27001:2022 Annex A 8.5, 5.17 and 8.2 as agreed in writing.
- Confirm which password policy, OTP, HBAC, sudo and delegation settings are in scope and which stay with your existing tools.
- Agree in writing the deliverables, exclusions and timeline before any work starts, since most engagements are fixed-scope.
- Ask us to confirm which evidence items your certification body expects, because DeployOpen prepares evidence but does not issue audit reports.
How we build
- Deploy or review the FreeIPA topology in your own cloud accounts, data centers or air-gapped network, following the vendor's deployment recommendations.
- Configure password policy, lockout behavior, OTP tokens and HBAC and sudo rules against the scoped control requirements.
- Set up role-based delegation so administrative rights are granted to named groups and recorded, not shared accounts.
- Test login, lockout, token enrollment and privilege escalation paths in a non-production environment before cutover.
How we hand over
- Provide written configuration documentation with the settings, their owners and the control each one supports.
- Deliver an evidence pack covering policy exports, rule listings, group membership reports and sample authentication logs.
- Walk your identity and security teams through backup and restore procedures, including the warning about restoring outdated backups into active replicas.
- Document the procedures your staff must follow to issue, reset and revoke authentication information.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the initial engagement.
- Review FreeIPA security releases and advise on which fixes apply to your deployment and how to schedule them.
- Repeat access reviews and configuration checks on a schedule you agree, and record the results for your management review.
- Keep the scope, documentation and evidence current when your authentication policy or the ISO 27001 mapping changes.
