5 月のパッチ リリース後に確認した上で、@IT さんの連載で書くつもりですが、5 月(日本だと 9 日の予定)の更新プログラムで CredSSP 認証に関係するポリシー設定の既定値(ポリシー未構成のときの挙動)の変更が予定されています(あくまでも、現時点では予定です)。 Show
とか、 サーバーとクライアントの更新サイクルが違う運用だとか、 ここ数か月更新をさぼっている PC、 新規インストール直後の PCに対する、RDP 接続や CredSSP を使用するその他の接続(Hyper-V レプリカとか Hyper-V マネージャーとか WinRM とか PowerShell Remoting とか ISV アプリとかにも影響するかも)が失敗することになるので要注意です。
CVE-2018-0886 の CredSSP の更新プログラムについて(Ask the Network & AD Support Team、2018年4月20日) CredSSP 認証は、リモートデスクトップ接続のネットワークレベル認証(NLA)とかで使用されているもの。対象のポリシーは、2018 年 3 月、および 4 月の累積的な品質更新プログラム(ロールアップ品質更新プログラム)で追加された「Encryption Oracle RemendationRemediation」というポリシー。今はポリシーを設定しない限り脆弱性は解消しませんが、5 月になるとポリシーを設定しなくても... 「Encryption Oracle RemendationRemediation」ポリシーは CVE-2018-088 の脆弱性に対応したもの(なぜこんなポリシー名なのかはよくわかりません)。3月の更新でその機能がポリシーとして実装されたものの、既定では有効化されていませんでした。パッチ済みでポリシーが未構成な場合、ポリシーが Vulnerable に設定されているのと同じ状態であり、 ポリシーをいじっていなければパッチ済み/未パッチ間の接続を含めブロックされることはありません(ただし CVE-2018-0886 の脆弱性は放置された状態)。これが、 5 月の更新で「Encryption Oracle Remendation Remediation」ポリシーが未構成のときの既定が「Mitigated」に変更されるそうです(つまり、ポリシーを設定しなくても CVE-2018-0886 の脆弱性が解消された状態)。その場合、ポリシーをいじっていなくても、 未パッチ(3 月、4 月、または 5 月の更新が未パッチ)のサーバーに対する、パッチ済み(5 月の更新による既定の変更)クライアントからの CredSSP がブロックされ、接続できなくなります。サーバーとクライアントの両方が、3 月または 4 月の更新がパッチ済みであれば、既定が変更になってもブロックされることはありません。 右のスクリーンショットは、Windows 10 バージョン 1709 (17299.371、つまりパッチ済み)で、5 月に予定されている更新後の状況を再現するためにポリシーを「Mitigated」にしてから、RDP クライアントで Windows 10 バージョン 1507(つまり未パッチ、EOS なのでパッチ予定なし)に接続したときのエラーメッセージ。最新の 17299.402 (KB4093105)の場合、なぜかエラー メッセージは出ずに(イベントログに LSA(LsaSrv)からの ID 6041 エラーは記録される)、何も言われず接続失敗しました(バグだと思う)。 で、サーバー側が未パッチでこの状況に遭遇してしまったら、クライアント側で例のポリシーを「Vulnerable」にすれば接続できるようになるはずです。クライアント側(Pro 以上なら、Home はレジストリ設定でいけるかもしれませんんが未確認)だけで対処できるので、サーバー側をあわてて更新する必要はありません。サーバーは最新パッチよりも安定稼働が大事なはず。なお、ポリシー名やポリシーの選択肢は、現在は英語ですが、そのうち日本語化されるかもしれません(現在は、%Windir%\PolicyDefinitions\ja-jp\CredSsp.adml の中のこのポリシーの部分が英語)。 "認証エラーが発生しました。要求された関数はサポートされていません "認証エラーが発生しました。要求された関数はサポートされていません "認証エラーが発生しました。 4/26 さらに追記) いつ出るかわからない Windows 10 バージョン 1803 ですが、Insider Preview ビルド 17134.1 の場合、最初から「Encryption Oracle RemendationRemediation」ポリシーが存在し、未構成のときの既定は「Vulnerable」の模様。 メイン コンテンツにスキップ このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。 ユーザーが認証できない、または 2 回認証する必要がある
この記事の内容この記事では、ユーザーの認証に影響する可能性のあるいくつかの問題について説明します。 アクセス拒否、制限された種類のログオンこの状況では、Windows 10 のユーザーが Windows 10 または Windows Server 2016 のコンピューターに接続しようとすると、次のメッセージでアクセスを拒否されます。
この問題は、RDP 接続にネットワーク レベル認証 (NLA) が必要であり、ユーザーが Remote Desktop Users グループのメンバーではない場合に発生します。 また、Remote Desktop Users グループが [ネットワーク経由でのアクセス] ユーザー権利に割り当てられていない場合にも、発生する可能性があります。 この問題を解決するには、次のいずれかを実行します。
ユーザーのグループ メンバーシップまたはユーザー権利の割り当てを変更するこの問題の影響を受けるユーザーが 1 人だけの場合、この問題の最も簡単な解決策は、ユーザーを Remote Desktop Users グループに追加することです。 ユーザーが既にこのグループのメンバーである場合は (または、複数のグループ メンバーに同じ問題がある場合は)、リモートの Windows 10 または Windows Server 2016 コンピューターでユーザー権利の構成を確認します。
アクセス拒否、SAM データベースへのリモート呼び出しが拒否されるこの動作が発生する可能性が最も高いのは、ドメイン コントローラーで Windows Server 2016 以降が実行されていて、ユーザーがカスタマイズされた接続アプリを使って接続しようとした場合です。 具体的には、Active Directory のユーザーのプロファイル情報にアクセスするアプリケーションは、アクセスを拒否されます。 この動作は、Windows に対する変更による結果です。 Windows Server 2012 R2 以前のバージョンでは、ユーザーがリモート デスクトップにサインインすると、リモート接続マネージャー (RCM) はドメイン コントローラー (DC) にアクセスし、Active Directory Domain Services (AD DS) 内のユーザー オブジェクト上にあるリモート デスクトップに固有の構成をクエリします。 この情報は、[Active Directory ユーザーとコンピューター] MMC スナップインで、ユーザーのオブジェクト プロパティの [リモート デスクトップ サービスのプロファイル] タブに表示されます。 Windows Server 2016 以降では、RCM は AD DS 内のユーザーのオブジェクトをクエリしなくなっています。 リモート デスクトップ サービスの属性を使っているため、RCM で AD DS をクエリする必要がある場合は、クエリを手動で有効にする必要があります。 重要 慎重にこのセクションの手順に従います。 レジストリを正しく変更しないと、重大な問題が発生する可能性があります。 変更する前に、問題が発生した場合に復元するためにレジストリをバックアップします。 RD セッション ホスト サーバーで以前の RCM の動作を有効にするには、次のレジストリ エントリを構成した後、リモート デスクトップ サービスのサービスを再起動します。
RD セッション ホスト サーバー以外のサーバーで以前の RCM の動作を有効にするには、これらのレジストリ エントリと、次の追加レジストリ エントリを構成します (その後、サービスを再起動します)。
この動作について詳しくは、KB 3200967 「Windows Server のリモート接続マネージャーへの変更」をご覧ください。 ユーザーがスマート カードを使用してサインインできないこのセクションでは、ユーザーがスマート カードを使用してリモート デスクトップにサインインできない 3 つの一般的なシナリオについて説明します。 読み取り専用ドメイン コントローラー (RODC) を使用するブランチ オフィスにスマート カードでサインインできないこの問題は、RODC を使うブランチ サイトに RDSH サーバーが含まれる展開で発生します。 RDSH サーバーは、ルート ドメインでホストされます。 ブランチ サイトのユーザーは子ドメインに属し、認証にスマート カードを使います。 RODC はユーザーのパスワードをキャッシュするように構成されています (RODC は Allowed RODC Password Replication グループに属しています)。 ユーザーは、RDSH サーバー上のセッションにサインインしようとすると、次のようなメッセージを受け取ります。"実行しようとしたログオンは無効です。 ユーザー名または認証情報に誤りがあります。" この問題は、ルート DC と RDOC によるユーザー資格情報の暗号化の管理方法が原因で発生します。 ルート DC では暗号化キーを使って資格情報が暗号化され、RODC では復号化キーがクライアントに提供されます。 ユーザーが "無効" エラーを受け取った場合、2 つのキーが合致していないことを意味します。 この問題に対処するには、次のいずれかを試してみてください。
これらのいずれの解決策でも、パフォーマンスまたはセキュリティ レベルの低下が避けられないことに留意してください。 ユーザーがスマート カードを使用して Windows Server 2008 SP2 のコンピューターにサインインできないこの問題は、ユーザーが KB4093227 (2018.4B) で更新された Windows Server 2008 SP2 コンピューターにサインインするときに発生します。 ユーザーは、スマート カードを使ってサインインしようとすると、次のようなメッセージでアクセスを拒否されます。"No valid certificates found. カードが正しく挿入され、密着していることを確認してください。"同時に、Windows Server コンピューターでは次のアプリケーション イベントが記録されます。"挿入されたスマート カードからデジタル証明書を取得しているときにエラーが発生しました。 署名が無効です。" この問題を解決するには、KB 4093227 「Windows Server 2008 における Windows リモート デスクトップ プロトコル (RDP) のサービス拒否の脆弱性を解決するためのセキュリティ更新プログラムについて:2018 年 4 月 10 日」の 2018.06 B の再リリースで Windows Server コンピューターを更新してください。 スマート カードでのサインインを維持できず、リモート デスクトップ サービスのサービスがハングするこの問題は、ユーザーが KB 4056446 で更新された Windows または Windows Server コンピューターにサインインするときに発生します。 最初、ユーザーはスマート カードを使ってシステムにサインインできる場合がありますが、その後 "SCARD_E_NO_SERVICE" のエラー メッセージを受け取ります。 リモート コンピューターが応答しなくなる可能性があります。 この問題を回避するには、リモート コンピューターを再起動します。 この問題を解決するには、適切な修正プログラムでリモート コンピューターを更新します。
リモート PC がロックされている場合、ユーザーがパスワードを 2 回入力する必要があるこの問題は、RDP 接続に NLA を必要としない展開内の Windows 10 バージョン 1709 が実行されているリモート デスクトップにユーザーが接続しようとしたときに発生する可能性があります。 これらの条件下では、リモート デスクトップがロックされている場合、ユーザーは接続するときに資格情報を 2 回入力する必要があります。 この問題を解決するには、Windows 10 バージョン 1709 コンピューターを KB 4343893、2018 年 8 月 30 日 — KB4343893 (OS ビルド 16299.637) で更新します。 ユーザーは、Windows Vista SP2 以降または Windows Server 2008 SP2 以降の任意のバージョンを使ってサインインしようとすると、アクセスを拒否され、以下のようなメッセージを受け取ります。
"CredSSP 暗号化オラクルの修復" とは、2018 年の 3 月、4 月、5 月にリリースされた一連のセキュリティ更新プログラムのことです。 CredSSP は、他のアプリケーションに対する認証要求を処理する認証プロバイダーです。 2018 年 3 月 13 日の "3B" およびそれ以降の更新プログラムでは、攻撃者がユーザーの資格情報を中継してターゲット システムでコードを実行する悪用に対処しました。 最初の更新プログラムでは、新しいグループ ポリシー オブジェクトである暗号化オラクルの修復のサポートが追加されました。設定できる値は次のとおりです。
2018 年 5 月 8 日の更新プログラムでは、暗号化オラクルの修復の既定の設定が Vulnerable (脆弱性あり) から Mitigated (軽減済み) に変更されました。 この変更により、更新プログラムが適用されたリモート デスクトップ クライアントは、適用されていないサーバー (または、更新後に再起動されていないサーバー) に接続できません。 CredSSP 更新プログラムの詳細については、KB 4093492 に関するページをご覧ください。 この問題を解決するには、すべてのシステムを更新して再起動します。 更新プログラムの完全な一覧および脆弱性の詳細については、「CVE-2018-0886 | CredSSP のリモートでコードが実行される脆弱性」をご覧ください。 更新が完了するまでこの問題を回避するには、KB 4093492 で許可される接続の種類を確認してください。 可能な代替手段がない場合、次のいずれかの方法を検討できます。
グループ ポリシーの使用について詳しくは、「ブロックしている GPO を変更する」をご覧ください。 クライアント コンピューターを更新した後、一部のユーザーが 2 回サインインする必要があるユーザーが Windows 7 または Windows 10 バージョン1709 が実行されているコンピューターを使用してリモート デスクトップにサインインすると、2 つ目のサインイン プロンプトがすぐに表示されます。 この問題は、クライアント コンピューターに次の更新プログラムがある場合に発生します。
この問題を解決するには、ユーザーが接続するコンピューター (および RDSH または RDVI サーバー) が、2018 年 6 月まで完全に更新されていることを確認します。 これには次の更新プログラムが含まれます。
複数の RD 接続ブローカーを含む Remote Credential Guard を使用する展開でユーザーがアクセスを拒否されるこの問題は、Windows Defender Remote Credential Guard が使われている場合に、複数のリモート デスクトップ接続ブローカーを使用する高可用性の展開で発生します。 ユーザーは、リモート デスクトップにサインインできません。 この問題は、Remote Credential Guard では認証に Kerberos が使われていて、NTLM が制限されるために発生します。 ただし、負荷分散されている高可用性構成の RD 接続ブローカーでは、Kerberos の操作をサポートできません。 負荷分散された RD 接続ブローカーが含まれる高可用性構成を使う必要がある場合は、Remote Credential Guard を無効にすることで、この問題を回避できます。 Windows Defender Remote Credential Guard の管理方法について詳しくは、「Windows Defender Remote Credential Guard を使用してリモート デスクトップの資格情報を保護する」をご覧ください。 Windows RDPの認証方式は?リモートデスクトップのネットワークレベル認証(NLA)とは、接続元のクライアントと接続先のサーバのセッションが確立する前に資格情報の確認をする認証方式です。
Ubuntuのリモート接続方法は?[設定] > [共有] を開き 「共有」 をオンにする。. 「リモートデスクトップ(D)」 を押す。. [リモートデスクトップ]ウィンドウで、上記のように共有接続を「オン」にし、画面接続時のユーザ名とパスワードを設定。 ... . 設定が終わったら、念のため、Ubuntuパソコンを再起動する。 ... . 「▼オプションの表示」を押す。. |