3 Minutes NetWorking Supplement
No.08

3Minutes NetWorking Supplement

補講第8回Kerberos(5) クロスレルム認証

■ クロスレルム認証

おねーさん

おね〜さんと、

ほげたん

ほげたんのっ!!

おねーさん

3 Minutes Networking、

ほげたん

Supplement !!

おねーさん

さて〜っと。Kerberosで認証する方法を説明してきたわけだけど。

ほげたん

うん。TGSとAS。チケット、だね?

おねーさん

そうそう。でね、いままでの説明は、基本的な認証、つまり1つのレルム内の認証だったわけでね。
認証されるユーザと、そのユーザが使うサーバと、KDCはみんな同じレルムにあったという場合なわけでしょ?

ほげたん

ん、そういえばそうだね。よくよく考えてみると、「レルム」って言葉はKerberosの第一回以来、ひさびさに聞いた気がするよ。

おねーさん

まぁ、基本的なのは、やはり同一レルム内の認証だからね。でもでも、同一のレルムだけの認証ですべてやっていける、ってわけじゃないわよね。
例えば、部門別でレルムを作っていたり、大学(レルム)間で共同作業をしたり、そういうことだってしたいわけじゃない。

ほげたん

ん〜っと、つまり、別のレルムのサーバを使うために認証されたいわけだよね。
じゃあ、そのレルムにユーザを登録しておけばいいんじゃない?

おねーさん

それはSSOの理念に反することになっちゃうじゃない。
Aというレルムのユーザが、Bというレルムのサーバを使いたいから、Bレルムにアカウントを作る。ユーザは、AとBの両方のアカウントを使わなきゃいけないのよ?

ほげたん

SSO、シングルサインオンは、1つのアカウントですべてのサーバに認証され、1度の認証だけでOKにしたい…。
確かに、レルムごとにアカウント作ったらSSOじゃなくなっちゃうよね。

おねーさん

そういうこと。これを解決するのが、クロスレルム認証なわけ。

ほげたん

くろすれるむ?

おねーさん

「レルム横断認証」ってところかな?

[FigureSP08-01:クロスレルム認証]

ほげたん

KDC間の信頼関係
あれれ? 信頼ってどっかで聞いたような…、ActiveDirectory?

おねーさん

うん、そうね。ActiveDirectory、つまりKerberos5レルムで使われてるわね。

ほげたん

あ、あ〜、そうだ。ツリーやフォレストの信頼関係だ。
そうでしょう、おね〜さん?

おねーさん

ほげたん、正解。そう、まさしくActiveDirectoryで言われてる信頼関係は、このクロスレルム認証の信頼関係のことなのよ。
さて、このクロスレルム認証、まずそうね、ほげたん、これなんだっけ?

  • krbtgt/3min.jp@3MIN.JP
ほげたん

え? 3min.jpのKerberosチケット交付サービスプリンシパル?

おねーさん

そう、ユーザは「TGTを交付するサービス」つまりASに対し、認証を要求してTGTをもらうんだったわよね。
その時に使う「要求するサービスのプリンシパル」が「krbtgt」で始まるプリンシパルよね。

ほげたん

うん、そうだよ。

おねーさん

今回、クロスレルムで使用する「要求するサービスのプリンシパル」は、これになるわ。

  • krbtgt/30min.com@3MIN.JP
ほげたん

ん? んんんん? なんか変?

おねーさん

プリンシパル名は、「サービス名/サービスのホストのFQDN@レルム」だったわね。
それを踏まえて、このプリンシパル名で要求するってのはどういうこと?

ほげたん

「3MIN.JPレルム」の「30min.comのホスト」の「krbtgtサービス」を要求する?
3MIN.JPレルムにある30min.comホスト?

おねーさん

そうよ。「krbtgt/30min.com@3MIN.JP」を要求して、30min.comホストのサービスチケットを入手することで、クロスレルム認証は行われるのよ。

[FigureSP08-02:クロスレルム認証]

ほげたん

え〜っと、自分のレルムのKDCに、認証されたい他レルムのKDCのチケットを発行してもらうんだ。

おねーさん

そういうことね。最初の自レルムのKDCからTGTをもらうのはお約束だからいいとして。
他レルムのKDCに認証されるために、krbtgtチケットをもらうわけね。

ほげたん

で、そのkrbtgtチケットは、信頼関係を結んだKDCの双方が保有する秘密鍵で暗号化されてるから。krbtgtチケットを送ってきた=信頼関係にあるKDCが発行した、で認証するわけだね。

おねーさん

そういうこと。で、ポイント1。
その秘密鍵だけど、鍵はプリンシパル1つにつき1つ作成されるものよね。同じ鍵を持つ2つのプリンシパルがあるって変よね。

ほげたん

うん、そうだね。

おねーさん

よって、信頼関係は方向がある

[FigureSP08-03:クロスレルム認証の方向]

ほげたん

krbtgt/30min.com@3MIN.JPは、レルムが3min.jpだから、3min.jpに所属するサービス扱い?
30min.comのKDCは「3min.jpで30min.comのチケットを配布するサービス」って意味になっちゃうってことかな?

おねーさん

その理解でOK。よって、30min.comのユーザがkrbtgt/30min.com@3MIN.JPを使うことはできないわけ。違うレルムのサービスだからね。

ほげたん

krbtgt/30min.com@「3MIN.JP」だから、30min.comのユーザは使えない、と。

おねーさん

だから、30min.com側にはkrbtgt/3min.jp@30MIN.COMという「30min.comで3min.jpのチケットを配布するサービス」のプリンシパルが必要ってこと。

ほげたん

そういえば、ActiveDirectoryでも、信頼は両方に設定しなきゃダメだったっけ。

おねーさん

ポイント2つめ。
このクロスレルム認証方式は、「ダイレクトクロスレルム認証」って呼ばれてるんだけど。

ほげたん

ダイレクト?

おねーさん

うん。KDCがクロスレルムするレルムの鍵を持つ方式って意味なんだけど。
ほげたん、この方式だと、クロスレルムするレルムの数が多くなるとどうなる?

ほげたん

クロスレルムするレルムの数だけ、鍵が必要になるよ。
え〜っと、もしかして、鍵の数が多くなるのが問題?

おねーさん

単純計算で、n2個の鍵が必要になってしまうわけよね。ちょっとそれは大変だなぁと思うわけよ。
なので、仲介レルムを使う形になるわけ。

[FigureSP08-04:仲介レルム]

ほげたん

うわ〜、なんか面倒くさい方法だね。

おねーさん

まぁ、そうなっちゃうわね。ユーザは所属するレルムに認証して、つぎに仲介レルムに認証して、最後に宛先レルムに認証してもらうというステップを踏むわけよ。でも、これなら仲介レルムとだけ鍵を共有すればいいから楽でしょ?

ほげたん

それは確かに。

おねーさん

実際は、これを利用して階層型信頼ってのを使うのが多いかな?
まったく別のレルム同士じゃなくて、1つのドメイン(レルム)の子ドメインって形にするの。

ほげたん

木構造(ツリー)?

おねーさん

そう。仲介レルムは親ドメインがなって、子ドメイン同士で認証するって形ね。

ほげたん

なるほど。

■ 転送可能チケット

おねーさん

クロスレルム認証は、SSOを実現するための手段として存在するわけだけど。
他にも、Kerberosを普通に使ってると、SSOにならないことってあるのよ。

[FigureSP08-05:リモートログインとTGT]

おねーさん

くどいようだけど、2度も3度もパスワードを要求するのは、SSOとして失格よね。
これって何が問題なの?

ほげたん

なにが問題って……。
TGTがホストに保存されて使用されること、かな?

おねーさん

そうよね、TGTってホストに保存されちゃうのよね。
そのユーザがそのホストを使用している間はTGTは使いたい放題なんだけど、ホストを移動しちゃうとダメになっちゃう。

ほげたん

うん、でも、まぁ、これはしかたないんじゃないかなぁ。

おねーさん

でもよ、ほげたん。実際に物理的に移動するならともかく、リモートホストよ? ちょっと面倒くさくない?

ほげたん

それは確かに面倒くさいと思うよ。

おねーさん

シングルサインオン、一度認証されたらそのホストからログオフするまではパスワードなんか入力する必要なし、ってしたいじゃない。
ってことで、Kerberosにはちゃ〜んと用意されてます。それが転送可能チケットよ。

ほげたん

ふぉわーだぶる? 転送可能? どこに?

おねーさん

リモートホストに、よ。

[FigureSP08-06:転送可能チケット]

ほげたん

TGTもユーザと一緒に移動するんだ。

おねーさん

うん、そう考えるのがいいわよね。
それでね、これで考えることは2つ。1つ目、リモートホストに転送されたTGTは残ってしまうってこと。

ほげたん

残らないとまずいんじゃない? リモートホストに保存されないと使えないじゃない。

おねーさん

ん〜いやいや、そういう意味じゃなくてね。リモートホストからログオフしても残っちゃうのよ。なので、ログオフ前に消すっていう作業が必要ね、ってこと。

ほげたん

あぁ、なるほど。

おねーさん

もう1つ、リモートログインの際に転送されたチケットだけど。
さらにリモートホストから他のホストにリモートログインした場合どうなるかってこと。

ほげたん

リモートからさらにリモートへ? でもSSOから考えると、また転送してくれないと困らない?

おねーさん

うん。転送可能チケットの場合は、さらに転送される。
それとは別に、1回しか転送されないってオプションもあるのよ。こっちは代理可能チケットって呼ばれるわ。

ほげたん

代理、ぷろきさぶる。
最初にリモートログインされる時には転送されるけど、リモートからリモートへは転送されないってこと?

おねーさん

そういうこと。

■ IPアドレスとポート番号

ほげたん

……おね〜さん。

おねーさん

なに?

ほげたん

ちょっと気がついたんだけどさ。

KRB_AP_REQ

[FigureSP07-06:KRB_AP_REQ]

ほげたん

これはサービスチケットだけど、TGTもサービスチケットも、クライアントIPアドレスが入ってるよね。
リプレイ攻撃を防ぐために。

おねーさん

うん、入ってるわね。

ほげたん

さっきの話。リモートホストにTGTを送って、認証に使うんだけど。
最初にTGTを取得したローカルホストと、リモートホストってIPアドレス違うじゃない。どうするの?

おねーさん

うん、そうよね。
そうなると、リモートホストからの要求は、IPアドレスが違うからリプレイアタックと判断されちゃうわよね。

ほげたん

でしょ? どうするの?

おねーさん

簡単。要求の際にチケットのクライアントIPアドレスを変えてもらうことができるよ。

ほげたん

? つまり、リモートホストで使うから、こっちのIPアドレスにしてって頼むわけ?

おねーさん

もしくは、クライアントIPアドレスなしのチケットを要求することができるのよ。

ほげたん

なんだ、そんなことができるんだ。

おねーさん

うん。他にもNATによる変換にIPアドレスが変わっちゃう場合もあるわけだしね。そこらへんは抜かりなしって感じ?

ほげたん

へ〜。

おねーさん

そうそう、Kerberosで使うポートの話してなかったわね。Kerberosは88番ポートを使います。

ほげたん

TCPとUDPどっち?

おねーさん

両方。あと、管理用749番と464番を使うの。パスワードの変更とかにね。
まぁ、基本的なチケットのやりとりは88番でOKだけど。

ほげたん

なるほど。

おねーさん

じゃ、今回はこれぐらいにしておきましょ。
まだまだKerberosの話はあるんだけど、一応これで一区切り。

ほげたん

そなの?

おねーさん

うん。他にもいずれ使われるであろう公開鍵暗号化方式との組み合わせとか、あることはあるんだけど。
これ以上詳しい話はちょっと実装面の話ばっかりになっちゃうのよ。

ほげたん

う〜ん、それはちょっとね。

おねーさん

現在のKerberos認証の代表格であるActiveDirectoryドメイン認証とか、いろいろ話はしたかったけど。うん、ここでおしまい。

ほげたん

次回は?

おねーさん

まだ、な・い・しょ。
おね〜さんと、

ほげたん

ほげたんのっ!!

おねーさん

3分間ネットワーク、

ほげたん

サプリメントでした〜〜〜っ!!
それはそれとして、「な・い・しょ」が壮絶に似合ってないよ、おね〜さん

おねーさん

(ギロリ)

ほげたん

うごぁっ!!

クロスレルム認証
[Cross=Realm Authentication]
ツリーやフォレスト
WindowsのActiveDirectoryドメインでは、ドメイン(レルム)が親子関係にある(例えば3min.jpとex.3min.jp)場合、ツリーと呼ぶ。そのツリーをまとめたものがフォレスト。
階層型信頼
[Hierarchical Trust]
Kerberos5から対応。
転送可能チケット
[Fowardable Ticket]
Kerberos5から対応
代理可能チケット
[Ploxiable Ticket]
これもKerberos5から。
ほげたんほげたんの今日のポイント
  • 異なるレルムのサービスを使うために、使用するのがクロスレルム認証。
    • レルム間で信頼関係を構築する必要がある。
    • 信頼関係は片方向なので、双方向にする場合は2つの鍵を設定する。
    • 多くのレルムでクロスレルム認証するには、仲介レルムを使うと効率的
  • リモートログインなどでSSOを実現するために、転送可能チケットを使うことができる。
  • チケットのクライアントIPアドレスは要求時に変更が可能

3 Minutes NetWorking Supplement No.08

管理人:aji-ssz(at)selene.is.dream.jp