Azure 上の仮想マシンをオンプレミスの Active Directory ドメイン コントローラーに昇格しようとした際、「ユーザー名またはパスワードが違います（1326）」で失敗していませんか。本記事では、よく見落とされる資格情報の書き方の落とし穴と、再発防止のためのチェックポイントを、Azure IaaS＋サイト間 VPN 構成を例に具体的に解説します。
Azure 上のサーバーを DC に昇格しようとするとエラー 1326 が出る
まずは、今回の典型的なシナリオを整理します。
- オンプレミスに DC01（testlab.local の最初のドメイン コントローラー）が存在
- Azure IaaS 上に DC02（すでに testlab.local ドメインに参加済み）が存在
- オンプレと Azure は サイト間 VPN でつながっている
- DC02 を 追加ドメイン コントローラーとして昇格しようとすると失敗
- ウィザードでは TESTLAB\Administrator を使用
このとき、次のようなエラーが発生します。
ウィザード上のエラー メッセージ
Error getting the list of sites from the target environment:
the user name or password is incorrect
dcdiag（DC02側）でのエラー
dcdiag /s:testlab.local
LDAP bind failed with error 1326,
The user name or password is incorrect.
疎通確認（Ping やポート スキャン）や VPN、Windows ファイアウォールには明らかな問題がないにもかかわらず、このように 「ユーザー名またはパスワードが違います (1326)」 で昇格が止まってしまうケースは、Azure 環境を含めたハイブリッド構成でよく発生します。
結論：資格情報を「NetBIOS 形式」から「UPN 形式」に変える
結論から言うと、この事象は 資格情報の書き方を変えるだけで解決するケースが非常に多いです。
具体的には、昇格ウィザードで入力しているアカウントを次のように変更します。
- （変更前）TESTLAB\Administrator（NetBIOS / SAM アカウント形式）
- （変更後）[email protected]（UPN 形式）
同じ「ドメイン管理者」であっても、表記方法を UPN 形式に変えるだけで昇格が成功するという報告は、オンプレ＋Azure のハイブリッド環境で特に多くあります。
推奨される資格情報の書き方
| 用途 | 形式 | 入力例 | 推奨度 |
|---|---|---|---|
| AD DS 昇格ウィザード | UPN 形式 | [email protected] | ◎ 強く推奨 |
| AD DS 昇格ウィザード | NetBIOS / SAM 形式 | TESTLAB\Administrator | △ 非推奨（誤解釈リスクあり） |
| RDP ログオンなど | どちらも使用可能 | TESTLAB\Administrator / [email protected] | ○ 使い分け可 |
特に ドメイン名とプライマリ DNS サフィックスが一致していないマシン や、複数ドメイン / 別名が絡む環境では、NetBIOS 形式が想定とは違うドメインとして扱われ、結果的に エラー 1326（LOGON_FAILURE） になることがあります。UPN 形式はこの誤解釈を避けるための、もっともシンプルで確実な方法です。
なぜ「TESTLAB\Administrator」でエラー 1326 になるのか
同じアカウントなのに表記を変えただけで成功・失敗が分かれるのはなぜでしょうか。ここでは少し踏み込んで、Active Directory ドメイン サービス（AD DS）昇格時の認証の流れを整理します。
AD DS 昇格時のざっくりした流れ
- 昇格ウィザード（Server Manager /
Install-ADDSDomainController）が起動 - 「既存ドメインに追加する」オプションを選択
- ドメイン名（例：
testlab.local）と資格情報を入力 - ウィザードが LDAP / Kerberos を使って 既存の DC（DC01）にバインド
- サイト情報やドメイン情報を取得し、必要な権限があるかチェック
- SYSVOL のレプリケーションや DNS の設定などの処理を順に実行
このうち、ステップ 4〜5 の 「どのドメインに、どのアカウントで」 バインドするかを決める際に、資格情報の表記方法が影響します。
NetBIOS 形式（TESTLAB\Administrator）の落とし穴
TESTLAB\Administrator のような形式は、いわゆる SAM アカウント / NetBIOS 形式 です。これは古くから Windows で使われている表記で、次のような特徴があります。
- ドメイン名として NetBIOS 名（例：TESTLAB）を使用
- 実際の FQDN（
testlab.local）とは別物 - クライアント側の プライマリ DNS サフィックス や、信頼関係の設定により、
「TESTLAB」という文字列が 意図しないドメイン名にマッピングされる ことがある
Azure IaaS 上の DC02 で、オンプレとは別の DNS サフィックスや別名ドメインを運用していると、次のような現象が起こることがあります。
- 昇格ウィザードが
TESTLAB\Administratorを別ドメインのアカウントとして解釈 - その結果、正しい
testlab.localに対して認証できず、エラー 1326 になる - ログ上には、想定外のサフィックス（例：
cloudcomputing.local）が登場することもある
このように、「パスワードが間違っている」のではなく、そもそも 「違うドメインの別人として認証されようとしている」 ために失敗している、というのが本質です。
UPN 形式（[email protected]）のメリット
一方、[email protected] のような UPN（User Principal Name）形式は、次のようなメリットがあります。
- 完全修飾ドメイン名（FQDN）を明示できる（
@testlab.local） - NetBIOS 名や別名に影響されず、どのドメインかが一意に決まる
- 複数ドメインや UPN サフィックスを併用している環境でも、誤解釈されにくい
- Kerberos のチケット発行時も、対象のドメイン コントローラーが明確になる
そのため、AD DS の昇格時のように「どのドメインに対して管理操作をするか」が重要な場面では、UPN 形式を使うのがベスト プラクティスと言えます。
実際の操作手順：Azure VM を DC へ昇格させる
ここからは、「資格情報を UPN 形式に変える」ことを含めて、Azure VM（DC02）を testlab.local の追加ドメイン コントローラーに昇格させる際の一般的な手順を整理します。
事前前提
- DC01：オンプレミスの既存ドメイン コントローラー（
testlab.local） - DC02：Azure IaaS 上の Windows Server（2016/2019/2022 など）
- DC02 はすでに testlab.local ドメインに参加済み であり、
通常のドメイン ログオンは成功している - サイト間 VPN は確立済みで、双方向で名前解決と通信ができている
手順 1：DC02 の DNS 設定を確認する
最初に必ず、DC02 のネットワーク設定を確認します。
- DC02 上で管理者として PowerShell / コマンド プロンプトを開く
- 次のコマンドを実行して DNS 設定を確認します。
ipconfig /all
ここで確認すべきポイントは次の通りです。
- 優先 DNS サーバーが DC01 の IP アドレスになっているか
- Azure 既定の DNS（例：
168.63.129.16）を設定していないか - DC02 自身の IP を DNS に設定している場合は、昇格前は一旦 DC01 を優先にすることを検討
AD DS 昇格時には、既存の DC（DC01）に対して正しく名前解決と LDAP 通信ができることが最重要です。そのため、Azure VM の DNS を外部や Azure 既定に向けたままにしないよう注意します。
手順 2：時刻同期を確認する
Kerberos 認証は、デフォルトで ±5 分以上の時刻ズレがあると失敗します。昇格前に、DC01 と DC02 の時刻がズレていないか確認しましょう。
w32tm /query /status
必要に応じて、次のコマンドで再同期します。
w32tm /resync
Azure VM はホスト側の時刻に引きずられることもあるため、「オンプレ DC と Azure DC の時刻がほんの数分ずれていた」というのはよくある落とし穴です。
手順 3：既存ドメインへの接続性をテストする
次のコマンドで、DC01 を検出できるか確認します。
nltest /dsgetdc:testlab.local /force
また、セキュア チャネルの状態も確認します。
nltest /sc_verify:testlab.local
どちらも成功することが望ましいですが、ここで失敗した場合は認証以前にネットワークや DNS の問題がある可能性が高いので、先にそちらの切り分けが必要です。
手順 4：AD DS 役割のインストール
まだ DC02 に AD DS 役割を入れていない場合は、先にインストールします。
- Server Manager > 「役割と機能の追加」
- 「サーバーの役割」で Active Directory ドメイン サービス を選択
- ウィザードを完了し、必要であれば再起動
PowerShell で行う場合は次のコマンドでも構いません。
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
手順 5：昇格ウィザードで UPN 形式の資格情報を入力
ここが今回の 最重要ポイントです。
- Server Manager のフラグから「このサーバーをドメイン コントローラーに昇格する」を選択
- 「既存ドメインにドメイン コントローラーを追加する」を選択し、
testlab.localを指定 - 「別の資格情報を指定」や「変更」ボタンをクリック
- ユーザー名：
[email protected] - パスワード：Administrator アカウントのパスワード
- 「OK」をクリックしてウィザードを進める
このとき、絶対に TESTLAB\Administrator と入力しないように注意してください。見た目上は同じアカウントのように見えますが、内部では解釈されるドメインが変わる可能性があります。
手順 6：昇格完了後の確認
昇格が完了し、DC02 が再起動したら次の確認を行います。
- Active Directory ユーザーとコンピューター で DC02 が「ドメイン コントローラー」として表示されているか
- サイトとサービス で DC02 が適切なサイトに所属しているか
- 次のコマンドで診断：
dcdiag /v /c /e /f:dcdiag.txt
repadmin /replsummary
dcdiag.txt に重大なエラーがないかを確認し、特に DNS やレプリケーション関連の項目に注意します。
UPN 形式でも失敗する場合のチェックリスト
UPN 形式に切り替えても昇格に失敗する場合は、他の要因が絡んでいる可能性があります。ここでは、優先度の高いチェック項目を一覧表にまとめ、その後で個別に解説します。
| 優先度 | チェック項目 | 概要 | 代表的なコマンド / 設定 |
|---|---|---|---|
| 高 | 権限レベル | Domain Admins / Enterprise Admins の所属確認 | ADUC でグループ メンバー確認 |
| 高 | DNS 設定 | DC02 の DNS が DC01 を向いているか | ipconfig /all |
| 高 | 時刻同期 | DC01 と DC02 の時刻ズレ（±5 分以内） | w32tm /resync |
| 中 | ポート / VPN | AD 必要ポートが双方向に開いているか | FW / NSG / ルーター設定 |
| 中 | ドメイン探索 | DC 検出とセキュア チャネルの状態 | nltest /dsgetdc, nltest /sc_verify |
| 低〜中 | 認証キャッシュ | 古い Kerberos チケットの影響排除 | klist purge |
| 中 | DNS サフィックス整合性 | DC02 のプライマリ DNS サフィックスとドメイン名の一致 | システムのプロパティ（コンピューター名） |
権限の確認：Domain Admins で十分か
既存ドメイン（testlab.local）に 追加ドメイン コントローラーを立てるだけなら、通常は Domain Admins グループ所属 のアカウントで十分です。
- 追加 DC：Domain Admins があれば OK
- 新しいドメイン / フォレストの作成：Enterprise Admins が必要
ただし、過去のグループ ポリシーやセキュリティ強化の結果、標準とは異なる権限モデルになっている環境もあります。昇格に使用しているアカウントが、想定通りのグループに所属しているか確認してください。
DNS 設定：DC02 の優先 DNS は DC01 を向いているか
DC 昇格トラブルの 8割は DNS 周り と言っても過言ではありません。特に Azure IaaS では、次の点を重点的に確認します。
- DC02 の NIC 設定で、優先 DNS サーバーが DC01 の IP になっているか
- DNS が Azure 既定（
168.63.129.16など）やインターネット向け DNS になっていないか - 昇格前の段階では、DC02 自身の IP は DNS から外しておく ほうが無難
Azure 内からオンプレ ドメインに参加している場合、DC02 が名前解決を Azure DNS やパブリック DNS に投げてしまうと、内部のドメイン コントローラーが見つからず、昇格に必要な情報が取得できません。
時刻同期：Kerberos の大前提
Kerberos 認証では、クライアントと KDC（ドメイン コントローラー）との時刻のズレが一定以上あると、セキュリティ上の理由からチケットの発行が拒否されます。
- 一般的な許容範囲は ±5 分
- オンプレ DC と Azure DC でタイムゾーンや NTP サーバーが異なると、ズレやすい
トラブル時は、次のようにして両方のサーバーの時刻と同期先を確認し、必要に応じて再同期を行います。
w32tm /query /status
w32tm /resync
ポート / VPN：AD 必須ポートが双方向に空いているか
サイト間 VPN やファイアウォール、Azure Network Security Group（NSG）の設定により、必要なポートが片方向しか開いていなかったり、動的ポート範囲が閉じているケースもあります。代表的なポートは次の通りです。
| プロトコル | ポート | 用途 |
|---|---|---|
| TCP/UDP | 88 | Kerberos 認証 |
| TCP | 135 | RPC エンドポイント マッパー |
| TCP/UDP | 389 | LDAP |
| TCP | 445 | SMB / SYSVOL レプリケーション |
| TCP | 636 | LDAPS |
| TCP | 3268 / 3269 | グローバル カタログ |
| TCP | 49152–65535 | 動的 RPC（Windows Server 2008 以降） |
特に、動的 RPC ポート（49152〜）が遮断されていると、昇格の途中でさまざまな謎エラーが発生します。VPN 装置やオンプレ側のファイアウォール、Azure NSG のルールを見直しましょう。
ドメイン探索 / セキュア チャネル
DC02 から testlab.local の DC を検出できるか、セキュア チャネルが正常かどうかは、次のコマンドで確認できます。
nltest /dsgetdc:testlab.local /force
nltest /sc_verify:testlab.local
ここで失敗する場合は、ドメイン参加自体に問題がある、もしくは VPN / DNS / ファイアウォールの影響が考えられます。
認証キャッシュ（Kerberos チケット）のクリア
以前の誤った資格情報やドメイン情報が Kerberos チケットとしてキャッシュされていると、正しい UPN を入力しても古いチケットを使おうとして失敗するケースがあります。その場合は、一度チケットをクリアしてから再試行します。
klist purge
実行後、再度昇格ウィザードを起動し、UPN 形式の資格情報を入力してください。
DNS サフィックスとドメイン名の整合性
dcdiag やイベント ログに、意図しない DNS サフィックス（例：cloudcomputing.local など）が登場する場合は、DC02 の プライマリ DNS サフィックス が問題の原因になっている可能性があります。
確認方法：
- DC02 で「システムのプロパティ」を開く（
sysdm.cpl） - 「コンピューター名」タブの「変更」から「詳細」をクリック
- 「プライマリ DNS サフィックス」が
testlab.localになっているか確認
もし別のサフィックスになっている場合は、ドメイン名と一致するように修正することで、不審なサフィックスがログに出なくなり、昇格が安定することがあります。
Azure 環境特有の注意点
同じ AD DS の問題であっても、Azure IaaS 環境ではオンプレとは違った落とし穴が存在します。ここでは、ドメイン コントローラーを Azure に配置する際に特に意識したいポイントをまとめます。
Azure DNS とオンプレ DNS の役割分担
- Azure 既定の DNS は、AD ドメインの名前解決を理解していません
- ドメイン参加済みの Azure VM（特に DC 候補）は、オンプレ DC（DC01）の IP を DNS に設定する必要があります
- 必要に応じて、オンプレ側 DNS からインターネット向けのフォワーダーを設定し、
Azure VM からの外部名前解決も間接的に行えるようにする
静的 IP と NIC 設定
Azure では、VM 側 OS に直接 IP を固定せず、Azure ポータル側でプライベート IP を予約し、OS からは DHCP で取得する構成が推奨されます。
- OS 側で IP を手動固定すると、Azure の管理情報とずれが生じる場合がある
- ドメイン コントローラーは特に IP 変更の影響が大きいので、事前に固定化しておく
可用性とバックアップ
Azure 上の DC とオンプレ DC では、障害パターンや復旧手順も変わります。
- スナップショット / VM のクローン復元は、ドメイン コントローラーには基本的に非推奨
- 障害時は、可能な限り 再昇格（再構築） を検討
- DNS ゾーンや SYSVOL など、重要データはレプリケーションで保護される前提にする
今回のエラー 1326 をきっかけに、Azure 側 DC の運用ポリシーもあわせて見直しておくと、長期的な安定運用につながります。
トラブル再発を防ぐための運用 Tips
最後に、今後同様のトラブルを避けるために実践しやすい運用上の工夫をいくつか紹介します。
管理者向けの「入力例テンプレート」を作っておく
- 昇格作業手順書に、具体的な入力例 を明記する
- 例：
・ドメイン名：testlab.local
・資格情報：[email protected] - 「
TESTLAB\Administratorは使用しない」など、やってはいけない例も併記する
チェックリスト形式の手順書を用意する
手順書を「文章形式」ではなく、次のようなチェックリストにしておくと、作業時の見落としを防ぎやすくなります。
| 項目 | 確認内容 | OK / NG |
|---|---|---|
| DNS 設定 | DC02 の優先 DNS が DC01 の IP になっている | [ ] |
| 時刻同期 | DC01 と DC02 の時刻差が ±5 分以内 | [ ] |
| 資格情報 | UPN 形式（[email protected]）を使用 | [ ] |
| VPN / ポート | AD 必要ポートが双方向に許可されている | [ ] |
| ログ確認 | dcdiag / repadmin で重大エラーがない | [ ] |
トラブル発生時の「最低限取るべきログ」を決めておく
問題が起きてから何を取れば良いか悩むのではなく、あらかじめ「これだけは取る」と決めておくと、後からの分析も格段に楽になります。
dcdiag /v /c /e /f:dcdiag.txtrepadmin /showrepl > showrepl.txt- イベント ビューアー（Directory Service / DNS Server / System / Application）のエクスポート
ipconfig /all > ipconfig.txtnltest /dsgetdc:testlab.local /force > nltest_dsgetdc.txt
これらをフォルダにまとめて保管しておけば、後から原因分析を行う際にも情報が不足しづらくなります。
まとめ：まずは UPN 形式で再試行し、基本要件を押さえる
この記事では、Azure 上のサーバーを既存ドメインのドメイン コントローラーに昇格しようとした際に発生する 認証エラー 1326 の代表的な原因と対処法を解説しました。
- 主因は、資格情報の表記形式（NetBIOS 形式の誤解釈）であることが多い
- 昇格ウィザードでは、
TESTLAB\Administratorではなく[email protected]のような UPN 形式を使用する - UPN 形式なら、FQDN ベースでドメインを明示できるため、誤ったドメインとして扱われるリスクを避けられる
- それでも失敗する場合は、DNS 設定・時刻同期・必要ポート・ドメイン探索・DNS サフィックス整合性 を重点的に確認する
- Azure IaaS では、DNS の向き先と動的 RPC ポートの開放 が特に重要
まずは、昇格時に使用している資格情報を UPN 形式（例：[email protected]）に切り替えて再試行し、そのうえで本記事のチェックリストを順に確認していけば、多くのケースで原因を特定し、再発しない形で解決できるはずです。
コメント