Quantcast
Channel: IdM実験室
Viewing all 769 articles
Browse latest View live

安全!? #PokemonGo のログインと OpenID Connect と PokeIV

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

今回はもPokemon Goとアイデンティティのネタです。


前回、前々回とPokemon Goのログインの流れを見てきました。

 攻略! #PokemonGo のログインと OpenID Connect
 http://idmlab.eidentity.jp/2016/07/pokemongo-openid-connect.html

 続!#PokemonGo のログインと OpenID Connect
 http://idmlab.eidentity.jp/2016/07/pokemongo-openid-connect_25.html


これまでのポストでは、主にGoogleでログインすることで、Googleサービスへの不要なアクセスができる状態になっていないか?という観点で調査をしてきましたので、Scopeパラメータを見る限りはメールアドレスくらいにしかアクセスしていないことが分かったので、ひとまず安心、という結論を出していました。


◆Pokemon Goのふりをするアプリの登場

しかし、逆にPokemon Go側から見ると、Pokemon GoのサービスへのアクセスはGoogleから取得したid_tokenを持っていることだけを条件にしているので、何とかしてPokemon Goアプリの”ふり”をしてid_tokenを取得してしまえば、あとは何とでもなる、という状態でもありました。

最初のポストを書く時に、OpenID ConnectでGoogleからid_tokenを取得する流れを見ていると、public clientにもかかわらずimplicitではなくcode flowを使っており、codeやclient_secretが丸見えな点にものすごく違和感を感じて、サードパーティ・クライアントでも作るつもりなのかな???など、色々と議論をしていたんですが、やはり出てきてしまいました。

 PokeIV : 個体値チェックサイト
  https://pokeiv.net/



Gigazineでも紹介されていますが、Pokemon Goで使っているアカウントでGoogleにログオンし、codeを取得しPokeIVに貼り付けることでPokemon Goへアクセスして個体情報を取得するという仕組みなのですが、内部的には、Pokemon Goのclient_idとclient_secretを使ってPokemon Goのサービスへアクセスできるid_tokenを取得しているようです。

以下の同意画面を見るとクライアントがPokemon Goになっており、クエリパラメータの中のclient_idを見るとiOS版のPokemon Goで使っているclient_idと同じものが使われています。


Googleに登録されているredirect_uriがurn:ietf:wg:oauth:2.0:oobなので、redirect_uriにクエリでcodeを渡す代わりに、取得したcodeを手動(コピペ)で渡し、tokenエンドポイントを叩く、という実装はしていますが、色々とタチが悪いですね。

最近OpenID Foundation Japanの事務局長になったnov氏がoauth.jpで書いているようにcode置き換えもあるでしょうし、そもそもclient_secretが漏れている段階で今回のPokeIVのように単純にPokemon Goのふりをしてデータを取得するようなクライアントの開発が出来てしまいます。

今は集めたポケモンの情報をとってくるだけ、ということになっているので良いんでしょうが、例えば、今後Pokemon Goからユーザの位置情報の履歴を取得できたりすると、一気にホラーな話になってしまいますよね。。。


◆Pokemon Goはどうすれば良かったのか?

そもそも論、HTTPSを使っているにも関わらずFiddlerでトレースできてしまう段階でCertificate Pinningなどの対策が出来ていない、という話もありますが、ネイティブアプリ(パブリック・クライアント)として実装している段階で逆コンパイルや解析をされる前提でOpenID ConnectやOAuthの設計をすべきです。具体的にはimplicit flowを使ったり、Google Sign-In SDK for iOSを使って、client_secretを使わない方法で実装するのが一番簡単な対策だと思います。

簡単にまとめるとこんな感じかと。(他にもあるとは思いますが)

脅威対策
通信トレースによるcodeやclient_secretの漏えいCertificate Pinning
バイナリ解析によるclient_secretの漏えい難読化(限界あり)
Proxyサーバの通信ログよりcodeの漏えいPKCEの利用(Googleは既にPKCE対応してます)
client_secretの漏えいによるクライアントなりすましclient_secretを使わないフローの採用(implicit/Google Sign-In SDKの利用)



◆現バージョンのPokemon Goはどうなっているのか?

最近バージョンが上がったクライアントはどうなっているのか?を見てみました。

Proxyを挟んだ状態でアクセスするURLなどを見て推測すると、Google Sign-In SDKを使っているみたいです。また間にfiddlerを挟んだ構成だとログオンに成功しないので、MITMもチェックもしているみたいです。(うまくトレースできなかったので深追いはしていませんが)


◆PokeIVなどのアプリを使ってしまった場合の対策

しかし、一度PokeIVなどのアプリを使ってしまった場合、id_tokenやrefresh_tokenがアプリ側に保管されている可能性もあり、勝手にPokemon Goへ不正にアクセスされてしまう可能性もゼロではありません。

このような場合は、Googleアカウントのページからアプリケーションからのアクセスを一旦取り消して、正規のPokemon Goで再度サインインをしましょう。

アクセスを許可しているアプリケーション一覧が以下のURLで確認できるので、Pokemon Goを探して、一旦削除してしまいましょう。

https://security.google.com/settings/security/permissions



Pokemon Goを起動すると再度Googleアカウントへのアクセス許可のページが表示されますので、ここで改めて許可をすることでid_tokenが取得できるので引き続きPokemon Goを楽しむことが出来ます。


[Azure AD]登録済みデバイスからのみアクセスを許可する

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

最近Pokemon Goの話題ばかりだったので、Azure Active Directory(Azure AD)の話題を。

以前、IdM実験室別館(Channel 9)やセミナで紹介したことがありますが、組織内のネットワーク以外からのアクセスを拒否したり多要素認証を要求したりする「条件付きアクセス(Conditional Access)」の新機能の「デバイスベースの条件付きアクセス」のパブリック・プレビューが公開されました。

 公式Blogでのアナウンス
 #AzureAD Conditional Access Policies for iOS, Android and Windows are in Preview!
 https://blogs.technet.microsoft.com/enterprisemobility/2016/08/10/azuread-conditional-access-policies-for-ios-android-and-windows-are-in-preview/


具体的に何ができるのか、というと

  • ドメインに参加しているデバイスからのみアクセスを許可する
  • MDM(Intune)で管理されているデバイスからのみアクセスを許可する
ということです。
※ドメイン参加は以下の条件
 ・オンプレミスのADに参加しており、デバイス同期がAzure ADに対して実行されている
 ・Azure AD自体に参加している
 ・Workplace Joinしている
※対応しているデバイスは、Windows PC、Windows Mobile、iOS、Android

 やはりネットワーク・ベースのアクセス制御だと業態によっては適用が難しかったり、信頼済みネットワークのメンテナンスが面倒だったりするので、デバイス自体を見てアクセスを制御する機能の必要性が挙がっており、ようやくの対応となりました。まだまだパブリック・プレビューですがニーズは多いはずなので早く正式リリースしてもらいたいですね。


と、いうことで早速試してみます。

◆設定はアプリケーション単位

ネットワークベースの条件付きアクセス制御と同様にアプリケーション単位で設定を行います。
(Azure AD Premiumのライセンスが必要です)

[設定]メニューを開くと「デバイスベースのアクセス制御」が表示されているので「アクセス規則を有効にする」をONにします。

すると、適用対象とデバイスルールの2つのメニューが表示されます。
適用対象は、対象とするユーザを選択します。例えばルール適用対象から除外したいユーザがいる場合は、ユーザやグループの単位で除外することが出来ます。
また、デバイスルールは、対象とするデバイスの種類、およびWindowsデバイスの場合のルール準拠の条件(ドメイン参加やIntune登録など)を設定することが出来ます。

以下が設定画面です。



今回は、全てのユーザが、すべてのデバイスにおいてルールに準拠している必要があるように設定してみました。

では、早速アクセスしてみます。

◆Windows PCからのアクセス。IEとEdge以外は対応していない!

まずはPCでアクセスしてみます。

まずはルールに準拠していないPCからのアクセスです。

ログインをすると、アクセスが拒否されました。

しかし、FirefoxやChromeでアクセスした時とInternet ExploreやEdgeでアクセスした時で出てくるメッセージが異なります。
どうやらInternet ExploreとEdgeしか対応していないようです。

Firefoxでのアクセス。The current browser is not supportedと言われてしまう。

Edgeでのアクセス。The application contains sensitive information and can only be accessed from the devices that are compliant with eIdentity access policyと言われ、デバイスベースでのアクセス制御が有効に働いていることがわかる。



次に、ポリシーに準拠しているPCからアクセスしてみます。今回はAzure ADに直接参加しているWindows 10のPCからアクセスしてみます。

Firefoxからのアクセスだとやはりブラウザが対応していない、と言われます。


Edgeでアクセスすると問題なくアクセスできるので正常にデバイスベースのアクセス制御が働いていることがわかります。


◆モバイル(iOS)でアクセスする。同じくブラウザを選ぶ!

同じくiOSでアクセスします。このデバイスはIntuneに登録済みなので、ポリシーに準拠している状態です。

まずはiOS版のChromeです。
やはりブラウザを選ぶようで、アクセスできません。

Safariでアクセスするとクライアント証明書認証が走ります。


証明書をタップするとうまくアクセスできました。


◆まとめ

デバイスの状態をちゃんとみてアクセス制御が働いていることがわかります。これでネットワーク制御に加えて、さらに柔軟に制御をすることもできるようになりそうです。

しかし、デバイス状態をAzure ADが判断するためには仕方ないことかもしれませんが、ブラウザを選んでしまうのが難点といえば難点です。
せめてChromeやForefoxなど他のブラウザ用にプラグインなどを用意して対応していってもらいたいものです。。。

[SAML]Oracle CloudとのSSOを構成する~AD FS編

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

色々なクラウドサービスとフェデレーション、シングルサインオンを構成してみるコーナーです。
今日はAD FSを使ってOracle CloudへのSSOできるように構成してみたいと思います。(別途Azure AD編も公開予定です)

◆Oracle Cloudとは

POCO(Power Of Cloud by Oralce)ってやつですね。SaaS、PaaS、IaaS、DaaS領域でOracleが提供しているソリューションをクラウドで提供しているものです。(DaaSがあるあたりがOracleらしいですね)
例えば、SaaSだったらHRとかSCM、ERPなど、PaaSだとJava実行環境、IaaSならCPU、ネットワーク、ストレージ、DaaSはデータそのものだったりします。

この辺りに概要が説明されており、30日間のトライアルを申し込むことが出来ます。
http://www.oracle.com/jp/cloud/overview/index.html




◆Oracle Cloudのユーザ情報の持ち方とシングルサインオン対応

Oracle Cloudではユーザを識別するのに、ユーザIDもしくは電子メールアドレスを使います。
(この電子メールアドレスは実際にメールが届くアドレスである必要があります)

そして、シングルサインオンを行うための手段としてエンタープライズ・クラウドらしくSAMLに対応しており、上記の識別子であるユーザIDもしくは電子メールアドレスをIdPから受け取ることでシングルサインオンが成立する仕組みになっています。

ユーザ情報の持ち方と識別子の考え方、IdPで発行されるSAML Assertionの中の値との関係性は以下の図の通りとなっています。



◆シングルサインオンを構成する

では、早速SSOの構成をしてみたいと思います。最初に書いた通り、今回はSAML IdPとしてAD FSを使います。(手元にあったのがWindows Server 2016 Technical Preview 5のAD FSなので本稿ではPreview版のAD FSを使いますが、Windows Server 2012R2でも基本的には変わりません)

まず、Oracle Cloud側の設定を行います。

管理者アカウントでログインし、まずはSSOさせるユーザを作ります。
尚、デフォルトで電子メールとユーザ名は同じもの(電子メール)を使うようになっているのですが、色々なパターンを確認したいので、今回は電子メールとユーザ名は別々の文字列を使うことにします。


次にSSOの構成画面へ遷移します。
SSO設定は何故かユーザメニューの中にあります。


ユーザメニューを開くとSSO構成というタブがあります。


シングルサインオンを構成する画面が出てきます。



早速IdPの設定を入れてみたいと思います。
Oracle CloudはMetadataを使った設定をサポートしているので、まずはAD FSのFederationMetadataを取得します。
https://ADFSサーバ名/FederationMetadata/2007-06/FederationMetadata.xml
にアクセスするとXMLがダウンロードされてきますので、これを使います。
ちなみに、Internet ExploreだとXML自体が開いて表示されてしまうので、私はいつもFireFoxを使っています。FireFoxだと直接ダウンロードが走るので。


MetadataをダウンロードしたらOracle CloudのSSO構成画面を開き、Metadataをアップロードします。


次に、先にも説明したとおり、識別子としてユーザIDを使うか電子メールアドレスを使うか、SAML Assertionのどこに識別子の値が入ってくるのかを指定します。

まず、識別子を選択します。

次に格納場所を選択します。

ちなみに、SAML属性を選択した場合はAssertionの中のAttribute Statementにある属性名URIを指定する必要があります。

尚、ここで重要な注意点です。
Oracle Cloudは識別子にユーザIDを、格納場所にNameIDを指定した場合にはnameid-formatとしてunspecifiedでよいのですが、それ以外の設定を行った場合はnameid-formatにemailaddressを指定する必要があります。
また、格納場所にSAML属性を選択したとしてもNameID自体には値を入れてあげる必要があります。(実際のユーザの識別には使われないので任意の値でOKです。ただし、nameid-formatにはemailaddessを指定する必要があります)

ケース毎に以下の通りのフォーマット指定が必要になります。
ユーザー識別子格納場所NameID Format
ユーザーIDNameIDurn:oasis:names:tc:SAML:2.0:consent:unspecified
SAML属性urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
ユーザーの電子メールアドレスNameIDurn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
SAML属性urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress





さて、話が逸れましたが、以上でSP側(Oracle Cloud側)の設定は終わりなので、次はIdP側(AD FS側)の設定を行います。

同じく、AD FSもMetadataを使った設定ができるので、Oracle CloudからSP側のMetadataをダウンロードし、AD FSへ読み込ませます。

Oracle Cloud側でMetadataのエクスポートを行います。


このMetadataを使ってAD FSにSP登録(証明書利用者信頼)を行います。


設定ウィザードの中で先ほどダウンロードしたMetadataを指定します。


これで登録自体は終わるので、あとはAD上のユーザのどの属性をAssertion上にどうやって乗せるか?の設定を行います。

まず、AD上のユーザですが、以下のように作成してあります。
・sAMAccountName : nfujie
・mail : naohiro.fujie@eidentity.jp



まずは、Assertion内のNameIDにログインID(nfujie)をマッピングしてみます。
SPのセットアップが終わると、要求発行ポリシーのウィザードが起動するので、新規ルールを作成します。

ADのユーザを元にAssertionを構成するので、LDAP属性を要求として送信というテンプレートを使用します。

AD上のsAMAccountNameをNameIDにマッピングするので、以下のようなルールになります。


これで設定は完了です。

Oracle Cloudの管理画面に戻り、SSOのテストを行います。


テスト用の画面が開くので、Start SSOをクリックします。

クリックするとAD FSのログイン画面へリダイレクトされるので、ADのユーザでログインします。


すると、Authentication Failed。。。。エラーですね。


これが2つ目の注意点です。
Oracle CloudからダウンロードしたMetadataを見ると署名アルゴリズムにSHA1を使うように指定がされているのですが、AD FSで発行されたSAML Assertionの中を見るとSHA256で署名されており、このアンマッチが原因で検証に失敗し、エラーとなっているようです。

Oracle CloudのMetadata内の署名アルゴリズムの指定


AD FSで発行されたAssertionの中身


これはAD FSの昔からのバグ?でMetadataを読み込んでRPを作成する場合、署名アルゴリズムがMetadataの中の指定を無視して自動的にSHA256になってしまいます。
と、いうことでAD FS上で署名アルゴリズムをSHA1に設定し直します。


これで再度テストを行うと、今度は成功しました。


これで全ての設定が完了したので、Oracle Cloud側でSSOを有効にします。

確認が求められます。



◆実際にSSOでログインする

テストもうまくいったので先に作成したユーザをログオンしてみます。
ログオン画面を開くと、SSOが有効になっている環境ではCompany Sign Inというボタンが出てきますので、SSOしたい場合はこのボタンをクリックします。

すると、AD FSにリダイレクトされるので、ADのユーザでサインインします。


ログオンに成功するとOracle Cloudへ戻ります。意図したユーザでログインできていることがわかります。



◆他のバリエーションも試してみる

ここからはオマケですが、識別子と格納場所を他のパターンにした場合にどの様な設定を行う必要があるか確認してみます。

まずは、識別子に電子メールアドレスを使うパターンです。格納場所はNameIDのままにします。
この場合は、先の表にもある通り、nameid-formatを指定する必要があります。

AD FSではnameid-formatを指定するにはプロパティを当該クレームに対して付加する必要があるので、クレームを発行するルールのあとにプロパティを付加するルールを追加します。

まずは、電子メールをNameIDにマッピングするルールを設定します。


この後に、カスタム規則のテンプレートを使いルールを一つ追加します。


設定するルールはクレーム記述言語で記載する必要があります。
以下の内容を設定します。

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress");



これで、問題なく動作します。

ちなみにこのnameid-formatの追加をしない状態でSSOテストを行うと、Invalid NameIDFormatというエラーが出ます。


うまくいった場合のAssertionにはちゃんとnameid-formatと値が入っていることがわかります。



次に格納場所をNameIDからSAML属性へ変更してみましょう。

先のSSO設定で格納場所をSAML属性にし、属性名にAssertion上の属性URIを設定します。


後は、AD FS側もこれに合わせて属性のマッピングを作ればOKです。上記例ではwindowsaccountnameという属性にユーザIDの値がマッピングされていればOKなので、NameIDのルールに加えて、一つルールを設定します。

これを既存のNameIDおよびフォーマット設定のルールのあとに追加します。


テストするとAssertionに意図した属性が乗ってきており、SSOに成功することがわかります。




◆まとめ

AD FSを使ってOralce Cloudとのシングルサインオンを構成する場合、以下に注意が必要ですが、割と簡単につながります。
・AD FS側に設定する署名アルゴリズムを手動でSHA1に修正する必要がある
・識別子にユーザID、格納場所にNameIDのパターン以外ではnameid-formatにemailaddressを指定する必要がある



次回は、Azure ADを使ったパターンを解説したいと思います。

[SAML]Oracle CloudとのSSOを構成する~Azure AD(Premium)編

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

前回に引き続きOracle Cloudとのシングルサインオンを構成していきます。今回はIdentity ProviderとしてAzure ADを使ってみます。

 参考:前回の記事)
   [SAML]Oracle CloudとのSSOを構成する~AD FS編
   http://idmlab.eidentity.jp/2016/08/samloracle-cloudssoad-fs.html


尚、基本的な考え方や構成は前回の記事で解説したものと変わりませんので、前回の記事を読んでいない方は、先に前回の記事を読んでください。

◆構成するにはAzure AD Premiumが必要

尚、初めに結論を書きますが、Oracle Cloudとのシングルサインオンを構成するには、タイトルにある通りAzure AD Premiumのライセンスが必要となります。

これまでも書いてきたとおりAzure AD自身は、無償版であってもSAMLのエンドポイントが使えるのでSAML SPとのシングルサインオンを構成することが出来ます。

ただ、現在のところ何故かOracle Cloudとのシングルサインオンは無償版では動作させることが出来ませんでした。(後述しますが、Oracle CloudのAssertion Consumer ServiceへSAMLアサーションをPOSTしたところでシステムエラーが出ます。私のやり方が悪いだけかもしれませんが、POSTされているSAMLアサーションの中身はAzure AD Premiumで構成したものと変わらないので、何が違うのかよくわかっていません)

では、早速構成してみます。

◆Azure ADへOracle CloudをSAML SPとして登録する

他のアプリケーションと同様にAzure ADのギャラリーからアプリケーションを追加し、Oracle CloudのSAMLに関連するパラメータを入力、SPとして登録を行います。



カスタムアプリケーションを追加します。

アプリケーションの作成が完了したら、シングルサインオンを構成します。
まずはシングルサインオンの構成としてAzure ADのシングルサインオンを選択します。


次に、Oracle Cloudの以下の情報を登録します。

EntityID : Oracle Cloudの識別子
Assertion Consumer Service URI : SAML AssertionをPOSTする先のURI

これらの情報はOracle CloudのSSO設定の中に記載されているので、コピー&ペーストします。

少しずつ言葉が違いますが、

  • EntityID=Oracle Cloud上の「プロバイダID」=Azure ADにセットする「識別子」
  • Assertion Consumer Service URI=Oracle Cloud上の「アサーションコンシューマーサービスURL」=Azure ADにセットする「応答URL」

です。



次に進むと、Azure ADに関する情報が表示されますので、メタデータのダウンロードをしておきます。ダウンロードが終わったら一番下のチェックボックスにチェックを入れてウィザードを終了させてしまっても大丈夫です。



◆Oracle CloudへAzure ADをSAML IdPとして登録する

次は、反対にOracle Cloud側へAzure ADを登録します。
SSOの構成ページを開き、先ほどダウンロードしたAzure ADのメタデータをアップロードします。


これで構成は完了です。


◆ユーザの割り当てとテスト

早速テストを行いますが、その前にAzure AD側でユーザの割り当てを行っておきます。もちろんOracle Cloud側にも対象のユーザを作っておく必要もあります。

Azure ADのアプリケーションの構成でユーザの割り当てを行います。


SSOの動作試験は前回の記事と同様にOracle CloudのSSO設定ページから行うことが出来ます。


Start SSOのボタンをクリックするとAzure ADのサインイン画面へリダイレクトされるので、ログインします。


ログインが完了するとOracle CloudへSAMLアサーションがPOSTされ、シングルサインオンが完了します。


◆他の属性マッピングのバリエーションを試す

Azure ADを使った場合もAD FSの場合と同様に他の属性を識別子にマッピングすることも可能です。

例えば、識別子を電子メールアドレスにし、NameIDに格納する場合は以下のような設定になります。尚、Azure ADではNameIDの値はUserPrincipalName(メールアドレス形式)でnameid-formatはemailaddressなので、AD FSの場合のようにカスタムプロパティの設定を行う必要はありません。


また、SAML属性に入っている値を識別子にマッピングする場合は以下のように設定します。
この場合も特別なマッピングルールを作ったりプロパティの設定を行う必要はありません。


全体にAD FSを使うよりも楽に設定できる感覚があります。



◆Azure AD Premiumがない場合はどうなるか?

冒頭に書いた通り、上記はAzure AD Premiumのライセンスを保持している場合の設定の方法です。(具体的にはPremiumライセンスがないと、ギャラリーからカスタムアプリケーションの追加が出来ません)

ただ、無償版であってもSAMLのエンドポイント自体は有効なので自力でSPを登録すれば、SAMLアプリケーションとのシングルサインオンを構成すること自体は可能です。
(現に、MS松崎さんがsimplesamlphpを使ったSPとの連携を無償版の機能だけで実現しています。関連ポストはこちら

しかし、Oracle Cloudで同様の手順を実施したところ、SAMLアサーションの発行まではうまくいきますが、Oracle CloudのAssertion Consumer Serviceがうまくアサーションを受け取ってくれませんでした。

これは推測ですが、SAML SSOエンドポイントアドレスがPremiumでのカスタムアプリケーション追加で作成した場合はlogin.windows.net、無償版で作った場合はlogin.microsoftonline.comとなっており、自動的にリダイレクトされるので差異はないと思うのですが、微妙な機能差があるのかもしれません。(無償版のメタデータのエンドポイントをwindows.netに書き換えても同じエラーになるので違うのかもしれませんが)


参考までに手順と結果を載せておきます。(ここが間違ってるよ!という情報などあればぜひ!!)

まずはアプリケーションの追加をしますが、ギャラリーからではなく、組織で開発中のアプリケーションを選択します。

アプリケーションの種類はWebアプリケーションにします。


アプリケーションのプロパティには以下をセットします。

  • サインオンURL : Oracle CloudのアサーションコンシューマサービスのURL
  • アプリケーションID/URI : Oracle CloudのプロバイダID



次に、Oracle Cloud側にAzure ADの情報を設定しますが、ギャラリーからのアプリケーション追加ではないので、メタデータをウィザードから取得することが出来ません。
そこで、画面の下部にあるエンドポイントメニューよりFederationMetadataを取得し、Oracle Cloudへアップロードします。

このURLへアクセスし、表示されるXMLを保存します。




設定はこれで終わりなので、先ほどと同じ手順でテストをします。
尚、この手順で作成した場合はデフォルトではAzure AD側でのユーザ割り当ては不要です。

Start SSOをクリックすると同じくAzure ADのログイン画面へリダイレクトされます。


サインインすると、Oracle CloudのアサーションコンシューマサービスへSAMLアサーションがPOSTされますが、システムエラーが出てしまいます。


普通にOracle Access Managerなんですね。
SAML Tracerで上記のPremiumを使ったうまくいくパターンと無償版を使った失敗するパターンの両方のSAMLアサーションをトレースしてみたんですが、変わった点は見当たらず、何が原因なのかはよくわかっていません。
Oracle Cloud側へのAzure ADの情報登録もメタデータを使わず手動で構成したり、メタデータの不要な部分の削除など色々と試してはいるのですが、今のところ解決の糸口はつかめず。。。


◆まとめ

AD FSを使った場合に比べ、Azure ADをIdPとして使った場合は簡単に構成することが出来ます。しかし、以下の注意点があります。

  • Azure AD Premiumライセンスが必要
  • Azure ADのログインIDはUserPrincipalNameなのでOracle CloudのログインIDとマッピングする際は値のフォーマットを合わせる必要がある






[MIM]Microsoft Identity Manager 2016 SP1がRTM

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

2016年に入ってから細かくPreviewビルドが公開されてきたMicrosoft Identity Manager 2016(MIM)ですが、ついにService Pack 1がRTMとなりました。

これまでのリリースの履歴。3月、4月、6月にPreview版が出ていました。
 [MIM]June CTPで遂にExchange Onlineをサポート
 http://idmlab.eidentity.jp/2016/06/mimjune-ctpexchange-online.html

 [MIM]Microsoft Identity Manager April 2016 Previewが公開
 http://idmlab.eidentity.jp/2016/04/mimmicrosoft-identity-manager-april.html

 [MIM]Microsoft Identity Manager March 2016 Previewが公開
 http://idmlab.eidentity.jp/2016/03/mimmicrosoft-identity-manager-march.html


まだ、Connectサイトに公開されただけなので、リリースノートも9/11時点では出てきていませんが、ざっくり触った感じでは、これまでのPreview版の総まとめになっており、目玉は以下の点くらいです。(あとはPAMフォレストの構成とかコマンドレットの追加などです)
  • ワークフロー用のメールボックスにExchange Onlineのサポート
  • Chrome/Firefoxのサポート
  • 新バージョンのOS、SQL Server、SharePointのサポート

取り敢えずインストールして動作を見てみました。

バージョン表記は「4.4.1237.0」となっています。
しかし相変わらずForefront Identity Manager 2010 R2のままなんですね・・・
<Synchronization Service>


<Portal>



インストール中のメールボックス指定。Exchange Onlineが選択できるようになっています。



Chromeでのアクセス。Webページダイアログが以前とは変わっており、IE以外でも使えるようになっています。


Firefoxだと若干怪しいです。




後は色々とバグフィックスなどはありますが、その辺りはリリースノートが公開されてから、ということで。

[MSA]職場または学校のアカウントで新規サインアップが不可に

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

ID & IT Management Conference 2016の準備などで多忙だったので、色々とスルーしていた間にあった重要な発表を少しづつキャッチアップしていきたいと思います。

以下が9月上旬~中旬で発表された割と重要な発表です。(私基準です)

  1. マイクロソフトアカウント(MSA)へ職場または学校のアカウントで新規サインアップ不可に
  2. Azure Active Directory Premium P2の提供開始
  3. 新ポータルでAzure Active Directoryの管理が可能に
  4. MicrosoftとPing Identityの提携によるレガシーアプリへのSSO拡大
  5. Azure AD Connect 1.1.281.0のリリース


取り敢えず今回は1の「マイクロソフトアカウント(MSA)へ職場または学校のアカウントで新規サインアップ不可に」をお届けします。

9月15日に公式アナウンスが出てきました。(割と突然だったので私もびっくりしました)

 Cleaning up the #AzureAD and Microsoft account overlap
 https://blogs.technet.microsoft.com/enterprisemobility/2016/09/15/cleaning-up-the-azure-ad-and-microsoft-account-overlap/


早速内容を見ていきます。

◆これまでの課題

マイクロソフトのサービスを利用するには、職場また学校のアカウント、つまりOffice365やAzure Active Directory(Azure AD)で管理されているアカウント、もしくはマイクロソフトアカウント(従来のLive ID。MSA)を使ってログインする必要があります。

ただし、マイクロソフトアカウントはlive.comやoutlook.comなどマイクロソフトが用意しているドメイン以外に既存のメールアドレスを使ってサインアップすることも可能でした。


ここでOffice365やAzure ADのアカウントを使ってサインアップすると同じユーザ名のアカウントが職場または学校のアカウントおよびマイクロソフトアカウントの両方に出来上がることになり、マイクロソフトの提供するサービスへログインする際に以下のようなアカウント選択画面が表示されてしまいました。



これは一般利用者にとってわかりにくく、しばしば混乱を招いてきました。


◆今回のマイクロソフトによる対策のポイント

かなり乱暴な対策ではありますが、すでにOffice365やAzure ADで管理されているドメインのメールアドレスを使って、新規にマイクロソフトアカウントへサインアップすることが出来なくなりました。

これで新規ユーザは同じユーザ名でOffice365/Azure ADとマイクロソフトアカウントの両方にIDが作成されることは無くなりますので、ID選択画面が表示されることは無くなります。


では、既に作成済みのアカウントや、後からOffice365/Azure ADにドメイン追加されたアカウントの場合はどうなるんでしょうか?

結論、既存のマイクロソフトアカウントのIDを変更する、というのが答えです。


◆既存のマイクロソフトアカウントのIDを変更する

注意点を含む詳細はこちらのページで解説されていますので、確認して対応してください。

基本は既存のアカウントに新しいメールアドレスをエイリアスとして追加、プライマリ側と入れ替えた後、Office365/Azure ADと重複しているメールアドレスを削除するという方法です。


◆影響があるサービスがあるので注意

公式ページにも記載がありますが、職場のメールアドレスでサインアップしたマイクロソフトアカウントでないと利用できないマイクロソフトのサービスが一部あるので、職場のメールアドレスがOffice365/Azure ADで利用しているドメインと一致している環境においては、マイクロソフトアカウントのメールアドレスを切り替えるとそれらのサービスが使えなくなります。(新規にはサインアップすらできないので、当該環境において新規ユーザはそれらのサービスを使うことは出来なくなっています)

例えば、
・Windows Dev Center
・Microsoft Partner Network
などに影響があるようです。

また、既存のアカウントのメールアドレスを変更することによりデバイスのリセットなどをする必要がある場合もあるので、こちらも要注意です。

例えば、
・Windows Phone 8を使っている場合はデバイスのリセットが必要になります
・一部XBox開発ツールを使っている場合は別のIDになってしまいますので、実質アカウント作成し直しとなります
などが大きな影響といえます。


◆まとめ

MSALやv2エンドポイントなどAzure ADアカウントとマイクロソフトアカウントのコンバージが進む一方で、IDの重複問題が長年の懸案事項となっていたので、今回の対策は長い目で見れば非常に有益なことだと思います。
そもそも同じ識別子を持つ複数のIdPで同じサービスが利用できてしまうというのは、保証レベルの面などセキュリティ的にも重大な問題でした。例えば、個人の自己申告でサインアップできてしまうマイクロソフトアカウントを在職中に作成、退職後も継続的に利用しているケースにおいて、いくらAzure AD側で退職アカウントを削除したとしても、MSALを使ったコンバージ・アプリケーションへ職場のメールアドレスを使ったサインインが継続的に可能になってしまう、という課題です。

他方でMPNなど重要なサービスが職場メールアドレスのMSAでしかアクセスできないなど、過渡期に解決すべき課題もあるので、若干性急な気もした今回の対策ですが、早期に各サービス側での対応をすすめ、一日も早く綺麗な姿でサービスを提供できるようになってもらいたいものです。











[告知]ID Management Conference 2016で登壇します

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

先週末のID & IT Management Conference 2016に続き、10月初旬に東京と大阪でID Management Conference 2016が開催されます。

今年のID & IT Management Conference 2016では私はタイムテーブルに載らない裏トラックで新入社員~IDやセキュリティに関連する部門へ配属されて2~3年以内の方向けのセキュリティ・ID教育を担当しました。(完全招待性だったので、告知もしませんでした)



認証とID管理を新入社員向けに45分で解説するというのは中々のハードルでしたが、良い経験になりました。しかし、ID業界の老朽化や後継者問題が取り沙汰される昨今、非常に良い取り組みだと思いましたので、来年以降もこの取り組みは続けていきたいですね。



というわけで今年も無事にID & IT Management Conferenceは終了したのですが、早速次です。

次は、10月初旬に東京、大阪で開催されるID Management Conference 2016です。



以下、開催概要です。
今回、OpenIDファウンデーション・ジャパンでID連携・ID管理に関する解説をさせていただきます。東京はOpenIDファウンデーション・ジャパンの理事の林さん、大阪はEnterprise Identity Working Groupとして私が担当します。

イベント名:ID Management Conference 2016
イベントURL:
 http://www.f2ff.jp/idm/2016/

<大阪会場:富士榮>
日時:10月4日(火) ※セッションは17:05~17:45
場所:グランフロント大阪、ナレッジキャピタル・カンファレンスルーム
タイトル:エンタープライズにおける次世代ID連携標準
セッション内容:
 エンタープライズ企業においてもクラウド・サービスやモバイルデバイスの利活用に伴い、ネットワーク境界を超えてセキュアにID情報を連携する「ID連携」の重要性は増大しています。本セッションでは、OpenIDファウンデーション・ジャパンのEnterprise Identity Working Groupでの最新の成果物である「OpenID ConnectとSCIMのエンタープライズ利用と実装ガイドライン」を元に、企業におけるID連携の使いどころ、次世代のID管理/認証システムが対応すべきID連携標準技術について解説します。

<東京会場:林さん>
日時:10月5日(水) ※セッションは17:20~18:00
場所:KITTE、JPタワーホール&カンファレンス
タイトル:次世代ID連携標準によるAPIエコノミーの実現
セッション内容:
 パスワードによる認証が事実上有効性を失った今、認証の世界は大きく変わろうとしています。FacebookやGoogleを始めとしたソーシャルログインなどが台頭する中、ID連携への注目が高まると同時に、アイデンティティそして認証・認可の領域では、データ駆動社会の動きと共に様々な新しい動きもあり、制度や国際的な流れを踏まえて、APIを中心とした大きな動きが出てきています。本セッションでは、アイデンティティ分野の現在の状況と、技術的な動向、標準化の現状などを踏まえつつ、次世代のID管理/認証システムが対応すべきID連携標準技術について解説します。



開催まで約2週間ですが、ぜひ事前登録の上、ご来場ください。

[MSA]同一メールアドレスでマイクロソフトアカウントとAzure ADアカウントを利用するリスク

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

先日、職場または学校のアカウント(Azure Active Directory/Office365で管理されているアドレス)で新規にマイクロソフトアカウントをサインアップすることが出来なくなった、という話を紹介しました。

[MSA]職場または学校のアカウントで新規サインアップが不可に
http://idmlab.eidentity.jp/2016/09/msa.html


MPNやXBoxの開発関係など、まだAzure ADでのサインインをサポートしていないマイクロソフトのサービスが存在しているにも関わらず上記のような制限をかけたことについて、乱暴で性急な対応だ!という声も各国から上がっていますが、今回は逆にこれまでの様に複数のアカウントで識別子が共通になってしまっている状態だと何が起きえるのか?について考えてみたいと思います。


◆マイクロソフトアカウントでもAzure ADアカウントの両方でアクセスできるサービスを用意する

一番手っ取り早い方法として、Azure ADのOpenID Connectのv2 エンドポイントを使ったアプリケーションを開発してみます。

詳細は省くのとかなり手抜きなコードなので色々とツッコミどころはありますが、こんなコードを書きました。




◆アクセスする

v2 エンドポイントを使ったアプリケーションにアクセスし、ログインID(メールアドレス)を入力すると、ログイン用のIDをマイクロソフトアカウントとAzure ADアカウントから選択する画面が出てきます。



◆Azure ADのアカウントでログインする

まずは、Azure ADのアカウントでログインします。

職場または学校アカウントを選択すると、Azure ADのログイン画面へ遷移します。


結果、Azure ADからユーザ名をはじめとするID情報が取得できます。(id_tokenをほどいているだけですが)

preferred_usernameにログインIDが入っていることがわかります。


◆マイクロソフトアカウントでログインする

次にマイクロソフトアカウントでログインしてみます。
先ほどのID選択画面で個人のアカウントを選択すると、マイクロソフトアカウントのログイン画面へ遷移します。


結果、同じくID情報が取得できます。

同じくpreferred_usernameにログインIDが入ってきています。



◆何を注意すべきなのか?

上記の例では、どちらのアイデンティティ・プロバイダでログインしても同じ値がpreferred_usernameに入ってきてしまっています。この状態でユーザをpreferred_usernameで識別してしまうと便利な反面、セキュリティ面で問題があると言えます。個人でID登録できるマイクロソフトアカウントと管理者が登録・管理を行うAzure ADではIDの管理レベルが全く異なるからです。

上記のようなアプリケーションはB2BやB2Cのシナリオではそれほど珍しいものではありません。
アプリケーションが内部で自社のドメインのユーザからのアクセスならば管理メニューを出して、それ以外なら一般向けのメニューしか出さない、というようなロジックを書くこともあるためです。

通常は、自社ドメインのユーザは退職したら削除または無効化されログインできなくなるので、一見セキュリティ上問題はないように思われますが、退職前に自社ドメインのメールアドレスでマイクロソフトアカウントを作ってしまっていた場合、退職後も継続して管理メニューにアクセスできてしまうことになります。


今後は、マイクロソフトが新規にAzure ADやOffice365で使っているドメインのアカウントでマイクロソフトアカウントを作成することを禁止したので、すでにAzure ADやOffice365にドメインを追加している場合は、問題は減っていくとは思います。

ただ、
・現時点でAzure ADやOffice365に自社ドメインを追加していない
・すでに自社ドメインのアドレスでマイクロソフトアカウントを登録してしまっているユーザがいる
といった場合も多々あるはずなので、少なくとも「いくら信頼しているアイデンティティ・プロバイダとは言え、識別子だけで認可をすべきではない」ということを十分に認識してサービスの開発を行うべきだと言えるでしょう。

ちなみに、以前発生したOffice365のSAML SPの脆弱性も本質的には同じような問題に起因していましたね。

参考)
 Office365のSAML脆弱性に見るマルチテナントSP実装時の注意点
 http://idmlab.eidentity.jp/2016/05/office365samlsp.html






[MIM]Microsoft Identity Manager 2016 SP1がリリースされました

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

2016年に入ってから細かくPreviewビルドが公開されてきたMicrosoft Identity Manager 2016(MIM)ですが、ついにService Pack 1がRTMとなりました。

これまでのリリースの履歴。3月、4月、6月にPreview版が出ていました。
 [MIM]June CTPで遂にExchange Onlineをサポート
 http://idmlab.eidentity.jp/2016/06/mimjune-ctpexchange-online.html

 [MIM]Microsoft Identity Manager April 2016 Previewが公開
 http://idmlab.eidentity.jp/2016/04/mimmicrosoft-identity-manager-april.html

 [MIM]Microsoft Identity Manager March 2016 Previewが公開
 http://idmlab.eidentity.jp/2016/03/mimmicrosoft-identity-manager-march.html


ConnectサイトやMSDNには先行して公開されていましたが、Igniteに合わせてリリースノートを含め正式に公開されました。ざっくり触った感じでは、これまでのPreview版の総まとめになっており、目玉は以下の点くらいです。(あとはPAMフォレストの構成とかコマンドレットの追加などです)
  • ワークフロー用のメールボックスにExchange Onlineのサポート
  • Chrome/Firefoxのサポート
  • 新バージョンのOS、SQL Server、SharePointのサポート

リリースノートはこちら
https://docs.microsoft.com/en-us/microsoft-identity-manager/understand-explore/microsoft-identity-manager-2016-sp1-release-notes

取り敢えずインストールして動作を見てみました。

バージョン表記は「4.4.1237.0」となっています。
しかし相変わらずForefront Identity Manager 2010 R2のままなんですね・・・
<Synchronization Service>


<Portal>



インストール中のメールボックス指定。Exchange Onlineが選択できるようになっています。



Chromeでのアクセス。Webページダイアログが以前とは変わっており、IE以外でも使えるようになっています。


Firefoxだと若干怪しいです。




後は色々とバグフィックスなどはありますが、その辺りはリリースノートが公開されてから、ということで。

Windows Server 2016のリリースとハイブリッドID基盤

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

アトランタで開催中のIgniteのタイミングに合わせてWindows Server 2016が正式にリリースされました。

 公式ブログでのアナウンス
 https://blogs.technet.microsoft.com/hybridcloud/2016/09/26/announcing-the-launch-of-windows-server-2016/

9月28日現在、評価版のダウンロードが先行して可能になっていますが、正式版の提供は10月に入ってからの様ですね。

と、いうことでとりあえず評価版をダウンロードしてセットアップし、ハイブリッドID基盤の構成を確認してみました。

以前Windows Server 2012R2のドメインコントローラとAzure AD、Windows 10を使って構成した構成ですね。

 [Windows 10/Azure AD]ハイブリッド環境におけるドメイン参加とシングルサインオン①
 http://idmlab.eidentity.jp/2016/01/windows-10azure-ad.html


結論から言うと特に変化点はありません。

以下のシナリオでいわゆるDesktop SSO(PCへのサインイン~ブラウザアプリケーションへのサインインがシームレスに行える)が実現できます。

- Windows 10へのサインインはPINで行われる
- ファイル共有へは従来通りKerberosで認証が行われる
- AD FSに関連づけられたアプリケーションへもKerberosで認証が行われる
- Azure ADに関連づけられたアプリケーションへはMicrosoft Passportで認証が行われる

軽く動画を撮ってみました。



ちなみに、このシナリオの中で1点Technical Preview 5のころのAD FSと異なるところは、ブラウザにEdgeを使ってもAD FSへのWindows統合認証ができるようになっているところです。

単純にWIASupportedUserAgentsにEdgeなどがデフォルトで追加されているだけですけどね。

PS C:\Users\Administrator> $a = (Get-AdfsProperties).WIASupportedUserAgents
PS C:\Users\Administrator> $a
MSAuthHost/1.0/In-Domain
MSIE 6.0
MSIE 7.0
MSIE 8.0
MSIE 9.0
MSIE 10.0
Trident/7.0
MSIPC
Windows Rights Management Client
MS_WorkFoldersClient
=~Windows\s*NT.*Edge

そして、Technical Previewから変わらずに残念だったのが、AD FSの認証方式にMicrosoft Passportが選択できるにも関わらず、ブラウザアプリケーションでのSSOシナリオでは相変わらず使えないところです。

ここは別途、もう少し詳しく状況を解説したいと思いますので、とりあえずPINでログインしてもAD FSに関連づけられたアプリケーションへはMicrosoft Passport認証ではなく、Windows統合認証でSSOするしか現状は無い、ということだけ覚えておいてください。



設定関係も簡単に動画に撮っています。



そのうちもう少し細かく解説を加えて、Channel 9の別館の方にもアップしたいと思います。


[Azure AD/Office365]管理者は要注意。ディレクトリ同期に関する仕様変更

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

Azure AD Connectを使ってオンプレミスのActive DirectoryからAzure ADへオブジェクトを同期する構成でAzure ADやOffice 365を運用している方にとって非常に大きなインパクトのある動作変更が予定されています。

これまでディレクトリ同期を行う際、しばしば問題になってきたのが、
①複数ドメインからの同期時のオブジェクト重複
②同期元ドメインでの識別子の変更時のクラウド側への反映
です。(もちろん他にもありますが)

これまでは①のオブジェクト重複が発生した際はディレクトリ同期エラーが発生し、対象オブジェクトの同期はスキップされてきました。


同じく②について、特定の条件(Office365を使っている、など)のユーザについてはオンプレミスのuserPrincipalNameを変更してもAzure AD/Office365上のユーザのuserPrincipalName(ログインID)は変更されませんでした。

それぞれの動作の詳細は後述しますが、この動作の制御パラメータの初期値が変更になっています。

◆変更点

2016年8月24日以降に新規に作成されたAzure ADディレクトリでは、①のオブジェクト重複に関するエラーを回避するロジックが走るようになっています。また、既存のディレクトリについても今後強制的に設定の変更が行われ、従来とは異なる挙動をすることになるので一部運用方法の変更が必要な場合があります。

同じく②についてもオンプレミスのuserPrincipalNameの変更がAzure AD/Office365へ反映されるように変更されています。
※ちなみに②については8/24以前にすでに変わっていた可能性があります。①のアナウンスを見て環境を比較していて気が付いたので。


ディレクトリ同期機能2016年8月24日までに作成したディレクトリ2016年8月24日以降に作成したディレクトリ
重複属性の回復性FALSETRUE
userPrincipalNameの更新の同期FALSETRUE


ちなみに現在の設定がどのようになっているかはConnect-MsolServiceで接続した後で、Get-MsolDirSyncFeaturesで確認することが出来ます。

以下の図は8/24より前に作成したディレクトリ同期の機能の状態です。


こちらは8/24以降に作成したディレクトリ同期の機能の状態です。



良い機会なので、それぞれの機能について簡単に解説をしつつ、動きの違いを見ていきたいと思います。


◆重複属性の回復性

まずは、オブジェクトの重複回避機能です。Azure AD/Office365ではuserPrincipalNameおよびProxyAddressが複数のオブジェクトで重複することを許可していません。

しかし、例えばuserPrincipalNameをオンプレミスのADのuserPrincipalName属性以外の属性(例えばメールアドレスなど)を使ってディレクトリ同期を構成する場合、複数のユーザが同一のuserPrincipalNameを持ってしまうことがあります。
※現状はAlternative LoginIdや別の属性をAzure ADのuserPrincipalNameにマッピングしている構成では重複回避の機能は動作しないので、これまで通りエラーではねられます。ただ、ADでユーザを削除して、Azure ADのゴミ箱からユーザが削除される前に再作成、同期するなど、AD上のuserPrincipalName属性が重複するケース、またuserPrincipalNameが他のユーザのProxyAddressと重複するケースなどが該当します。

従来は先にあげた様にエラーが発生して該当するオブジェクトが同期されることはありませんでしたが、同期パラメータを変更することでオブジェクト同期を検知した時の動作を制御することが出来ます。

該当するパラメータは、
・DuplicateUPNResiliency
・DuplicateProxyAddressResiliency
の2つで、それぞれuserPrincipalNameの重複とProxyAddressの重複に対する動作を制御します。

例えば、DuplicateUPNResiliencyをtrueに設定すると重複するuserPrincipalNameを持つユーザを検知すると、
 ユーザ名+ランダムの4桁の数字@デフォルトドメイン名
というuserPrincipalNameが自動的に割り当てられます。


一応同期エラーのメールが飛んでくるので重複が発生したことはわかりますが、従来とは対応方法が変わるので要注意です。


尚、Get-MsolDirSyncProvisioningError -ErrorCategory PropertyConflictでエラーが起きているオブジェクト一覧を取得することも可能なので、メールだと気が付かない場合や自動的にアクションをしたい場合はスクリプト化をすることも可能です。


ちなみに、この重複回復機能は一旦trueに設定してもfalseに戻すことも現状(2016/09/30時点)は可能ですが、今後は戻すことはできなくなります。また、現在falseに設定されているディレクトリについて、強制的にtrueに設定変更がされるようなので、今のうちに運用への影響を洗い出して対応しておく必要があります。



◆userPrincipalNameの更新の同期

このパラメータは、オンプレミスのADのuserPrincipalName属性が変更された場合に、Azure AD側に変更を同期するかどうかを制御するものでした。

従来(SynchronizeUpnForManagedUsersがfalse)は以下の条件を満たさない限り、オンプレミスのADでuserPrincipalNameを更新してもAzure ADへ変更は同期されませんでした。

・ユーザが管理対象ユーザ(非フェデレーションユーザ)である
・ユーザにライセンス(Office365など)が割り当てられていない
 ※EMSなどAzure AD系ライセンスだけなら変更は同期される


同期ログを見ると更新がかかったように見えます。


しかし、Office365のライセンスが割り当てられているとuserPrincipalNameは変更されません。


しかし、新しく作成したディレクトリでは初期値がtrueなので、ライセンスの割り当て状況などにかかわらずオンプレミスのuserPrincipalNameの変更がAzure ADへも反映されます。つまり、従来は移行などの都合でオンプレミスのADのuserPrincipalNameを変更してもユーザがOffie365へのログインに使うIDへ影響はありませんでしたが、新しいディレクトリを使っているとログインIDが変更されます。

ちなみに旧UPNはエイリアスとして残ります。


尚、このパラメータは一度trueに設定すると二度とfalseへ戻せないので要注意です。
つまり、古いディレクトリを使っていてfalseを前提とした運用をしている場合は絶対にtrueに設定をしてはいけません。
(現在はまだアナウンスがありませんが、先の重複回避のパラメータと同様に、どこかのタイミングで強制的にtrueに変更されることも想像できます。今のうちにtrueになってもいいように運用を見直しておくべきかもしれません)


以下、参考ページです。頻繁にアップデートされるので更新情報に注意しておく必要があります。

Azure AD Connect 同期サービスの機能
https://azure.microsoft.com/ja-jp/documentation/articles/active-directory-aadconnectsyncservice-features/

ID 同期と重複属性の回復性
https://azure.microsoft.com/ja-jp/documentation/articles/active-directory-aadconnectsyncservice-duplicate-attribute-resiliency/


[Azure AD]Azure AD Domain Servicesが正式リリース(GA)

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

ちょうど1年前にPublic Previewが公開されたAzure AD Domain Services(AADDS)が正式にリリースされました。

 公式Blog
 #AzureAD Domain Services is now GA! Lift and shift to the cloud just got WAY easier!
 https://blogs.technet.microsoft.com/enterprisemobility/2016/10/12/azuread-domain-services-is-now-ga-lift-and-shift-to-the-cloud-just-got-way-easier/





◆AADDSとは何か

要するにオンプレミスのActive DirectoryのDomain ServiceがAzure VMで提供されている、というヤツです。Azure IaaS上のVNETにAADDSをくっつければ、VNETに紐づけたIaaS上のサーバをドメイン参加させたり、Express Route経由で社内とつなげば社内のPCやサーバも同じくドメイン参加ができるので、自前でドメインコントローラを持ちたくない小規模な企業にはおすすめ、というサービスです。

詳しくはPreview段階の記事ではありますが、山市良さんがアットマークITに書いてくれているので、そちら参照ということで。

 クラウドでもWindowsドメイン認証とグループポリシー管理が可能になる――Azure ADドメインサービス (1/3)
 http://www.atmarkit.co.jp/ait/articles/1511/06/news018.html


◆使用上の制限事項など

同じくPreview段階で確認した事項で、今回のGAでも解消はされなかった(おそらく永遠に解消されないと思いますが)制限事項として完全なるIaaSではないので、Domain Adminsグループそのものが利用者に公開されるわけではないので、「Domain Admins」というグループを必要とするサービスをメンバサーバにインストールすることが出来ません。

 [AzureAD]Azure AD Domain Servicesを使って既存サービスをクラウド上へ移行する際の注意事項
 http://idmlab.eidentity.jp/2015/10/azureadazure-ad-domain-services.html

もちろん他にもオンプレのドメインコントローラではできていたことがすべて実現できるわけではないので(サービスなので当然ですが)、十分に検証してから導入すべきでしょう。


◆Preview版からの強化点

公式アナウンスによると、以下の点がプレビュー時より強化されています。
  • LDAPのサポート
  • カスタムOUのサポート
  • DNSの構成が可能に(普通にWindows DNSサーバの構成ツールが使える様に)
  • Linuxのドメイン参加のサポート
  • Azure ADテナントとの同期の改善
  • パスワードを無期限にする属性のサポート
  • Azure ADと同期時にグループ名がおかしくなる不具合の修正
  • オンプレADとのSIDHistoryの同期
  • VNET Peeringのサポート

特にオンプレADからSIDHistoryが同期できるのはありがたいですね。
今のオンプレドメイン完全撤廃の実現可能性も見えてきたりすると思います。

またおいおい触ってみたいと思います。

[告知] 11/1~2 はTech SummitでAzure AD三昧

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

いよいよ今週に迫ってきたTech Summitですが、春先のde:codeに引き続き登壇の機会を頂きました。

今回は、ブレークアウトセッションに加えて、体験型セッションのハンズオンラボも受け持つことになったので、合計3コマ登場します。(ハンズオンラボはリピートセッションなので同じ内容を2回に分けて実施します)

ようやく資料も固まってきたので、チラ見せをしつつ概要を紹介しておきたいと思います。


◆ブレークアウトセッションではAzure ADのアプリ連携の実情を

この業界で働いていると製品提供ベンダの言う「出来る」と、実際に導入して「使える」には大きな開きがあることが多いのはご存知の通りだと思いますが、じゃ、Azure ADは実際「使えるのか?」というあたりを、エンタープライズの実情とハマりポイントを中心に解説します。

公式サイトでの掲載はこんな感じです。


◆ハンズオンラボでは、Azure ADの新ポータルを使ったアプリ連携設定を

ID管理とかSSOは、ハンズオンだと中々レベル感を合わせるのが難しい&非常に地味かつ難しいのであまりハンズオンラボのネタとしては向いていないとは思うのですが、そこを無理やりやってしまおうという企画です。対象が1回につき12名ということで何とかなるとは思いますが、最悪途中までで終わっても宿題に出来るのがクラウドの良いところだと割り切って進めていきたいと思います。
(以前.NETラボさんのイベントでFIMとAD FSのハンズオンをやってかなり難航した経験もあり内心はひやひやしていますが)


こちらも公式サイトの掲載はこんな感じです。




◆セッションスケジュール

ということで、セッションスケジュールです。Day1はかなりギリギリな感じもしますが、何とかこなしたいと思います。

Day 1(11/1)

  • 12:45-13:30 HOL001 Azure AD新ポータル事始め
  • 14:00-14:50 SEC020 アイデンティティの MVP が語る Azure AD とアプリ連携の勘所


Day 2(11/2)

  • 13:10-13:55 HOL008 Azure AD新ポータル事始め



と、いうことで来場される方は会場でお会いしましょう。

[Azure AD] Tech Summit 2016 ハンズオン動画を公開しました

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


先週お知らせしたとおり、去る 11/1 ~ 11/2 は Tech Summit 2016 へ参加してきました。

セッションにご参加いただいた皆様ありがとうございました。
おかげさまで、ブレークアウトセッションは120名部屋で立ち見、ハンズオンラボは早い段階で整理券がなくなり満席、と盛況でした。

ブレークアウトセッションの資料はおいおい公式に公開されると思うので、ここではハンズオンのおさらいをしておきたいと思います。

何しろ、絶対に 45 分では終わらない前提で作ったテキストで、目標としてた前半部分の完了についても初日、二日目を合わせても参加いただいた方の半分くらいの方が終わっていない状態だったので、参加いただいた方も、整理券を入手できず参加頂けなかった方も、存在自体を知らなかった方も、この動画を見ていただきやってみていただければと思います。
(参加いただいた方にはマイクロソフトアカウントと AzurePass が配布されたので、サブスクリプションが有効な間は続きが出来ます。参加頂けなかった方は無償評価版など別途サブスクリプションを入手いただき試してみてください)

と、いうわけで動画です。
(Channel 9 の別館にアップロードしています)




[告知]Internet Week 2016に登壇します

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

しばらくTech SummitやMVP Global Summitなどで忙しくて更新できていませんでした。

また、一連のイベントが終了したと思ったら11月末はInternet Week、ということで資料の締め切りやデモ環境の準備などでバタバタ、という状態でしたがようやく目途がついたので、取り急ぎ溜め込んだネタを吐き出していこうと思います。


まずは11月中旬のバタバタと準備をしていたInternet Week 2016です。

イベント自体はものすごくメジャーなので皆さんご存知だとは思いますが、今回登壇の機会を頂きましたので、エンタープライズID管理の話をデモを交えてする予定です。


Internet Week 2016

申込サイト:https://internetweek.jp/
日程:11/29~12/2
    ※私の出番は11/30の夕方(16:15~18:45)です。
場所:ヒューリックホール&ヒューリックカンファレンス
主催:JPNIC



従来のInternet WeekというとISPなどの技術者が集まるどちらかというと技術オリエンテッドなイベントだと思っていたのですが、プログラム委員の方から、そろそろ上位レイヤの認証とかの話もしていきたいというご相談をうけたので、エクスジェン・ネットワークスの江川社長、NRIセキュアテクノロジーズの勝原さんと一緒に「知らなきゃ損するクラウド時代のID運用~管理から連携まで~」というトラックで2時間半にわたってID管理ネタをお届けします。

私は、「ID管理/認証システム導入の理想と現実」というタイトルで、技術面・非技術面の両面からID管理システム導入プロジェクトの中のジレンマや、すこしトリッキーな方法で認証基盤を導入~クラウドへの巻取りを進める方法などを紹介します。

技術側面では、OpenAMで構築した認証基盤を利用者に気づかれないうちにAzure Active Directoryへ切り替える、というデモをする予定です。OpenAMのDesktopSSO連携とWindows Server 2016+Windows 10を使ったWindows Hello for Business、Azure AD Connectを使ったデバイス同期との組み合わせによるAzure Active Directory連携のDesktop SSOあたりが要素技術としての紹介内容となります。

また、非技術側面では、グローバルでID管理プロジェクトを進める上で、何をあきらめて、どうやってリスクを担保するのか?といった話が中心となります。こちらはInternet Week的にはちょっと珍しい話になるのかもしれません。


また、一緒に登壇する江川さんからは「なぜID管理やID連携が必要なのか?」といったそもそも論の話とIDaaSなど最近の業界トピックスについて、勝原さんからはこれからの企業にとってDigital Identityは競争力の源泉となっていく、という刺激的な話もありますので、個人的にもとても楽しみです。

どうやら登録受付は終了してしまったようですが、デモの内容などは本ブログでも公開していきたいと思いますので、お楽しみに。
(告知をするのが遅すぎました・・・)


[MIM] Microsoft Identity Manager 2016 SP1 の更新版インストーラが公開

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

こちらもしばらく寝かせてしまったネタなので、少々古くなっていますが。。。

先の9月に公開されたMicrosoft Identity Manager 2016 SP1ですが、実は既存環境へ適用するのに一旦アンインストールしてから再インストールが必要、という無茶なアップグレードパスしかなく、あちこちから避難ごうごうだったんですが、リリースから1か月半が経過しようとしている11月の初旬にようやく更新版インストーラ(MSP版)が公開されました。

公式ブログ
 Microsoft Identity Manager 2016 Service Pack 1 update package
 https://blogs.technet.microsoft.com/iamsupport/2016/11/08/microsoft-identity-manager-2016-service-pack-1-update-package/


※ちなみに新規インストールする方はMSDNなどでSP1適用済みメディアが公開されているので、そちらを使うことになると思います。


これでようやく安心してサービスパックが適用できるようになりますね。

ちなみに、先に出たSP1(アンインストールが必要な版)のビルドは4.4.1237.0でしたが、今回のSP1を適用すると4.4.1302.0になるようです。

[Azure AD] Azure AD ConnectがようやくWindows Server 2016に対応

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


これまでもWindows Server 2016にインストールして使ってしまっていたAzure AD Connectですが、11月版の更新(ビルド1.1.343.0)でやっと正式にWindows Server 2016への対応をしました。

Azure AD Connect version history
https://docs.microsoft.com/en-us/azure/active-directory/active-directory-aadconnect-version-history


細かいバグフィックスと同時に、SQL Server 2016への対応、およびAD FS 2016の管理についてもサポートする様になったので、新しい環境に導入する場合はこのバージョンを使っていきましょう。

Tech Summitの資料と動画が公開されていました

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

公式に資料と動画が公開されていました。


当日は詰め込んだところもあり、後半は結構早口になっているので資料と合わせておさらいをしてもらえると幸いです。

「アイデンティティのMVPが語るAzure ADとアプリ連携の勘所」

動画)

資料)
https://docs.com/mstechsummit16/c1cf9d12-5f48-4668-a630-39d708bc026d/sec020-mvp-azure-ad



ちなみに、ハンズオンの動画は公式には公開されていないので、こちらでどうぞ。
http://idmlab.eidentity.jp/2016/11/azure-ad-tech-summit-2016.html


[Azure AD] IE/Edge以外でAzure ADにSSOする(Desktop SSO)

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

これまでAD FSとAzure ADを比較する際に重要なポイントの一つだったのが、PCへのログオンからブラウザ・アプリケーションへのシングルサインオンです。これをDesktop SSOと呼んでいます。

AD FSは統合Windows認証が利用できるので、ドメインネットワークではDesktop SSOが実現できましたが、Azure ADの場合はWindows 10でWindows Hello for Businessを使わないとDesktop SSOは実現できませんでした。

また、AD FSの場合はChromeやFirefoxなどIE/Edge以外のブラウザでもDesktop SSOを行う方法がありましたが、Windows Hello for Businessを使った場合はIE/Edge以外のブラウザでDesktop SSOを行うことはできませんでした。

参考)MVP渡辺元気さんのBlog : 「IE以外でADFSにSSOする」
    http://blog.o365mvp.com/2014/07/07/sso_adfs_without_ie_2012r2/


この課題を解決するために新たなAzure ADの機能「Desktop SSO」のプレビュー版として公開されました。

 公式アナウンス
  Enterprise Mobility and Security Blog
  Introducing #AzureAD Pass-Through Authentication and Seamless Single Sign-on
  https://blogs.technet.microsoft.com/enterprisemobility/2016/12/07/introducing-azuread-pass-through-authentication-and-seamless-single-sign-on/

 詳細ドキュメント
  https://docs.microsoft.com/en-us/azure/active-directory/active-directory-aadconnect-sso


 動作イメージ(公式ドキュメントより)

このAzure AD Desktop SSOを利用すると、Windows 7/8/8.1/10のPCにおいてChromeやFirefoxを使った場合でもシームレスにAzure AD連携しているアプリケーションへサインオンできるようになります。(Windows 7/8/8.1でIEを使った場合でもSSOできるようになります)


セットアップは簡単で最新版のAzure AD Connectを使い、

  • 認証方式に「Password Hash Sync」もしくは「Pass-Through Authentication」を設定する
  • イントラネットゾーンに以下の2つのURLを入れる
    • https://autologon.microsoftazuread-sso.com/
    • https://aadg.windows.net.nsatc.net/

の2つを行うだけです。

結果、こんな感じで動きます。
Azure ADのログイン画面でIDを入れるとパスワードを入れることなく自動的にサインインが行われます。



ますますAD FSを使わなくても実現できることが増えてきました。。。。

[告知]Japan Web API Community #1 で OAuth2.0 の話をしてきます

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

またまた定員オーバーな状態からの告知です。いつもblogに書くのが遅いんですね。。。

まだキャンセル待ちが2名(12/12朝時点)なので興味のある方は補欠申し込みをしておけば入れるかもしれませんので、どうぞよろしくお願いいたします。


と、いうことで、中身です。

Web APIをテーマとしてコミュニティをMVP優吾さんが立ち上げる、ということで少し OAuth 2.0 についてお話してきます。
(初回ということなのであんまりガチな話をするとドン引きされると思うので優し目を心がけます・・・。Azure AD を使ったデモなどもお見せする予定です。)

登録ページはこちらです。
https://jwacom.connpass.com/event/45812/


ロゴが素敵ですね。



ページを見ると、対象者は以下のような方々、ということで非技術者を含めた入門レベルから、といったところでしょうか。とても楽しみです。

  • 何らかの Web API に軽い気持ちで接続しようとして、非常に苦労した人
  • この API はこうやって使うんだ!ドヤァな人
  • あれとこれを組み合わせると、ほら新たなサービス確立!
  • API に完全なるノンコーディングで繋ぐにはどうすればよいか、知りたい人
  • API の価値が知りたい人
  • Web API って何?という人(大歓迎です!)

こちら概要です。マイクロソフトの品川のセミナルームを使うそうなので、110名の定員となっています。また、平日の夕方ということでお仕事帰りのエンプラエンジニアの方にも参加しやすい感じです。

項目内容備考
名称Japan Web API Community 第1回勉強会名称は仮です。
日時2016年12月21日(水) 18:30 - 21:00開始時刻は仮です。
場所日本マイクロソフト株式会社 31F / セッションルームA
その他受付開始 18:00 ~

そしてこちらがタイムスケジュールです。
他のセッションがノンコーディングで!とうたっている中、プロトコルの話をして大丈夫なのか、、、という話もありますが、なるべく優しく話をしたいと思います。
No.時刻タイトル発表者
118:30 - 18:40(10分)ご挨拶主催者(清水、疋田より)
218:40 - 19:10(30分)Web API をノンコーディングで使えるツールやサービスのご紹介CData Software Japan 合同会社 桑島 義行
-19:10 - 19:15(5分)休憩
319:15 - 19:45(30分)OAuthによるWeb APIの保護伊藤忠テクノソリューションズ株式会社 富士榮 尚寛
-19:45 - 19:50(5分)休憩
419:50 - 20:20(30分)This is Zapier.ノンコーディンでPPAP♪サイボウズ株式会社 北川 恭平
-20:20 - 20:25(5分)休憩
520:25 - 20:55(30分)【フリートーク】Web API あるあるネタ!~第2回に向けて~(仮)主催者 清水 優吾

お会いできるのを楽しみにしております。


Viewing all 769 articles
Browse latest View live