<buttonid="sidebar-toggle"class="icon-button"type="button"title="Toggle Table of Contents"aria-label="Toggle Table of Contents"aria-controls="sidebar">
<ahref="https://github.com/kanidm/kanidm/edit/master/kanidm_book/src/accounts_and_groups.md"title="Suggest an edit"aria-label="Suggest an edit">
<iid="git-edit-button"class="fa fa-edit"></i>
</a>
</div>
</div>
<divid="search-wrapper"class="hidden">
<formid="searchbar-outer"class="searchbar-outer">
<inputtype="search"id="searchbar"name="searchbar"placeholder="Search this book ..."aria-controls="searchresults-outer"aria-describedby="searchresults-header">
administrative actions. These include groups for account management, person management (personal and
sensitive data), group management, and more.</p>
<h2id="recovering-the-initial-admin-accounts"><aclass="header"href="#recovering-the-initial-admin-accounts">Recovering the Initial Admin Accounts</a></h2>
<p>By default the <code>admin</code> and <code>idm_admin</code> accounts have no password, and can not be accessed. They need
to be "recovered" from the server that is running the kanidmd server.</p>
<td>Persons may change their own displayname, name, and legal name at any time. You MUST NOT use these values as primary keys in external systems. You MUST use the `uuid` attribute present on all entries as an external primary key.</td>
</tr>
</table>
<!-- deno-fmt-ignore-end -->
<h2id="resetting-person-account-credentials"><aclass="header"href="#resetting-person-account-credentials">Resetting Person Account Credentials</a></h2>
<p>Members of the <code>idm_account_manage_priv</code> group have the rights to manage person and service accounts
security and login aspects. This includes resetting account credentials.</p>
<p>You can perform a password reset on the demo_user, for example as the idm_admin user, who is a
default member of this group. The lines below prefixed with <code>#</code> are the interactive credential
update interface.</p>
<pre><codeclass="language-bash">kanidm person credential update demo_user --name idm_admin
# spn: demo_user@idm.example.com
# Name: Demonstration User
# Primary Credential:
# uuid: 0e19cd08-f943-489e-8ff2-69f9eacb1f31
# generated password: set
# Can Commit: true
#
# cred update (? for help) # : pass
# New password:
# New password: [hidden]
# Confirm password:
# Confirm password: [hidden]
# success
#
# cred update (? for help) # : commit
# Do you want to commit your changes? yes
# success
kanidm login --name demo_user
kanidm self whoami --name demo_user
</code></pre>
<h2id="creating-service-accounts"><aclass="header"href="#creating-service-accounts">Creating Service Accounts</a></h2>
<p>The <code>admin</code> service account can be used to create service accounts.</p>
kanidm service-account get demo_service --name admin
</code></pre>
<h2id="using-api-tokens-with-service-accounts"><aclass="header"href="#using-api-tokens-with-service-accounts">Using API Tokens with Service Accounts</a></h2>
<p>Service accounts can have api tokens generated and associated with them. These tokens can be used
for identification of the service account, and for granting extended access rights where the service
account may previously have not had the access. Additionally service accounts can have expiry times
and other auditing information attached.</p>
<p>To show api tokens for a service account:</p>
<pre><codeclass="language-bash">kanidm service-account api-token status --name admin ACCOUNT_ID
kanidm service-account api-token status --name admin demo_service
</code></pre>
<p>By default api tokens are issued to be "read only", so they are unable to make changes on behalf of
the service account they represent. To generate a new read only api token:</p>
<h2id="resetting-service-account-credentials-deprecated"><aclass="header"href="#resetting-service-account-credentials-deprecated">Resetting Service Account Credentials (Deprecated)</a></h2>
Year-Month-Day T hour:minutes:seconds Z +- timezone offset
</code></pre>
<p>Set the earliest time the account can start authenticating:</p>
<pre><codeclass="language-bash">kanidm person validity begin_from demo_user '2020-09-25T11:22:04+00:00' --name idm_admin
</code></pre>
<p>Set the expiry or end date of the account:</p>
<pre><codeclass="language-bash">kanidm person validity expire_at demo_user '2020-09-25T11:22:04+00:00' --name idm_admin
</code></pre>
<p>To unset or remove these values the following can be used, where <code>any|clear</code> means you may use
either <code>any</code> or <code>clear</code>.</p>
<pre><codeclass="language-bash">kanidm person validity begin_from demo_user any|clear --name idm_admin
kanidm person validity expire_at demo_user never|clear --name idm_admin
</code></pre>
<p>To "lock" an account, you can set the expire_at value to the past, or unix epoch. Even in the
situation where the "valid from" is <em>after</em> the expire_at, the expire_at will be respected.</p>
<pre><codeclass="language-bash">kanidm person validity expire_at demo_user 1970-01-01T00:00:00+00:00 --name idm_admin
</code></pre>
<p>These validity settings impact all authentication functions of the account (kanidm, ldap, radius).</p>
<h3id="allowing-people-accounts-to-change-their-mail-attribute"><aclass="header"href="#allowing-people-accounts-to-change-their-mail-attribute">Allowing people accounts to change their mail attribute</a></h3>
<p>By default, Kanidm allows an account to change some attributes, but not their mail address.</p>
<p>Adding the user to the <code>idm_people_self_write_mail</code> group, as shown below, allows the user to edit
their own mail.</p>
<pre><codeclass="language-bash">kanidm group add_members idm_people_self_write_mail_priv demo_user --name idm_admin
</code></pre>
<h2id="why-cant-i-change-admin-with-idm_admin"><aclass="header"href="#why-cant-i-change-admin-with-idm_admin">Why Can't I Change admin With idm_admin?</a></h2>
<p>As a security mechanism there is a distinction between "accounts" and "high permission accounts".
This is to help prevent elevation attacks, where say a member of a service desk could attempt to
reset the password of idm_admin or admin, or even a member of HR or System Admin teams to move
laterally.</p>
<p>Generally, membership of a "privilege" group that ships with Kanidm, such as:</p>
<ul>
<li>idm_account_manage_priv</li>
<li>idm_people_read_priv</li>
<li>idm_schema_manage_priv</li>
<li>many more ...</li>
</ul>
<p>...indirectly grants you membership to "idm_high_privilege". If you are a member of this group, the
standard "account" and "people" rights groups are NOT able to alter, read or manage these accounts.
To manage these accounts higher rights are required, such as those held by the admin account are
required.</p>
<p>Further, groups that are considered "idm_high_privilege" can NOT be managed by the standard
"idm_group_manage_priv" group.</p>
<p>Management of high privilege accounts and groups is granted through the the "hp" variants of all
privileges. A non-conclusive list:</p>
<ul>
<li>idm_hp_account_read_priv</li>
<li>idm_hp_account_manage_priv</li>
<li>idm_hp_account_write_priv</li>
<li>idm_hp_group_manage_priv</li>
<li>idm_hp_group_write_priv</li>
</ul>
<p>Membership of any of these groups should be considered to be equivalent to system administration
rights in the directory, and by extension, over all network resources that trust Kanidm.</p>
<p>All groups that are flagged as "idm_high_privilege" should be audited and monitored to ensure that
