ネットワークスペシャリスト 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という）が、DSから取得したアカウント情報を基に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)に答えよ。
問題文を見る模範解答
ア：外部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レコード, ケルベロス認証
