ラベル ADFS の投稿を表示しています。 すべての投稿を表示
ラベル ADFS の投稿を表示しています。 すべての投稿を表示

2017年4月29日土曜日

[MIM]3月のアップデートでサポートプラットフォームの大幅な改善+α

こんにちは、富士榮です。

色々と追い付いていなかったので、改めてまとめておきます。

3月にMicrosoft Identity Manager 2016 SP1 (MIM)向けのホットフィックスがリリースされ、特にサポートされるプラットフォームが大幅に追加されました。

個人的には、プラットフォームサポート周りでは「SQL Server 2016 Always Onのサポート」が非常に熱いトピックスでしたが、他にもSCSM 2016がサポートされたり、Visual Studio 2017が使えるようになったり、など色々とエンハンスが行われています。

MIM 2016でサポートされるプラットフォーム一覧
https://docs.microsoft.com/en-us/microsoft-identity-manager/plan-design/microsoft-identity-manager-2016-supported-platforms


他にも以下が新しく使えるようになった代表的なシナリオです。



こちらからダウンロード可能なので、MIM使いの皆さんは適用しておきましょう。

2017年3月21日火曜日

[小ネタ]NAT構成のVMに構成されたAD FSへiOSデバイスを登録する

こんにちは、富士榮です。

今回は完全に小ネタというか自分用のメモです。

普段、BootcampなMacbook AirにWindows 10を入れ、その上でVMware Workstationを動かして、AD FSやMIMを動かして検証してるんですが、VMやAzureだけでクローズできないネタを検証する場合です。

具体的にはiOSやAndroidデバイスなどをAD FSへデバイス登録してデバイス認証をしたい場合、以下が困ります。
・JailbreakしていないiOSだとhosts登録が出来ない
・色々と事情があってVMをNAT構成で動かしているので母艦PC以外からVMへアクセスできない

ということで、対処してみます。

と、言ってもやることは母艦にApacheを立ててForward Proxyにするだけなんですが。

◆Apacheをダウンロードして構成する

Apacheの本家からWindows用のbinaryのダウンロードは出来なくなっているので、本家からリンクされているサイトからダウンロードをして使います。
 http://httpd.apache.org/docs/current/platform/windows.html#down

母艦がWindows 10 Pro x64なので、64bit版をダウンロードしてきました。バージョンは現時点の最新版な2.4.25です。

zipアーカイブを解凍したら少々コンフィグをいじくります。(conf\httpd.confを編集します)
ポイントは、

  1. パスを合わせる
  2. Proxyに必要なモジュールをロードする
  3. Forward Proxyとして構成する
  4. ServerNameをつける

の4点です。

では順番に。

1.パスを合わせる

 変更箇所はServerRoot、DocumentRoot、ScriptAlias、cgi-binのディレクトリ設定の4か所です。単にForward Proxyとして使うだけなので変更しなくても問題はありませんエラーが出るので。以下の5行が変更対象です。今回、C:\Tools\Apache以下にモジュールを展開したので環境に合わせて編集します。
ServerRoot "C:/Tools/Apache/Apache24"
DocumentRoot "C:/Tools/Apache/Apache24/htdocs"

    ScriptAlias /cgi-bin/ "C:/Tools/Apache/Apache24/cgi-bin/"

2.Proxyに必要なモジュールをロードする

 必要なモジュールのLoadModule行のコメントアウトを外します。今回AD FSを使うのでhttpsのフォワードも必要なのでmod_proxy_connectも使います。
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_http_module modules/mod_proxy_http.so

3.Forward Proxyとして構成する

 非常に雑な構成ですが、httpd.confの最後に以下を追記します。

  ProxyRequests On
  ProxyVia On
  Listen 8080
  AllowCONNECT 443
 
    Order deny,allow
    Deny from all
    Allow from all
 

4.ServerNameをつける

 これはしなくてもいい設定ですが、Apacheの起動時にワーニングが出るのでとりあえず設定しておきます。

ServerName hoge:80

取り敢えずここまで設定したらOKなので、起動しておきます。
私の場合は検証したい時だけ立ち上げれば良いので、サービス化はせずにコマンドプロンプトから直接起動します。

binディレクトリ配下でhttpd.exeを起動するだけです。


◆母艦からアクセスできるようする(hostsファイルの構成など)

母艦経由でVMへアクセスさせたいので、まずは母艦からアクセス出来るようにネットワークを構成をしてあげる必要があります。

多くの場合、適当な名前(.localとか)でドメインを構成していたりするので、母艦のhostsファイルを使って適切にアクセスできるように構成する必要があります。

後は、念のため母艦からAD FSへアクセスできることを確認しておきましょう。


◆iOS側のProxy設定をする

最後にiOSのWifi設定でProxyサーバに母艦PCを指定します。
尚、当然の事ながら母艦PCへの8080ポートの通信をWindows Firewallで開放しておく必要があります。

iPhoneの設定からWifiを開き、母艦PCと同じアクセスポイントへ接続していることを確認したら、母艦PCのIPアドレスとProxyサーバとして指定した8080番を指定します。


設定はこれで終了です。

◆DRSへアクセスしてデバイス登録する

この状態でiPhoneからAD FSのデバイス登録サービス(DRS)へアクセスして、プロファイルがインストールされるか確認してみます。

DRSのアドレスは
 https://ADFSServer/EnrollmentServer/otaprofile
ですが、当然インターネットにしか繋がっていないiPhoneからVMで動いているAD FSへアクセスは出来ず、DRSへ到達できません。

しかし、今回母艦に立てたProxyを経由することでVM上のAD FSへアクセスでき、無事にプロファイルがインストールできます。



当然、デバイスクレームの取得もできるので、手元でアクセス制御のテストも行うことが出来ます。



まぁ、Azure上にIaaSを立ててインターネットからもアクセス出来るようにすればいいんでしょうが、iOSからアクセスできるようにちゃんとDNS登録が必要だったり、特にDRSの場合はenterpriseregistrationの名前が解決できる証明書を用意しなければいけなかったりするので、手元で済ませられれば手軽なのでこういう方法もありかな~と思っています。

2015年10月19日月曜日

[AzureAD]Azure AD Domain Servicesを使って既存サービスをクラウド上へ移行する際の注意事項

こんにちは、富士榮です。

先日パブリック・プレビューが公開されたAzure Active Directory Domain Services(Azure AD DS/AADDS)を使うことでオンプレミスのActive Directoryが提供してきたドメイン・サービス(ドメイン参加やグループポリシーなど)を、同一Azure VNET上のマシンに対して提供することが可能になりました。

公式blogでのアナウンス
 Azure AD Domain Services is now in Public Preview ? Use Azure AD as a cloud domain controller!
 http://blogs.technet.com/b/ad/archive/2015/10/14/azure-ad-domain-services-is-now-in-public-preview-use-azure-ad-as-a-cloud-based-domain-controller.aspx

尚、基本的なセットアップ方法や簡単な注意点についてはMicrosoft Regional Directorの亀渕さんが紹介しているので、そちらを参考にしてください。

ブチザッキ
 Azure Active Directory Domain Services (Public Preview)
 https://buchizo.wordpress.com/2015/10/15/azure-active-directory-domain-services-public-preview/



公式ドキュメントや亀渕さんのblogにも書かれているとおり、AADDSで提供されているドメインサービスには一部制限があります。
・サイトの構成やマルチフォレスト・マルチドメインなどのドメイン構成自体のカスタマイズはできない
・グループポリシーはビルトインのもののみで、カスタマイズができない
・直接ユーザやグループをMMCで管理できない
・管理者(ドメイン参加権限くらいしかない)はAAD DS Administratorsグループに入る
などなどです。


オンプレミスの既存サービスをクラウドへ持って行こうとすると、これらの制限によって少々困ることが出てくるので移行計画を立てる際は注意が必要です。

私が試していて特に困った点は「Domain Admins」権限をユーザに付与できない、という点です。
既存アプリケーションの中にはActive Directory上のオブジェクトを参照・更新するものもあり、それらのアプリケーションは多くの場合Domain Admins権限を要求します。
(アプリケーションの作りの問題ではありますが・・・)

ちなみにAzure AD DSのDomain Adminsにはdcaasadminというユーザが固定でメンバ登録されていますが、このユーザのパスワードがわからないので、なんともなりません。
もちろんこのユーザのパスワードを更新することはできないようになっていますし、Azure AD側への同期もされていません。



以下、Domain Admins権限を求める例です。

1.メンバサーバへのリモート・デスクトップ・ログイン
 これは回避策がありますが、サーバをAzure仮想マシンで構築し、Azure AD DSへ参加させた後、サーバへリモート・デスクトップでAzure AD DS上のユーザでログインしようとしても拒否されてしまいます。


 これはメンバサーバへのリモート・デスクトップ接続が初期状態でビルトインのAdministratorsのみに許可されているためです。Domain Adminsはドメインに参加した時点でビルトインAdministratorsグループに登録されるため、オンプレミス環境ではDomain Adminsのメンバでサーバを管理すれば特に困ることはありませんでした。

 ところが、Azure AD DSでは先述の通り、Domain Adminsは使えないので、まずはローカル・アカウントでログインし、コンピュータの管理からローカルのAdministratorsにリモート・デスクトップ接続したいユーザもしくはグループを追加する必要があります。



2.Domain Admins権限を要求するアプリケーションを導入する
 これは現状どうしようもありません。アプリケーションが固定でDomain Admins権限を要求してくるので、なんともなりません。

 例えば、Active Directory Federation Services(AD FS)などマイクロソフトのサービスはこの時点でほぼ全滅です。(この辺りはAzure ADを使えってことなんでしょうけど)




今後正式版がリリースされるまでにうまく回避策が出てくるといいですねぇ。。

2015年10月9日金曜日

[AD FS]Azure ADに引き続きAD FSもOpenID Connect適合性認定

こんにちは、富士榮です。

本blogでも紹介してきたとおり、Azure Active Directory(Azure AD)に引き続き、次期Active Directory Federation Services(AD FS)もOpenID Connectに対応していますが、OpenID Foundationによる適合性を認定されたとの発表がありました。



 Active Directory Federation Server gains OpenID Certifications!
 http://blogs.technet.com/b/ad/archive/2015/10/08/active-directory-federation-server-gains-openid-certifications.aspx

 OpenID Foundationの認定ページ
 http://openid.net/certification/

 ここを見るとAzure Active DirectoryおよびAD FS for Windows10(Windows Server 2016のことだと思うので表現はどうかと思いますが)が認定されていることがわかります。


参考)本blogでの検証結果
 [AD FS]OpenID Connectに対応した次期AD FSを試す
 http://idmlab.eidentity.jp/2015/08/ad-fsopenid-connectad-fs.html

 [AD FS]OpenID Connectに対応した次期AD FSを試す(UserInfo編)
 http://idmlab.eidentity.jp/2015/09/ad-fsopenid-connectad-fsuserinfo.html


検証結果を見るとまだまだな点もありますが、このようなオープンな仕様に準拠していることがわかる形で公表されると安心できますね。

ちなみに、AD FSがLibertyのSAML2.0の相互運用性テストに合格したのは2009年でした。

 クラウド時代のID管理へ? ~ADFS2.0がSAML2.0相互運用性テストにパス~
 http://idmlab.eidentity.jp/2009/10/idadfs20saml20.html

もう6年も前なんですね。
(6年前からやってることが変わらないこのblogもアレですが)

2015年9月26日土曜日

[AD FS]OpenID Connectに対応した次期AD FSを試す(UserInfo編)

こんにちは、富士榮です。

先月のポストでは、Windows Server 2016のTechnical Preview 3に搭載される新AD FSのOpenID Connectへの対応の概要を紹介しました。

 [AD FS]OpenID Connectに対応した次期AD FSを試す
 http://idmlab.eidentity.jp/2015/08/ad-fsopenid-connectad-fs.html


また、同じく既にOpenID Connectに対応しているAzure Active Directory(Azure AD)について、userinfoエンドポイントを使ってユーザ情報を取得する方法についても紹介しました。

 [Azure AD]OpenID ConnectのUserInfoエンドポイントを使ってユーザ情報を取得する
 http://idmlab.eidentity.jp/2015/08/azure-adopenid-connectuserinfo.html



と、いうことで今回は新AD FSのUserInfoエンドポイントよりユーザ情報を取得できるかどうか確認して見たいと思います。

◆エンドポイントを確認する

前回同様、/adfs/.well-known/openid-configurationをGETして各種エンドポイントの情報を確認すると、UserInfoエンドポイントは
 "userinfo_endpoint":"https://adfs.example.com/adfs/userinfo"
であることがわかります。

別の方法としては、AD FSの管理コンソールから登録されているエンドポイント一覧を確認することもできるので、コンソールアクセスできる場合はそちらから確認しても大丈夫です。



◆クライアント登録する

次に、UserInfoを取得するクライアントを登録します。
新しいAD FSでは、「Application Groups」メニューよりアプリケーション・グループを作成し、その中にアプリケーション(クライアント)を登録します。

今回はダミークライアントでOKなので、以下のパラメータで登録しました。
・Template:Standalone applications - Server application or Website
・Redirect URI:http://localhost
・Application Credentials:Generate a shared secret

以下、登録ウィザードの画面です。




◆UserInfoへアクセスするためのアクセストークンを取得する

code flowでアクセストークンを取得していきますので、まずは認可エンドポイントへアクセスし、認可コードを取得します。
UserInfoエンドポイントからプロファイル情報やメールアドレスなどの情報も取得したいので、scopeにはopenid profile emailを指定します。

https://adfs.example.com/adfs/oauth2/authorize/
    client_id=2155e727-7560-4e2f-985d-274a91691af9&
    response_type=code&
    redirect_uri=http%3A%2F%2Flocalhost&
    scope=openid%20profile%20email&
    state=12345


結果、Redirect URIに指定したアドレスにクエリパラメータとして認可コードが返ってきます。

http://localhost/?
    code=fcCKuMdQjUmSBo8l1mZWFA.XE6TFE7G0ggOAPXOTd4Eag7n30A.ENQ1pomEwEqzzWB_-q3HhwKX0pYq0mAuN-o_6qa4JAiMD8lWIbvaxThqlbkE8SAkZ4Ik0RfbuzdqHfzEjXSj_U513DgjLyq5VmPt34nLmcs9BhpoBjZJY84b-0rmiWmCe8lbHZHb1ENQy7KbytmDwC7j_fRjzXDkAcr9ReeFkQPl6PCe7mSOTvGOEpi04YrzDeY6tk_YKMPpRv8d2YnKd4R3qMAUKCfeNfhgOdua8xTcVDj0d-9bDVIW5GKD6Agydu1xsnTv3Mzm_UirAWMTpRQtpbtRJZUt3fdNSQAxpgst3H7qbG3Iy7bmfYb2FpxmP02BMHikr36vS09tTk6KnA&
    state=12345


このcode=xxxの部分が認可コードです。


次に取得した認可コードをトークンエンドポイントにPOSTしてアクセストークンを取得します。
https://adfs.example.com/adfs/oauth2/token
    grant_type: authorization_code
    client_id: 2155e727-7560-4e2f-985d-274a91691af9
    code: fcCKuMdQjUmSBo8l1mZWFA.XE6TFE7G0ggOAPXOTd4Eag7n30A.ENQ1pomEwEqzzWB_-q3HhwKX0pYq0mAuN-o_6qa4JAiMD8lWIbvaxThqlbkE8SAkZ4Ik0RfbuzdqHfzEjXSj_U513DgjLyq5VmPt34nLmcs9BhpoBjZJY84b-0rmiWmCe8lbHZHb1ENQy7KbytmDwC7j_fRjzXDkAcr9ReeFkQPl6PCe7mSOTvGOEpi04YrzDeY6tk_YKMPpRv8d2YnKd4R3qMAUKCfeNfhgOdua8xTcVDj0d-9bDVIW5GKD6Agydu1xsnTv3Mzm_UirAWMTpRQtpbtRJZUt3fdNSQAxpgst3H7qbG3Iy7bmfYb2FpxmP02BMHikr36vS09tTk6KnA
    redirect_uri: http://localhost
    client_secret: 6MsbJZTFr2ZEC-BNb8c6rRdIolxCm_c1HgA5hHFQ


すると、アクセストークン、リフレッシュトークン、IDトークンが返ってきます。
{
    "access_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IlFsOVdvTDVNQ1FCZTdlSzZjdjc4T2RLTzFpMCJ9.eyJhdWQiOiJ1cm46bWljcm9zb2Z0OnVzZXJpbmZvIiwiaXNzIjoiaHR0cDovL3RwMy5hZGZzMjAubmV0L2FkZnMvc2VydmljZXMvdHJ1c3QiLCJpYXQiOjE0NDMyNTY4MDYsImV4cCI6MTQ0MzI2MDQwNiwiYXBwdHlwZSI6IkNvbmZpZGVudGlhbCIsImFwcGlkIjoiYTgyNDg4NWItYzVkOS00ZDNhLWI2OWEtN2M4OTZiODBhZjhkIiwiYXV0aG1ldGhvZCI6InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphYzpjbGFzc2VzOlBhc3N3b3JkUHJvdGVjdGVkVHJhbnNwb3J0IiwiYXV0aF90aW1lIjoiMjAxNS0wOS0yNlQwODo0MDowNi41NjRaIiwidmVyIjoiMS4wIiwic2NwIjoib3BlbmlkIiwic3ViIjoiajhtMUZBT3hVWE5ZeFpxZHMwYkVNZG9MM1gybTZLcFA2Wkt4elZQYW42TT0ifQ.fNmEOEARGbWURRoRazcW36jgtw0a3h4i7Z5--UC9nLB0mFFjZVxcJe4-1hhaCQExn04oUD9-HXXI4BFKkbctWNJJKUo8kT4kAn_Uj8J10INYUAJA5veKis1MdUIZ7glpEfMzEvzjrTGnMhN4v4y_CEzziU0LB1nGogozOkDOD3Y6gfaUJbrOv4V8lbmjm9cuMNDRs6ZEwGf5aqc2ChAbWw2icqW3XBwTnUR_X0je2LKmwjcljY145-fybEgUbFANbAnSSC8WOcS-KGOKzlqIbf3AxQ1PaetMGAb02N25KM36b24I9yzDPDs8EmKgL4mSfjTPHxnUWCu7UB4wMcfvIw",
    "token_type":"bearer",
    "expires_in":3600,
    "resource":"urn:microsoft:userinfo",
    "refresh_token":"5dC-njXY426ezdn5gD3F0I303XUf7otp3hxwUTfPuXgAAQAAknmNeJNokXbBjoJ8_0szNQ6IyCQ0jM7VerjRPZl-fnpGzMz7eT6p6CZ2IUh2o_uv09DZZkLCKemeEdZakCQ84goI6drbRYXuCGCgjeZ4OXXJWshjLrO94qWD7hLeVxScBna7ZKDik2zU5ep4yQxljkIGcHzH4csh9cumG_Yr_SntMDdvXYGkVhT3DDf68hKn_fqWTCYygN5cRol3OjlX5ipVL-8x73ndaaqdrYfNVtacjIJmdgqm4qmfOi89kjajlt3VLXAqWfkdwRupLbmvQ4uXunriR9tYq-67zJcok2SD1m4Us9qeS9PEKLdjIeKzQusUKaO8rH0yYp4D3sZamHAFAABfIdD674BFeJV6xPKn3Rk7NmrZeSPKi5GY70mzUy0qjIwx93kKGV83INvNgkB608h5ZR4m-VrNMjxUZjIF6cCtxcrz85cjcCqj99W0pxXm_5-GzfBN1lUxhejAuWZxX-3LK05yTiWoSvSoqJUYDE2tyHQ4kX42dWqWv1QerfOo54QZQ72H8DWNNvxhAslDFrnQlJr9Y-h5ppaPpU2F9ViBKlJx6d0R8gIZs6ZJfgkgMG4X8Lw0K3OuM4vHBfVmBSSEAqCNMm8SLwI4i0Y6hb9G-WXGjd2c0SvgsOBWNvptWEdD571ggr2RUgyYqPHP5Aj3368mwKoHiWfdDR07YCIlk889lLhnA3kD2LItaYGgTuJ65N2kpiPoyc6EaTo-Nr961ERjxz9ajZijD69Ck6z6VRkqbphfhNXEVMop2ZJLW5dkXDiFoBMuM0oV95hjuwgBOHwUfTfM0RkjjEauARSN4DjV3enuWfIUKTCGFo-meI_Jt2c5mQ80U-7Fxfy2RxhbuJgXRa37I4YEtbeMBptu_o_vSvSqF__Z9fgpuWXYLJfpTfi0VI5k9GfJvmZm7zisyyRsEh1mWlDJdgE9hwl6GCIaoAd2kjrJmPnnNJrguOvwAXLCZVsY6IQxk8OsUjnZQ9a1OgdrAgHE3W0LRMPi6qEvNkKKlQxIoV4K0gyXrWnx752_7LCHfpGmKBG6Ot0FhVrw5z1JcAClBSv_4gWuKpkvXu6x8Ne4Km6dzmsVWsN7GyX3M9GUsW05CDASJ9KAbGbKNPeQpp8FBFdnooULAcb0KqGtPBDIu4dazZtpFMK2l9le2kfvaJOB87S1wod5CsR2ms5A6EDKcMOaXVmMl1H5MR_Mdae1057KulOze0HtQoebKRZHJHZL5DWE0r7qKUtINxz1LQ2eMAitcslcJCpD_j09YtOpkZIIhJzjx7kyisgv5yEoIh_qOTvMAr97wnewU63ZgYAHUdGPVBgOFKKuew_I0bIOIj4ZKk3qpXFdzdpYVXewy9VIffOkISlszUyjhL6xnU_W26M0YfWu4KDOpysTSF_rvPJXfix4eRc0CdeARCiYx4SJHzz8IzDEkCZwdy9zcpfufGphEfM3Pixey00xT5v0pACNMhvfBFD4-jY26iZbjMdiXr9hLlH1-GkOzkuNartjNiCN-vms3ris4Ywau3POuSoKCfmxLCzGORCw5t2K7AhQ85dVb6b8dqqcXD4-LsNOxgYWfGD4r064X1ZEOzhVZBBmttp0dipuV84ZQnc6gkc7AugipBYGv_T-UMsU8jyw99Y-hPCx0ZpQRB97T_LZz9yVqDqPGFFM1-72RMhJK6yK_smFXvd8rTXuKFewRhaRNa0I5ezBTcxm--DoHjBmyOycrd9O_3NddIMoVAXGQt9IS6QmoHyJGxF2rMFXlAidew2Ws_BojU6XSRBbRh91o-y5oZ94PvviDqxI6DtJFZpKNrNKBwlbUregs8cmHsZiTj3MgplzDJOf02aygRJ8is-XvQB--UWS4lMLrUIV7c40BlpsTuC2KDQUPx-LKcoUG0TqGcqG4bj2T4uzxr9oY5ZH5n8YSW2ZVnVXhvh-CyP-uVdfRULx9ZCBDGT4QD4h_r5dw1rSU72_XBCDzVGcWOEGx1Rfnm3v4uyjHCr0NZQtznOWf1-gBdQ_4GhUsiJsU8Wdev6J7Ul3733hm8o78I7GSbfr1rRtT9_UjX7cmrViHMPZr5uzGge7y4EAMf-bV6gse91mx_0z-sCriEjr8Ull7rsQedN5hlTbuDOHkc_jVp0jvcK7vlGVtJmSfsUZeMrGKxqGKkEYzb3Xn4OweYiCwGhx1ATCV-xAPTBHAGtyMX4e47Q.YEBU6-rJ4Ah-VZXWpoXirCIynU_JT2Ox5UMvD1CZnV1y7MuCib2uKFmwymSnk2iJe5FY4CfG-4AIK9Di4l9n82viNxRvcXh5mKD6wOd4xvh92N3_odYry72HXe6PtJa42gp5zdTDgoLkyXmJkyO04oguyuUhvbDK7VDoJQmAolCOG4IOM7LqvrvKRPs34uzFUrMlko0dLOCgECTT1XvzIigEb23HNQpOBJybwHw6zcpfkvNH-Lqa-70qbo9Rkjb3G9A9hb1G_IojZie3vaYGmwVKNwXKg9Y7p7wzgrnwWEyDKt1JdoMcVCXho7bvx-SpAGgdqWWMR11zDtR5OR4e8g",
    "refresh_token_expires_in":28799,
    "scope":"openid",
    "id_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IlFsOVdvTDVNQ1FCZTdlSzZjdjc4T2RLTzFpMCIsImtpZCI6IlFsOVdvTDVNQ1FCZTdlSzZjdjc4T2RLTzFpMCJ9.eyJhdWQiOiJhODI0ODg1Yi1jNWQ5LTRkM2EtYjY5YS03Yzg5NmI4MGFmOGQiLCJpc3MiOiJodHRwczovL3RwMy5hZGZzMjAubmV0L2FkZnMiLCJpYXQiOjE0NDMyNTY4MDYsImV4cCI6MTQ0MzI2MDQwNiwiYXV0aF90aW1lIjoxNDQzMjU2ODA2LCJzdWIiOiJqOG0xRkFPeFVYTll4WnFkczBiRU1kb0wzWDJtNktwUDZaS3h6VlBhbjZNPSIsInVwbiI6Im5mdWppZUB0cDMuYWRmczIwLm5ldCIsInVuaXF1ZV9uYW1lIjoiVFAzXFxuZnVqaWUiLCJwd2RfZXhwIjoiNTE5ODk5In0.iCRZlDKci_QxsCEY-m_AwKeZCO1wj95SRSZNyxslaQheMt2oOG9gh8cueFBowOeGRxg76vUbjqt8qIpH5JkV1iFBevTLmD8m_JggTdkL_n2WO-zGzVLKV48li6zL2y2VnakNwgERKaH9ccv_A3p81oPZf9coPJtphA0Z8CjM5xMTOJNpK3Oi_E7PtSw0ft8s1WBPKvA-TEvDqRVbiBwTuucazjF4rDdoIvAAMvr2PZfP3Rz-DzdEfprN7DLrKGtawQIzr3G2vhYIKaCZjC4kX4ys-MBK7dVJKZ4w2fT86iYVrOrkem6e4OCCiZFhgbDKLoo9y5VZAYt5eYoVDzNDvQ"
}



ん?なぜかscopeがopenidのみになってしまっていますね。。。
いやな予感しかしません。


◆UserInfoエンドポイントへアクセスする

取得したアクセストークンをAuthorizationヘッダに入れてGETします。
https://adfs.example.com/adfs/userinfo
    Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IlFsOVdvTDVNQ1FCZTdlSzZjdjc4T2RLTzFpMCJ9.eyJhdWQiOiJ1cm46bWljcm9zb2Z0OnVzZXJpbmZvIiwiaXNzIjoiaHR0cDovL3RwMy5hZGZzMjAubmV0L2FkZnMvc2VydmljZXMvdHJ1c3QiLCJpYXQiOjE0NDMyNTY4MDYsImV4cCI6MTQ0MzI2MDQwNiwiYXBwdHlwZSI6IkNvbmZpZGVudGlhbCIsImFwcGlkIjoiYTgyNDg4NWItYzVkOS00ZDNhLWI2OWEtN2M4OTZiODBhZjhkIiwiYXV0aG1ldGhvZCI6InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphYzpjbGFzc2VzOlBhc3N3b3JkUHJvdGVjdGVkVHJhbnNwb3J0IiwiYXV0aF90aW1lIjoiMjAxNS0wOS0yNlQwODo0MDowNi41NjRaIiwidmVyIjoiMS4wIiwic2NwIjoib3BlbmlkIiwic3ViIjoiajhtMUZBT3hVWE5ZeFpxZHMwYkVNZG9MM1gybTZLcFA2Wkt4elZQYW42TT0ifQ.fNmEOEARGbWURRoRazcW36jgtw0a3h4i7Z5--UC9nLB0mFFjZVxcJe4-1hhaCQExn04oUD9-HXXI4BFKkbctWNJJKUo8kT4kAn_Uj8J10INYUAJA5veKis1MdUIZ7glpEfMzEvzjrTGnMhN4v4y_CEzziU0LB1nGogozOkDOD3Y6gfaUJbrOv4V8lbmjm9cuMNDRs6ZEwGf5aqc2ChAbWw2icqW3XBwTnUR_X0je2LKmwjcljY145-fybEgUbFANbAnSSC8WOcS-KGOKzlqIbf3AxQ1PaetMGAb02N25KM36b24I9yzDPDs8EmKgL4mSfjTPHxnUWCu7UB4wMcfvIw


やはりsubしか返ってきません。profileとかemailがscopeから消えてしまっているからですかね。。
{"sub":"j8m1FAOxUXNYxZqds0bEMdoL3X2m6KpP6ZKxzVPan6M="}



AD FSの管理コンソールから定義されているscope一覧を見るとちゃんとprofileやemailもあるんですけどね。


まだTechnical Preview版なので、こんなものなのかも知れません。今後の進化に期待ですね。

2015年8月24日月曜日

[告知]9月はイベント三昧。ID&IT Management ConferenceとJapan SharePoint Group

こんにちは、富士榮です。

9月にある2つのイベントに登壇することになったので、告知です。

1.ID&IT Management Conference 2015

世界3大アイデンティティ・イベントの一つである「ID&IT Management Conference」が9月18日に開催されます。今年で5回目になるんですね。

私もなんだかんだでほぼ毎年関わらせていただいているんですが、今年もパネル・セッションにパネリストとして参加させていただきます。

私は「エンタープライズIDの正しい捉え方、活用方法」というセッションでNTTデータの山田さん、NIIの中村先生、エクスジェンの江川さんと一緒にパネルディスカッションをする予定です。社内管理部門、学認、パッケージ、SIerという複数の立場からエンタープライズにおけるアイデンティティのあり方みたいな話ができると思います。

以下、セッション概要(イベントページより引用)です。
エンタープライズIDの正しい捉え方、活用方法 (パネルセッション)
認証基盤システム整備のための予算を確保するのに苦労する組織は、大変多いのではないでしょうか。
これは認証基盤整備が、セキュリティ確保や内部統制を主目的とし、また既に稼働中の基盤システムに対する再構築である場合が多く、利益増を主目的とする企業にとっては優先課題にはなりづらいからではないでしょうか。
IDを適切に運用、管理することで実現される理想像を描けているにも関わらず、我々には乗り越えないといけない様々な現実的な(技術論ではない)問題が多くあります。大規模認証基盤システム構築事例を元に、パネリストがそれぞれの立場から、様々な壁を乗り越える策を議論します。

以下のURLから申し込みが可能なので、お早めに!
 http://nosurrender.jp/idit2015/index.html



2.Japan SharePoint Group

2つ目はこれまでもたまにお手伝いさせていただいておりますMVP山崎さんが主宰しているJapan SharePoint Groupで9月12日に開催されます。こちらも20回目の開催になるんですね。

同日にSystem Center User Group Japanが品川で開催され、そちらがActive Directory特集ということなので、スピーカー不足ということで招集がかかりましたw

SharePointグループということでどちらかというと情報系アプリケーションの開発者の方や社内管理者の方が多く参加されると思いますので、テクニカルというよりもハイブリッドな認証/ID管理基盤の基礎的な話、プロジェクトの進め方、Windows 10のAzure AD Joinなんかの話が出来ればいいかな、と考えています。

こちらも以下のURLから申し込みが可能です。
 http://jpsps.com/event/20150912/

時間的に国井さんのセッションとダダ被りですね。。。。

2015年8月22日土曜日

[AD FS]OpenID Connectに対応した次期AD FSを試す

こんにちは、富士榮です。

先日3回目のTechnical Previewが公開された次期Windows ServerであるWindows Server 2016のActive Directory Federation Services(AD FS)はOpenID Connectに対応しています。
実は前回のTechnical Preview 2からOpenID Connectには対応しており、すでに色々と試してあったのですが、情報をまとめる暇がなくblogに投稿していなかったのですが、とりあえず新しいPreviewも出たので、軽く動作確認をした結果を公開したいと思います。

参考)
 [AD FS]Windows Server Technical Preview 2のAD FSファーストレビュー(管理GUI編)
  http://idmlab.eidentity.jp/2015/05/ad-fswindows-server-technical-preview.html


尚、インストール方法やASP.NETアプリケーションでの動作についてはVittorioがまとめているのでそちらも参考にしてみてください。
 OpenId Connect Web Sign On with ADFS in Windows Server 2016 TP3
  http://www.cloudidentity.com/blog/2015/08/21/OPENID-CONNECT-WEB-SIGN-ON-WITH-ADFS-IN-WINDOWS-SERVER-2016-TP3/


今回はとりあえずの動作確認ということで先日Azure Active Directory(Azure AD)のApp Model v2.0の紹介をした際に使ったphpアプリケーションをそのまま使います。

 [Azure AD]App Model v2.0を利用して組織内外共用のアプリケーションを開発する
  http://idmlab.eidentity.jp/2015/08/azure-adapp-model-v20.html


では、早速試してみます。


◆AD FSへアプリケーションを登録する

新しいAD FSではアプリケーション登録をGUIからできるようになっています。(Windows Server 2012 R2ではOAuthクライアントはPowerShellのコマンドレットからしか登録できませんでしたので、とっても便利です)

新しいメニューとしてApplication Groupsという項目が出来ているので、ここにアプリケーションを登録します。


任意の名前を付けてアプリケーションの種類を選択します。
今回はWebアプリケーションなので、「Server application or Website」を選択します。


client_idが生成されるのでメモしておきます。
また、redirect_uriにこれから作成するアプリケーションのURLを登録しておきます。


次のページでGenerate a shared secretにチェックを入れるとclient_secretが生成されるので、こちらの値もメモしておきます。


後はウィザードを先に進めればアプリケーションの登録は完了です。


◆アプリケーションにAD FSの情報を登録する

次はアプリケーション側にAD FSのエンドポイントの情報や先ほどのclient_id/client_secretを登録していきます。

まず、authorizeおよびtokenエンドポイントを確認するために、.well-known/openid-configurationにアクセスしてみます。
rootにあるべき.well-knownが/adfs以下にあるのは微妙ですが、以下のようなURLになっています。(Technical Preview 2の時にフィードバックしたんですが結局治らないんでしょうねぇ)

 https://adfs.example.com/adfs/.well-known/openid-configuration

{
  "issuer":"https://adfs.example.com/adfs",
  "authorization_endpoint":"https://adfs.example.com/adfs/oauth2/authorize/",
  "token_endpoint":"https://adfs.example.com/adfs/oauth2/token/",
  "jwks_uri":"https://adfs.example.com/adfs/discovery/keys",
  "token_endpoint_auth_methods_supported":
  [
    "client_secret_post",
    "client_secret_basic",
    "private_key_jwt",
    "windows_client_authentication"
  ],
  "response_types_supported":
  [
    "code",
    "id_token",
    "code id_token",
    "token id_token"
  ],
  "response_modes_supported":
  [
    "query",
    "fragment",
    "form_post"
  ],
    "grant_types_supported":
  [
    "authorization_code",
    "refresh_token",
    "client_credentials",
    "urn:ietf:params:oauth:grant-type:jwt-bearer",
    "implicit",
    "password",
    "srv_challenge"
  ],
  "subject_types_supported":
  [
    "pairwise"
  ],
  "scopes_supported":
  [
    "openid",
    "profile",
    "email",
    "logon_cert",
    "aza",
    "vpn_cert",
    "user_impersonation"
  ],
  "id_token_signing_alg_values_supported":
  [
    "RS256"
  ],
  "token_endpoint_auth_signing_alg_values_supported":
  [
    "RS256"
  ],
  "access_token_issuer":"http://adfs.example.com/adfs/services/trust",
  "claims_supported":
  [
    "aud",
    "iss",
    "iat",
    "exp",
    "auth_time",
    "nonce",
    "at_hash",
    "c_hash",
    "sub",
    "upn",
    "unique_name",
    "pwd_url",
    "pwd_exp"
  ],
  "microsoft_multi_refresh_token":true,
  "userinfo_endpoint":"https://adfs.example.com/adfs/userinfo"
}


これを見ると、
Authorizeエンドポイントは
 https://adfs.example.com/adfs/oauth2/authorize/
Tokenエンドポイントは
 https://adfs.example.com/adfs/oauth2/token/
であることがわかります。


この情報を前回作ったphpアプリケーションに設定します。


これで準備は完了です。


◆動作確認

早速、アプリケーションにアクセスしてみます。
すると、AD FSのログイン画面に飛ばされますので、ログインします。


ログインに成功するとid_tokenがアプリケーションにわたるので、前回と同じくClaimとValueが取得できます。




いかがでしょうか?
Discoveryの課題はあるものの、かなり手軽に自前のOpenID Provider(OP)を立てることが出来るようになったと思うので、今後はテスト用のOPとしても使えるかも知れませんね。

2015年7月23日木曜日

[AzureAD/RemoteApp]AzureADでRemoteAppのアクセス制御を行う

こんにちは、富士榮です。

Azure RemoteAppはいわゆるクラウド上でホストされるVDIサービスで、これを使うとiOSやAndroidを含む組織外のデバイスを使って企業内で使ってきたデスクトップアプリケーションを利用できるようになります。

 詳しくはこのあたりで。
  Microsoft RemoteAppで何ができるの?
  http://www.atmarkit.co.jp/ait/articles/1405/15/news035.html


Azure RemoteAppを利用する際は、Azure Active Directory(Azure AD)を使って認証をすることになるので、多要素認証やアクセスルールを使った制御、さらにActive Directory Federation Services(AD FS)の多要素認証機能やDevice Registration Servie(DRS)と連携したハイブリッドID基盤を構成することでクライアント証明書がインストールされている端末のみアクセスを許可する、など細かなデバイス制御を行うことも可能になります。

と、言うことで今回は先月末に公開されたAzure ADのアクセスルールを使ったアクセス制御を試してみます。

 Active Directory Team Blog
  Azure AD Conditional Access preview update: More apps and blocking access for users not at work
  http://blogs.technet.com/b/ad/archive/2015/06/25/azure-ad-conditional-access-preview-update-more-apps-and-blocking-access-for-users-not-at-work.aspx


◆RemoteAppのセットアップ

 ここはバッサリと省きますが、管理ポータルからRemoteAppコレクションを作ります。今回は素のOSイメージでよかったのでWindows Server 2012R2のテンプレートを使いました。実運用ではAzure VMやHyper-V上に実際の業務アプリケーションをインストールしてsysprepしてカスタムテンプレートを作ります。


 それなりに時間がかかりますが、セットアップが終わるとデフォルトでいくつかアプリケーションが発行されています。



◆ユーザの割り当て

 実際にRemoteAppを利用するユーザを割り当てます。割り当て可能なユーザはAzure ADのディレクトリに登録されているユーザです。
 ※ここがグループベースで割り当てできるようになると良いんですけどねぇ。。。





◆まずはそのまま利用する

 ここまででRemoteAppとしては設定が終わりなので、まずは素の状態で使ってみます。

 PCからだとRemoteAppクライアントは以下のURLからダウンロード出来るので、あらかじめダウンロード・インストールしておきます。

 https://www.remoteapp.windowsazure.com/

 ※ちなみにiOS/AndroidではRemote DesktopアプリケーションからRemoteAppを使えます。
 iOS版:
  https://itunes.apple.com/jp/app/microsoft-rimoto-desukutoppu/id714464092?mt=8
 Android版:
  https://play.google.com/store/apps/details?id=com.microsoft.rdc.android&hl=ja


 起動~開始するとAzure ADのログイン画面になるのでログインします。


 ログインに成功するとアプリケーション一覧が表示され、利用できます。




◆アクセス制御をかける

 いよいよ本題です。
 RemoteAppを構成した段階でAzure ADディレクトリの中のアプリケーション一覧にRemoteAppが追加されます。AzureADから見ると管理対象のアプリケーション(サービス)という扱いになっているんですね。


 早速RemoteAppアプリケーションを開き、構成メニューを見るとお馴染みのアクセス・ルールが構成できます。

 ここでは以前紹介したのと同じように社外からのアクセスだったら多要素認証を要求する、というルールを入れてみます。

 参考)
 [AzureAD]アクセスルールで社外からのアクセスを制御する
 http://idmlab.eidentity.jp/2015/06/azuread.html


 構成後、同じようにRemoteAppを立ち上げてみると多要素認証を要求されるようになります。


 また、この際、社外からのアクセスをブロックするように設定するとエラーメッセージが出てアクセスに失敗します。
 メッセージとしては普通にWebアプリケーションへSSOする時よりも親切なメッセージになっている気がします。



 ちなみにiOS版のRemoteDesktopからだと右上の+メニューよりAzure RemoteAppが追加できます。


 ログオンUIはPCとほぼ同じですね。


 アプリケーション一覧もこんな感じです。



 ただ、アプリを起動するとちょっと寂しいです。





いかがでしょうか?
今回は単純にAzure AD側でアクセス制御をしてみましたが、AD FSと組み合わせるともっと柔軟に制御ができるようになるので、おいおい試してみたいと思います。

2015年6月25日木曜日

[AzureAD]AAD ConnectとConnect HealthがGAになりました

ついにAzure AD ConnectとConnect Healthが一般公開されました。

公式blog)Azure AD Connect & Connect Health is now GA!
 http://blogs.technet.com/b/ad/archive/2015/06/24/azure-ad-connect-amp-connect-health-is-now-ga.aspx

それぞれを一言で紹介すると以下の通りとなります。
モジュール解説主な機能
Azure AD ConnectAzure ADとオンプレミスADのハイブリッド構成(SSO、ID同期)を構成するためのツール群AD FS/AAD Syncの簡単設定機能
マルチフォレストAD連携、非ADのオンプレミスIdPとのID同期
Connect HealthAD FSのモニタリングツールリクエスト数、ログインエラー数などのモニタリングとグラフィカル表示


今回はAAD Connectの方を中心に紹介したいと思います。


◆AAD ConnectのリリースによりDirSyncおよびAAD Syncの個別リリースが終了

重要なポイントですがAAD Connectがリリースされたことにより、DirSyncおよびAAD Syncについては今後個別のモジュールとしてリリースされることはありません。今後はAAD Connectの更新として提供されることとなります。

Azure AD Connect incorporates the components and functionality previously released as Dirsync and AAD Sync. These tools are no longer being released individually, and all future improvements will be included in updates to Azure AD Connect, so that you always know where to get the most current functionality.

出典)https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-learn-more/


◆AAD ConnectではActive Directory以外のIDストアもサポート

現状ではまだExpress Settings(簡単設定)を行うためにはActive Directoryが存在する環境でしかAAD Connectの設定はできませんが、今後はActive Directory以外のIDストアをベースにAzure ADと同期を行うことができるようになると思われます。

Ignite 2015のセッションスライド。他のIDストアとの接続が明示されている。



ドメイン参加していないサーバにAAD ConnectをセットアップしようとするとExpress Settingsは使えないもののセットアップ・ウィザードは先に進められる。



オンプレミスのIDストアの設定にDirectory Typeというプルダウンが存在する。(現在はActive Directoryしか選択できないが)



Synchronization Managerの初期状態で管理エージェントとして以下の3種類が選択できる。

  • Active Directory Domain Service
  • Azure Active Directory
  • Extensible Connectivity 2.0(ECMA2.0)





◆その他

ウィザードの最後にドメイン参加したWindows 10のデバイスの情報をAzure ADと同期するためのオプションについての記載もあり、今後のハイブリッドシナリオの拡張を予感させます。



今後はこのツールがAzure ADとのハイブリッドシナリオでは主役となるはずなので、他の拡張要素についても今後紹介していこうと思います。
しかし一昔前に比べてものすごく簡単にセットアップができるようになったもんです・・・。

2015年6月20日土曜日

[IdM全般]トレーニングコンテンツ色々/プロジェクトの進め方~モバイルデバイス管理~開発まで

最近のポストで2回ほど紹介したMicrosoft Virtual Academy(MVA)というオンライントレーニングコースですが、その後もアイデンティティ関連のコースを探索していたら何個か面白いものが出てきたので紹介したいと思います。

参考)これまで紹介したポスト
[IdM全般]アイデンティティ管理プロジェクトに必要なスキル(Active Directory/Azure AD編)
[AzureAD]入門コンテンツ - クラウド時代のActive Directory次の一手シリーズ



今回紹介させて頂くコンテンツの一つ目は「ID とアクセス管理の全体像」シリーズです。

基本はMicrosoft Conference 2014の中のセキュリティ~ID管理系のコンテンツを集めたシリーズになっており、以下の6つのコンテンツ+セットアップ手順書のセットになっています。
  • 基本から見直すセキュリティ~標的型攻撃の実態と取り組むべきセキュリティ対策~
  • Dynamic Identity Framework~クラウド時代適応のためのID管理手法~
  • ハイブリッドな認証基盤で生産性を高めるために必要な基礎知識
  • モバイルの企業活用を支えるデバイス統合管理ソリューション
  • Azure Rights Managementによる社外ユーザーとのセキュアのコンテンツ共有の実現
  • 多要素認証Deep Dive~ハイブリッド認証基盤だからこそ実現できる柔軟で高機能な多要素認証~

特に2つ目のDynamic Identity Framework(DIF)のセッションでは実際のコンサルティングプロジェクトで企業のID管理の現状分析と課題の洗い出しを行う方法論について語られているのでプロジェクトにかかわる方には参考になるかもしれません。

もちろんそのような方には、JNSAのアイデンティティ管理WGの出している「改訂版クラウド環境におけるアイデンティティ管理ガイドライン」もあわせておすすめです。(宣伝)



二つ目に紹介するMVAコンテンツはAndroid / iOSのようなモバイルデバイスを管理するためのソリューションセット「Enterprise Mobility Suite(EMS)」に関する「Taming Android and iOS with Enterprise Mobility Suite」というコンテンツです。
URL:http://goo.gl/8IOhcm

基礎的な部分からAndroid / iOSそれぞれについての具体的な仕組みや設定についてデモを交えて紹介しています。


最後は開発系コンテンツの「Customizing ASP.NET Authentication with Identity」です。
URL:http://goo.gl/t95rEu

OAuth/ソーシャルアイデンティティ連携から多要素認証まで、ASP.NET Identityでどうやって実装するのか、具体的な実装方法に関する紹介をしています。


私を含めBlogやTechnet / MSDNなどだと都度都度情報が分散してしまっているので、こういう形でまとめてあると基礎から勉強しなおすにはいいですね。


2015年6月19日金曜日

[AzureAD]アクセスルールで社外からのアクセスを制御する

※現在Public Previewとして提供されている機能なので、今後の機能変更などが発生する可能性があります。

Office365やGoogleApps等のSaaSアプリケーションのメリットはどこからでも(社内からも、社外からも)アクセスできるところにあります。
ただ、企業の情報システム部門としてはいつでも、どこでもアクセス出来るからと言って、自宅のPCやネットカフェなどの安全ではない端末からIDとパスワードだけでアクセスされるのはちょっと、、ということもあり、オンプレミスのAD FSなどと組み合わせて信頼できるネットワークからのみのアクセス出来るようにしたり、多要素認証を強制したり、と安全性を何とか確保しようと日々努力をしています。

たとえば以下のような方式です。
・社内ネットワークからしかアクセス出来ないようにする
 方法1:VPNで社内ネットワークへ参加しないとAD FSに到達できないように構成する
 方法2:AD FSのクレーム・ルールを書いてクライアントIPによって承認を制御する 
・社内ネットワーク以外からのアクセスであれば多要素認証を要求する
 方法1:AD FSの多要素認証を構成し、社外ネットワークの場合の認証ポリシーを構成する

これまで、これらの方法はいずれもAD FSが必要でしたが今回紹介するアクセスルールを使うとAzure Active Directory(Azure AD)だけで実装ができるようになるので、より手軽に実装が可能になります。

ちなみに話はそれますが、個人的にはAD FSとWeb Application Proxy(WAP)を使って社内のIdPをDMZに配置してインターネットからでも利用できるようにするくらいなら、素直にAzure ADで認証をしてしまった方が良いと考えています。セキュリティの専門家を自社に抱えていて、DMZのIdPを守る努力を日々継続的に実行できるなら話は別ですが、なかなかあることではないので、Azure ADなりOktaなりの外部のIDaaSに任せてしまった方が安全なのではないかと思います。(さらに多要素認証を使えばより強固になりますし)
この辺りはまた別の機会に書いていこうと思います。


本題に戻ります。

現在、Azure ADのアプリケーション・アクセスルールで出来ることは以下の通りです。

アプリケーション単位で、
・必ず多要素認証を要求する
・社外からのアクセスなら多要素認証を要求する
・社外からのアクセスをブロックする
ことができる。
その際、
・ルール適用対象のグループ
・ルール適用除外のグループ
を設定することができる。


では早速やってみたいと思います。

今回、テスト用アプリケーションにはGoogle Appsを利用し、多要素認証のON/OFF、ルール適用除外グループへの参加/不参加、社内/社外からのアクセスの各パターンでの挙動を確認します。
(ちなみに必ず多要素認証を要求する、というルールは単純すぎるので除外しています。単に多要素認証が要求されるだけなので)

初めに書いてしまいますが、結果は以下の表のようになります。
※External Usersというグループについてルールの適用を除外するように設定をしています。
ルールアクセス元所属グループ多要素認証結果
作業中でない場合、多要素認証が必要です
- 除外:External Users
社内ネットワークExternal UsersYesOK
NoOK
Google UsersYesOK
NoOK
社外ネットワークExternal UsersYesOK
NoOK
Google UsersYesOK
NoNG
※多要素認証設定が要求される
作業中でない場合、アクセスをブロック
- 除外:External Users
社内ネットワークExternal UsersYesOK
NoOK
Google UsersYesOK
NoOK
社外ネットワークExternal UsersYesOK
NoOK
Google UsersYesNG
NoNG



では、順番に行きます。
まずは、「作業中でない場合、多要素認証が必要です」というルールを使います。
※「作業中=社内ネットワークからのアクセス」ととらえてください。翻訳・・・


社内ネットワークの定義は多要素認証プロバイダの管理コンソールで行います。



まずは多要素認証が設定されているユーザでアクセスします。


当然ですが、社内からでも社外からでもアプリケーションが利用できます。


次に、多要素認証が設定されていないユーザで社内ネットワークからアクセスしてみます。
こちらも当然問題ありません。

一方で同じユーザを使って社外ネットワークからアクセスしてみます。
今回は多要素認証が必要となるので、ログオン時に多要素認証のセットアップを要求されます。


ただ、この同じユーザを除外対象のグループ(External Users)へ参加させて再度アクセスすると今度は問題なくアプリケーションが利用できます。


次に、「作業中でない場合、アクセスをブロック」というルールを使います。



ルールに適合するケースは単にアクセス出来てしまうだけなので、条件に適合しない場合の挙動を確認します。
除外対象グループメンバに所属していないユーザが、社外からアクセスした場合が該当しますので試してみます。



見事にブロックされました。
エラーメッセージをよく見ると、「User account 'アカウント名' does not satisfy Access Policy」とある通り、アクセス条件を満たさなかったのでエラーが出ていることがわかります。

内勤の人など、業務上に社外からアクセスする必要がない人についてはこのようなルールを適用して安全にアプリケーションを使う、というのも良いシナリオかも知れませんね。