ADサーバのホスト名変更で「コンピューターアカウントがありません」エラーに遭遇した話

Active Directory設計・運用

使っているADサーバのホスト名に誤りが見つかり、直すことになりました。
「ただの名前変更でしょ」くらいの気持ちでホスト名変更したら、思った以上に沼りました。

せっかくいろいろ検証したので、記録として残しておきます。

設定アプリからの変更

一番手軽な方法として、設定アプリから変更しました。

設定 → システム → 詳細情報 → このPCの名前を変更

現在のPC名（DC01）を確認し、新しい名前（DC02）を入力して「次へ」をクリック。

「再起動後に、PC名は次のように変更されます」という案内が出て、再起動しました。

ここまでは何の問題もなく、普通のPCの名前変更と同じ挙動でした。

再起動後、いつものAdministratorアカウントでログインしようとしたら、以下のエラーが出ました。

サーバーのセキュリティデータベースにこのワークステーションの信頼関係に対する
コンピューターアカウントがありません。

はぃ…？？
他のユーザーとしてログインを試したり、ローカルアカウントを試したりしましたが、どれも「ユーザー名かパスワードが正しくありません」という結果に終わりました。

完全にログインできない状態です。（やっちまった…）

一旦スナップショットで変更前の状態に戻しました。（便利だなぁ…）

システムのプロパティからの変更

次は方法を変えて、サーバーマネージャー経由で試しました。

サーバーマネージャー → ローカルサーバー → コンピューター名

これは実質、sysdm.cplの「システムのプロパティ」と同じ画面に行き着きます。
「変更」ボタンを押すと、さっきは出なかった警告ダイアログが表示されました。

DC専用の警告のようです。
設定アプリの画面には、こういった警告は一切出ていませんでした。

新しい名前（DC02）を入力してOKを押し、再起動が必要というメッセージに従って再起動しました。

今度はAdministratorアカウントで無事にログインでき、hostnameコマンドでもDC02に変わっていることが確認できました。

なぜ結果が違ったのか

同じ「ホスト名を変える」という操作なのに、なぜ結果が違ったのか。
調べてみると、そもそもの前提が誤っていたことがわかりました。

ドメインコントローラーの名前変更は、どちらの方法でもGUIから行うこと自体が推奨されていません。
 複数の技術情報を確認したところ、GUI経由でのDC名変更については以下のような報告がありました。

  • 「GUIから名前変更を実行するとエラーが表示され、名前変更に失敗するケースが散見される。最悪、ドメインコントローラーがADから外れてしまうこともある」
  • 「（GUIでの変更が）常にうまくいくとは限らず、OSの完全な再インストールが必要になるほど問題が広がったのを見た」

つまり、設定アプリでの失敗は「DC特有の後処理が行われなかったことによる、起こり得る失敗の一例」で、システムのプロパティ経由での成功も「たまたま今回の単一DC構成の環境では表面上うまくいった」というだけで、内部的に何かが正しく処理されていない可能性が残る、というのが実情のようです。

本当に完全に切り替わったか、確認してみる

「動いたから終わり」にせず、念のため確認してみました。

コンピューター名の登録状況

powershell
netdom computername %computername% /enumerate

古い名前（DC01）が代替名として残っている様子はなく、ここはクリーンでした。

SPN（サービスプリンシパル名）の登録状況

powershell
setspn -L DC02

HOST/DC02・GC/DC02.nlab.local/nlab.local・ldap/DC02...など、DC02名義のSPNが並んでおり、古いDC01名義のSPNは見当たりませんでした。
ここも反映されてます。

DNSレコードの登録状況

DNSマネージャーでnlab.localゾーンを確認したところ、ここで古い情報（残留物）が見つかりました。

dc01とdc02、両方のAレコードが同じIPアドレスを指したまま残っていました。
名前は変わったのに、古い名前でも新しい名前でも同じサーバーに到達できる状態です。
コンピューター名・SPNはきれいに切り替わっていたのに、DNSだけ古いレコードが自動的には削除されないという結果になりました。

この状態を放置するとどうなるか

古いAレコードが残っていること自体が即座にセキュリティ上の重大な問題になるわけではありませんが、いくつか気をつけたい点があります。

社内の他のシステム（監視ツール・バックアップジョブ・スクリプトなど）がdc01という名前を直接参照して動いている場合、その参照は「たまたま今は動いている」だけの状態になります。将来的にこのIPアドレスが別の用途に再利用されたときに、古い設定が残ったままの何かが誤って接続してしまう、という事故の芽にもなり得ます。

対処としては、DNSマネージャーから古い名前（dc01）のAレコード・AAAAレコードを手動で削除するのが基本です。今回は検証目的でそのままにしていますが、実際の運用環境であれば、新しい名前での動作確認が済んだ段階で速やかに削除することをおすすめします。

本来やるべきだった、正しい手順

今回の2つの方法はいずれも「動くこともあるが推奨されない」やり方でした。Microsoft公式のドキュメントで案内されている、DCの名前変更の正しい手順はnetdom computernameコマンドを使う方法です。

cmd
# ステップ1：新しい名前を代替名として追加する
netdom computername DC01.nlab.local /add:DC02.nlab.local

# ステップ2：新しい名前をプライマリ名にする（この後、再起動が必要）
netdom computername DC01.nlab.local /makeprimary:DC02.nlab.local

# （ここで再起動）

# ステップ3：古い名前を削除する
netdom computername DC02.nlab.local /remove:DC01.nlab.local

# ステップ4：正しく切り替わったか確認する
netdom computername DC02.nlab.local /enumerate

(ここで再起動)

この手順では、一時的に新旧2つの名前が両方有効な状態を経由してから、最後に古い名前を明示的に削除します。
GUIでの一発リネームとは違い、DCが持つべきSPN・DNSレコード・レプリケーション関連の情報を、段階を踏んで正しく引き継がせることを想定した手順になっているようです。
（※この手順を実施してもDNSレコードは残留していた）

参考：Netdom computername | Microsoft Learn

なお、今回私が目にした警告ダイアログの中でも「Renaming a Domain Controller」という関連ドキュメントへの案内リンクが表示されていました。
DCの名前変更を検討する際は、GUIの案内文だけで進めず、こうした公式情報を先に確認してから作業することをおすすめします。

まとめ

同じ「ホスト名を変える」という操作でも、対象がドメインコントローラーだった場合は手順が変わってきます。
今回わかったことを整理すると、以下の3点です。

  • ドメインコントローラーの名前変更は、GUI（設定アプリ・システムのプロパティのどちらも）ではなくnetdom computernameコマンドで行うのが公式に案内された正しい手順
  • GUIでの変更が「たまたま動いた」ように見えても、コンピューター名・SPN・DNSといった複数の要素すべてが正しく切り替わっているとは限らない
  • 特にDNSの古いレコードは自動的には削除されないため、変更後は必ず確認し、不要になった古いレコードは手動で削除する

もし同じようにDCのホスト名変更を検討する機会があれば、まずはnetdom computernameコマンドの使い方を確認してから着手することをおすすめします。

AD環境全体のDNS設計については「ADのDNS設計と運用ガイド」でも詳しく解説しています。
コンピューターとドメインの間の信頼関係（セキュアチャネル）が壊れるケースについては、「『このワークステーションとプライマリドメインとの信頼関係に失敗しました』の原因と直し方」も参照してください（こちらは一般的なメンバー端末の話で、今回のDC自体のリネームとは原因が異なります）。

あわせてご覧ください

参考文献

コメント

タイトルとURLをコピーしました