今日非常に一般的なシナリオを想像してみましょう。 多くのビジネスアプリケーションが企業ネットワークに展開されています。 これらのアプリケーションは、HTTPSを介した外部アクセス用に公開されています。 企業ネットワークの外部にいる会社のモバイル従業員は、Windows、iOS、またはAndroidで実行されている個人のタブレットからこれらのアプリケーションに接続したいと考えています。 これらのデバイスは、ドメインに含めることができないか、ユーザーがこれを実行しません。 そのようなデバイスから企業アプリケーションへのアクセスのセキュリティを強化する方法は？ Windows Server 2012 R2のデバイス登録サービス（DRS）が役立ちます。



この記事では、DRSの基本原則とアーキテクチャに焦点を当てます。 設定の詳細は、コース「 コーポレートデバイス 」の4番目のモジュールに記載されています。 ハイブリッド資格情報を管理する方法 。」

主な問題は何ですか？

企業ネットワーク内には、外部から接続するために公開されたHTTPSアクセスを備えたWebアプリケーションがあります。 どのブラウザからでも任意のプラットフォームから接続され、ブラウザとアプリケーション間のすべてのトラフィックは暗号化されます。 しかし、現代のモバイルデバイス、特にタブレットのすべての明らかな利点には、マイナス面があります。 どこにでも持ち運ぶのに便利なものは、簡単に紛失したり盗まれたりする可能性があります。 好奇心のデバイスの新しい「所有者」は、悪意のために、または悪意を持って、ブラウザ履歴でURLを「学習」しようとすることができます。 また、個人用デバイスで使用される可能性が高い保存されたCookieを使用すると、組織のアプリケーションを含むアクセスを取得することは難しくありません。







ドメインネットワークでは、グループポリシーによりこのような状況を簡単に回避できます。 ドメインデバイスへのログイン用のパスワードで始まり、アプリケーションにアクセスする際の認証用の証明書で終わります。 ドメインに含めることができないデバイスについてはどうですか？ アプローチは異なる場合があります。パスワードまたはPINコードの必須使用を設定してデバイスを入力したり、タブレットで証明書を生成してインストールしたりできます。 プラットフォームが異なる場合のみ、これらの手順は異なり、おそらくITスタッフが手動で行う必要があり、新しいデバイスごとに適切な一連のアクションが生成されます。 そして、私は、デバイスの所有者がそのようなタスクに対処できるようにしたいと考えています。



1つの解決策は、Windows Server 2012 R2のDRSを使用することです。

主なアイデアは何ですか？

サービスの名前が示すように、DRSはデバイス登録手順を実装しています。 登録プロセス中に、DRSはX.509証明書を生成します。これはデバイスにダウンロードされ、デバイスと登録を完了したユーザーの両方に関する情報を含むActive Directoryに新しいオブジェクトを作成します。



ユーザーが登録済みデバイスからアプリケーションに接続するたびに、ユーザーは認証され（パスワードを入力するか、Cookieが使用されます）、証明書が検証されます。 そして、両方のチェックに成功した場合のみ、ユーザーはアプリケーションにアクセスできます。 実際、2要素認証を扱っています。







ただし、いくつかの点に注意することが重要です。

1. 登録手順は可能な限り簡単で、ITスペシャリストによるデバイスの事前設定は必要ありません。
2. DRSはさまざまなプラットフォームをサポートしています。
   
   
   1. Windows 8.1以降
   2. iOS 6以降
   3. Android-Samsung KNOX
   4. Windows 7 Pro（ドメインに含まれる）
3. DRSはPKI展開を必要としません

どのように見えますか？

Windows Server 2012 R2では、DRSはADFSとともにインストールされます。 ADFSは、上記の図からわかるように、認証プロセスで重要な役割を果たします。 アプリケーションに登録サービスを使用するには、ADFSを介して認証を構成する必要があります。 セキュリティ上の理由から、ADFSを備えたサーバーは通常企業ネットワーク内にあるため、インターネットから要求を受信して​​ADFSにリダイレクトする境界ゾーンにはプロキシコンポーネントが必要です。 Webアプリケーションプロキシ（WAP）は、Windows Server 2012 R2の新しいサービスであるプロキシの役割を果たすことができます。 次に、ADFSはユーザー認証を実行し、デバイス登録が構成されている場合は証明書の検証を実行します。 認証に成功した場合、ADFSは要求されたアプリケーションのアクセストークンを生成し、ユーザーデバイス上のブラウザーにトークンを返します。 その後、ユーザーはアプリケーションにアクセスできます。







インフラストラクチャの要件について説明する場合、DRSを使用するには、ADスキーマを拡張し、Windows Server 2012 R2とADFSロールが昇格されたサーバーを少なくとも1つ持つ必要があります。



デバイス登録プロセスを次の図に示します。







Windows 8.1を搭載したタブレットの所有者の観点からこのプロセスがどのように見えるか、そして舞台裏で何が起こるかを見てみましょう。 私のインフラストラクチャでは、デバイスが企業ネットワークの外部にある場合にのみデバイスの登録が必要になるようにADFSが構成されています。 たとえば、タブレットが企業のWi-Fiに接続されている場合、ユーザー名とパスワードによる認証で十分です。 そしてもちろん、ユーザーが企業ネットワーク上のドメインコンピューターからアプリケーションにアクセスする場合、ユーザーには何も必要ありません。 完全なシングルサインオンがあります。 このような条件付きアクセス条件を構成する機能は、特定のアプリケーションに対して、問題のシナリオでADFSを使用するもう1つの重大な利点です。 条件付きアクセスポリシーの定義方法は、コース「 企業デバイス 」の4番目のモジュールに記載されています。 ハイブリッド資格情報を管理する方法 。」



そのため、会社の従業員は会社の外にいて、ドメインに含まれていないタブレットのブラウザーで、SharePointの企業ポータルのURLをダイヤルします。 WAPを介した要求はADFSによってリダイレクトされ、そのような画像が表示されます。







ご覧のとおり、ADFS認証ページの要素とエラーメッセージページ（画像、ロゴ、メッセージテキスト）が構成されています。 ユーザーはドメインアカウントのユーザー名とパスワードを指定し、ログインはユーザープリンシパル名（UPN）の形式で入力されます。 デバイスはまだ登録されていないため、アクセスは拒否されます。







エラーメッセージのテキストで、タブレットを登録するためにユーザーが実行する必要があるアクションを示しました。 これらのアクションはプラットフォームごとに異なります。 したがって、iOSの場合は、 https：// <adfs server name> / enrollmentserver / otaprofileのURLに移動するだけです 。 Windows 8.1の場合、登録はOSインターフェースで提供されます： PC設定->ネットワーク->ワークプレース 。 Workplace joinと呼ばれます。







[ 参加 ]ボタンをクリックすると、既におなじみのADFS認証ウィンドウが表示されます。







Windows 8.1はどのようにADFSを検出しますか？ ユーザーが入力したUPNから、接尾辞（この場合はcontosomsspb.com 、定義済みの名前）が取得され、 enterpriseregistrationがそれにドッキングされ、OSがIPで解決しようとしているFQDNであるenterpriseregistration.contosomsspb.comになります。 したがって、このようなDRSディスカバリメカニズムを機能させるには、組織AレコードのパブリックDNSドメインに、名前がenterpriseregistrationで、ポックスコンポーネント（WAPサーバーなど）のIPアドレスを登録する必要があります。



パスワードが正しく入力されると、デバイスが登録され、前のウィンドウに戻ります。ここで、 Workplace参加操作が完了したことがわかります。







舞台裏で何が起こっていますか？ タブレット自体で、 証明書スナップインを使用して、新しい証明書の出現を検出できます。







アプリケーションに接続するときに、2番目の認証要素として使用されるのは彼です。



Active Directoryでは、対応する証明書オブジェクトは新しいRegisteredDevicesコンテナーにあります。 オブジェクトの名前はCN証明書と一致します。 このオブジェクトの属性は、たとえばADSI Editを使用して表示できます。







属性の中には、デバイス名、OSタイプとバージョン、登録を完了したユーザーのSID、登録日時などがあります。



ポータルへの接続を再試行し、再びADFSページにアクセスして、再度ADアカウントの資格情報を入力します。 しかし、今では、パスワードの確認に加えて、証明書の確認とアプリケーションへのアクセスが正常に完了しています。







さらに、最初の接続に成功すると、ユーザーはこのアプリケーションのSSOを受け取ります。 彼はブラウザを閉じ、マシンを再起動し、ブラウザを再度開き、URLを入力して、追加の質問なしでアプリケーションにアクセスできます。 実際、Cookieは最初の認証要素を提供し、証明書は2番目の認証要素を提供します。 当然、永久ではなく、ユーザーはパスワードを入力して自分の信by性を確認する必要があります。 しかし、この用語はITを制御します。

セキュリティに関する追加の考慮事項

タブレットの紛失/盗難の状況に戻りましょう。 デバイスが既に登録されている場合、アプリケーションにSSOが実装され、デバイスは間違った手に落ちました。 最初の防衛線は、デバイスに入るためのパスワードまたはPINコードです。 非ドメインデバイスの場合、Microsoft Intuneまたは別のMDMソリューションなどを使用して、強制ロックを有効にできます。 これが行われていない場合は？ 攻撃者に追加の切り札を与えたことがわかります-彼はブラウザを開いてURLを入力するだけです。 明らかに、このような状況では、所有者はITサービスにできるだけ早く通知する必要があります。 ITは何をしますか？ いくつかのオプションを見てみましょう。



デバイス登録サービスがまったく使用されていない場合。

1. 公開されたアプリケーションへのユーザーアカウントアクセスを制限できます。 しかし、長距離旅行中に別のデバイス（メインラップトップ、セカンドタブレットなど）からアプリケーションにアクセスする必要がある場合はどうでしょうか。
2. ユーザーのパスワードをリセットできます。 しかし、これが他のサービスへのアクセスにどのように影響するかは必ずしも明らかではありません。

両方のソリューション、および提供可能な他のオプションは非常に適用可能ですが、理想的ではありません。



デバイスが登録されている場合。



管理者がADで失われたデバイスに関連付けられたオブジェクトを見つけて、オブジェクトを削除するか、msDS-IsEnabled属性のプロパティに値FALSEを設定するだけで十分です。







その後、アプリケーションに接続すると、デバイス証明書は検証に合格せず、ユーザーはエラーメッセージを受け取ります。 したがって、特定のデバイスへのアクセスをブロックします。







ユーザーのパスワードが危険にさらされ、攻撃者に知られるようになった場合はどうでしょうか？ 彼の再登録を妨げるものは何もありません。 このシナリオに対処する1つの方法は、Microsoft Azure Multifactor Authentication（MFA）サービスを使用してデバイスを登録することです。 この場合、ユーザーはデバイスを登録するときに、パスワードの入力に加えて追加のチェックに合格する必要があります-携帯電話への着信に応答するか、受信したSMSコードを入力するか、再びオンラインストアにある特別なアプリケーション（Multi-Fator Auth）を使用しますマイクロソフト、グーグル、アップル。







しかし、これは別の議論のトピックです。



そのため、Windows Server 2012 R2で導入されたデバイス登録サービスは、ADドメインに含まれておらず、さまざまなOSを実行している個人のモバイルデバイスから企業アプリケーションにリモートで接続する際のセキュリティレベルを追加するのに役立ちます。



ADFSとDRSのインストールと構成の詳細については、たとえばこちらをご覧ください 。

iOSデバイスの構成機能、条件付きアクセスポリシーの作成、WAPの展開など：

https://technet.microsoft.com/en-us/library/dn280939.aspx