Access Control

While Kanidm exists to make authorisation decisions on behalf of other services, internally it must make decisions about writes operations to the entries within its database. To make these choices, Kanidm has an internal set of access controls which are the rules describing who may perform what actions.

Default Permissions

The project ships default access controls which are designed to limit and isolate the privileges of accounts whenever possible.

This separation is the reason why admin and idm_admin exist as separate accounts. There are two distinct access silos within Kanidm. Access to manage Kanidm as a service (such as application integrations and domain naming) and access to manage people and groups. This is to limit the possible harm that an attacker may make if they gain access to these roles.

Permission Delegation

A number of types in Kanidm allow permission delegation such as groups and service accounts. This allows entries to be assigned an entry manager who has write access to that entity but not all entities of the same class.

High Privilege Groups

Kanidm has a special group called idm_high_privilege. This acts as a "taint" on its members to indicate that they have an elevated level of access within Kanidm or other systems.

This taint flag exists to prevent lateral movement from other roles that have higher levels of privilege.

An example is idm_service_desk which has the ability to trigger credential resets for users. This is an important aspect of the service desk role. However, a member of the service desk should not be able to modify the credentials of their peers, nor should they be able to escalate by accessing the credentials of users in a role such as idm_admins. Since idm_service_desk and idm_admins are both tainted with idm_high_privilege then this lateral movement is not possible. Only high privileged roles are able to then reset the accounts of high privilege users.

You may add other groups to idm_high_privilege to achieve the same taint effect for other services.

Default Permission Groups

Kanidm ships with default permission groups. You can use these to enable accounts to perform certain tasks within Kanidm as required.

group namedescription
domain_adminsmodify the name of this domain
idm_access_control_adminswrite access controls
idm_account_policy_adminsmodify account policy requirements for user authentication
idm_group_adminscreate and modify groups
idm_oauth2_adminscreate and modify oauth2 integrations
idm_people_adminscreate and modify persons
idm_people_on_boardingcreate (but not modify) persons. Intended for use with service accounts
idm_people_pii_readallow read to personally identifying information
idm_people_self_write_mailallow self-modification of the mail attribute
idm_radius_serversread user radius secrets. Intended for use with service accounts
idm_radius_service_adminscreate and reset user radius secrets, and allow users to access radius
idm_recycle_bin_adminsmodify and restore entries from the recycle bin
idm_schema_adminsadd and modify elements of schema
idm_service_account_adminscreate and modify service accounts
idm_unix_adminsenable posix attributes on accounts and groups

Default Roles

Kanidm ships with 3 high level permission groups. These roles have no inherent permissions, they are created by being members of the default permission groups.

group namedescription
idm_adminsmanage persons and their groups
idm_service_deskassist persons with credential resets or other queries
system_adminsmanage the operation of Kanidm as a database and service