CNAMEでSMB共有にアクセスしたい (1/2) - 彷徨うITエンジニアの雑記

CNAMEを使用してDNS エイリアスでファイルサーバにアクセスさせたい、という要求があると思います。
レプリケーション構成でプライマリ・セカンダリを切り替え運用する場合、リプレース時に既存ファイルサーバの名前を維持したい、等。
単純にファイルサーバを参照するCNAMEを設定しても、アクセスが通る場合、通らない場合があり、本投稿はその辺を調査・解説した内容となります。

前提としてクライアント、ファイルサーバは同一ドメインに所属しているものとします。
クライアントがファイルサーバに対しSMBアクセスする際の、正常なKerberos認証のフローは以下の通りです。

クライアントはADサーバ(KDC)からTGT(Ticket to Get Ticket)を取得する
クライアントはKDCに対しTGTとファイルサーバのSPN(Service Principal Name)を送信し、ファイルサーバのサービス鍵で暗号化されたサービスチケットを取得する
クライアントはファイルサーバに対しサービスチケットを送信する
ファイルサーバは自分のサービス鍵でチケットを複合化・検証し、クライアントを認証する

SPNは <クラス>/<ホスト名> @ <レルム> で指定され、SMBアクセスならcifs/nas-real.domain1.local @ DOMAIN1.LOCAL等になります。
SPNはドメインのコンピュータアカウントに紐づきますが、ホストのドメイン参加時にADサーバ上に自動作成されます。

コンピュータアカウントのSPNは setspn コマンドで確認可能です。

PS > setspn -L nas-real
次の項目に登録されている CN=nas-real,CN=Computers,DC=domain1,DC=local:
WSMAN/nas-real
WSMAN/nas-real.domain1.local
TERMSRV/nas-real
TERMSRV/nas-real.domain1.local
RestrictedKrbHost/nas-real
HOST/nas-real
RestrictedKrbHost/nas-real.domain1.local
HOST/nas-real.domain1.local

要求したSPNがKDCに存在しない場合、KRB_ERR_S_PRINCIPAL_UNKNOWN が返され、クライアントはサービスチケットを取得できません。
CNAMEを作成しただけでは、DNS エイリアスに対応するSPNcifs/dns-alias @ REALMが存在しないため、この状況が発生します。
そして、サービスチケットを入手出来なかったクライアントは、Kerberos認証からNTLM認証へフォールバックします。
NTLM認証が実行される条件としては他に、DNSベースでなくIPアドレスベースのアクセスが該当します。*1

上記より、CNAMEのみ登録した状態で、DNS エイリアスによるNASへのアクセスが成功するケースでは、NTLM認証が実行されていると推測できます。

クライアントがDNS エイリアスに対応するサービスチケットをキャッシュ出来ていないのにアクセスに成功していれば、NTLM認証です。

Windowsクライアントでキャッシュ済みのサービスチケットを確認するには、klist コマンドを使用します。

PS > klist tickets
...
#2>     クライアント: administrator @ DOMAIN1.LOCAL
        サーバー: cifs/nas-real.domain1.local @ DOMAIN1.LOCAL
        Kerberos チケットの暗号化の種類: AES-256-CTS-HMAC-SHA1-96
        チケットのフラグ 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
        開始時刻: 2/22/2020 18:22:09 (ローカル)
        終了時刻: 2/23/2020 4:18:43 (ローカル)
        更新期限: 2/29/2020 18:18:43 (ローカル)
        セッション キーの種類: AES-256-CTS-HMAC-SHA1-96
        キャッシュ フラグ: 0
        呼び出された Kdc: ad1.domain1.local

またはパケットをトレースするか、Windowsファイルサーバであればイベントログの4624からも判断できます。

Kerberos認証成功時のイベントログ：

...
ネットワーク情報:
	ワークステーション名:	-
	ソース ネットワーク アドレス:	10.10.1.100
	ソース ポート:		50120

詳細な認証情報:
	ログオン プロセス:		Kerberos
	認証パッケージ:	Kerberos
	移行されたサービス:	-
	パッケージ名 (NTLM のみ):	-
	キーの長さ:		0
...

NTLM認証成功時のイベントログ：

...
ネットワーク情報:
	ワークステーション名:	client1
	ソース ネットワーク アドレス:	10.10.1.121
	ソース ポート:		51983

詳細な認証情報:
	ログオン プロセス:		NtLmSsp 
	認証パッケージ:	NTLM
	移行されたサービス:	-
	パッケージ名 (NTLM のみ):	NTLM V2
	キーの長さ:		128
...

なお、WindowsにはサーバSPNターゲット名検証レベルという設定が存在します。*2
デフォルト無効ですが、有効の場合は必要と思われるSPNが登録されていても、DNS エイリアスでSMBアクセスした際に認証ダイアログが表示されて、さらに認証エラーとなりました。

f:id:wandering_engineer:20200222203424p:plain

よって、DNS エイリアスによるアクセスでKerberos認証をパスするには、以下の条件を満たしていれば良さそうです。

サーバ・クライアント間でSPNターゲット名の検証がオフになっている

ファイルサーバのコンピュータアカウントに、DNS エイリアスに対応するSPNが追加されている

ちなみに、AD上に手動でDNS エイリアス名のコンピュータアカウントを作成し、それにSPNを設定してみましたが動作しませんでした。
多分、サービスチケットの取得か複合化に失敗しているからだと思われます。（未調査）
NASリプレース時、旧NASのホスト名を引き継ごうとしてCNAME追加後に認証エラーとなるパターンも類似の事象で、旧NASのコンピュータアカウントとSPNがまだ存在している場合に、新NASが旧NASのサービス鍵で暗号化されたチケットの複合化に失敗しているのだと推測されます。

また、IPアドレスベース、非ドメインのホストからのアクセス(NTLM認証)を想定し、以下を実行しておくと良さそうです。