【図解】認証と認可の違いとは？Windowsのサインインからファイル共有までを初心者向けに解説

Windowsにサインインして、共有フォルダを開く。毎日あたりまえにしている操作ですが、裏では「認証」と「認可」という2つの別々のチェックが動いています。この2つを分けて考えられるようになると、「サインインはできるのに、フォルダが開けない」といったトラブルの原因を切り分けやすくなります。

この記事でわかること

認証と認可は、それぞれ何を確かめているのか
Windowsで共有フォルダを開くとき、誰が認証し、誰が認可しているのか
グループに追加したのに、すぐにアクセスできない理由

認証と認可をひとことで
1. 「名乗る」と「確かめる」も別のもの
順番は必ず「認証 → 認可」
Windowsでは誰が認証し、誰が認可するのか
1. 認証の結果は「アクセストークン」になる
グループに追加したのに、すぐ開けない理由
クラウドでも考え方は同じ
まとめ

認証と認可をひとことで

認証（Authentication）は「あなたは誰か、本当に本人か」を確かめることです。認可（Authorization）は「確かめた相手に、何をしてよいか」を決めることです。英語のつづりが似ているので、AuthN（認証）、AuthZ（認可）と略して書き分けることもあります。

オフィスビルにたとえると分かりやすくなります。受付で社員証の顔写真と本人を照らし合わせるのが認証で、もらった入館証でどの部屋に入れるかが決まるのが認可です。受付を通れた人でも、サーバ室のカードリーダーには入館証をはじかれることがあります。

図1　オフィスビルのたとえ。受付での本人確認が認証、部屋ごとに入れるかどうかを決めるのが認可

項目	認証	認可
英語	Authentication（AuthN）	Authorization（AuthZ）
答える問い	あなたは誰か。本当に本人か	その人に、何をしてよいか
使う材料	パスワード、証明書、指紋や顔などの生体情報	アクセス許可（ACL）、ロール、所属グループ
失敗すると	サインインできない	「アクセスが拒否されました」などで断られる
Windowsのドメインで担当するのは	ドメインコントローラ（DC）	アクセスされる側のサーバやPC

「名乗る」と「確かめる」も別のもの

ユーザー名を入力しただけでは、「user01です」と名乗っただけで、本人だとはまだ分かりません。パスワードや指紋など、本人しか持っていないものを示して、はじめて認証になります。名乗ることを「識別」と呼んで、認証と分けて説明することもあります。

順番は必ず「認証 → 認可」

認可は「誰に何を許すか」を決める処理なので、相手が誰か分からないうちは判断できません。そのため、必ず認証が先で、認可があとになります。認証に通っても、認可で断られることはよくあります。

図2　認証と認可の順番。どちらで止まったかによって、利用者に見える結果が違う

どちらで止まったかは、表示されるメッセージや症状からある程度見分けられます。切り分けのときは、まずどちらの問題かを決めると、調べる場所が絞れます。

症状	止まった場所	確認すること
「ユーザー名またはパスワードが正しくありません」と表示される	認証	パスワードの入力、パスワードの有効期限、アカウントのロック
サインインはできるが、ある共有フォルダだけ「アクセスが拒否されました」になる	認可	そのフォルダの共有とNTFSのアクセス許可、本人の所属グループ
フォルダは開けるが、ファイルを保存できない	認可	読み取りだけが許可されていないか

Windowsでは誰が認証し、誰が認可するのか

会社のPCがドメインに参加している環境で、ファイルサーバの共有フォルダを開く場面を例に見ていきます。登場するのは、利用者のPC、ドメインコントローラ（DC）、ファイルサーバの3台です。

図3　共有フォルダを開くまでの流れ。本人確認はDCが受け持ち、許可の判断はファイルサーバが行う

No.	何が起きているか	区分
①②	PCにサインインすると、PCはDCに本人確認を頼みます。パスワードが正しいかを判断できるのは、ドメインのアカウント情報を持っているDCです。確認できると、そのユーザーが入っているグループの情報も一緒に返ってきます。	認証
③	共有フォルダを開くと、PCはファイルサーバに「本人であることの証明」を送ります。Kerberosでは、DCが発行したチケットを見せます。	認証
④	ファイルサーバは、確かめたユーザーとグループを、フォルダのアクセス許可（ACL）と照らし合わせます。	認可
⑤	許可されていればフォルダが開き、されていなければ拒否されます。	認可

ポイントは、本人確認はDCの力を借りて行い、許可の判断はファイルサーバが自分のACLで行う、という分担です。どのフォルダを誰が読めるかという設定はファイルサーバ側にあり、DCはそれを知りません。

補足

③での本人確認のやり方は、認証プロトコルによって違います。Kerberosでは、DCが発行したチケットを見せるので、ファイルサーバは毎回DCに問い合わせずに本人を確かめられます。NTLMでは、ファイルサーバがそのつどDCに「この人は本人か」を問い合わせます。

認証の結果は「アクセストークン」になる

Windowsでは、認証に成功するとアクセストークンが作られます。アクセストークンには、ユーザーと、そのユーザーが入っているグループを表す情報が入っています。ファイルを開こうとすると、Windowsはこのトークンとファイルのアクセス許可（ACL）を照らし合わせて、許可するかどうかを決めます。

図4　アクセストークンとACLの照合。トークンのグループがACLの行と一致すると、その行の権限が与えられる

ACLに当てはまる行が複数あるときは、それぞれの権限が足し合わされます。たとえば、グループに読み取りが、本人に書き込みが許可されていれば、読み取りと書き込みの両方ができます。ただし、拒否を明示した行が先に当てはまると、そこでアクセスは拒否されます。

KerberosやNTLMは、あくまで本人を確かめる「認証」の仕組みです。KerberosのRFCにも、Kerberos自体は認可を行わないと書かれています。チケットはグループの情報を運びますが、それを使って許可するかを決めるのは、アクセスされる側のサーバです。

グループに追加したのに、すぐ開けない理由

管理者がユーザーを新しいグループに追加しても、そのユーザーがすでにサインインしていると、すぐには反映されないことがあります。アクセストークンはサインインしたときに作られ、その時点のグループの情報が入っているからです。Kerberosのチケットも同じで、チケットをもらった時点のグループの情報が入っています。

図5　グループの変更が反映されるタイミング。サインインし直して新しいトークンができると反映される

反映させるには、サインアウトしてサインインし直すのが確実です。今のトークンにどのグループが入っているかは、コマンドプロンプトで次のコマンドを実行すると確認できます。

利用者のPC（コマンドプロンプト）：今のトークンに入っているグループを表示する

whoami /groups

注意

サインインし直す前に開いていた共有フォルダの接続は、グループを変えても古い情報のまま続きます。テレワークなどで、DCに届かない状態でサインインした場合は、PCに残っている前回の情報でサインインするため、グループの変更が反映されないこともあります。

クラウドでも考え方は同じ

認証と認可を分ける考え方は、Windowsのファイル共有に限りません。Microsoft 365やAzureでは、Entra IDへのサインインが認証で、ロールやアクセス許可の設定が認可です。Webアプリの世界では、OpenID Connectが認証、OAuth 2.0が認可の仕組みとして使われています。

図6　場面ごとの認証と認可。どの場面でも、本人を確かめる仕組みと、何を許すかを決める仕組みが分かれている

AAAとの関係

ネットワーク機器へのログインなどでは、認証（Authentication）、認可（Authorization）に、記録（Accounting）を加えた「AAA」という言葉が使われます。RADIUSはAAAを担う代表的なプロトコルです。詳しくは【図解】RADIUSプロトコルがよくわかる！で紹介しています。

まとめ

認証は「本人か」を確かめ、認可は「何をしてよいか」を決めます。Windowsのドメイン環境では、本人確認はDCの力を借り、許可の判断はアクセスされる側のサーバが自分のACLで行います。

項目	押さえておくこと
認証	本人かどうかを確かめる。失敗するとサインインできない
認可	本人と分かった相手に、何を許すかを決める。失敗するとアクセスを拒否される
順番	必ず認証が先。認証に通っても、認可で断られることがある
Windowsでの分担	DCが本人確認を受け持ち、ファイルサーバが自分のACLで許可を判断する
アクセストークン	サインイン時にできる通行証。ユーザーとグループの情報が入り、ACLとの照合に使われる
グループの変更	サインインし直して新しいトークンができるまで反映されないことがある。`whoami /groups` で確認できる

参考にした資料

この記事は、次の資料を確認して書いています。