前の記事に引き続き検証を続けていきます。ここからWorkplace Joinに入ってきます。
この記事は3つに分割されたものの2つ目です。
①ADFSのデバイス認証を1時間でハンズオン(1/3 環境準備編)
②ADFSのデバイス認証を1時間でハンズオン(2/3 Workplace Join編)
③ADFSのデバイス認証を1時間でハンズオン(3/3 クレームルール制御編)
ここまでの説明で、CLIENT2がドメイン参加していないコンピュータであることは説明しました。BYODなどでWindowsタブレット持っていたらこれと同じ状態になるはずです。このCLIENT2をcontoso.comドメインにデバイス登録・認証をしていきます。
[CLIENT2]Workplace Joinをする
CLIENT2に接続して、チャームの検索から、「work」などのキーワードで検索してWorkplace settingsを選択します。
Workplaceの設定画面が開くのでユーザIDに「bensmith@contoso.com」と入力してJoinをクリックします。
Contoso-ADFS（つまりSERVER2）のログオン画面が表示されてきます。
少し余談ですが、内部的には「bensmith@contoso.com」のcontoso.comというドメイン名をキーにして、「enterpriseregistration.contoso.com」（enterpriseregistrationは固定＋ドメイン名)という名前で接続しにいきます。この環境の場合はCLIENT2のhostsファイルにこれを名前解決するためのエントリが含まれています。本当だったらPublic DNSに登録するなどして実現してあげることになると思います。
話がそれましたが、Workplace Joinが完了すると以下のメッセージが表示されているのが見えます。
This device has joined your workplace network
AD DSであるDCに接続して、デバイスが登録されていることを確認しましょう。これでADにデバイスを登録できました。 プロパティを見れば様々な情報が登録されているのが見れます。
ただ、この状態でクレームを確認してもデバイス関連のクレームは増えていません。つまりデバイス情報を認証に利用できていない状態です。これにはクレーム発行元のADFSの設定が必要です。
ADFSでデバイス認証を有効化
ADFSであるSERVER2に接続します。
AD FS Managementを起動します。
Authentication Policiesを選択すると、「Device Authentication」が「Not Enable」で無効化されているのがわかります。Editで設定を変更します。
「Enable device authentication」をチェックしてOKを選択します。
「Device Authentication」が「Enalbed」になりました。これでデバイス情報がクレームに含まれるようになります。
Workplace Join済みのCLIENT2から「Contoso ClaimsApp」に再度接続して確認してみましょう。まずIEからお気に入りの「Contoso ClaimsApp」にアクセスして、「Contoso sign-in page」をクリックします。
ADFSにユーザ認証します。
Device関連のクレームが表示されているのが確認できます。
ここで一旦IEを閉じます。そしてもう一回IEを起動して同じ手順をしてみます。
Contoso ClaimsAppに接続して、Contoso sign-in pageにアクセスすると、
ユーザ認証画面をスキップしてそのまま、アプリケーションにログオンできます。こういった動きが可能になります。
ただ、ここで問題が出てきます。この仕組みだとドメインのユーザIDを持っている従業員なら勝手にデバイスを登録して社内リソースを使えてしますことになります。次の記事では許可したデバイスのみが社内リソースに接続できるように設定調整してみます。
