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連携でオンプレ資産へのアクセスを拡張する
 https://idmlab.eidentity.jp/2017/03/azure-adpingaccess.html

 [Azure AD+PingAccess]Basic認証のあるバックエンドサイトへアクセスする
 https://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択になりそうです。