Windows Server 2025 への移行後に発生する secd.lsa.noServers エラーと SMB3 暗号化の対処法

冒頭文
Windows Server 2025 へ移行した環境で NetApp ONTAP を利用している際、SVM（Vserver）の作成や削除時に「secd.lsa.noServers」や「NT_STATUS_NOT_SUPPORTED」「Unable to connect to LSA service」などのエラーが出て処理が失敗する事例が報告されています。本稿では発生状況の整理、想定される原因の切り分け、および現場で実践できる検証手順と対処方法をわかりやすくまとめます。対象は ONTAP 9／CIFS（SMB）環境で、特に SMB3 の暗号化やプロトコルネゴシエーションが絡む場面を中心に説明します。

発生環境と代表的な症状
原因の整理（要点）
影響範囲の把握
対応の全体方針
具体的なトラブルシューティング手順（現場で実行する操作説明）
早見チェック表
代表的な対処・解決策
事例と所見（現場で注意すべき点）
まとめと推奨アクション

発生環境と代表的な症状

Windows Server 2025 をドメインコントローラー（DC）あるいは AD 関連役割として使う環境において、NetApp の SVM（Vserver）で CIFS/SMB を設定中または SVM 作成・削除中に次のようなエラーメッセージが出ることがあります。
例示されるエラー文（要点抜粋）：secd.lsa.noServers: None of the LSA servers configured for Vserver (<vserver_name>) are currently accessible via the network. / NT_STATUS_NOT_SUPPORTED for SMB command Negotiate / Unable to connect to LSA service on <dc-fqdn> / RESULT_ERROR_SECD_NO_SERVER_AVAILABLE。これらは「LSA（Local Security Authority）への接続が確立できない」「SMB ネゴシエーションでサポートされない機能が見つかった」ことを示しています。

原因の整理（要点）

根本原因は一つに限定されないが、以下の要素が絡むことが多い。
SMB プロトコルのバージョン不一致や暗号化要求のミスマッチ、SVM と DC 間のネットワーク経路（ファイアウォール、ポリシー、MTU、名前解決）の問題、ドメインコントローラー側での SMB3 暗号化要件の導入、または NetApp 側の ONTAP バージョンが新しい Windows Server の SMB/LSA 要件に未対応であるケースが典型です。エラー中の「NT_STATUS_NOT_SUPPORTED」は、ネゴシエートした SMB コマンドを受け側がサポートしていないと判断したことを示唆します。結果として NetApp の secd プロセスが LSA サービスへ接続できず「no server available」と報告します。

影響範囲の把握

SVM の AD 登録（Machine Account の作成）や CIFS サービスの有効化が阻害されるため、ファイル共有機能全体に影響が及びます。クライアントからの接続以前に発生する問題のため、SVM 単位での運用停止リスクがあります。影響を最小化するために、まずは SVM が参照する DC の一覧、優先度、名前解決、接続可否を確認します。

対応の全体方針

物理・ネットワーク・名前解決の基本を最初に確認する（DC 名が解決できるか、ポート 445/TCP の疎通など）。
SMB ネゴシエーションと暗号化ポリシーの不一致を切り分ける（SMB3 暗号化が必須になっているか、どちら側が暗号化を要求しているか）。
ONTAP と Windows Server 側の互換性・パッチレベルを確認する（NetApp のリリースノートや KB に対応パッチがある可能性）。
回避策として一時的に暗号化要件を緩める、あるいは NetApp 側の SMB 設定でネゴシエーションの互換性を持たせる。これらは運用ポリシーに従って慎重に実施する。

具体的なトラブルシューティング手順（現場で実行する操作説明）

ここからは実際に行う検証手順。操作説明なので箇条書きで手順を示す。

SVM が参照しているドメインコントローラーを特定する。NetApp 側の管理画面や設定から SVM の AD サーバー一覧を確認する。
DNS 名解決を確認する。SVM（または管理ネットワーク）から DC の FQDN が解決できること、逆引きが一致することを確認する。Windows／Linux からの nslookup と同等のチェックを行う。
ネットワーク疎通（ポート 445/TCP の到達性）を確認する。ファイアウォールやセキュリティグループが 445 をブロックしていないかを確認する。必要に応じてパケットキャプチャで SYN/ACK が返っているかを確認する。
Windows 側で SMB ネゴシエーションや暗号化ポリシーを確認する。ドメインコントローラーに SMB3 暗号化が強制されていないか、SMB の最小/最大バージョンポリシーが設定されていないかを調べる。
ONTAP のログ（secd ログ、cifs ログ）を確認し、ネゴシエート段階でどの機能のマッチングが失敗しているかを特定する。ログのタイムスタンプと Windows 側のイベントログを突き合わせる。
ONTAP と Windows 双方の更新状態を確認する。NetApp のサポート文書に Windows Server 2025 対応状況が示されている場合はそれを参照し、必要なパッチを適用する。
一時的回避策として、テスト環境で SMB3 暗号化を一時的に無効化して問題が解消するかを検証する。解消する場合は暗号化ネゴシエーションが原因である可能性が高い。実運用では暗号化を無効化することは推奨されないため、根本対応（ソフトウェア更新や設定調整）を優先する。

早見チェック表

チェック項目	実施方法	期待される結果
DNS 名解決	SVM 側から DC FQDN を解決	正しい IP が返る
ポート疎通（445/TCP）	SVM→DC で到達確認（tcp connect/packetcapture）	SYN/ACK で接続確立
SMB ネゴシエーション	ログで Negotiate フェーズ確認	SMB3 ネゴ成功または暗号化ポリシー整合
ONTAP バージョン	管理 UI または CLI でバージョン確認	Windows Server 2025 対応パッチが適用済み
DC の SMB 要件	Windows 側ポリシー確認	暗号化強制や最小 SMB バージョンが運用と整合

代表的な対処・解決策

まずは「互換性の確保」が根本的な解決になります。具体的な選択肢は次の通り。

NetApp 側のアップデート適用
NetApp は新しい Windows Server との互換性向上のためのアップデートやパッチを出すことがあるため、まず ONTAP のサポートページやリリースノートを確認し、推奨パッチがあれば適用する。これにより SMB3 暗号化周りや LSA 接続の互換性が改善されることが多い。
Windows 側の暗号化/SMB ポリシー確認と緩和（検証のみ）
運用ポリシーに反しない範囲で、テスト環境にて DC の SMB 暗号化ポリシーを一時的に緩和して SVM 作成が通るかを検証する。これで問題が切り分けられたら、正式には NetApp 側の対応や TLS/証明書ベースの保護など安全な代替策を検討する。
ネットワーク経路の修正
負荷分散装置、ファイアウォール、ACL、あるいはオーバーラッピングした VLAN などが原因で LSA/SMB トラフィックが破棄されている場合がある。パス上の機器でポート 445/TCP の透過性を確認し、必要に応じて設定を変更する。
一時的なワークアラウンド：別の DC を指定して登録を試行
SVM が参照する DC を別の（同じドメイン内の）DC に変更して問題が再現するか確認する。特定の DC の構成（SMB 設定や OS パッチレベル）が原因のケースでは有効。

事例と所見（現場で注意すべき点）

Windows Server の新バージョンはセキュリティ強化に伴い既定の SMB 設定が変更されることがあり、既存のストレージ製品側でのネゴシエーション互換性が問題になる。
ログのタイミングを合わせて双方（NetApp の secd ログと Windows のセキュリティイベントログ）を比較すると原因箇所の特定が早い。
本番で暗号化を恒久的に無効化することは推奨されない。常にセキュリティ影響を評価した上で、NetApp の公式サポート推奨の修正を待つか適用する。

まとめと推奨アクション

secd.lsa.noServers エラーは「LSA へ接続できない」「SMB ネゴシエーションでサポートされない要求があった」ことを示すため、ネットワーク／名前解決／SMB 暗号化ポリシー／ソフトウェア互換性の四点を体系的に確認することが重要です。まずは DNS・ポート疎通・ログ突合せで切り分けを行い、原因が SMB3 暗号化やプロトコル互換性であると判明したら NetApp のサポート情報に基づくパッチ適用や設定変更を行ってください。検証で一時的に暗号化を緩める場合は必ずテスト環境で実施し、本番では安全な代替手段（パッチ、設定の公式推奨）で解決することを推奨します。