本ページの位置づけ
「authentik超入門取扱説明書」がプロバイダー／アプリケーションの基礎概念を扱うのに対し、本ページはユーザーそのものの管理操作に特化した実践マニュアルです。「Phase 1 authentik連携 実践マニュアル」でのユーザー追加作業をもとに、汎用的な手順として整理しています。
目次
1. authentikのユーザー管理 全体像
authentikでは、1人のユーザーがどのアプリにアクセスできるかは、以下の3つの仕組みの組み合わせで決まります。
| 仕組み | 役割 |
|---|---|
| ユーザー（User） | ログインするアカウントそのもの。ユーザー名・パスワード・メールアドレス等を持つ |
| グループ（Group） | 複数のユーザーをまとめる単位。「営業部」「家族」のような括り。権限をグループ単位でまとめて管理できる |
| バインディング（Policy/Group/User Binding） | 「どのアプリケーションに」「誰が（ユーザー個別 or グループ単位で）」アクセスできるかを結びつける設定 |
小規模な自宅サーバー運用では、ユーザーを直接アプリにバインディングする方式（本ページの手順）で十分ですが、利用者や連携アプリが増えてきたらグループ経由の管理に切り替えると保守しやすくなります（4章参照）。
2. ユーザーを新規作成する
- 管理画面（
/if/admin/）でDirectory＞Usersを開く - 右上の Create ボタンをクリック
- フォームに入力：
項目 入力内容 Username ログインに使うID（半角英数字推奨） Name 表示名（任意、日本語可） Email パスワードリセットメールを使う場合は入力。その場でパスワードを設定するなら空欄でも可 - Create を押して作成完了
作成しただけではログインできない
ユーザーを作成しただけの状態ではパスワードが未設定です。次の章の手順でパスワードを設定するまで、そのユーザーは実質ログインできません。
3. パスワードを設定・リセットする
Directory＞Usersの一覧から対象ユーザーをクリックして詳細画面を開く- 「概要」タブの「アクション」欄、または画面上部に パスワードを設定（Set password）ボタンがある
- クリックすると「〇〇のパスワードを更新」という入力欄が開くので、新しいパスワードを入力して保存
ユーザー本人にメールでリセットさせたい場合は、同じユーザー詳細画面の「アクション」欄にある「リカバリ」（Recovery）から、パスワードリセット用のリンクを発行できます（ブランドの「リカバリフロー」設定が必要な場合があります）。
4. グループで権限をまとめて管理する
Directory＞Groups＞ Create でグループを作成（例：grp_family）- 作成したグループの詳細画面を開き、「メンバー」（Users）タブから既存ユーザーを追加
- アプリケーション側のバインディング（5章）で、ユーザー個別ではなく「グループ」を指定すれば、そのグループに所属する全員に一括でアクセス権を付与できる
ユーザーが増えるたびに個々にバインディングするのは手間がかかるため、2人目以降を追加する予定がある場合は最初からグループ運用にしておくことを推奨します。
5. アプリケーションへのアクセスを許可する
既定では、作成したアプリケーションにはバインディングを何も設定しない限り「全ユーザーがアクセス可能」です。特定のユーザー・グループだけに絞りたい場合は、明示的にバインディングを追加します。
Applications＞Applicationsで対象アプリを開く- 「ポリシー / グループ / ユーザーバインディング」タブを開く
- Bind ボタン ＞ Bind a user（個別ユーザーを許可）または Bind a group（グループ単位で許可）を選択
- 「Select an object...」から対象のユーザーまたはグループを選び、Create
重要：バインディングを追加すると「それ以外は締め出す」動作になる
1件でもバインディングを追加すると、そのアプリはバインディングにマッチしたユーザー・グループ以外は原則アクセス不可になります。管理者アカウント自身がそのアプリを操作・確認する必要がある場合（サーバー機器の認証など）は、管理者アカウントも忘れずにバインディングへ追加してください。追加を忘れると、ログインはできてもそのアプリの認可画面には進めず、管理者ダッシュボードに戻される、という分かりにくい挙動になります（7章のトラブル事例も参照）。
6. ユーザーを無効化・削除する
- 一時的に使わせたくない場合：ユーザー詳細画面の編集で「有効」（Active）のチェックを外す。アカウントもデータも残るので、後で再度有効化できる
- 完全に削除する場合：ユーザー一覧または詳細画面から「削除」（Delete）。関連するバインディングやグループ所属も合わせて解除される点に注意
Headscale等、外部サービス側にも別途ユーザー登録が残っている場合（本サイト内「Phase 1 authentik連携マニュアル」参照）、authentik側の削除だけでは連携先の登録は消えないため、必要に応じて両方で削除操作を行ってください。
7. 実体験ベースのトラブルシューティング
7-1. 「認可フロー」を選ばずに送信するとプロバイダー作成が失敗する
新しいアプリ作成ウィザードで「アプリの作成」を押すと「authentikはこの処理を完了できませんでした。プロバイダーにエラーがあります」という汎用エラーになる。
プロバイダー設定画面の一番上にある「認可フロー（Authorization flow）」が未選択のまま。よく似た名前の「認証フロー（Authentication flow）」とは別の項目で混同しやすい。
「認可フロー」に default-provider-authorization-implicit-consent（同意画面を省略）または default-provider-authorization-explicit-consent（初回のみ同意画面）のいずれかを選択する。
7-2. バインディング追加後、管理者自身がアプリに入れなくなる
特定ユーザーだけにアプリのアクセスを絞った直後、外部サービス（Headscale等）側でそのアプリ経由の認証を管理者アカウントで行おうとしたところ、ログインはできるのに認可が完了せず、管理者ダッシュボードに戻されてしまった。
管理者アカウントも同じアプリのバインディングに追加して解消（5章の警告欄を参照）。
7-3. OIDC連携先で「ユーザー名が空欄」になる
OIDC連携先（Headscale等）のログイン完了画面が「Authenticated as , you can now close this window.」のように、ユーザー名部分が空欄で表示された。
連携先が期待するユーザー名クレーム（preferred_username等）が、authentikのOIDCスコープ設定から渡されていない場合に発生する。認証・認可自体は成功していることが多く、実害がないケースもあるが、連携先で「ユーザーが空文字列の名前で登録される」といった副作用が出ることがある（本サイトのHeadscale連携マニュアルで実例あり）。
プロバイダー設定のScope（openid, profile, email等）が連携先の要求と一致しているか確認する。連携先が「メールアドレスをユーザー名として使う」仕様の場合、そのメールアドレスがそのままユーザー名として使われてしまう点にも注意（個人のメールアドレスを他サービスに晒したくない場合は、専用のダミーメールアドレスでユーザーを作成する等の対策を検討）。
8. 新規ユーザー追加チェックリスト
新しい人に何かのアプリへのアクセスを許可する際の、抜け漏れ防止チェックリストです。
- Directory ＞ Users でユーザーを作成した
- パスワードを設定した（本人にリセットさせる場合はメールアドレスも登録した）
- 対象アプリケーションのバインディング設定を確認した（既定＝全員可、絞る場合は明示的にBindが必要）
- バインディングを絞った場合、自分（管理者）が引き続きそのアプリを扱えるか確認した
- 連携先サービス（Headscale等、authentik以外の外部サービス）側でも、必要なユーザー登録・権限設定が完了しているか確認した
- 実際にそのユーザーの立場でログイン〜目的の操作までを一通りテストした
authentik ユーザー管理マニュアル 整備完了 🎉
ユーザー作成からパスワード設定、グループ、アプリへのアクセス許可、削除、実体験に基づくトラブルシューティングまでを整理しました。個別の連携事例は「Phase 1 authentik連携 実践マニュアル（Headscale／Samba編）」を、全体ロードマップは「ゼロトラスト統合基盤検証ロードマップ」をご参照ください。