Windows 7/2008 mstscがサーバー証明書の警告の前にユーザー名パスワードを要求するのはなぜですか？
Windows 7mstscを使用してWindowsServer 2008（リモートデスクトップ）に接続すると、説明できない問題に気付きます。
mstscは最初にユーザー名パスワードを要求します。間違ったものを指定すると、mstscは「接続に使用された資格情報が機能しませんでした」と表示します。
正しいものを提供した後でのみ、mstscはサーバーの証明書が信頼されていないことを警告します。
Mstscは、「ユーザー名/パスワードがサーバーで受け入れられているかどうか」を確認する前に、「サーバー証明書が信頼されていません」というプロンプトを表示する必要があると思います。
つまり、私の質問は、接続するサーバーが偽造されたサーバー（攻撃者によってホストされている）である場合、私の資格情報が危険にさらされる可能性はありますか？
このような状況で資格情報が危険にさらされることは決してない場合でも、ユーザー名/パスワードを要求する前に、mstscがサーバー証明書の問題を要求する方がよいのではないでしょうか。少なくとも、平均的なユーザーがパスワードを盗まれる心配はありません。
ここで起こっていることは少し複雑ですが、NLAとCredSSPを読むと、より良い状況が得られます。
http://technet.Microsoft.com/en-us/library/cc749211%28WS.10%29.aspx
http://en.wikipedia.org/wiki/Network_Level_Authentication
基本的に、あなたの質問に答えるために...いいえ、偽造されたサーバーはあなたの資格情報を危険にさらすことはありません。彼らが一緒にいるために最初にやらなければならないことは、DNSを間違ったIPにスプーフィングすることですが、それでもRDPが現在機能する方法（Win7またはVistaクライアントとWin2008以降のサーバーを話していると仮定）暗号化され、公開されていません（注意点は、Technetの記事の下部で説明されているNTLMです）。
Technetの記事から役立つ可能性のある抜粋を次に示します。
WindowsServer®2003ターミナルサーバーでのエクスペリエンスとは異なり、資格情報プロンプトはサーバーではなくクライアントコンピューターにあります。最も重要なのは、クライアント資格情報プロンプトが安全なデスクトップ上にあることです。したがって、ターミナルサービスクライアントでさえ、重要なコモンクライテリア要件である資格情報を見ることができません。さらに、プロンプトから取得した資格情報は、サーバーIDが認証されるまで委任されません（ポリシー構成に従います）。最後に、ターミナルサーバーは、クライアントを認証する前にユーザーのセッションを確立しません（サーバー上で大量のメモリとCPU処理時間を消費します）。これにより、サーバーでのサービス拒否攻撃が成功する可能性が低くなります。
編集：明確にするために例を追加しましょう...
例1-ユーザーはリモートサーバーにアクセスでき、正しいパスワードを使用しています
この例では、ユーザー名とパスワードを入力します。ドメインに対してローカルで認証され、有効なユーザー名/パスワードであることを確認してから、リモートサーバーに接続してみます。その時点で、それが最初の接続である場合は、おそらく「リモートコンピュータのIDを確認できません」というメッセージが表示され、信頼するかどうかを選択できます。
例2-ユーザーがリモートサーバーにアクセスし、誤ったパスワードを使用している
ここにあなたが投稿した写真が表示されます...資格情報が機能しませんでした。新しい資格情報を入力してください。これは、リモートサーバーに接続することなく、クライアント上でローカルに実行されます（KerberosチケットまたはDCに対して検証されます）。
例3-ユーザーはリモートサーバーにアクセスできませんが、正しいユーザー名とパスワードを使用しています
ここでは、有効なアカウントとpwdであるため、ローカルで認証しますが、サーバーに接続して資格情報を渡すと、次のようになります。
お役に立てば幸いです...