ActiveDirectoryサーバとクライアントPC間で正常にやりとりできない時の対処方法

今回はActive DirectoryサーバとクライアントPC間で正常にやりとりできない時の対処方法をご紹介したいと思います。
弊社のお客様から「使っているクライアントPCがファイルサーバに接続ができない」と問い合わせがありました。
このお客様はActive Directoryを導入しており、Active Directoryサーバ（ADサーバ）とファイルサーバが設置されこの2台は連携していました。

構成

お客様の構成は下記になります。

下記に各OSを記載いたします。
ADサーバ：Windows Server 2019 Standard
ファイルサーバ：Windows Server 2019 Standard
クライアントPC：Windows 10 Pro

症状

お客様からお問い合わせがあった際、どのような症状なのか詳細を確認しました。

• クライアントPCのログインはできる
• メールやサイト閲覧などは問題なくできる
• ファイルサーバへの接続ができない
  　ファイルサーバ接続時に「ログインユーザ名」と「パスワード」の入力が求められる
  　何度入力してもはじかれる
• 他のPCからファイルサーバへは正常に接続ができる

上記のことから

• ファイルサーバとADサーバは連携しており、他のPCでは問題はないのでクライアントPCの問題
• ファイルサーバ接続時に「ログインユーザ名」と「パスワード」の入力が求められるので、ADサーバとクライアントPCでアカウント情報（パスワード情報）に相違がある

と考え、ADサーバとクライアントPCの通信が上手くできていないのではと思いました。
そこで次の手順で一つ一つ確認を行いました。

原因の確認

まず基本的な確認をおこないました。

クライアントPCのDNSサーバおよびドメイン参加の確認

クライアントPCからドメイン参加するには、クライアントPCのDNSサーバをADサーバのIPアドレスに指定する必要があります。
また、所属するグループも参加するドメインを登録します。
確認しましたが上記の設定は問題ありませんでした。

クライアントPCの資格情報の確認

過去にクライアントPCの資格情報にファイルサーバ接続情報が登録されていたことがあったので確認しました。
確認しましたが接続情報の登録はありませんでした。

クライアントPC　システムログの確認

クライアントPCのシステムログを確認したところ、
「サーバーのセキュリティデータベースにこのワークステーションの信頼関係に対するコンピュータアカウントがありません。」
の記述がありました。この内容が表示される要因として

• ADサーバでアカウントが無効になっている
• 長い期間クライアントPCを起動していない
• ADサーバとクライアントPC間の通信が正常にできていない

ことが考えられます。
今回のケースでは、ADサーバ上でアカウントは有効になっておりクライアントPCも毎日起動し利用していました。
突発的な要因でADサーバとクライアントPCで通信ができなくなってしまったと思われます。

対応

セキュアチャネルの復旧

ADサーバとクライアントPCで正常に通信ができなくなってしまったと思われるので、まずは正常に通信ができるようにセキュアチャネルの復旧を試みました。

• セキュアチャネルとは
  セキュアチャネルはクライアントPCがADサーバと通信を開始するときに、パスワード認証して確立する通信チャネルです。パスワードは定期的に変更されますが正しく変更されない場合、今回のような現象が発生します。

「Windows PowerShell」から下記コマンドを実行しました。

今回は上記コマンドで復旧できなかったので、次の対応としてドメイン参加のやりなおしを行いました。

ドメイン参加のやりなおし

ドメイン参加のやりなおしを行う場合、ドメインから一度抜けるためローカルユーザアカウント（管理者権限）が必要になるので事前に作成する必要があります。

ドメイン参加から抜ける前にローカルユーザアカウント（管理者権限）を作成

ローカルユーザアカウントを作成する際、ADサーバの管理者ユーザおよびパスワードが求められました。

ローカルユーザアカウントでWindowsにログイン

一度ログアウトしローカルユーザでログインします。ユーザ名だけではドメイン参加した状態でのログインとなります。
ローカルユーザでログインするには
コンピューター名\ユーザー名
という形でユーザ名を指定しますが、コンピュータ名を入力するのが大変な場合は
.\ユーザー名
という形でもローカルユーザとしてログインできます。

ドメインからワークグループへ変更

「スタート」→「設定」→「システム」→「左側の項目　下部の「詳細情報」→右側の「システムの詳細設定」
「システムのプロパティ」→タブ「コンピュータ名」
「コンピュータ名を変更したりドメインに参加したりするには・・・」の変更をクリック

所属するグループをドメインからワークグループへ変更します。
ワークグループ名は特に指定はありません。
例：WORKGROUP

その後PCの再起動になります。

ワークグループからドメインへ参加

所属するグループをワークグループからドメインへ変更します。
ドメインは参加するドメイン名を入力します。
その後PCの再起動になります。

ドメイン参加の状態でWindowsにログイン

ドメインユーザのアカウントとパスワードでログインします。今回はログインができなかったので、ADサーバのユーザ管理画面からログインするドメインユーザのパスワードを変更することでログインができるようになりました。

ファイルサーバへの接続

ドメインに参加した状態でログインでき、ファイルサーバへの接続もできるようになりました。

まとめ

今回のケースではADサーバとファイルサーバが連携していたため、クライアントPCがファイルサーバへ接続できないという症状からADサーバとクライアントPC間による通信不具合の発覚につながりました。その他にクライアントPCがWindowsにログインできないケースもありました。
Active Directoryを導入の有無にかかわらず、ローカルアカウントユーザ（管理者権限）を作成することは大切です。ローカルアカウントユーザがあることで不測の事態がおこってもWindowsにログインすることができれば対応の幅が広がります。
PCの管理やActive Directory導入も弊社で対応できますのでお気軽にご相談ください。

この記事を読んだ方はこちらも読まれています

WideNet クラウドバックアップの復元機能をサポート事例と共にご紹介！ Winodws10でVPN（L2TP/IPsec）の自動接続設定