前回、Microsoft Azureで提供されているWorkplace Join機能(正確にはDevice Registration Servicesだと思うんだけど)を利用して、ADFSサーバーでデバイス認証ができる様子を紹介しました。
前回の手順では、デバイス認証のためのデバイス登録方法までを紹介しましたが、
反響が大きかったので、今回はデバイス認証そのものについてチャレンジしてみたいと思います。
証明書利用者信頼の設定
PowerShellから以下のコマンドレットを実行し、デバイス認証を行う証明書利用者信頼でWindows統合認証または多要素認証が利用できるように設定しておきます。設定してしまった後から気がついたのですが、おそらくこの設定はデフォルトで有効になっていると思います。
(でも設定しておいて、間違いはないです)
Set-AdfsRelyingPartyTrust -TargetName “Microsoft Office 365 Identity Platform” -AllowedAuthenticationClassReferences wiaormultiauthn
この設定では、Office365を想定していますが、もし他の証明書利用者信頼を利用している場合でしたら、Microsoft Office 365 Identity Platformの部分は必要に応じて書き換えてください。
発行変換規則
証明書利用者信頼に対する設定ができたら、続いて証明書利用者信頼の発行変換規則で、
以下のような規則(クレームルール)を追加します。
c:[Type == “http://schemas.microsoft.com/claims/authnmethodsreferences”]
=> issue(claim = c);
Office 365で利用する場合だったら、[Microsoft Office 365 Identity Platform]証明書利用者信頼の要求規則を開いて、[発行変換規則]に規則を追加します。
authnmethodsreferencesというクレームは認証方法が記述されたクレームです。どのようなメカニズムで使われるのか、わかりませんが少なくともデバイス認証を行う上では必須の設定です。
発行承認規則
お待たせしました。いよいよ、デバイス認証の設定です。
デバイス認証の設定は、証明書利用者信頼の発行承認規則を使って行います。
一番簡単で、かつ最も使われる可能性が高い設定は、
「登録されたデバイスだけがOffice365にアクセスできるようにする」でしょう。
その場合は、[発行承認規則]から新しい規則(入力方向に基づいてユーザーを許可または拒否)を作成して、以下のような設定を入れます。
入力方向の要求の種類：登録ユーザー
入力方向の要求の値：True
アクセス：この入力方向の要求を行ったユーザーのアクセスを許可
ちなみに、この規則をクレームルールにすると次のとおりです。
c:[Type == “http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser”, Value =~ “^(?i)true$”]
=> issue(Type = “http://schemas.microsoft.com/authorization/claims/permit”, Value = “PermitUsersWithClaim”);
このクレームルールをベースにして色々なルールを書けば、
あなた好みのルールでアクセス制御ができるようになります。
いくつかサンプルを書いてみますので、興味があれば使ってみてください。
■特定のグループに属しているユーザーが登録済みデバイスを使ってアクセスしたときだけ許可
c1:[Type == “http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser”, Value =~ “^(?i)true$”] &&
c2:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value == “S-1-5-32-545”]
=> issue(Type = “http://schemas.microsoft.com/authorization/claims/permit”, Value = “PermitUsersWithClaim”);
Windowsグループを指定する場合、グループ名ではなく、SIDで指定する必要があるので、
あらかじめActive Directoryユーザーとコンピューター管理ツールからグループのプロパティを開き、[属性エディタ－]タブでグループのSID(objectSID)を調べておくことをお勧めします。(英語OSでごめんなさい)
■特定のドメインに属しているユーザーが登録済みデバイスを使ってアクセスしたときだけ許可
マルチドメインの構成で、特定のドメインに所属するユーザーだけにアクセスさせたい、というシナリオです。
「特定のドメイン」を判定する方法として、私はUPNの＠以降を使ってみました。
正規表現を使って、ご覧のように書きます。
c1:[Type == “http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser”, Value =~ “^(?i)true$”] &&
c2:[Type == “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn”, Value =~ “^*@(?i)contoso.com$”]
=> issue(Type = “http://schemas.microsoft.com/authorization/claims/permit”, Value = “PermitUsersWithClaim”);
contoso.comという名前はお使いのドメイン名に合わせて書き換えてください。
また、Office365で使用している場合、UPNのドメイン名部分は代替UPNサフィックスによって書き換えられている場合があり、その場合には使えませんので注意してください。
Windowsグループを指定する場合、グループ名ではなく、SIDで指定する必要があるので、
■特定のユーザーが登録済みデバイスを使ってアクセスしたときだけ許可
ADFSやAADで提供されるDevice Registration Services(デバイス登録サービス)は
デバイスとそのデバイスを利用するユーザーの組み合わせをActive Directoryに格納しています。
そのため、特定のユーザーという指定をしなくても、デフォルトでユーザーとデバイスの組み合わせを見ています(と思います)。
デバイスを利用するユーザーはmsDS-RegisteredOwner属性にユーザーのSIDで格納されています。
ADFSでデバイス認証を利用できるようになれば、ADFSを利用するメリットはぐっと広がると思います。
また、デバイス認証の対応デバイスも、従来のWindows 8.1(Workplace Join)やiOSだけでなく、
Windows 7(ドメイン参加している場合のみ)やAndroid4.3(SamsungのKNOX利用時)など、徐々に増えているようなので、そろそろ検討してみる価値はありそうです。
