ネットワークスペシャリスト 2022年 午後1 問03
シングルサインオンの導入に関する次の記述を読んで、設問1~3に答えよ。
Y社は、医療機器販売会社であり、都市に本社を構えている。受発注業務システムのサーバ(以下、業務サーバという)、営業活動支援システムのサーバ(以下、営業支援サーバという)など、複数のサーバを本社で運用している。
Y社では、IT活用の推進によって社員が利用するシステムが増加した結果、パスワードの使い回しが広がり、セキュリティリスクが増大した。また、サーバの運用を担当する情報システム部(以下、情シスという)では、アカウント情報の管理作業が増大したことから、アカウント情報管理の一元化が課題となった。
このような状況から、Y社は、社内のシステムへのシングルサインオン(以下、SSOという)の導入を決定した。情シスのZ課長は、SSOの導入検討を部下のX主任に指示した。
〔ネットワーク構成及び機器の設定と利用形態〕
最初に、X主任は、本社のネットワーク構成及び機器の設定と利用形態をまとめた。X主任が作成した、本社のネットワーク構成を図1に示す。

現状の機器の設定と利用形態を次に示す。
(i) 社内DNSサーバは、内部LANのゾーン情報を管理し、内部LAN以外のゾーンのホストの名前解決要求は、外部DNSサーバに転送する。
(ii) 外部DNSサーバは、DMZのゾーン情報の管理及びフルサロンサーバの機能をもっている。外部DNSサーバは、社外からの再帰問合せ要求は受け付けない。一方、社内DNSサーバ及びDMZのサーバからの再帰問合せ要求は受け付け、再帰問合せ時には、送信元ポート番号のランダム化を行う。
(iii) PCでは、プロキシ設定でプロキシサーバのFQDNが登録されているが、(a) 業務サーバ及び営業支援サーバへのアクセスは、プロキシサーバを経由せず Webブラウザから直接行う。
(iv) PCのスタブリゾルバは、社内DNSサーバで名前解決を行う。
(v) PC、サーバセグメントとDMZのサーバでは、マルウェア対策ソフトが稼働している。マルウェア定義ファイルの更新は、プロキシサーバ経由で行う。
(vi)(b)PC には、L3SW で稼働する DHCP サーバから、PC のIPアドレス、サブネットマスク及びその他のネットワーク情報が付与される。
図1中のFWに設定されている通信を許可するルールを表1に示す。

次に、X主任は、アカウント情報の一元管理をDSによって行い、DSの情報を利用してSSOを実現させることを考え、ケルベロス認証によるSSOについて検討した。
〔ケルベロス認証の概要と通信手順〕
X主任が調査して理解した、ケルベロス認証の概要と通信手順を次に示す。
・ケルベロス認証では、共通鍵暗号による認証票及びデータの暗号化を行っている。
・PCとサーバの鍵の管理及びチケットの発行を行う鍵配布センタ(以下、KDCという)が、DBから取得したアカウント情報を基にPC又はサーバの鍵を発行する。
・KDCが管理するドメインに所属するPCとサーバの鍵は、事前に生成してPC又はサーバに登録するとともに、全てのPCとサーバの鍵をKDCにも登録しておく。
・チケットには、PCの利用者の身分証明書に相当するチケット(以下、TGTという)と、PCの利用者がサーバでの認証を受けるためのチケット(以下、STという)の2種類があり、これらのチケットを利用してSSOが実現できる。
・PCの電源投入後に、利用者がID、パスワード(以下、PWという)を入力してKDCでケルベロス認証を受けると、HTTP over TLSでアクセスする業務サーバや営業支援サーバにも、ケルベロス認証向けのAPIを利用すればSSOが実現できる。
・KDCは、導入予定のDSで稼働する。
X主任は、内部LANにDSを導入したときの、SSOの動作をまとめた。PCの起動から営業支援サーバアクセスまでの通信手順を図2に示す。

図2中の、①〜⑧の動作の概要を次に示す。
① PCは、DSで稼働するKDCにID, PWを提示して、認証を要求する。
② KDCは、ID, PWが正しい場合TGTを発行し、PCの鍵で暗号化したTGTをPCに払い出す。PCは、TGTを保管する。
③ 省略
④ 省略
⑤ PCは、KDCにTGTを提示して、営業支援サーバのアクセスに必要なSTの発行を要求する。
⑥ KDCは、TGTを基に、PCの身元情報、セッション鍵などが含まれたSTを発行し、営業支援サーバの鍵でSTを暗号化する。さらに、KDCは、暗号化したSTにセッション鍵などを付加し、全体をPCの鍵で暗号化した情報をPCに払い出す。セッション鍵は、通信相手の正当性の検証などに利用される。
⑦ PCは、全体が暗号化された情報の中からSTを取り出し、ケルベロス認証向けのAPIを利用して、STを営業支援サーバに提示する。
⑧ 営業支援サーバは、STの内容を基にPCを認証するとともに、アクセス権限をPCに付与して、HTTP応答を行う。
TGTとSTには、有効期限が設定されている。(c)PCとサーバ間で、有効期限が正しく判断できていない場合は、有効期限内でも、PCが提示したSTを、サーバが使用不可と判断する可能性があるので、PCとサーバでの対応が必要である。
〔SRVレコードの働きと設定内容〕
次に、X主任は、ケルベロス認証を導入する際のネットワーク構成について検討した。ケルベロス認証導入時には、DNSのリソースレコードの一つであるSRVレコードの利用が推奨されているので、SRVレコードについて調査した。
DNSサーバにSRVレコードが登録されていれば、サービス名を問い合わせることによって、当該サービスが稼働するホスト名などの情報が取得できる。
SRVレコードのフォーマットを図3に示す。

X主任は、図1に示したように、内部LANにDSを2台導入して冗長化し、それぞれのDSでケルベロス認証を稼働させる構成を考えた。
図3中の、Serviceには、ケルベロス認証のサービス名である、kerberosを記述する。Priorityは、同一サービスのSRVレコードが複数登録されている場合に、利用するSRVレコードを判別するための優先度を示す。Priorityが同じ値の場合は、WeightでTargetに記述するホストの使用比率を設定する。Portには、サービスを利用するときのポート番号を記述する。
X主任は、2台のDSでケルベロス認証を稼働させる場合の、SRVレコードの設定内容を検討した。
X主任が作成した、ケルベロス認証向けのSRVレコードの内容を図4に示す。ここで、DS1とDS2は、本社に導入予定のDSのホスト名である。

X主任は、調査・検討結果を基にSSOの導入構成案をまとめ、Z課長に提出した。導入構成案が承認され、実施に移されることになった。
設問1:〔ネットワーク構成及び機器の設定と利用形態〕について、(1)〜(4)に答えよ。
(1)本文中の下線(a)の動作を行うために、PCのプロキシ設定で登録すべき内容について、40字以内で述べよ。
模範解答
業務サーバと営業支援サーバのFQDNを、プロキシ除外リストに登録する。
解説
解答の論理構成
- PCは「プロキシ設定でプロキシサーバのFQDNが登録」されています。したがって通常の HTTP/HTTPS 通信はプロキシサーバ経由です。
- しかし本文には、引用 “(a) 業務サーバ及び営業支援サーバへのアクセスは、プロキシサーバを経由せず Webブラウザから直接行う” とあります。
- ブラウザで「特定ホストだけプロキシを使わない」方法は、一般に“プロキシ除外(バイパス)リスト”への登録です。
- 除外対象はホスト名ではなく「FQDN」で指定するのが誤解の余地がありません。
- 以上より、解答は「業務サーバと営業支援サーバのFQDNをプロキシ除外リストに登録する」となります。
誤りやすいポイント
- プロキシの無効化を“全体でオフにする”と勘違いしがちですが、要件は「特定サーバのみ直接接続」です。
- IPアドレスを除外リストに書くと、FQDNでアクセスした際に名前解決後再度プロキシ経由になるケースがあります。FQDNでの指定が安全です。
- PACファイルや WPAD の利用を想起して長いスクリプトを答えてしまうと論点がずれます。本問は単純な静的設定です。
FAQ
Q: プロキシ除外リストはブラウザごとに設定が必要ですか?
A: グループポリシーや構成プロファイルで一元配布可能ですが、手動設定の場合は各ブラウザで個別に指定する必要があります。
A: グループポリシーや構成プロファイルで一元配布可能ですが、手動設定の場合は各ブラウザで個別に指定する必要があります。
Q: サーバの IP アドレスを直接登録しても動作しますか?
A: 一部環境では機能しますが、FQDN でアクセスした際には再度プロキシが適用される恐れがあるため、FQDN の登録が推奨されます。
A: 一部環境では機能しますが、FQDN でアクセスした際には再度プロキシが適用される恐れがあるため、FQDN の登録が推奨されます。
Q: 業務サーバ・営業支援サーバが将来増えた場合の運用は?
A: PAC ファイルに条件分岐を書く、あるいは同一ドメイン配下をワイルドカードで除外する方法が考えられます。
A: PAC ファイルに条件分岐を書く、あるいは同一ドメイン配下をワイルドカードで除外する方法が考えられます。
関連キーワード: プロキシ設定, 例外リスト, FQDN, 内部サーバ, 直接接続
設問1:〔ネットワーク構成及び機器の設定と利用形態〕について、(1)〜(4)に答えよ。
(2)本文中の下線(b)について、(iii)〜(v)の実行を可能とするための、その他のネットワーク情報を二つ答えよ。
模範解答
①:社内DNSサーバのIPアドレス
②:デフォルトゲートウェイのIPアドレス
解説
解答の論理構成
- 下線部(b)にあるとおり、PCは「L3SW で稼働する DHCP サーバ」から
「PC の IP アドレス、サブネットマスク及びその他のネットワーク情報」を受け取ります。
ここで“その他”に何を含めるかが設問の焦点です。 - (iii)~(v)の利用形態を整理すると、PCは次の三つの通信を行います。
・(iii) 直接「業務サーバ」「営業支援サーバ」へアクセスする
・(iv) 「社内DNSサーバ」で名前解決を実施する
・(v) 「プロキシサーバ」経由でインターネットからマルウェア定義ファイルを取得する - これらを正しく行うには
① 宛先FQDNをIPアドレスへ変換するための「社内DNSサーバのIPアドレス」
② 内部LAN外(DMZやインターネット)への経路を示す「デフォルトゲートウェイのIPアドレス」
が不可欠です。 - よって、DHCPで配布すべき“その他のネットワーク情報”は
「社内DNSサーバのIPアドレス」および「デフォルトゲートウェイのIPアドレス」となります。
誤りやすいポイント
- プロキシサーバのFQDNはブラウザ設定内に固定で登録されているため、IPアドレスをDHCPで配布する必要はありません。FQDN解決に必要なのはDNS情報です。
- 「サブネットマスク」と混同して、ルータやL3SW自身の管理用IPアドレスを答えてしまうケースがありますが、ルーティングに必要なのは“経路の出発点”であるデフォルトゲートウェイです。
- SRVレコードの設定と混同し、DNSドメイン名を答えてしまうミスに注意しましょう。求められているのは“IPアドレス”です。
FAQ
Q: デフォルトゲートウェイのIPアドレスがなくても同一セグメント内のサーバには届くのでは?
A: 同一サブネットの通信は可能ですが、(v) のように DMZ へ出る場合やインターネット通信にはルーティングが必要です。したがってデフォルトゲートウェイの設定は必須です。
A: 同一サブネットの通信は可能ですが、(v) のように DMZ へ出る場合やインターネット通信にはルーティングが必要です。したがってデフォルトゲートウェイの設定は必須です。
Q: DHCPでプロキシサーバのアドレスを配布しても問題ありませんか?
A: 技術的には可能ですが、本問は“(iii)〜(v)の実行に最低限必要な情報”を問うています。ブラウザ設定にFQDNが登録済みなので必須ではありません。
A: 技術的には可能ですが、本問は“(iii)〜(v)の実行に最低限必要な情報”を問うています。ブラウザ設定にFQDNが登録済みなので必須ではありません。
Q: DNSに外部のパブリックDNSを指定しても動作しますか?
A: 社内システム(「業務サーバ」「営業支援サーバ」など)の名前解決には内部情報を持つ「社内DNSサーバ」が必要です。外部DNSのみでは社内ホストを引けず、(iii) が成立しません。
A: 社内システム(「業務サーバ」「営業支援サーバ」など)の名前解決には内部情報を持つ「社内DNSサーバ」が必要です。外部DNSのみでは社内ホストを引けず、(iii) が成立しません。
関連キーワード: DHCP, デフォルトゲートウェイ, DNS, ルーティング, FQDN
設問1:〔ネットワーク構成及び機器の設定と利用形態〕について、(1)〜(4)に答えよ。
(3)表1中のア、ウ〜カに入れる字句を、図1又は表1中の字句を用いて答えよ。
模範解答
ア:外部DNSサーバ
ウ:公開Webサーバ
エ:プロキシサーバ
オ:any
カ:社内DNSサーバ
解説
解答の論理構成
-
[ア] の決定
- 表1の項番1・3は “インターネット→DMZ” および “DMZ→インターネット” で TCP/53(DNS)を許可しています。
- 問題文 (ii) に「“外部DNSサーバは、DMZのゾーン情報の管理及びフルサロンサーバの機能をもっている。”」とあり、インターネット側と DNS 通信するサーバは DMZ 内の “外部DNSサーバ” だけです。
- よって [ア]=外部DNSサーバ。
-
[ウ] の決定
- 表1項番2は “DMZ” 内で TCP/443(HTTPS)を受け付ける宛先を設定しています。
- 図1の DMZ には “公開Webサーバ”“プロキシサーバ”“外部DNSサーバ” が存在。HTTPS の待受を行うのは通常 Web サーバです。
- したがって [ウ]=公開Webサーバ。
-
[エ]・[オ] の決定
- 表1項番4は “DMZ→インターネット” で TCP/80, TCP/443 を許可する送信元を指定しています。
- 問題文 (iii) に「“プロキシサーバ経由で”」とあるように、社内からの Web アクセスは DMZ の “プロキシサーバ” が代理で外部サイト(宛先は任意)へ接続します。
- 送信元は プロキシサーバ で、宛先は any(外部全般)。
- よって [エ]=プロキシサーバ、[オ]=any。
-
[カ] の決定
- 表1項番5も DNS 用ポートを用いており、宛先は [ア]=外部DNSサーバ。
- 問題文 (i) では「“社内DNSサーバは…内部LAN以外のゾーンのホストの名前解決要求は、外部DNSサーバに転送する。”」と明記されています。
- したがって外部DNSサーバへ問い合わせを行う送信元は “社内DNSサーバ”。
- よって [カ]=社内DNSサーバ。
以上から
ア:外部DNSサーバ
ウ:公開Webサーバ
エ:プロキシサーバ
オ:any
カ:社内DNSサーバ
ア:外部DNSサーバ
ウ:公開Webサーバ
エ:プロキシサーバ
オ:any
カ:社内DNSサーバ
誤りやすいポイント
- “外部DNSサーバ” と “社内DNSサーバ” の役割を混同し、[ア] と [カ] を逆にしてしまう。
- “公開Webサーバ” と “プロキシサーバ” のどちらが 443 を待受するか悩み、[ウ] を誤って “プロキシサーバ” としてしまう。
- 表1の “アクセス経路” 列を流れの向きと誤解し、送信元/宛先を逆に読んでしまう。
- any を具体的なホスト名で答えてしまい [オ] を失点する。
FAQ
Q: “外部DNSサーバ” が 53 番ポートを使うのは分かるのですが UDP ではなく TCP だけで良いのですか?
A: 表1は許可ルールの抜粋で、TCP/53 を例示しています。DNS は UDP/53 が一般的ですが、ゾーン転送や大きな応答では TCP/53 が使われるため、ここでは TCP を許可しています。
A: 表1は許可ルールの抜粋で、TCP/53 を例示しています。DNS は UDP/53 が一般的ですが、ゾーン転送や大きな応答では TCP/53 が使われるため、ここでは TCP を許可しています。
Q: “プロキシサーバ” が送信元になるのはなぜですか?
A: 社員の PC は DMZ の “プロキシサーバ” を経由して外部 Web へアクセスします(問題文 (iii))。従って実際にインターネットへ HTTP/HTTPS を発信するのはプロキシサーバであり、FW では送信元としてプロキシサーバを許可します。
A: 社員の PC は DMZ の “プロキシサーバ” を経由して外部 Web へアクセスします(問題文 (iii))。従って実際にインターネットへ HTTP/HTTPS を発信するのはプロキシサーバであり、FW では送信元としてプロキシサーバを許可します。
Q: “社内DNSサーバ” が DMZ 側の “外部DNSサーバ” に問い合わせる設計は一般的なのですか?
A: 内部向けの名前解決を行う権威サーバ(社内DNSサーバ)が、自ドメイン外の名前解決を行う際に DMZ のフルサービスリゾルバ(外部DNSサーバ)へフォワードする構成は、境界防御を強化しログを集約できるためよく採用されます。
A: 内部向けの名前解決を行う権威サーバ(社内DNSサーバ)が、自ドメイン外の名前解決を行う際に DMZ のフルサービスリゾルバ(外部DNSサーバ)へフォワードする構成は、境界防御を強化しログを集約できるためよく採用されます。
関連キーワード: DNSフォワード, DMZ, プロキシ, ファイアウォール, HTTPS
設問1:〔ネットワーク構成及び機器の設定と利用形態〕について、(1)〜(4)に答えよ。
(4)表1中のイに入れるプロトコル/ポート番号を答えよ。
模範解答
イ:UDP/53
解説
解答の論理構成
- 表1の行①では、インターネットから DMZ 内の ア(=「外部DNSサーバ」)へ許可する通信として
「TCP/53, イ」が列挙されています。
DNS の標準ポートは “53番” で、TCP と UDP の両方が使われます。 - 問題文 (i)・(ii) では、
・「社内DNSサーバは…内部LAN以外のゾーンのホストの名前解決要求は、外部DNSサーバに転送する。」
・「外部DNSサーバは…社内DNSサーバ及び DMZ のサーバからの再帰問合せ要求は受け付け…」
とあり、内部・外部双方からの名前解決(=通常の DNS クエリ/レスポンス)が必要であることが示されています。 - 通常のDNS問い合わせは UDP/53 を用い、ゾーン転送や応答サイズの大きい場合に限り TCP/53 が使われます。したがって、名前解決を成立させるには UDP/53 を許可しなければなりません。
- よって イ に入るべきプロトコル/ポート番号は
「UDP/53」 となります。
誤りやすいポイント
- 「DNS=UDP」と短絡し、TCP/53 を削除してしまう。表1には既に「TCP/53」が記載されているので、もう一方のプロトコルが抜けていないか確認が必要です。
- 逆に「ゾーン転送=TCP」という知識から TCP/53 だけを書き、UDP/53 を失念する。
- SMTP, HTTP など別サービスと混同し、25 や 80 番ポートを書いてしまう。
FAQ
Q: DNS で TCP が使われるのはどんなときですか?
A: ゾーン転送(AXFR/IXFR)や、応答が 512 バイト(EDNS 適用前)を超えてフラグメントできない場合など、大容量データを送るときです。
A: ゾーン転送(AXFR/IXFR)や、応答が 512 バイト(EDNS 適用前)を超えてフラグメントできない場合など、大容量データを送るときです。
Q: UDP/53 を閉じても名前解決できますか?
A: ほとんどの場合できません。リゾルバの通常問い合わせは UDP を前提とするため、TCP のみ開放では大幅に通信遅延や失敗が発生します。
A: ほとんどの場合できません。リゾルバの通常問い合わせは UDP を前提とするため、TCP のみ開放では大幅に通信遅延や失敗が発生します。
Q: 送信元ポート番号のランダム化は何のために行うのですか?
A: DNS キャッシュポイズニング攻撃を防ぐためです。問い合わせ ID と送信元ポートを推測しづらくして、偽回答を送り込む難易度を高めます。
A: DNS キャッシュポイズニング攻撃を防ぐためです。問い合わせ ID と送信元ポートを推測しづらくして、偽回答を送り込む難易度を高めます。
関連キーワード: DNS, UDP, TCP, ポート番号, ファイアウォール
設問2:〔ケルベロス認証の概要と通信手順〕について、(1)〜(3)に答えよ。
(1)攻撃者が図2中の②の通信を盗聴して通信データを取得しても、攻撃者は、⑦の通信を正しく行えないので、営業支援サーバを利用することはできない。
⑦の通信を正しく行えない理由を、15字以内で述べよ。
模範解答
STを取り出せないから
解説
解答の論理構成
-
②の通信で攻撃者が得られる情報
【問題文】では「② KDCは、ID, PWが正しい場合TGTを発行し、PCの鍵で暗号化したTGTをPCに払い出す」とあります。盗聴できるのは“TGT”であって“ST”ではありません。さらに「PCの鍵で暗号化」されているため、攻撃者は中身を閲覧できません。 -
⑦の通信に必要な情報
⑦の手順は「PCは、全体が暗号化された情報の中からSTを取り出し、…STを営業支援サーバに提示する」と記述されています。営業支援サーバ側はこの“ST”を検証して初めて認証を完了させます。 -
②で取得したTGTでは⑦を実行できない理由
(1) STそのものが存在しない。
(2) TGTを用いてKDCからSTを発行してもらうには「⑤ PCは、KDCにTGTを提示して、営業支援サーバのアクセスに必要なSTの発行を要求する」必要がありますが、ここでKDCは「PCの鍵」を用いて応答を暗号化します(⑥参照)。攻撃者はこの鍵を持たないため復号も利用も不可能です。 -
結論
よって、攻撃者は「STを取り出せない」ため⑦の通信を正しく行えず、営業支援サーバを利用できません。
誤りやすいポイント
- 「②でTGTを入手したからST取得も可能」と誤解する
→ ⑥でKDCが再度「PCの鍵」で暗号化する仕組みを見落とすと、この誤認に陥ります。 - 「TGTをそのまま⑦で送れば認証できる」と考える
→ サーバが受け入れるのはTGTではなくSTです。 - 「公開鍵暗号だと思い込み、鍵を推測できる」と誤解する
→ 本文は「共通鍵暗号」による暗号化であり、鍵は配布済みの秘密情報です。
FAQ
Q: TGTさえあればKDCを介さず直接サーバに提示できませんか?
A: できません。サーバが認めるのは「⑥ KDCは…STを発行し、営業支援サーバの鍵でSTを暗号化する」で生成されたSTだけです。TGTはKDCとのやり取り専用です。
A: できません。サーバが認めるのは「⑥ KDCは…STを発行し、営業支援サーバの鍵でSTを暗号化する」で生成されたSTだけです。TGTはKDCとのやり取り専用です。
Q: 攻撃者がPCの鍵を総当たりで推測したら?
A: PCの鍵は十分長くランダムな共通鍵であり、総当たり攻撃は現実的ではありません。また有効期限も設定されているため時間的猶予も限られます。
A: PCの鍵は十分長くランダムな共通鍵であり、総当たり攻撃は現実的ではありません。また有効期限も設定されているため時間的猶予も限られます。
Q: STを奪取できたとしても再利用は可能ですか?
A: STには「有効期限」が含まれ、「(c)PCとサーバ間で、有効期限が正しく判断できていない場合…」とあるように、期限外のSTは無効化されます。盗んでも期限切れで使えない場合が大半です。
A: STには「有効期限」が含まれ、「(c)PCとサーバ間で、有効期限が正しく判断できていない場合…」とあるように、期限外のSTは無効化されます。盗んでも期限切れで使えない場合が大半です。
関連キーワード: ケルベロス認証, 共通鍵暗号, チケット, DNS SRVレコード, シングルサインオン
設問2:〔ケルベロス認証の概要と通信手順〕について、(1)〜(3)に答えよ。
(2)図2中で、ケルベロス認証サービスのポート番号88が用いられる通信を、①〜⑧の中から全て選び記号で答えよ。
模範解答
①、②、⑤、⑥
解説
解答の論理構成
-
ケルベロス認証で使用されるポート
図4の SRV レコードには Port として 88 が設定されています。これは「サービス名 kerberos」に対するポート番号を示しており、すなわち “ケルベロス認証サービスのポート番号88” です。 -
図2の各動作と通信相手
- ① PC→DS …「PCは、DSで稼働するKDCにID, PWを提示して、認証を要求する。」
- ② DS→PC …「KDCは…TGTを発行し…PCに払い出す。」
- ③ PC→営業支援サーバ …HTTP 要求(Web アクセス)
- ④ 営業支援サーバ→PC …HTTP 401 応答
- ⑤ PC→DS …「PCは、KDCにTGTを提示して…STの発行を要求する。」
- ⑥ DS→PC …「KDCは…STを発行し…PCに払い出す。」
- ⑦ PC→営業支援サーバ …ST を提示した HTTP 要求
- ⑧ 営業支援サーバ→PC …HTTP 200 応答
-
ケルベロス認証の対象通信
KDC(DS)と PC 間でチケットのやり取りを行う①②⑤⑥は、ケルベロス認証そのものです。よって SRV レコードで定義した ポート番号88 が適用されます。 -
HTTP 上のケルベロス利用は対象外
⑦ は「ケルベロス認証向けのAPIを利用してST提示」とありますが、実際のトランスポートは「HTTP over TLS」であり、宛先サーバの TCP/443 が使われるためポート88ではありません。③④⑦⑧はいずれも HTTP 系である点に注意します。
以上より、ポート番号88を用いる通信は ①、②、⑤、⑥ です。
誤りやすいポイント
- ⑦もケルベロス関連語が登場するためポート88と誤認しやすいが、実態は TCP/443 の HTTP 要求。
- 「応答側(②⑥)はポート番号の出力側でない」として除外してしまうミス。双方向ともポート88を使用するので②⑥も含める。
- 「HTTP over TLS でアクセスする業務サーバや営業支援サーバにも、ケルベロス認証向けのAPIを利用すればSSOが実現できる。」という記述を読み、HTTP と同じポートだと混同するケース。
FAQ
Q: なぜ KDC 側応答の②と⑥にもポート88が当てはまるのですか?
A: ケルベロス認証は KDC が待ち受ける TCP/88 または UDP/88 で動作します。要求と応答は同じセッション内で行われるため、KDC→PC の戻り通信も同ポートを用います。
A: ケルベロス認証は KDC が待ち受ける TCP/88 または UDP/88 で動作します。要求と応答は同じセッション内で行われるため、KDC→PC の戻り通信も同ポートを用います。
Q: ⑦は “ケルベロス認証向けのAPI” とありますがポート88ではないのですか?
A: ⑦は HTTP(S) アプリケーション層で ST を送るだけで、トランスポート層は営業支援サーバの TCP/443 です。したがってケルベロス認証サービスのポート88には該当しません。
A: ⑦は HTTP(S) アプリケーション層で ST を送るだけで、トランスポート層は営業支援サーバの TCP/443 です。したがってケルベロス認証サービスのポート88には該当しません。
Q: ③と④は認証前のやり取りですがポート88は関係ない?
A: その通りです。③④は通常の Web 通信(要求は TCP/443、応答は同セッション)であり、ケルベロスプロトコルは走りません。
A: その通りです。③④は通常の Web 通信(要求は TCP/443、応答は同セッション)であり、ケルベロスプロトコルは走りません。
関連キーワード: ケルベロス認証, ポート番号, SRVレコード, TGT, ST
設問2:〔ケルベロス認証の概要と通信手順〕について、(1)〜(3)に答えよ。
(3)本文中の下線(c)の問題を発生させないための、PCとサーバにおける対処策を、20字以内で述べよ。
模範解答
PCとサーバ間で時刻同期を行う。
解説
解答の論理構成
- 【問題文】には
「TGTとSTには、有効期限が設定されている。」
「(c)PCとサーバ間で、有効期限が正しく判断できていない場合は、有効期限内でも、PCが提示したSTを、サーバが使用不可と判断する可能性がある」
とあります。 - ST(Service Ticket)は PC がサーバへ提示する際、サーバ側で “現在時刻” と ST に埋め込まれた “有効期限” を比較して妥当性を確認します。
- したがって PC とサーバで時刻がずれていると、ST の有効期限が誤って判定され、使用不可になる恐れがあります。
- 時刻ずれを解消する基本的な方法は、両端末が同一の時刻源(例:NTP)で同期することです。
- 以上より、PC とサーバの「時刻同期」を実施することが最も直接的な対処策となります。
誤りやすいポイント
- 「有効期限を長く設定すれば良い」と考えがちですが、認証票を長時間有効にするとリスクが増大し本質的な解決になりません。
- ケルベロス認証=共通鍵管理=暗号強度の問題と短絡し、時刻管理の重要性を見落とすケースがあります。
- タイムスタンプの検証はサーバ側だけが行うと誤解し、PC 側の時刻合わせを軽視してしまうことがあります。
FAQ
Q: 時刻ずれが数秒でも問題になりますか?
A: 有効期限チェックは秒精度で行われるため、わずかなずれでも ST が拒否される可能性があります。
A: 有効期限チェックは秒精度で行われるため、わずかなずれでも ST が拒否される可能性があります。
Q: NTP サーバは必ず社内に設置する必要がありますか?
A: 外部 NTP を利用しても構いませんが、FW やプロキシの許可ルールに留意し、安定した参照系を複数用意するのが望ましいです。
A: 外部 NTP を利用しても構いませんが、FW やプロキシの許可ルールに留意し、安定した参照系を複数用意するのが望ましいです。
Q: DS(KDC)とサーバの時刻が合っていれば PC は多少ずれていても動きますか?
A: PC も ST を生成・提示する際にタイムスタンプを利用するため、PC・サーバ・KDC の三者すべてで同期が必要です。
A: PC も ST を生成・提示する際にタイムスタンプを利用するため、PC・サーバ・KDC の三者すべてで同期が必要です。
関連キーワード: NTP, 時刻同期, ケルベロス認証, チケット
設問3:〔SRVレコードの働きと設定内容〕について、(1)〜(3)に答えよ。
(1)ケルベロス認証を行うPCが、図4のSRVレコードを利用しない場合、PCに設定しなければならないサーバに関する情報を、25字以内で答えよ。
模範解答
ケルベロス認証を行うサーバのFQDN
解説
解答の論理構成
-
SRVレコードがある場合
・【問題文】「DNSサーバにSRVレコードが登録されていれば、サービス名を問い合わせることによって、当該サービスが稼働するホスト名などの情報が取得できる。」
⇒ PC は “サービス名だけ” で KDC のホスト名(FQDN)とポート番号を自動取得し、接続先を判断できます。 -
SRVレコードを利用しない場合
・上記機能が使えないため、PC は自力で接続先を特定する必要があります。
・ケルベロス認証は KDC に対して行われるので、最小限必要なのは「どのホストに接続すべきか」という情報です。 -
どの情報を手動設定するか
・ポート番号はケルベロス既定の “88” で固定されており、多くの実装ではデフォルト値が用意されています。
・一方、ホストを識別する名前はネットワークごとに固有であり、SRVレコードなしでは自動解決できません。
⇒ 手動設定が求められるのは「ケルベロス認証を行うサーバの FQDN」です。
誤りやすいポイント
- 「IP アドレスを設定する」と誤解する
SRVレコードが返す主要情報はホスト名です。IP アドレスは通常、FQDN からの名前解決で得られます。 - 「Port“88”も手動設定が必須」と思い込む
多くのクライアント実装では “88/tcp” が既定値として組み込まれており、省略可能です。 - 「複数 KDC の優先度・重みを定義する」と考える
それらは SRV レコードで行う負荷分散機能であり、SRV を使わない前提では対象外です。
FAQ
Q: IP アドレスだけを設定してはダメですか?
A: FQDN を設定すれば名前解決で IP アドレスを取得でき、KDC を移設しても DNS 変更だけで済むため運用が容易です。
A: FQDN を設定すれば名前解決で IP アドレスを取得でき、KDC を移設しても DNS 変更だけで済むため運用が容易です。
Q: 複数 KDC を使う冗長構成の場合は?
A: SRV レコードを使わない場合、各 PC に冗長先の FQDN を複数登録するか、OS の設定で一覧を保持します。
A: SRV レコードを使わない場合、各 PC に冗長先の FQDN を複数登録するか、OS の設定で一覧を保持します。
Q: ポート“88”以外を使うケースはありますか?
A: ファイアウォールやポリシーの都合で変更する場合がありますが、その際はポート番号も明示設定が必要です。
A: ファイアウォールやポリシーの都合で変更する場合がありますが、その際はポート番号も明示設定が必要です。
関連キーワード: SRVレコード, FQDN, Kerberos, KDC, 名前解決
設問3:〔SRVレコードの働きと設定内容〕について、(1)〜(3)に答えよ。
(2)図4のSRVレコードが、PCのキャッシュに存在する時間は何分か答えよ。
模範解答
720
解説
解答の論理構成
- 図4の SRV レコードの TTL 欄には 「43200」 と記載されています。
- DNS の TTL は単位が秒であり、TTL の値の間は名前解決結果をキャッシュしてよいことを示します。
- 問いは「PC のキャッシュに存在する時間は何分か」とあるため、秒を分へ換算します。
- 以上より図4の SRV レコードが PC のキャッシュに残るのは 720 分となります。
誤りやすいポイント
- TTL の単位を誤って「分」や「時間」と思い込むと、43200 をそのまま回答してしまうミスが起こります。
- Priority や Weight の数値と混同しやすく、TTL の場所を見落とす受験者が少なくありません。
- DNS キャッシュの動作を OS 側のタイマーと混同し、「最長で保持される時間」と誤解して計算を省略するケースがあります。
FAQ
Q: TTL が過ぎる前にレコードが削除されることはありますか?
A: はい。PC などの DNS キャッシュはメモリ節約のために TTL 内でもエントリを破棄することがあります。ただし、TTL を超えて保持することはありません。
A: はい。PC などの DNS キャッシュはメモリ節約のために TTL 内でもエントリを破棄することがあります。ただし、TTL を超えて保持することはありません。
Q: Priority と Weight はキャッシュ時間に影響しますか?
A: 影響しません。それらは同一サービスが複数ある場合の到達先選択に用いられ、TTL はキャッシュ時間を決定します。
A: 影響しません。それらは同一サービスが複数ある場合の到達先選択に用いられ、TTL はキャッシュ時間を決定します。
Q: TTL を短く設定するとどんな利点と欠点がありますか?
A: 変更の反映が早くなる一方で、問い合わせ回数が増え DNS サーバの負荷や通信量が増加します。
A: 変更の反映が早くなる一方で、問い合わせ回数が増え DNS サーバの負荷や通信量が増加します。
関連キーワード: DNS, TTL, SRVレコード, キャッシュ
設問3:〔SRVレコードの働きと設定内容〕について、(1)〜(3)に答えよ。
(3)図4の二つのSRVレコードの代わりに、図5の一つのSRVレコードを使った場合、DS1とDS2の負荷がDNSラウンドロビンで行われることとなる。図4と同様の比率でDS1とDS2が使用されるようにする場合の、Aレコードの設定内容を、50字以内で述べよ。ここで、DS1のIPアドレスをadd1, DS2のIPアドレスをadd2とする。


模範解答
ホスト名がDSに対して、add1のAレコードを二つ、add2のAレコードを一つ記述する。
解説
解答の論理構成
- 図4の SRV レコードでは、
・「DS1.naibulan.y-sha.jp.」の Weight が【原文引用】「2」
・「DS2.naibulan.y-sha.jp.」の Weight が【原文引用】「1」
となっており、利用比率は DS1:DS2=2:1 です。 - 図5では Target が【原文引用】「DS.naibulan.y-sha.jp.」の 1 行だけに集約されています。したがって SRV レコード側では重み付けが行えません。
- DNS ラウンドロビンは、同一ホスト名に複数の A レコードを登録すると 各レコードを均等に返す 挙動です。
- 均等配布で 2:1 の比率を実現するには、A レコードの本数を DS1 用 2 本、DS2 用 1 本 とするのが最小構成です。
- 以上より、解答は「ホスト名がDSに対して、add1のAレコードを二つ、add2のAレコードを一つ記述する。」となります。
誤りやすいポイント
- SRV の Weight と DNS ラウンドロビンの動きの混同
Weight は SRV 内でのみ有効で、A レコードには影響しません。 - 「Priority『120』も 2:1 に関係する」と誤解
Priority は複数優先度が存在する場合の序列で、今回 2 レコードとも同一値なので比率とは無関係です。 - A レコードの登録順序で比率を制御できると考える誤り
多くの DNS 実装は順序を保持せず、応答時にシャッフルまたは round-robin します。必ず本数で調節します。
FAQ
Q: A レコードを 3 本以上にしても良いですか?
A: はい、add1 を 4 本・add2 を 2 本のように本数を倍増しても比率は 2:1 になりますが、最小本数が管理しやすいため 2 本と 1 本で十分です。
A: はい、add1 を 4 本・add2 を 2 本のように本数を倍増しても比率は 2:1 になりますが、最小本数が管理しやすいため 2 本と 1 本で十分です。
Q: DNS キャッシュが存在すると比率は崩れませんか?
A: 各クライアントがキャッシュを保持するため瞬間的に偏ることはありますが、TTL 満了ごとに再問い合わせが起こるので長期的には設定比率に収束します。
A: 各クライアントがキャッシュを保持するため瞬間的に偏ることはありますが、TTL 満了ごとに再問い合わせが起こるので長期的には設定比率に収束します。
Q: SRV ではなく A レコードで冗長化すると故障検知はできますか?
A: 標準的な DNS だけでは死活監視をしないため、障害時に無効 IP が返ることがあります。可用性を高めるにはヘルスチェック機能付きの GSLB やロードバランサと組み合わせます。
A: 標準的な DNS だけでは死活監視をしないため、障害時に無効 IP が返ることがあります。可用性を高めるにはヘルスチェック機能付きの GSLB やロードバランサと組み合わせます。
関連キーワード: SRVレコード, DNSラウンドロビン, 重み付け, Aレコード, ケルベロス認証


