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

2024年5月1日水曜日

Trusted Signing(元Azure Code Signing)がPublic Preview

こんにちは、富士榮です。
ちょっといつもと話題を変えてコード署名の話です。

昔から(少なくともプロダクションの)コードに署名しましょう、という話はありましたが署名するための環境を用意するのは面倒くさいという難点がありました。

ということでこの辺りをas a ServiceとしてMicrosoftが提供しようとしているのがAzure Code Signingなのですが、これが「Trusted Signing」としてPublic Previewになりました。

アナウンス

サービス内容はこちらのようです。基本的にマネージドな基盤として提供され、GithubやVisual StudioなどのCI/CDに組み込んでいくこともできるものです。
  • We manage the full certificate lifecycle – generation, renewal, issuance – and key storage that is FIPS 140-2 Level 3 HSMs. The certificates are short lived certificates, which helps reduce the impact on your customers in abuse or misuse scenarios. 
  • We have integrated into popular developer toolsets such as SignTool.exe and GitHub and Visual Studio experiences for CI/CD pipelines enabling signing to easily integrate into application build workflows. For Private Trust, there is also PowerShell cmdlets for IT Pros to sign WDAC policy and future integrations with IT endpoint management solutions. 
  • Signing is digest signing, meaning it is fast and confidential – your files never leave your endpoint. 
  • We have support for different certificate profile types including Public Trust, Private Trust, and Test with more coming soon! 
  • Trusted Signing enables easy resource management and access control for all signing resources with Azure role-based access control as an Azure native resource. 
  • To learn more about the service go to: https://learn.microsoft.com/azure/trusted-signing

まぁ、当然お金はかかるわけですが、自前でCAを立てて運用するよりは楽ですね。

  • BASICプラン
    • 基本料金:$9.99/月
    • 月間署名数上限:5,000
    • 上限超過分:$0.005/署名
    • プライベート署名、パブリック署名それぞれについて1つの証明書プロファイルポリシーの定義が可能
  • Premiumプラン
    • 基本料金:$99.99/月
    • 月間署名数上限:100,000
    • 上限超過分:$0.005/署名
    • プライベート署名、パブリック署名それぞれについて10個の証明書プロファイルポリシーの定義が可能

ちなみに使おうとするとサブスクリプションのResource ProviderにMicrosoft.CodeSigningを登録してあげる必要があります。
くわしくはこちらから。




まぁぼちぼち使ってみますかね。。。

2024年4月3日水曜日

CopilotにEntra IDのことを聞いてみた

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

今月からCopilot for Securityが正式ローンチということで盛り上がってますね。
Copilotはあまりウォッチしてこなかったので正直使い方を含めあまりわかっていませんが、取り急ぎセットアップはしてみました。(高いのですぐ消したけど)

ということでその記録です。

まずはこちらからセットアップを開始していきます。

管理権限のあるユーザでサインインするとセットアップが始まります。
必要な情報を入れていきます。
  • サブスクリプション
  • リソースグループ
  • 容量の名前
  • プロンプトの評価場所
  • 容量リージョン
  • ユニット数(1時間あたり4ドル/ユニット)
しかし高い!1ユニットだけでも月間2880ドル、1ドル=150円とすると432,000円です。まぁ、優秀な副操縦士(Copilot)がこの値段で雇えるならまあいいか、という話だとは思いますが個人課金のレベルではなさそうです。。

ちなみに、USリージョンを選んでセットアップをしていたのですが、一時的な問題なのかうまくセットアップが完了しませんでしたがUKを選んだらうまくいきました。

Copilotのリージョンとは関係なくデータはサブスクリプションの紐づいたリージョンに保存されるっぽいですね。

もう少しです。

設定が終わるとダッシュボードに遷移します。



まだあまり数はありませんがプロンプトライブラリも用意されています。


日本語で聞いてみると色々教えてくれます。

ちょっと難しい質問をしたらおかしな回答が返ってきたので英語でもう一度聞いてみましたが、やっぱりおかしな回答が返ってきました。
仲良くなるにはまだ時間がかかりそうです。
(課金が恐ろしいので消しちゃいましたが・・・)


ちなみに、別の方法でセットアップを行うこともできます。Azure PortalからCopilot for Securityのリソースを探して追加する方法です。先の方法はARMテンプレートを使ってセットアップしているだけなのでPortalでの方法とやっていることは変わりませんが。







2018年12月19日水曜日

TechSummitのおさらい②:Azure ADとSaaSアプリのSSO構成時のトラブルシュートあれこれ

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

前回に引き続きTechSummitのフォローアップです。

今回は2つ目のネタ「SaaSアプリのSSO構成時のトラブルシュートあれこれ」についてです。

簡単に言うと、同じ種類のSaaSアプリを複数インスタンス(例えば本番環境と開発環境とか)を単一のAzure ADとSSOの構成をしようとすると動きがおかしくなる「ことが」ある、というお話しです。

よくあるシーンはこんな感じで、本番・開発の2環境を用意したいけど、Azure ADってテナント毎、ユーザ毎のライセンスなので出来ればAzure ADは単一の環境で済ませたいよね、っていう話です。

TechSummitでは個人的な経験を基に、G Suiteを複数インスタンス用意してSSOを構成しようとしたとき、たまに発生する問題を紹介しました。
※ちなみにSalesforceでも起きることがあるようですが、すべてのアプリで発生するわけではありません。また、G Suiteでも毎回起きるわけではありません。

何が起きる(た)のか

先ほど書いたように、毎回起きるわけでもなく、発生条件も良くわからない状態なので、ここに書いたことが必ず起きるわけでもなく、他に発生する問題がある可能性もありますが、とりあえず私が体験したことを書いていきます。

  • NameIDの値のマッピングが上手くいかない(UPNを使ってくれない)
  • SP EntityIDが一致していない、と言われる


NameIDのマッピング不良と対策

まずは前者です。
初期状態のAzure ADはG SuiteのSSO構成時、NameID属性としてuserPrincipalName属性をマッピングします。また、G SuiteのNameID Formatの指定はunspecifiedです。

通常、この構成だとAzure ADはuserPrincipalNameの値をそのままG Suiteへ渡すのですが、なぜか仮名が生成されてNameIDとして渡されてしまうことがあります。通常はNameID FormatがTransientやPersistent以外は仮名が生成されることは無いはずなのですが、何かがおかしいです。


これを解消しようとすると、Azure AD側のでNameID Formatを明示的に指定してあげる(つまり、G Suiteからの指定を無視する)必要があります。
G Suiteはメールアドレス形式でNameIDの値が飛んでくるのを期待しているので、NameID Formatをemailaddress(電子メールアドレス)にしてあげます。


これでうまくいきます。


SP EntityIDの不一致

次に、SSOを試みた時に出てくる「AADSTS65005: Misconfigured application」エラーへの対策です。このエラーはAzure AD側でアプリケーション構成がおかしいので見直せ!というエラーです。


最近はAzure ADのSSO構成も人にやさしくなっており、エラーの詳しい原因が管理ポータルからある程度確認できるようになっています。(Salesforceが昔から実装していた機能ですね)
これまでSAMLのやり取りをトレース&解析しないとダメだったのですが、この機能が出来てかなり楽になりました。

この機能を使って先のエラーの原因を探ると、なぜかSP EntityID(要するにアプリケーションを一意に識別する情報)がマッチしていない、と言われます。どう見ても一致してるんですが・・・
もちろんアプリケーションが一つしか構成されていない状態ではこのようなことは言われないのですが、G Suiteを複数インスタンス構成するとタマにこのエラーが出ます。
※ちなみに昔はもっとひどかった(構成するとユーザの割り当てが混ざったりしていた)ので、マシにはなったんですが・・・


実はこのエラーが出ると、Azure AD側ではどうしようもなく、強引に複数のG Suiteインスタンス間でEntityIDが絶対に重複しない様に構成を工夫するしかなくなります。
今回やったのは、片方のG Suiteについて、Google側でEntityIDにドメイン固有情報を含めるのを辞める、という苦肉の策です。
これで複数のG Suiteインスタンス間で必ず異なるEntityIDが使われるようになるので、問題が解決します。(本来はこんなことをしなくても必ず異なるEntityIDは使われるんですが)



まぁ、今回紹介したものは発生することもある、というレベルなので仕組みを理解した上で適度に使ってもらえれば、というレベルの話でした。

引き続きフォローアップをしていきますので、お楽しみに。


2018年2月13日火曜日

[Azure AD]Duo Securityを使った3rdパーティ多要素認証を行う

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

昨年10月に公表されてから時間が経ってしまいましたが、Azure Active Directory(Azure AD)でマイクロソフト純正の多要素認証プロバイダ(いわゆる買収したPhoneFactorですね)ではなく、サードパーティの多要素認証プロバイダ(今のところ、RSA、Duo、Trusonaの3社)を使って多要素認証が出来るようになっています。(現在、Preview)
※ちなみにAzure AD Premium P2のライセンスが必要な機能です。高いので私はトライアル版を使っています。

公式ブログ
 Azure AD + 3rd party MFA = Azure AD Custom Controls
 https://blogs.technet.microsoft.com/cbernier/2017/10/16/azure-ad-3rd-party-mfa-azure-ad-custom-controls/


ようやく試してみましたので、簡単に紹介して行きます。
ちなみに今回はDuoを試してみました。
(RSAはトライアル版がなかったのと、Trusonaは個別に設定をしてもらわないとダメらしく断念しました)

後、ちなみに自前でカスタムMFAプロバイダを作ってAzure ADと連携させるってこともプロトコル上は可能になっていますが、現状はマイクロソフトに承認を受けたプロバイダしか登録が出来ないということなので、こちらはもし調整がついたらやってみたいと思います。

では早速。

◆Duoのアカウントを作る

まずはココからです。
Duoのサイトへアクセスし、右上にあるStart Trialをクリックすると無償トライアルへのサインアップが出来ます。
登録を進めると、アカウントのアクティベーションを行う場面が出てきます。

ここではDuo MobileというモバイルアプリをインストールしてQRコードを読み込む必要があります。
早速インストールしてADD AccountでQRコードを読み込みます。
うまく追加できるとこんな感じでアカウントが表示されます。


横道にそれますがDuo Mobileは端末の状態を確認して問題があると警告を出してくれます。問題があると画面の下部に表示されるのでFix Nowをタップすると詳細が見れます。
今回はiOSが最新でない、という警告でした。他にもTouch IDが有効になっているか、とか脱獄していないか、などについて確認が行われます。

なんだかんだでセットアップが完了するとDuoの管理コンソールへたどり着きます。


ひとまずこれでDuoのアカウント作成は完了です。

◆Azure ADと接続するためのアプリケーション設定を行う

ややこしいんですが、Azure ADから見てDuoはIdentity Providerです。ということは、Duoから見るとAzure ADはRP、つまりアプリケーション(OAuthクライアント)となります。
(ちなみにAzure ADとDuoの間はOpenID Connectで繋がります)

ということで、Duo上にAzure ADをアプリケーションとして登録する必要があるのですが、DuoではプリセットでAzure ADと接続するための設定が入っていますので、こちらのテンプレートを使っていけば非常に簡単にセットアップが出来ます。

アプリケーションの検索画面に「Microsoft」とキーワードを入れるとAD FSやOWAなどと共にAzure ADが出てきますので、こちらを選択します。

アプリケーション設定画面に行くとシンプルに「Authorize」というボタンが現れますので、こちらをクリックしていきます。

するとAzure ADのログイン画面が出てきますので、管理者でログインします。するとAzure ADのディレクトリへの読み取り権限などを要求されるので認可を行います。
ちなみに、DuoでMFAしてログインする通常の流れにおいてはDuoがIdP、Azure ADがRPという構成ですが、ここではディレクトリの情報を読み出すためにDuoがRP、Azure ADがIdPという構成になります。ややこしいですね。

上手くいくと、Duoの管理画面にAzure ADに設定するための構成情報(json)が表示されます。

ここで表示されるjsonは後でAzure AD側に設定するのでコピーしておきます。

これでDuo側の設定は完了です。
非常にシンプルです。

◆Azure AD側にDuoをカスタムMFAプロバイダとして登録する

DuoのようなカスタムMFAプロバイダは条件付きアクセスの一つの条件として扱われます。そのため、設定は条件付きアクセスの中のCustom controlsというメニューから行います。(Azure AD Premium P2のライセンスが割り当たっていないとこのメニューは出てきません)

ここでNew custom controlをクリックすると、いきなり巨大なテキストボックスが現れるので、先ほどのjsonを貼り付けてCreateをクリックします。

これで完了です。
上手くいけば、こんな感じで一覧にDuoが出てきます。

後は、普通の条件付きアクセスと同じです。
ポリシーを書く時のControlとしてDuoMFAを要求する、という形で設定すると条件に当てはまったアクセスだとDuoのMFAが要求されます。


◆テストしてみる

ポリシーの作成が終わったら念のためポリシーの適用が正しく行われるか確認してみます。
 ※事前に確認するには先日紹介したWhat Ifを使うと便利です。
 http://idmlab.eidentity.jp/2018/01/azure-adwhat-if.html

該当のユーザでの初回アクセスだとMFA設定を促されますので、画面に従いMFA設定を進めます。

利用するMFAの方法を選択します。

モバイルを選択したので、携帯の番号は入れさせられます。この辺りはAzure AD純正のMFAと一緒ですね。

何故かモバイルの種類を選択させられます。アプリのインストールを促すためでしょう。

既にインストール済みなのでI have Duo mobile installedを選んでスキップします。

ここでようやくQRコードが出てくるので先ほど管理者がやったのと同じくアプリを使ってアクティベーションを行います。

上手くアクティベーションが終わると、認証の方法を指定します。
毎回方法を聞いてくるか、PUSH通知 or ワンタイムコードの表示をあらかじめ指定しておくことが出来ます。
ここでは毎回方法を聞いてくるように指定しました。

ここで設定が終わったので、ようやく実際のMFAです。(次からはこの画面がスタート地点になります)
毎回聞いてくるように指定をしたので、方法を選択する画面が表示されます。

PUSHを選択するとモバイルアプリに通知がされてきます。

この辺りは純正と同じですね。
ここでApproveをするとログインが完了します。

◆補足(id_token_hintの利用について)

ちなみに、アプリ⇒Azure AD⇒Duoという流れでFederationが連鎖している状態でのMFAをやろうと思うと、セッション管理をちゃんと実施しないといけません。通常はAzure ADのIdPがDuo、という構成だとDuoで認証されたらそのままAzure ADでも認証されたことにしてしまうためです。
Azure ADが外部MFAプロバイダ連携をする際、セッションをコントロールするためにid_token_hintというものを使っています。

OpenID Connect coreのスペックではid_token_hintについて以下のように記載されています。
Authorization Server が以前発行した ID Token. Client が認証した End-User の現在もしくは過去のセッションに関するヒントとして利用される. もしこの ID Token に紐づく End-User が認証済, もしくはこのリクエスト中で認証された場合, Authorization Server はポジティブレスポンスを返す. さもなければ, Authorization Server は login_required のようなエラーを返す (SHOULD).

つまり、最初にAzure ADでID/PWDで認証された結果の情報をid_token_hintに入れた状態でDuoへ渡し、Duoで追加の認証が上手く行われたらポジティブレスポンス(何を返すか、についてはjsonの中に書いてある通りで、Duoの場合はMfaDoneというメッセージを返します)をAzure ADへ返します。

Azure ADからDuoへPOSTされるid_token_hint。認証されたユーザの情報が入っています。

これに対してDuoからの返事となるid_token。成功したのでMfaDoneが返っています。


細かくはスペックを読みましょう。
http://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html



2018年2月7日水曜日

[Azure AD B2C]複数SNSアカウントの連携、GitHub連携等の追加機能がリリース

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

Azure Active Directory B2C(Azure AD B2C)の追加機能のリリースがアナウンスされています。

公式Blog
 Lots of News about Azure AD B2C feature updates!
 https://cloudblogs.microsoft.com/enterprisemobility/2018/02/05/lots-of-news-about-azure-ad-b2c-feature-updates/

これまでAzure AD B2Cの弱みの一つだったのが、SNSアカウントでサインアップしたAzure AD B2Cアカウントを他のSNSアカウント変更したり、追加で別のSNSアカウントを追加で紐づけることが出来なかった、という点でした。

これまでは、カスタマイズをすることにより、以下を実現してきました。
・ローカルアカウントにSNSアカウント(同時に一つだけ)を紐づける
 *Graph APIで作成したアカウント、もしくはメールアドレスとパスワードでサインアップしたアカウント
・上記のアカウントに紐づけたSNSアカウントを別のSNSアカウントへ紐づけ直す
 *同時に一つだけ、という制限があり最初に紐づけたSNSアカウントでログインは出来なくなる
※他にも色々とトリッキーなカスタマイズすれば出来ることは多々あるのですが、ここでは解説しきれないので省略します。


今回のリリースでGraph API経由でSNSアカウントの識別子をAzure AD B2Cへ書き込むことが出来るようになったため、このカスタマイズが柔軟に出来るようになりました。
(Preview機能、かつGraph APIを使った開発は必須。頑張ればカスタムポリシーでも組めなくはないとは思いますが)

このGraph API辺りの詳細は別途書こうと思います。


他にリリースされた機能は以下の通りです。
<プレビューとしてリリース>
・パスワードポリシーのカスタマイズ
・監査ログの出力(id_tokenやaccess_token、認可コードの発行の記録など)
・外部Identity ProviderとしてGitHubと連携
・多言語対応の強化
・アクセストークン関連の強化(Client Credentialのサポート?)
<正式リリース>
・外部Identity Providerとしてtwitterと連携
・Graph API(ver. 1.6)経由でのSNSアカウント識別子の操作(先ほどの話)


GitHub連携はこれまでカスタマイズで対応していたので、正式対応したのはとても助かります。他にもInstagramなど独自カスタマイズで実装してしまっている連携先も色々とあるので、基盤側で取り込んでもらえると楽になれそうな気がします・・・


今後も色々と拡張が予定されているようなので引き続きウォッチしていきたいと思います。
ちなみにまだデプロイ中らしく、テナント毎に徐々にこれらの機能が有効化されてくるそうです。ゆっくり待ちましょう。

2018年1月15日月曜日

[Azure AD/Intune]ログイン画面からPINをリセットする(モバイル編)

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

前回はAzure AD JoinしているWindows 10 PCのPINをログイン画面からリセットする方法を紹介しましたが、今回は今更ながらですがWindows 10 MobileのPINをリセットする方法です。

今更ではありますが、最近Lumia 950を滅多に起動しなくなり、PINを忘れてFactoryリセット、、、という繰り返しをしていたので、最初からこの方法を実装しておけばよかった・・・と後悔したので。。

さて、やり方ですが実装方法は前回とほぼ同じですが、リセットの方法が若干異なります。(管理者がIntuneの管理画面からリセットします)

ということで早速。

◆必要な物、準備事項

  • デバイス
    • Azure AD参加したWindows 10 Creator Updateが動作しているデバイス(Creator Update/1703からこの機能は使えるとドキュメント上は書いてあります。が、私の環境が既にFall Creator Update/1709だったので1709でしか試していません)
  • ライセンス
    • 該当ユーザにIntuneのライセンスが割り当たっていること
  • 設定
    • IntuneでPINリセット用のプロファイルを構成していること

◆Intuneでデバイス構成プロファイルを作成する

ここはPC用と同じプロファイルが使えるので、前回紹介したものをそのまま使います。
尚、ドキュメント上はMicrosoft PIN Reset Service IntegrationとMicrosoft PIN Reset ClientをAzure AD上にプロビジョニングしておかないとダメ、とありますがどうやらこの手順は無くても動きそうです。(どうしても動きがおかしい場合は試してみても良いかも知れませんが)

念のため、Microsoft PIN Reset Service IntegrationとMicrosoft PIN Reset Clientのプロビジョニング方法です。

- Microsoft PIN Reset Service Integration

Intuneテナントの管理者でこのURLにアクセスし、ディレクトリへのアクセス権限を与えます。

承諾すると、エラーが出ますがこれでOKです。

- Microsoft PIN Reset Client

同じくIntune管理者でアクセスします。

こちらもエラーが出ますがOKです。
(カスタムスキームだったので、Azure AD Joinした端末へIntune管理者でログインしたり、Windows 10 Mobileからアクセスしてみましたが、結果は同じだったのであまり関係ないのかも知れません)


エラーは出るものの、上記2つを実行することでAzure AD上にサービスがプロビジョニングされます。私の環境ではあっても無くてもPINリセットは実行できたので無くてもOKかも知れません。


◆リセットする

モバイルの場合はPCとは異なり、ログイン画面から自分自身でPINをリセットすることはできず、あくまでIntune管理者へリセットを依頼することになります。

- 管理者によるリセット要求

Intuneの管理画面で対象のデバイスを選択、Overviewの一番右上のドロップダウンよりReset passcodeを選択します。

確認画面が出てリセット要求が行われます

しばらく(5分~10分くらい)して画面をリロードすると新しいPIN(テンポラリPIN)が表示されます。(7日間表示されるので、この間に利用者へ通知してリセットさせるという方式です)

- 利用者側の操作

管理者がPINのリセット要求を行うと一時的に端末がロックされます。

完了を押すと管理者から聞いたテンポラリPINコードを入力する画面が出てきますので、入力します。
(尚、不具合だと思うのですが、管理者側で発行したテンポラリPINコードにモバイルのキーボードで入力できない文字記号が含まれることがありました。その場合は再度管理者にテンポラリPINコードを発行してもらう必要があります)

入力が完了すると、自身で使うPINを登録することが出来るようになります。ここで設定したPINが以降デバイスのロック解除を行うPINとなります。

上手くいけばデバイスを使えるようになります。



もうWindows 10 Mobileを使うことも減ってくるとは思いますが、PINを忘れるたびにリセットして写真やデータが消える、ということもなくなるので使用頻度が減ってきた今がPINリセットを実装しておくべき時なのかも知れません。