「ドメインが利用できないため、この資格情報ではサインインできません」と出た時は、組織のドメインコントローラーへ接続できるか、利用するアカウントが正しいか、以前のサインイン情報を利用できるかを分けて確認します。以下はActive Directoryのドメイン参加端末を中心とした説明です。職場・学校で管理されているPCでは、接続やアカウントを確認してから管理者へ相談します。
—- エラー内容 —-
ドメインが利用できないため、この資格情報ではサインインできません。デバイスが組織のネットワークに接続されていることを確認し、やり直してください。このデバイスで、別の資格情報を使用して最近ログインした場合は、その資格情報を使ってログオンすることができます。

Windowsに入れない時に、先に確認する4項目
- 画面に表示されたエラー全文と、サインインしようとしているアカウント名・PC名を記録する。
- サインイン画面のネットワーク状態を確認し、組織が案内する社内LANや接続経路を使う。
- このアカウントで以前このPCにサインインしたか、初めて使うPCかを確認する。
- 自宅や社外の場合は、組織のVPNがサインイン前に使える構成かを管理者へ確認する。
MicrosoftのAlways On VPNの説明では、ユーザートンネルはサインイン後、デバイストンネルはサインイン前に接続する方式として区別されています。すべてのVPNが同じ動作ではないため、「VPNを入れればログイン前でもつながる」とは決めず、組織の構成を確認します。
| 状況 | 次に確認すること |
|---|---|
| 初めて使うPC・初めて使うアカウント | 組織の認証先への接続。既存のキャッシュがあるとは扱わない |
| 以前使ったPCで社外から失敗 | サインイン前の接続と、キャッシュが利用できる条件 |
| 同じアカウントで別PCは成功 | 対象PCの接続・DNS・直前の変更を管理者と比較 |
| 同じPCで複数の許可済みアカウントが失敗 | 端末と組織の接続、認証先の状態を管理者へ確認 |
【確認1】Active Directoryとの通信はできるのか?
ドメインコントローラーは、ドメインのユーザー認証に必要なサーバーです。インターネットのページが開けるだけでは、組織のドメインコントローラーに通信できることは確認できません。社内LANや、組織が用意した接続経路を確認してください。
Windowsの公式ポリシー資料の「InteractiveLogon_NumberOfPreviousLogonsToCache」は、過去のドメインサインイン情報を端末に保存する仕組みを説明しています。以前そのPCでサインインしていて、キャッシュが残り、組織の設定が許可する場合は、ドメインコントローラーに届かなくてもサインインできることがあります。初めて使うPCや、キャッシュが無効・置き換え済みの場合は同じ条件になりません。
管理者と確認する際は、次の違いを記録します。別の人のパスワードを借りて試すのではなく、許可されたアカウントと端末の状況を比較してください。
- 新規ユーザーが、そのPCで初めてログインしようとした際に、ログインができない。
- 以前にそのPCでサインインしたユーザーが、キャッシュを利用できる条件では入れることがある。
「以前使ったユーザーは入れるが、新しいユーザーは入れない」という差は、ネットワークとキャッシュを調べる材料になります。ただし、それだけで原因は確定しません。キャッシュの設定を緩めて回避する前に、組織への接続を復旧する方針を管理者と確認します。
【確認2】DNSは機能しているか?
ドメインコントローラーを見つけるためには、ドメイン用のDNSによる名前解決も必要です。MicrosoftのDC Locatorの説明では、クライアントがDNSのSRVレコードとAレコードを使って接続先を探す仕組みを説明しています。「ADには接続できるがDNSだけが関係する」と決めず、発見と通信を分けて診断します。
ブラウザーで外部サイトが開くことや、一つのIPアドレスに応答があることだけでは、ドメインに必要な名前解決・認証通信全体は確認できません。管理者が端末のDNS設定とドメイン側の登録・接続経路を照合してください。
DNSが機能していない原因特定には以下の記事をご参考にしてください。
Windowsで『DNSによる名前解決が出来ない!』場合に確認すべき項目一覧
【Windows Server】DNSのログ取得方法を3分で説明
【確認3】クライアント端末にドメイン名が解決できるDNSが指定されているか
このPCに設定されているDNSが、組織のドメインを解決できるものか確認します。社内LANとVPNで利用するDNSが異なる場合は、接続時の設定も確認対象です。画面の値を記録し、組織が指定する設定と照合してください。
「速い」「信頼できそう」という理由で公開DNSへ変更しないでください。ドメインの内部名を解決できるかが、この問題では重要です。優先・代替の値や自動取得の扱いは、組織のネットワーク設計と管理者の案内に合わせます。
Windowsにサインインできる許可済みのアカウントがある場合は、ipconfig /all でアダプターごとのIP・DNSなどを表示できます。ipconfigの公式仕様を参照し、使用中のLAN・Wi-Fi・VPNの違いを確認します。結果には内部ネットワーク情報があるため公開せず、必要な管理者へ共有してください。

【確認4】許可されたアカウントで入れる場合のDNSキャッシュ確認
管理者が用意したローカルアカウントなどでサインインでき、DNSキャッシュを調べる必要がある場合だけ、管理者権限のコマンドプロンプトから以下を実行します。サインインできない画面から実行できる操作ではありません。
ipconfig /flushdnsipconfig /flushdns はDNSクライアントの名前解決キャッシュを消去します。DNSサーバーの設定やドメインの信頼関係、ユーザーのパスワードを修復するコマンドではありません。接続先やDNS設定が誤っている状態では、キャッシュを消しても解決しないため、変更結果を管理者と確認します。
接続と名前解決の状態を確認した後、正しいドメインアカウントで再度サインインした結果を記録します。何度も失敗を繰り返す前に、アカウントのロックや状態も管理者へ確認してください。
【確認5】直前の変更とドメインの信頼関係を管理者が確認
PC名の変更、端末の復元・交換、組織側の端末管理変更などが発生していないか、直前の変更内容を記録します。変更があったことだけを、このエラーの原因とは断定しません。
ネットワークとDNSを確認しても問題が続く場合は、管理者が端末とドメインの信頼関係を確認します。ドメインメンバーのPCでは、管理者としてWindows PowerShellを開き、Test-ComputerSecureChannel -Verbose で状態を調べられます。公式コマンド仕様は、ドメインコントローラー自身には使えないことも明記しています。ここでは診断だけを行い、修復・アカウントの変更は管理者が判断します。
ドメインの再参加は管理者が必要性と条件を確認
ドメインからの離脱・再参加は、一般利用者が最初に試す操作ではありません。管理者が必要と判断した場合に、離脱後にサインインできるアカウント、再参加の権限と接続経路、保存データ・組織の設定への影響を確認してから進めます。以下は管理者が選択した場合の関連手順です。
管理者が離脱を選択した場合の参考:ワークグループへの参加
再参加の条件が確認できた場合の参考:ドメインへの参加
「Active Directoryの運用」PCのドメインへの参加手順を分かり易く紹介
サインイン先のドメインとユーザー名の形式を確認
ユーザー名だけを入力した時に、意図したドメインが選ばれているか確認します。Microsoftのユーザー名形式の仕様には、DOMAIN\UserName とUPN形式 UserName@Suffix が示されています。管理者が案内する正しいアカウント名を使ってください。
たとえば [email protected] はUPN形式の表記例です。実際に使うUPNの末尾は管理者が設定する場合があるため、メールアドレスや推測したドメイン名をそのまま入力すればよいとは限りません。
ログイン形式の指定は、別のドメインやローカルアカウントを誤って選ぶ問題の確認に役立ちますが、ドメインコントローラーへの接続やDNSを修復する操作ではありません。形式を変えても同じエラーなら、接続・キャッシュ・アカウント状態の確認結果を管理者へ伝えます。
まとめ
このエラーでは、サインイン画面から確認できる接続・アカウントと、サインイン後に管理者が行うDNS・信頼関係の診断を分けます。以前使ったPCか、社内と自宅で結果が違うか、直前の変更はあるかを整理してください。DNSの一律変更、キャッシュ設定の緩和、ドメインからの離脱へ先に進まず、確認結果に合った対処を管理者と選びます。

コメント
コメント一覧 (8件)
以前ログインしたことがあるのにログインできませんが、どうしてでしょう。インターネットにはつながっています。
ADとの疎通はどうでしょうか?Pingで疎通ができているのか確認してみてください
Active Directory を利用していたPCでWINDOWSログオン自体ができない場合、
左下にある”他のユーザー”をクリックし、ログオンユーザー名にフルドメインユーザー名(例:[email protected])を入力、いつも使っているパスワードを入力するとログオンできる場合があります
在宅勤務などで社内PCを自宅に持ち込み、自体ネットワーク環境(wifi)などで接続後、VPNを利用し
接続する場合などにこのようなケースがありましたので参考になれば。。。
貴重な情報ありがとうございます。
かなり本気で悩んでいるのですが、別ドメインのファイルサーバへアクセスする方法で悩んでいます。
ドメインAのユーザがドメインBのファイルサーバへアクセスしたいです。
ドメインAのユーザとADは同じセグメントで、ドメインBのユーザとADも同じセグメントです。
例)ドメインA 10.0.01、ドメインB 172.16.0.1
上記のような状態だと、ドメインAとBの双方向通信が必要ですか、それともドメインAからBに対しての通信だけで大丈夫ですか?よろしくお願いします。
けっこう悩んでいるので相談さえてください。
新しくファイルサーバを構築しております。ファイルサーバはドメインBに構築し、ドメインAのユーザがアクセスしにきます。
ドメインAのユーザが参加するADは同じネットワーク内にあり、ドメインBもユーザーが認証するADは同じネットワーク内にあります。
ドメインA(10.0.0.1)ドメインB(172.16.0.0)
上記のような場合は、ドメインAとドメインBの間で通信許可が必要なのでしょうか?
なお、ICMPは正常に動作しています。よろしくお願いします。
すいません、本件解決できました。
ありがとうございました。
直ぐに回答できなくて申し訳ないです。でも解決して良かったです。