none
リモートデスクトップで「認証エラーが発生しました」 RRS feed

  • 質問

  • 初めて質問させていただきます。

    症状

    クライアントPCからサーバーへリモートデスクトップで接続すると、ログイン情報入力後に「認証エラーが発生しました(コード:0x80004005)」と表示され、接続できない。

    頻度

    不定期に発生する。

    一番多いパターンはクライアントPCの起動後初めて対象サーバーにリモートデスクトップすると上記エラーが発生し、エラーポップアップをOKで閉じて再度同じサーバーにリモートデスクトップを実行するとログインできる。

    ただし、1度目ですんなりつながることもあれば、何度実行してもエラーになることもあり、傾向をつかみきれない。

    環境

    ・ネットワーク

    ActiveDirectoryでドメインを構築

    サーバーとクライアントは同一LAN上に存在

    サーバーへのログインはドメインのAdministratorと普段サーバーにログインしているドメインユーザーで試行

    ・クライアントPC

    Windows7ProSP1(RDVer:6.3.9600)

    Windows10Pro(RDVer:10.0010586)

    ・サーバー

    WindowsServer2012(RDVer:6.2.9200)

    WindowsServer2012R2(RDVer:6.3.9600)

    リモートデスクトップの設定

     ○このコンピュータへのリモート接続を許可する

     ○ネットワークレベル認証でリモートデスクトップを実行しているコンピュータからのみ接続を許可する

    WindowsServer2008R2以前ではこのような現象が発生したことはありませんでした。

    対応策がありましたらご教授ください。

    よろしくお願いいたします。


    • 編集済み NakaMeta 2016年8月24日 2:34
    2016年8月24日 1:47

回答

  • ネットワークレベル認証が有効になっているリモートデスクトップは、IPアドレスを指定するとそのサーバーに対してNTLM認証が、ホスト名を指定するとドメインコントローラと通信するKerberos認証が実施されます。

    なのでサーバとDCの通信は安定しているけれど、クライアントとDC間の通信で問題があるというケースでは「IPアドレスなら問題ないけどホスト名だと時々問題がある」といったことになるのかもしれません。

    あとは2016/08/09のWidowsUpdate関連でKerberosとNTLM周りの仕様が変更になりました。
    もしこのアップデートと発生時期が重なっているのであれば要確認ですね。

    「MS16-101: Windows 認証のセキュリティ更新プログラム (2016 年 8 月)」を適用するとユーザーのパスワード変更に失敗する場合がある
    https://blogs.technet.microsoft.com/jpntsblog/2016/08/17/ms16-101/


    • 編集済み やき(Yaki) 2016年8月29日 5:39
    • 回答としてマーク NakaMeta 2016年9月5日 0:14
    2016年8月29日 5:18

すべての返信

  • こんにちは。

    そのMSTSCの接続設定をファイルに出力すると、それをメモ帳で開く事ができます。

    IPアドレス(またはホスト名)とユーザー名を伏せたうえで内容をここに掲示することはできますか?

    2016年8月24日 3:52
  • ご返信ありがとうございます。

    以下の内容が表示されますが、合っていますでしょうか?

    ---------------------------------------------------------------------

    screen mode id:i:1
    use multimon:i:0
    desktopwidth:i:1024
    desktopheight:i:768
    session bpp:i:32
    winposstr:s:0,1,92,103,1132,910
    compression:i:1
    keyboardhook:i:2
    audiocapturemode:i:0
    videoplaybackmode:i:1
    connection type:i:7
    networkautodetect:i:1
    bandwidthautodetect:i:1
    displayconnectionbar:i:1
    enableworkspacereconnect:i:0
    disable wallpaper:i:0
    allow font smoothing:i:0
    allow desktop com:0
    disable full window drag:i:1
    disable menu anims:i:1
    disable themes:i:0
    disable cursor setting:i:0
    bitmapcachepersistenable:i:1
    full address:s:sv-cnv10
    audiomode:i:0
    redirectprinters:i:1
    redirectcomports:i:0
    redirectsmartcards:i:1
    redirectclipboard:i:1
    redirectposdevices:i:0
    autoreconnection enabled:i:1
    authentication level:i:2
    prompt for credentials:i:0
    negotiate security layer:i:1
    remoteapplicationmode:i:0
    alternate shell:s:
    shell working directory:s:
    gatewayhostname:s:
    gatewayusagemethod:i:4
    gatewaycredentialssource:i:4
    gatewayprofileusagemethod:i:0
    promptcredentialonce:i:0
    gatewaybrokeringtype:i:0
    use redirection server name:i:0
    rdgiskdcproxy:i:0
    kdcproxyname:s:

    ---------------------------------------------------------------------

    よろしくお願いいたします。

    2016年8月24日 5:04
  • 以前似たような現象に陥ったことがあります。
    また接続すると、特定のOSの組み合わせの時だけリモートデスクトップが非常に重かったりしました。

    接続先がHyper=Vのゲストだったのですが、ゲストOS、ホストOS、接続元の3か所でSNP機能を無効化したところ問題なく動作しました。

    ■ SNP機能を無効化してみる

    予期せぬ挙動が!? 新機能 Scalable Networking Pack をご存知ですか?
    https://blogs.technet.microsoft.com/jpntsblog/2010/03/22/scalable-networking-pack/

    以上、参考まで。

    追記:
    ドメインコントローラとの通信がうまくいかず一時的にローカルキャッシュを使用しての接続を試みている可能性もあります。たとえば一方のIPv6を無効化しているとか、DNSに古いDCの情報が残っていたりしないでしょうか。
    • 編集済み やき(Yaki) 2016年8月26日 1:33
    • 回答の候補に設定 佐伯玲 2016年8月26日 2:12
    2016年8月25日 8:33
  • こんにちは

    設定に不都合なところは無さそうです。

    接続先の指定ですが、IPアドレスとFQDNで結果は同じですか?

    それぞれ数回試してみてください。

    2016年8月26日 3:36
  • 回答ありがとうございます。

    SNPは私も気になっていて、サーバー側のSNPを無効化してみましたが効果ありませんでした。

    ただ、その時試したクライアントはSNPが有効だったように思います。

    現在サーバーのSNPは有効に戻していて、本番稼働しているサーバーのためなかなか再起動できないのですが、再度試してみたいと思います。

    DNSに関しては1台だけ古いDCが残っていました。

    削除して様子を見てみます。

    2016年8月26日 6:15
  • 回答ありがとうございます。

    私自身は確認できていないのですが、別の担当者はIPアドレスなら問題でなかったといっていたように思います。

    Pingなどでは問題なくサーバー名で名前解決できていますが、DNS周りでおかしなところがあるのでしょうか?

    2016年8月26日 6:17
  • このスレッドと似た事象だと思いますが、解決されていないようですね。

    https://social.technet.microsoft.com/Forums/ja-JP/281d9845-ea38-4fa3-92db-b9b14c458553/getting-a-authentication-error-0x80004005-using-rdp-on-windows-server-2012-servers?forum=winserverTS

    どのPCでもIPで接続OKでFQDNがダメなら、サーバ側の確認が先になるでしょうか。
    NICのNETBIOS over TCP/IP とか TCP/IP NetBIOS Helper サービスの再起動などやってみてもいいかもしれませんが、あてずっぽうで申し訳ないです。


    2016年8月26日 9:03
  • ネットワークレベル認証が有効になっているリモートデスクトップは、IPアドレスを指定するとそのサーバーに対してNTLM認証が、ホスト名を指定するとドメインコントローラと通信するKerberos認証が実施されます。

    なのでサーバとDCの通信は安定しているけれど、クライアントとDC間の通信で問題があるというケースでは「IPアドレスなら問題ないけどホスト名だと時々問題がある」といったことになるのかもしれません。

    あとは2016/08/09のWidowsUpdate関連でKerberosとNTLM周りの仕様が変更になりました。
    もしこのアップデートと発生時期が重なっているのであれば要確認ですね。

    「MS16-101: Windows 認証のセキュリティ更新プログラム (2016 年 8 月)」を適用するとユーザーのパスワード変更に失敗する場合がある
    https://blogs.technet.microsoft.com/jpntsblog/2016/08/17/ms16-101/


    • 編集済み やき(Yaki) 2016年8月29日 5:39
    • 回答としてマーク NakaMeta 2016年9月5日 0:14
    2016年8月29日 5:18
  • >社員番号042様

    >やき様

    情報ありがとうございます。

    IPアドレス指定→サーバーへのNTML認証

    ホスト名→DCへのKerberos認証

    これは知りませんでした。

    勉強になりました。

    私が担当者からこの問題を聞いたのはお盆前でしたが、現象としてはもっと前から出ていたようです。

    Kerberos認証の失敗であれば、どこかのイベントログを見れば載っているのでしょうか・・・?

    2016年8月30日 4:32
  • 追記です。

    金曜日にDNSに残っていた古いDCを削除しましたが、本日相変わらず1回目の接続で認証エラーが発生しました。

    なかなか解決の糸口が見えません。。

    2016年8月30日 6:06
  • 改善の兆しがあったので報告します。

    やき様の情報をヒントにKerberos認証で利用するモジュールのバージョンを調査し、古いモジュールだったのでバージョンアップしました。

    また、同一サイト内に2003R2と2008R2のDCが混在しているので、DNSゾーン及びレジストリで2008R2DCの優先度を高くしました。

    それ以後、認証エラーが発生する確率が格段に減りました。(アップデート途中のテストでは何度か出ていましたが)

    WireSharkでパケットキャプチャするとまだ2003R2DCに認証が飛んでいるようですが、モジュールバージョンアップしたDCだからか?問題なくつながります。

    トラブル出ていた時にWireSharkで調査していればもう少し原因究明できたかもしれませんが、、気が回りませんでした。

    ひとまず2,3日様子を見たいと思います。

    2016年9月1日 1:28
  • 本件、9/1の作業後問題発生していないので、解決とさせていただきます。

    回答マークは8/29のやき様の投稿とさせていただきますが、社員番号042様、やき様ともに貴重なご意見ありがとうございました。

    2016年9月5日 0:19