2017年7月13日木曜日

「ID管理システム導入における現状把握チェックリスト」が公開されました

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

JNSA(日本ネットワークセキュリティ協会)のアイデンティティ管理ワーキンググループで一昨年~昨年と分科会リーダーとして取りまとめて来た「ID管理システム導入における現状把握チェックリスト」が公開されました。

 こちらからダウンロードできます。
 http://www.jnsa.org/result/2017/std_idm/index.html

主にID管理システムの導入を企画する段階でエンドユーザ企業と導入ベンダやコンサルとの間に発生しやすいギャップを埋めることを目的として作成したツールで、様々な観点で企業内の現状把握をどのような観点で行うか、をチェックリスト形式で取りまとめました。

本来は、どこまで出来ていれば良いか?という基準・水準も設定できるのがゴールなのですが、まず今回リリースした第1版では現状把握を行うための観点、項目をとりまとめています。

Excelシート上で各項目を評価していくと、グラフを作成することが出来るので、現状把握の度合を可視化することが出来ます。


是非一度試して頂き、フィードバックを頂ければと思いますのでよろしくお願いいたします!



2017年6月30日金曜日

[Office365]Azure AD Connectの脆弱性?と最新版へ更新後の運用上の変化点

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

先日、Azure AD Connectに関するセキュリティ・アドバイザリが発表され、脆弱性対応版として最新版がリリースされました。
脆弱性対応のためとはいえ、一部ヘルプデスク運用が変わってくるので、Office365やAzure ADの管理者の方は十分に注意して運用マニュアルの修正などを行う必要があります。

 セキュリティ・アドバイザリ 4033453
  Azure AD Connect の脆弱性により特権が昇格される
  https://technet.microsoft.com/ja-jp/library/security/4033453

 最新ビルド(1.1.553.0)
  https://www.microsoft.com/en-us/download/details.aspx?id=47594

しかし、発表された内容を見ていると、どちらかというと脆弱性というよりも単に不適切な運用をしているだけじゃ、、、という話なので内容を解説してみたいと思います。

また、アドバイザリの中では対応策として、最新ビルドにバージョンアップすることが推奨されていますが、単にバージョンアップしただけでは環境によっては不具合が出ることもあるので、その辺りも解説しておきます。

最後に、Azure AD Connectの話としてアドバイザリが出ていますが、構成によってはFIM(Forefront Identity Manager)/MIM(Microsoft Identity Manager)にも当てはまる内容なので、FIM/MIMを使っている場合の構成の見直しポイントも簡単に。

◆脆弱性?の概要

簡単に言うと、パスワード書き戻しが有効になっているテナントにおいて、同期元のローカルActive Directory上で管理者権限を持っているユーザのパスワードをAzure ADやOffice 365上でリセットすると当然の事ながらローカルActive Directory上の管理者権限を持ったユーザのパスワードもリセットされてしまうので、悪意のあるAzure AD管理者がクラウド上でパスワードリセットを行うことによりローカルActive Directoryの管理者権限の奪取が可能になってしまう、という話です。

色々と前提があるので整理をしておきましょう。

  • 環境
    • パスワード書き戻しが有効になっていること
    • 管理者権限のあるユーザをAzure ADへ同期していること
    • 同期を実行しているユーザに特権ユーザに対するパスワードリセットの権限を付与していること(以下が典型的なケースです)
      • Domain AdminsやEnterprise Adminsのメンバにしている
      • 同期対象のOUの管理権限を同期ユーザへ委譲し、AdminSDHolderコンテナにパスワードリセット権限を付与している
  • 脆弱性利用者
    • 悪意のある管理者。オンプレミスのリソース(AD配下)へアクセスが可能なこと

※AdminSDHolerの話は国井さんのブログ記事を参照してください。
 

こうやって見ていくと当たり前すぎて、製品の不具合というより構成の問題という気がしてきます。
基本的に同期対象となっているOUに管理者権限を持ったユーザが存在するのは、、、ということです。同期してOffice365にログインするユーザなのであれば、恒常的にローカルActive Directoryの管理者権限を与える必要もないはずですし。

◆実際どうなるのか?

では、管理者権限を持ったローカルActive Directory上のユーザをAzure Active Directoryへ同期させてみて、パスワード・リセットをしてみます。

まずは、同期されたユーザ自身によるパスワード変更のパターンです。
アクセスパネルのプロフィール変更画面よりパスワードを変更します。

当然ですが、パスワードがオンプレミスに書き戻され、新しいパスワードでログインできるようになります。(試しにリモートデスクトップしてみるとちゃんとログインできます。当たり前ですが)


次に、SSPR(セルフ・サービス・パスワード・リセット)のシナリオを見てみます。いわゆる秘密の質問や認証用電話・メールなどを使ってパスワードを忘れた際に回復する、というシナリオです。
ログイン画面からパスワード忘れの場合のリンクをクリックすると回復画面に遷移するので、CAPTCHAを入力します。

秘密の質問への回答をします。


無事にパスワードがリセットされ、ローカルActive Directoryへパスワードが書き戻されます。

悪意のあるユーザが秘密の質問を推測してしまうケースは結構あるそうなので、第3者によってパスワードのリセットがされ、ローカル管理者の権限が奪取される、ということもあり得ますね。


最後に、管理者によるリセットです。
Azure AD Portalからユーザを選んでパスワードをリセットするやつですね。

これも管理者がリセットを行い、一時パスワードが割り当てられた段階でローカルActive Directoryのパスワードも変更されるので、一時パスワードでローカルリソースへアクセスできてしまいます。

そう、パスワード書き戻しの機能を普通に使っているだけです。
単に対象となっているユーザの中に管理者権限を持っているユーザが存在しただけです。

これが脆弱性なのか、と・・・。


◆Azure AD Connectのバージョンアップと注意点

どのみち、今後のバージョンのAzure AD Connectにはこの改修が入ってしまうので、仕方がないので対応版である1.1.553.0へバージョンアップします。

バージョンアップによる具体的な変更内容は、アドバイザリのサイトにもあるように以下の2点です。

  • 対象ユーザのadminCount属性の値を見てNullもしくは0なら一般ユーザとみなし、パスワード書き戻しを許可する
  • 対象ユーザが特権ユーザだった場合、パスワードリセットを要求したAzure ADユーザが、対象ユーザと同じユーザだった場合は書き戻す(メタバース上で要求したユーザと対象ユーザの関係を確認する)
    • この部分が原文・翻訳ともにものすごくわかりにくいです。
      • 日本語「要求したユーザーが対象のオンプレミス AD アカウントのオーナーであるかどうかを検証します。それは、対象のオンプレミス AD アカウントと、要求したユーザーの Azure AD アカウントの関係をメタバースで確認します。要求したユーザーがオーナーの場合、Azure AD Connect はパスワード ライトバック要求を許可します。そうではない場合、要求は拒否されます」
      • 原文「it then validates whether the requesting user is the owner of the target on-premises AD account. It does so by checking the relationship between the target on-premises AD account and the Azure AD account of the requesting user in its Metaverse. If the requesting user is indeed the owner, Azure AD Connect permits the Password writeback request. Otherwise, the request is rejected」
    • このオーナー(is the owner)というのが何を指すのか、が全く分からず、ローカルAD上のOUや対象ユーザのセキュリティ構成でオブジェクトのオーナーにしてみたり、と色々とやったのですが、結局オーナー=自身のアカウント、というオチだと思います。#違ったらご指摘ください。


早速バージョンアップを行います。


無事に1.1.553.0になりました。


この状態でユーザ自身でのパスワード変更をAzure AD側で行います。


ここは問題なく変更、書き戻しされます。

同様に自身によるパスワード・リマインドでも問題なく変更、書き戻しされます。

次に管理者によるリセットです。
見事に失敗します。

この時、イベントログには特権ユーザに対するパスワードリセットが拒否された旨、記録されます。
このAdminUpnとうのがリセットを要求した管理者ユーザ、そのあとのUserPrincipalNameが対象のユーザでこの2つのUPNが合致しないとリセット・書き戻しは行われません。


ちなみに、対象ユーザが一般ユーザの場合は従来通り問題なく管理者によるパスワード・リセットを行うことが可能です。

つまり、今後は運用を行う上で、ローカルActive Directory上で管理者権限を持っているユーザについては自分自身でしかパスワード・リセットが出来ない、ということになりますので、従来のヘルプデスク等の運用を変えなければなりません。
この点が最大の注意点です。


◆最後に。FIM/MIMユーザへ

今回「脆弱性」として取り上げられた仕組みは基本的にFIM/MIMにおいても同じですので、管理者権限を持つアカウントのパスワードを、悪意のある別の管理者がリセットすることが出来ます。これを製品の脆弱性や不具合と呼ぶのは微妙ですが、FIM/MIMにおいては今回Azure AD Connectが行った対応は入っていませんので、管理者権限を持つユーザについては自分自身でしかパスワードを更新できない様にMPRを工夫する、などの対応が必要となります。


2017年6月26日月曜日

[告知]CDATA API Serverローンチイベントとグローバル企業向けITセミナでIDの話をします

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

7月20日(木)と21日(金)に以下2つのセミナで登壇します。
いつも告知が直前すぎるので、今回は早めに告知させていただきます。

1.CDATA Day 2017
 日時  :7月20日(木)15:00~18:00
 申し込み:http://www.cdata.com/jp/events/cdataday17/
 タイトル:アイデンティティAPIとデータ統合プラットフォームの活用
 場所  :日本マイクロソフト株式会社 品川本社 セミナルーム

2.Enterprise IT seminar by professionals from global IT companies
 日時  :7月21日(金)14:30~17:00
 申し込み:https://www.xlsoft.com/jp/products/cdata/seminar.html
 タイトル:Designing cloud-based Identity and Access Management system for global enterprises
 場所  :エクセルソフト株式会社 セミナルーム


それぞれ簡単に内容を紹介します。

まずはCDATA Day 2017からですが、こちらはCDATA社のAPI Serverのローンチイベントということもあり、API Serverを使ってSCIMなどアイデンティティAPIを実装する話をします。(完全SCIM互換にするにはまだ若干機能不足はあるのですが、その部分は今後の期待ということで)
また、元々のCDATAの強みであるデータ統合基盤としてのアダプタの豊富さを利用してプロビジョニングを手軽に実装する方法なども考えられるので、その方面への活用についてもお話しできればと思っています。

先日ドイツで開催されたEuropean Identity & Cloud Conference 2017のKeynoteでOne IdentityのVPであるJackson Shawも話していましたが、現状各種アプリケーションのSCIMへの対応が中々進んでいない中で、ID管理製品側で専用のアダプタを開発するのではなく、データ統合プラットフォーム(クラウドベースのiPaaS/Integration Platform as a Serviceを含む)をID管理システムとターゲットシステムの間に挟む、という構成もあり得ると考えています。

こんな感じです。(出典:European Identity & Cloud Conference 2017 Keynote : When will Identity and Access Management be Digital Transformed – Jackson Shaw / VP One Identity)


この辺りを(できれば)デモを交えながら話せれば、と思います。


次に、翌21日(金)に行われるEnterprise IT Seminarです。
こちらは外資系企業のIT部門や日系企業で現地法人とやり取りをするIT部門の方々を対象として、セキュリティ、ERP/CRM、アプリケーション開発、データ統合の4つのテーマでグローバル・プロジェクトをどのように進めるか、という話があり、私はその中のセキュリティ、アイデンティティ管理のコマを受け持ちます。(全編英語です)

法令の違いはもちろんですが、全体最適に関する考え方のスケールがやはり日本企業の中だけで進めるプロジェクトとは違いますので、利用するツールやサービスの選定を含め色々と考えるべきことが多々あります。また、特にIDaaSの優位性が出やすい領域でもあるので、その辺りの割り切り方などについてもお話しできるといいかな、と思っています。


それでは。会場でお会いしましょう。

2017年6月19日月曜日

[Azure AD] PingAccess連携が正式リリース

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

遂にAzure ADとPingAccessとの連携機能が正式リリースされました。Public Preview公開から約3月で正式リリースされたので、かなり早いペースで出てきましたね。
やはり今週シカゴで開催されているCloud Identity Summit(PingIdentity主催)に合わせて来た、というところでしょう。

公式Blogでのアナウンス
 Ping Access for Azure AD is now Generally Available (GA)!
 https://blogs.technet.microsoft.com/enterprisemobility/2017/06/15/ping-access-for-azure-ad-is-now-generally-available-ga/

画像出典:公式blog

出来ることは、Azure AD Web Application Proxyを使ってPingAccessへの認証をAzure ADで行うことにより、PingAccess配下(リバプロ、エージェント)のアプリケーションへのシングルサインオンを実現する、というようなところです。

詳しくは以前紹介したこちらのポストを参照してください。
 [Azure AD]PingAccess連携でオンプレ資産へのアクセスを拡張する
 http://idmlab.eidentity.jp/2017/03/azure-adpingaccess.html

 [Azure AD+PingAccess]Basic認証のあるバックエンドサイトへアクセスする
 http://idmlab.eidentity.jp/2017/03/azure-adpingaccessbasic.html


2017年6月15日木曜日

[Azure AD/Windows 10]外部SAML IdPとID連携しているとAzure AD Joinできない

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

今回はかなり、レアかつマニアックな話です。
以前、Office365へOpenAMを使ってログインする方法を紹介しました。

 [Office365/AzureAD]OpenAMとのID連携①
 http://idmlab.eidentity.jp/2014/11/office365azureadopenamid.html


Azure ADは純正の外部IdPであるAD FS以外にもws-federationもしくはSAMLに対応した外部IdPとのフェデレーションもサポートしているので、OpenAMやPingFederateなどのサードパーティIdPでOffice365などAzure ADと連携されているアプリケーションへのログインが可能になる、という事です。

通常のWebアプリケーションであれば問題はないのですが、実はWindows 10のAzure AD Join(いわゆるWorkplace Joinではなく)を外部SAML IdPと連携したAzure ADで実行しようとすると問題が起きます。
(外部IdPがws-federationだと行けます。本国の方々と話をしていたんですが、あまりにもレアケースなので・・・という感じでした。まぁ、確かに。)

ということで、現状はAD FS以外の外部IdPと連携したAzure ADへのWindows 10デバイスの直接参加は不可能なので、もし将来的にAzure AD Joinを行う計画のある人は外部SAML IdPを使うのはやめておいた方が良いかも知れません。
注)AD FSを使う場合も正規の手続き(Convert-MsolDomainToFederated)以外を使った場合(Set-MsolDomainAuthenticationでプロトコルにSAMLを指定)は他の外部SAML IdPと同様にAzure AD Joinが出来なくなります。


では、どんなことが起きるのか、何が原因なのか、について少しだけ解説しておきます。

◆何が起きるのか?

[設定]からAzure ADへの参加を使用とすると「職場または学校のアカウント」の入力を求められます。


正規の手順で構成されたAD FSを使っている場合は、ユーザ名を入力して[次へ]をクリックすると組織のサインインページ(要はAD FSのログイン画面)へ遷移します。


しかし、その他の外部SAML IdPを使っている場合は以下の様に「組織のアカウントではない」と怒られてしまい、Azure AD Joinが出来ません。


◆何が起きているのか?

Azure ADへのサインインを行う際、入力したユーザがどこで認証されるべきか?をドメインパート(@より後ろ)を見て判別する、いういわゆるホームレルムディスカバリというプロセスが実行されます。これは、ブラウザシナリオでも今回のような非ブラウザシナリオでも同様です。

今回ブラウザシナリオでは外部IdPを使ってもログインできて、Azure AD Joinの場合だけダメなのか?はこのホームレルムディスカバリの方法と仕様が異なるためです。

ブラウザシナリオにおいては
 https://login.microsoftonline.com/common/userrealm
というエンドポイントにクエリパラメータに「user=ユーザ名」をつけたGETリクエストを行うのに対し、Azure AD Joinの場合は、
 https://login.microsoftonline.com/common/GetCredentialType
というエンドポイントにユーザ名の情報をPOSTします。
※ちなみにワークプレイスジョイン(組織アカウントの追加)の場合はブラウザシナリオと同じエンドポイントを使うので、外部SAML IdPを使っても問題なくサインインできます。

エンドポイントが異なるのと同様に返ってくるレスポンスも異なり、ブラウザシナリオでは、外部SAML IdPの種類にかかわらず、ちゃんと利用プロトコルと外部SAML IdPのURLを返してきますが、Azure AD Joinの場合は、外部SAML IdPのURLが返ってこず、ここでレルム探しが失敗、先のエラーメッセージが表示されています。

ブラウザシナリオでのレスポンスの例
{
  "NameSpaceType":"Federated",
  "federation_protocol":"SAML20",
  "Login":"hoge@example.net",
  "AuthURL":"https://idp.example.net",
  "DomainName":"example.net",
  "FederationBrandName":"eIdentity",
  "federation_saml_request":"xxxxx",
  "federation_saml_relay_state":"xxxxx",
  "cloud_instance_name":"microsoftonline.com"
  "TenantBrandingInfo":[{"xxxx"}]
}

Azure AD Joinのレスポンスの例(AD FSの場合)
{
  "Username":"hoge@example.net",
  "Display":"hoge@example.net",
  "IfExistsResult":0,
  "Credentials":{
    "PrefCredential":4,
    "HasPassword":true,
    "RemoteNgcParams":null,
    "FederationRedirectUrl":"https://fs.example.net/adfs/ls/?...omit...",
    "EstsProperties":{"xxx"},
    "apiCanary":"xxx"
  }
}

Azure AD Joinのレスポンスの例(外部SAML IdPの場合)
{
  "Username":"hoge@example.net",
  "Display":"hoge@example.net",
  "IfExistsResult":1,
  "Credentials":{
    "PrefCredential":1,
    "HasPassword":true,
    "RemoteNgcParams":null},
    "EstsProperties":{"xxx"},
    "apiCanary":"xxx"
   }
}

上記のように、外部SAML IdPを使っているとFederationRedirectUrlが返ってこないので、フェデレーション先にリダイレクトがされません。

どこかのタイミングでこの挙動も変わるかも知れませんが、取り合えず現状はAzure AD Joinの計画がある場合は、Azure ADだけでサインインするか、AD FSを含む外部ws-federation IdPとして使う、という2択になりそうです。

2017年5月13日土曜日

[Azure AD] Azure AD B2C に OIDC/SAML 対応の外部 IdP が設定可能に

こんにちは、富士榮@ミュンヘンです。

最近何かと熱い分野でもある CIAM(Consumer Identity and Access Management)ですが、今週ドイツ・ミュンヘンで開催された European Identity & Cloud Conference 2017(EIC)でも他のテーマである GDPR、PSD2 などプライバシー系の法令対応の話や 昨年のニューオリンズで開催された Cloud Identity Summit(CIS)でも大きな話題となった Blockchain による信頼できる Identity 基盤と VRM(Vendor Relationship Management)、Respect Network の文脈での Self Sovrin Identity などと並行して大きく取り上げられていました。

そんな中、平行して US で開催されていた Build ではマイクロソフトの CIAM の実装である Azure Active Directory B2C の大きなエンハンスが発表されました。

ポイントは、カスタムの外部 IdP として

  • OpenID Connect の OP をサポート
  • SAML 2.0 の IdP をサポート
したことです。

これまでは Microsoft Account、Facebook、Google、LinkedIn、Amazon.com、などメジャーなコンシューマ ID プロバイダが正式サポート、twitter や Weibo、QQ、WeChat が Preview として対応、という状況でしたが、OpenID Connect および SAML に対応したことで、自分の好きな ID プロバイダをカスタムで追加することが出来るようになりました。

公式なドキュメントでは OpenID Connect 対応の IdP として Azure AD、SAML 対応の ID プロバイダとして salesforce.com を例として構成例が解説されています。

公式ドキュメント

ガリガリと XML を書いてアップロードする必要があるなど、まだまだ手順が面倒なのですが、公式アナウンスでも次の数週間でもう少し簡単な実装方法に対応させる、とありますのでそちらに期待しましょう。

管理画面の Identity Experience Framework - Preview というものが皆さんの Azure AD B2C にも来ているはずです。この中にカスタムポリシーを構成するための機能が詰まっています。



早速 Azure AD を Azure AD B2C のカスタム IdP として追加してみたのが以下の画面です。

色々とカスタマイズの余地もあるので、引き続き触っていきたいと思います。


2017年5月6日土曜日

[Azure AD]条件付きアクセスの信頼済みネットワークが拡張されてました

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

永らく条件付きアクセスの信頼済みIPの上限数(50レンジ)に悩まされてきた管理者の皆さんに朗報です。(といってもしばらく前に拡張されていたので、既に気が付いた人は使っていると思いますが)

これまでは、旧MFAポータルで信頼済みIPを設定していたのですが、登録可能な数は50レンジまででした。



この上限で困るケースが社内からのネットワークの出口が事業所毎にあったり、クラウドベースのプロキシサービスを使っているようなケースです。

以前、マイクロソフト・コーポレーションの開発チームとのディスカッションの場でもこの制限に関しては私を含め複数の人から改善リクエストが出ており、名前付きネットワーク・オブジェクトとの統合のロードマップが示されていましたが、条件付きアクセスの設定が正式に新ポータルへ移行されたタイミングで信頼済みIPについても移行されました。

尚、現段階では以下の注意点があります。
・過去に作成したアプリケーションの条件付きアクセスの構成は新ポータルからは見えないので、構成し直す必要があります
・再構成しない場合、過去に作成したアプリケーションについては旧ポータルの信頼済みIPが使われます
・新しくアプリケーションを作成する場合、旧ポータルからアプリケーションを作成する場合でも、条件付きアクセスは旧ポータルからは構成できなくなっています。条件付きアクセスの構成は新ポータルから実施してください


早速ですが、構成を見てみます。

新ポータルの条件付きアクセスの構成にNamed Locationsという項目が存在するので、New locationをクリックしてネットワークの場所を定義していきます。

IPレンジをどんどん追加できます。(画面からの直接入力の場合は10個単位で保存をしないとダメですが、保存した後に再度ネットワーク構成を開いて追加していけばどんどん追加できます)また、テキストファイルにネットワークレンジの一覧を書いてUploadすることで一気に追加することが出来ます。


次はこれを使って条件付きアクセスのルールを構成してみます。

まずは対象のユーザ・グループを選択します。ここでは全員を対象としています。


次に対象とするアプリケーションを選択します。ここでは「pharaoh1234」という名前のアプリケーションを対象としています。

次に、条件を設定します。今回信頼済みIPに設定されていないネットワークからのアクセスの場合は多要素認証を要求しようと思うので、ここのLocationsにInclude:All locations、ExcludeにAll trusted IPsを指定します。



条件に一致した場合のアクションとして多要素認証を要求したいので、以下の通りRequire multi-factor authenticationにチェックを入れます。

後は、ルールをEnableにして保存すると完了です。


この状態で信頼済みIP以外のネットワークからアプリケーションにアクセスすると以下のように多要素認証が要求されます。



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年4月18日火曜日

今年の de:code はユーザ事例を通して Azure AD 導入の実情をお伝えします

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

いつの間にか de:code 2017 まで約1か月となりました。
昨年の de:code ではチョークトークで何でも QA コーナーみたいなセッションを担当しましたが、今年は本職?での株式会社アシックス様の案件事例を通して Azure AD の活用の実際をお伝えします。



これまでも事例をベースにしたセッションはやってきたんですが、実は Azure AD 案件の事例をオープンな場でお話しするのって初めてなんですよね。今回は Azure AD を導入するにあたり Azure Web App や Azure Automation、Express Route など Azure 関連のサービスをそれなりの種類使っていたりしますので、Azure AD 自体の使い方に加えて、その辺りの話も織り交ぜつつグローバル企業におけるクラウド・ベースの認証基盤のあり方や既存環境からのマイグレーションなどについてお話できると良いなぁ、と思っています。

参考)これまでオープンにしてきた IdM 系の事例です。(節操なく色んなベンダの仕事してますね)



どうしても本職絡みだと言えないこともあったりするんですが、今回はなるべく Azure AD の各種技術的な要素が実際の案件ではどのように使われているのか?を皆さんにお伝えすることで、色々とイメージをしてもらえればと思いますので、お手すきの方はぜひお越しください。

あ、2日目の最終コマだったと思います。


尚、今回の de:code ではセキュリティ・トラックが 16 セッションもあり、私の他にも Enterprise Mobility の MVP が大勢出てきてマイクロソフト社員が語れないこと?を語ってくれると思いますので、私自身も非常に楽しみです。

以下、セキュリティ・トラックのセッション一覧です。

セッション番号タイトル担当
SC01DevSecOps on Azure : セキュリティ問題に迅速に対応するためのパイプライン設計MS安納さん
SC02シチュエーション別 Active Directory デザインパターンMVP宮川さん
SC03Active Directory の DR 対策~天災/人災/サイバー攻撃、その時あなたの IT 基盤は利用継続できますか?MVP渡辺さん
SC04あなたのサービスを "ID" で守る! Azure Active Directory の条件付きアクセスの基礎と実装MS松井さん
SC05株式会社アシックス様における Azure AD 導入プロジェクトの実際MVP富士榮
SC06Windows と Azure、2つの Information Protection をディープに解説!MVP国井さん
SC07Azure AD と Ruby で学ぶ OpenID Connect!MVP真武さん(nov)
SC08SDL からビジネスモデルまで IoT セキュリティを俯瞰するMS高橋さん
SC09パッチ待ちはもう古い!Windows 10 最新セキュリティ技術とゼロデイ攻撃攻防の実例MS村木さん
SC10Intune Application Protection を可能にするモバイル アプリ開発MSロバートさん
SC11セキュリティマニアックス ~侵入。ダメ。ゼッタイ。~MS蔵本さん
SC12DevSecOps 時代のセキュリティ人材DIT河野さん
SC13ログ管理で向上させるセキュリティMS山本さん
SC14IoT のセキュリティアーキテクチャと実装モデルMS安納さん
SC15Windows Hello で実現するハイブリッド 生体認証MS小町さん
SC16スパムの脅威から企業を守る!Office 365 で実現するセキュアコラボレーションtwofive末政さん


ちなみに、今年はゴールデンウィーク明けの EIC(European Identity & Cloud Conference 2017)に行こうと思っているので、実はほとんど資料を作る時間がないのが最大の課題です・・・。



2017年4月5日水曜日

Office365管理者は要対応)UPNとProxyAddress重複オプションの強制変更がいよいよ開始

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

以前紹介したAzure AD Connectでのディレクトリ同期時にUPNやProxyAddressが重複しないように自動的にサフィックスをつけてくれるオプションがいよいよ全テナントで強制的に有効になるようです。

 以前の紹介記事
 [Azure AD/Office365]管理者は要注意。ディレクトリ同期に関する仕様変更
 http://idmlab.eidentity.jp/2016/09/azure-adoffice365.html

簡単に内容をリマインドしておくと、複数のオンプレミスADから単一のAzure ADディレクトリへ同期したり、オンプレミスのUPN以外の属性(例えばメール属性)をAzure ADのUPNにマッピングするなど属性のユニーク性が担保されない環境で運用を行う際、ディレクトリ同期時にAzure AD側でUPNを自動的に「ユーザ名+4桁のランダム数値@デフォルトドメイン名」という様に変更する、というオプションが追加されました。
(UPN版とProxyAddress版の2つのオプションがあります)

このオプションが有効だとディレクトリ同期時の重複エラーを抑制することはできますが、勝手にUPNが書き換わってしまうのでオンプレミスのディレクトリの状態によっては若干困ることがあるので、昨年発表された段階では強制的に有効化されることはなく、しばらくは猶予期間が作られました。

しかし、この4月から遂に強制変更が開始されるようです。

4月1日前後に以下のメールが管理者宛てに来た場合は、メールに記載の日程から強制的に有効化されます。私のテナントの場合は4/19から強制有効化されるようです。
(以外と急でした・・・)

タイトル:New Identity Synchronization Feature Being Enabled - Duplicate Attribute Resiliency
差出人:MSOnlineServicesTeam@microsoftonline.com




急ぎ、自社のディレクトリ構成を確認してUPNが急に変わった~~~というようなパニックに陥らないように準備しておきましょう。




2017年3月29日水曜日

[Azure AD+PingAccess]Basic認証のあるバックエンドサイトへアクセスする

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

前回はAzure ADとPingAccessの組み合わせで、PingAccessのバックエンドに配置したHTTPヘッダ認証のサイトをAzure AD Web Application Proxy(Azure AD WAP)で公開する構成を紹介しました。

PingAccessは色々と器用なツールなので、既存のアプリケーションがBasic認証だった場合にも「ある程度」対応ができます。今回はPingAccessのバックエンドのサイトがBasic認証で構成されている場合の設定を紹介します。

尚、「ある程度」と書いたのはBasic認証がユーザのIDとパスワードをエンコードしたものを認証ヘッダにつけるという仕組みである以上、Password Vaultingをしないといけないので、固定のIDとパスワードしか投げ込むことしかできず、個別のユーザ認証とはならない為です。

では、早速。

◆サイトを用意する

何はともあれ、Basic認証を要求するサイトを作ります。今回はIISで構成しました。
PingAccessのサーバからアクセスしてBasic認証が要求されることを確認しておきます。


◆PingAccessのSite Authenticatorを作成する

SitesメニューよりSite Authenticatorを作成します。

TYPEにBasic Authentication、USERNAMEとPASSWORDにBasic認証に使うユーザ名とパスワードを設定します。
ここが微妙なところで、個別のユーザ毎ではなく、Authenticator単位での設定しかできないので、実際のサイトへアクセスするユーザ名とパスワードが共通になってしまいます。

◆SiteにAuthenticatorを紐づける

Authenticatorを作ったらSiteに紐づけます。既存サイトであれば構成を編集して、新規サイトなら追加をして、SITE AUTHENTICATORSに先に作成したSite Authenticatorを設定します。

その他の設定は前回行ったものと同じなので、詳細は省略します。

◆Azure AD WAP経由でアクセスする

Azure AD WAP、PingAccessを経由せずにアクセスするとBasic認証が要求されましたが、Azure AD WAPを経由してアクセスするとBasic認証はかからずにサイトへログオンできます。

Webサーバのログを見ると、先ほど設定したユーザでWebアクセスがあったことがわかります。



今回はここまでです。せっかく色々な機能があるPingAccessなので、上手に連携していけば既存のオンプレミスのアプリケーションのAzure ADへ対応させる新たな構成の選択肢となってくる可能性もありますので、今後も目が離せませんね。

2017年3月27日月曜日

[Azure AD]PingAccess連携でオンプレ資産へのアクセスを拡張する

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

待ちに待ったPingAccess+Azure AD連携のパブリック・プレビューが始まりました。
昨年のTechSummitで少しだけ紹介しましたが、当時はプライベート・プレビュー段階だったのでお見せ出来ず。。。

アナウンス
 公式blog
 PingAccess for Azure AD: The public preview is being deployed!
 https://blogs.technet.microsoft.com/enterprisemobility/2017/03/22/pingaccess-for-azure-ad-the-public-preview-is-being-deployed/


簡単に言うと、Azure AD Web Application Proxy(Azure AD WAP)を経由してPingAccessのサーバをインターネットへ公開、PingAccessのリバースプロキシ配下のアプリケーションへアクセスを可能にする、という構成が取れるようになります。

このことにより、これまでAzure AD WAPではバックエンドのアプリケーションは統合Windows認証が前提だったのが、HTTPヘッダ認証のアプリケーションなどPingAccessが対応している認証方式のアプリケーションであれば外部に公開することが出来るようになります。


とりあえず今回はHTTPヘッダ認証を使ったアプリケーションとの連携を公式ドキュメントの手順+αでやってみたいと思います。
(ちなみに公式ドキュメントが一部間違っているので・・・)

参考手順はこちら
 Azure AD側
 https://docs.microsoft.com/en-us/azure/active-directory/application-proxy-ping-access

 PingAccess側
 https://docs.pingidentity.com/bundle/paaad_m_ConfigurePAforMSAzureADSolution_paaad43/page/pa_c_PAAzureSolutionOverview.html


では早速。

◆Azure AD WAP経由で公開するオンプレミスアプリケーション定義を作成する

通常のAzure AD WAPでオンプレミスアプリケーションを公開するのと同じ手順で、PingAccessサーバを公開します。この段階ではPingAccessはまだダウンロード・インストールはしていないので内部URLなどは適当なものを設定しておき、あとで修正しても問題ありません。

Azure ADポータルよりエンタープライズアプリケーションの登録を行います。アプリケーションの種類は「オンプレミスのアプリケーション」を指定します。

内部URL、公開URL、認証方式などの設定を以下の通り行います。

  • 内部URL
    • Azure AD WAP ConnectorからアクセスできるPingAccessサーバのURLです。今回はPingAccessとConnectorを同じサーバにインストールしたので、https://localhost:3000としています。
    • 尚、公式ドキュメントでは内部URLにもアプリケーションパスを追加する、とありますが、Azure ADで認証された後、認可コードをPingAccessサーバのコールバックエンドポイントへGETで渡す必要があるので、アプリケーションパスを追加するとコールバックエンドポイントへアクセスできず、うまく動かないのでパスを追加してはいけません。
    • また、PingAccessサーバがhttpsで動いているので、Connectorサーバからのアクセス時に証明書エラーが起きないように、一旦ConnectorサーバでPingAccessサーバへアクセス、証明書をインストール、エラーが起きない状態にしておく必要があります。
  • 公開URL
    • ここは適当に設定します。後で使うので値は覚えておきましょう。
  • 事前認証
    • Azure ADで認証するので当然Azure ADを選択します。
  • ヘッダーのURL変換
    • 「いいえ」を選択します。
  • コネクタグループ
    • PingAccess用のAzure AD WAP Connectorが属しているコネクタグループを選択します。
こんな感じです。


次にシングルサインオン設定を行います。
これまで出てこなかった、「Header-based Sign-on」が認証方式として選択できるようになっているので、これを設定します。
※ちなみにテナントによっては出てこない場合があるので、その場合はPreview版のAzure ポータルからAzure ADにアクセスしてみてください。私の環境では一度Previewポータルで設定をしたら次からは現ポータルでも出てくるようになりました。
 Preview版ポータルは
 もしくは、
 あたりからアクセスできます。

Header-based Sign-onを選択するとPingIdentityのロゴとともに、PingAccessのダウンロードサイトへのリンクが出てきますので、アクセスします。

リンクを開くとPingIdentityの登録サイトへ行くので名前などを登録します。

登録するとメールが届き、その中にモジュールとライセンスのダウンロードページへのリンクが入っているのでアクセスします。リンクは7日間有効だそうです。

ここで各プラットフォーム用のモジュールとライセンスのダウンロードができます。
ちなみに、普通のPingAccessのサイトからダウンロード(現時点では4.2.2)できるモジュールとこのサイトからダウンロードできるモジュール(4.3.0BETA)は別物なのでここからダウンロードしてください。(そのうち統一されるとは思いますが)

◆PingAccessがAzure ADからid_tokenをするためクライアント登録を行う

PingAccessはAzure ADから渡されたid_tokenの中のClaimをヘッダにマッピングするだけなので、先ほど作成したアプリケーションにscopeの設定、client_idとclient_secretの取得をしておく必要があります。

先ほどはエンタープライズアプリケーションの設定メニューでしたが、この設定を入れるにはアプリの登録メニューから操作を行う必要があります。
アプリの登録メニューから先ほど作成したエンタープライズアプリケーションを探して開きます。

まずはAPIアクセスの許可です。
  • 対象API
    • Windows Azure Active Directory
  • 必要なスコープ
    • アプリケーションへのアクセス許可
      • Read and write all applications
    • 委任されたアクセス許可
      • Sign in and read user profile

次にclient_secretの作成です。Azure AD用語ではキーですので開いて作成・保存します。

保存するとキーが表示されるので、控えておきます。
同様にclient_idはアプリケーションIDなのでこの値も、そしてディレクトリID(Active Directoryのプロパティから確認できます)を控えておきます。

ここまででPingAccessの設定に必要な情報はそろいました。
尚、公式手順を見るとReply UrlにAzure AD WAPの外部URLが設定されていることを確認し、必要に応じて手動設定すること、という説明がありますが特に問題なく自動設定されました。

◆PingAccessのインストールとライセンス設定

いよいよPingAccessのインストールと設定です。先ほどのPingIdentityのページよりダウンロードしたモジュールを使います。
今回はWindows Server 2016のサーバにAzure AD WAP Connectorと同居する形でインストールしました。

MSIモジュールを実行すると以下の通りインストールが走ります。基本的には次へ、次へでOKです。ちなみに事前にJRE1.8以降がインストールされておりJAVA_HOMEが環境変数に設定されている必要があります。

とりあえずスタンドアロン版にしていますが、プロダクション環境ではクラスタを作ることになると思います。







取り敢えずインストールは簡単ですね。
次は設定を行います。

まずはブラウザで管理コンソールへアクセスします。デフォルトインストールだと
 https://サーバ:9000/
でアクセスできます。

初回アクセスの場合、ライセンスのアップロードが求められるので先にダウンロードしたライセンスファイル(zip)を解凍して出来るlicファイルを選択してアップロードします。

上手くライセンスが登録されると、管理者でログインが求められます。
初期状態ではID:Administrator、パスワード:2Accessでアクセスできます。

初回ログインが成功するとパスワード変更が求められますので適当に変更しておきましょう。

これでようやく管理コンソールが開きます。


◆PingAccessとAzure ADの連携設定、バックエンドアプリへのプロキシ設定を行う

いよいよAzure ADとの連携設定です。

まず、SystemメニューよりTOKEN PROVIDERを開きます。

流石専用版、ISSUERに最初からAzure ADのURLが固定で入っているので、先ほど確認したディレクトリIDを設定してSAVEします。

次に、VirtualHostの設定です。要するにAzure AD WAPからアクセスが来た場合の挙動の設定をするための入れ物です。

HOSTに先ほどAzure AD WAPの設定の時に指定した外部URLのホスト名パートを設定し、PORTには443を設定しておきます。

次は、WEB SESSIONの指定をします。Azure ADから取得したid_tokenを使ってセッションを生成するので、先に取得したclient_id、client_secretはここで使います。


NAMEは適当に、COOKIE TYPEはSigned JWT、AUDIENCEはCookie名になるのでそれなりの値を設定します。

次に先ほどAzure ADで取得したclient_idとclient_secretを指定します。


次は、id_tokenから取得したClaimをヘッダへ変換するためのマッピング設定を行います。IDENTITY MAPPINGから設定していきます。

TYPEにHeader Identity Mappingを設定して、、

id_tokenの中のClaim名とヘッダ名をマッピングしていきます。


ここまででAzure ADとの連携部分は終わりなので、後はバックエンドサーバの設定をしていきます。まずはSite設定です。Sitesメニューを開き、Add Sitesをクリックします。

ここが実際のバックエンドサーバのアドレスやURLを入れる部分なので、今回は手元にあったCentOSのApache CGIを指定してみたいと思います。
適当な名前を設定して、TARGETSにサーバアドレスを指定します。


最後にここまでに設定してきた内容を組み合わせてPingAccess上でApplicationとして定義を行います。Applicationsメニューを開き、Add Applicationをクリックします。

名前は適当に。CONTEXT ROOTにはリバースプロキシとしてのパス設定なので、バックエンドアプリケーションのパスを指定します。今回はcgiを動かしてみようと思うので、/cgi-binを公開します。

後は、VIRTUAL HOST、WEB SESSION、SITEなどここまでに定義したものを設定していきます。

同様にIDENTITY MAPPINGも選択し、最後に「ENABLED」にチェックを入れてSaveします。

これで設定は完了です。

早速テストしてみましょう。

◆動作確認

Azure AD WAPに設定した外部URLに、今回PingAccessで公開しているバックエンドサーバのパスを付けたものへアクセスしてみます。
 今回だとこんな感じです。
 https://pingaccess-pharaoh.msappproxy.net/cgi-bin/

すると、Azure AD WAPに事前認証として指定した通り、Azure ADのログオンがおこなわれ、PingAccessからAzure ADへのアクセスに関する許可が求められます。(初回のみ)

そして、うまくいくとPingAccess配下のアプリケーションが表示され、ヘッダにマッピング設定した通りに値が表示されます。

もちろんテスト前にAzure ADでアプリケーションへユーザの割り当てをしておいてください。



今回はPingAccessのリバースプロキシ配下のアプリケーションへHTTPヘッダでAzure ADのClaimを渡すというシナリオだったので、mod_auth_openidcとmod_proxyを使って同じような環境は割と簡単に作れるとは思います。
 参考)CentOS+Apacheの認証をAzure AD/OpenID Connectで行う
   http://idmlab.eidentity.jp/2017/01/centosapacheazure-adopenid-connect.html

PingAccess連携を使うメリットは既にPingAccessで構成されたアプリケーション資産が存在していたり、Agent型でPingAccessが構成されているような場合に最大化されます。また、PingAccess自体が他のWAM製品との連携(というか他製品のフリをする)が得意な製品なので、Oracle Access ManagerやIceWallなどが既存で入っている環境をAzure ADへシームレスに移行する際には本領を発揮することになると思います。

このあたりのシナリオもまた検証してみたいと思いますので、またそのうち公開するかも知れません。