パスキー（Passkeys）を使った認証を試してみる

最近何かと話題の「パスキー（Passkeys）」。いろいろ調べてみましたが、一応、以下が私の認識です。

【パスキーとは？】
・FIDO2認証技術を利用しており、FIDO認証方式の1つ（だと理解している）。
・認証デバイスをPCがBluetoothで自動検出する仕組みがあるので物理的に認証デバイスを差す必要がない。
　→これは「caBLE」というパスキーの関連技術の1つ。
　→外部デバイスを利用する場合、やり取りはQRコードの読み取りからスタート。
　→MacbookのTouchIDなど内臓センサーを利用するのが楽。
・認証デバイスに入っている（認証で利用する）秘密の鍵はアカウント間で共有される。
　→故にどのデバイスでも同じアカウントでログインしていれば、認証デバイスとして使える。
　→そして、現時点では認証デバイスを固定できない（日本の企業だと受け入れられないのでは・・・）。

という事で、文字の説明だけだといまいち「何がうれしいのか？」分からないので、実際に試してみました。

■前提条件

パスキーを利用するためには、認証を行うWebサービス（SP）やSSOしている場合にはID Provider（IdP）がパスキー（FIDO2認証）に対応している必要があります（パスキーの認証技術はFIDO2を採用している）。そしてもちろん認証デバイスもパスキーをサポートしている必要があります。また、今回は外部認証デバイスとして「iPhone13」を利用するのでクライアントPC（Windows11）と認証デバイス（iPhone13）の「Bluetooth」を「ON」にしておきます（ペアリングはしなくて大丈夫です！）。これで認証時にブラウザが「Bluetooth」通信を介して認証デバイスを探したり、やり取りを行うことができます。

【前提条件】
・認証を行うWebサービス（SSO環境ではIdP）が「パスキー（FIDO2認証）」に対応している必要がある。
・利用するブラウザと認証デバイスがパスキーに対応している必要がある。
・認証を行うWebサービス（SSOしている場合にはIdP）に認証デバイスの事前登録が必要。
・クライアントPCと認証デバイスの「Bluetooth」を「ON」に設定（今回はIPhoneを利用するため）。

■パスキーを使った認証の流れ

パスキーを使った認証の大まかな流れは以下となります。

①　認証デバイス（今回はiPhone13を利用）の登録（事前準備）
②　認証時にブラウザが「パスキーがあるデバイスの選択画面」を表示
③　デバイス選択後（今回は「別のデバイス」を選択）、ブラウザが「QRコード」を表示
④　「Bluetooth」通信でデバイスを検出
⑤　認証デバイスで「QRコードを読み取り」
⑥　認証デバイスで認証（今回はiPhoneを利用しているのでFaceIDで認証）
⑦　認証完了情報を「「Bluetooth」通信で返却

↑ブラウザ上にこんな感じのポップアップが表示されます。まさかの「QRコードをスマホで読み取る」んですね。iPhoneのカメラをかざすと「パスキーでサインイン」って黄色い文字が表示されます。文字をタップするとiPhoneが「パスキーをiCloudに保存するか？」みたいなメッセージを（最初だけ）出すので、「続ける」ボタンをタップしてください。2回目以降は「保存済みのパスキーを使用してサインインしますか？」というメッセージに変わります。今回はiPhone13を利用しているので「FaceID」で顔認証すると、待ち状態になっていたブラウザ画面がログイン完了に変わっていると思います。

う～ん・・・どうでしょう・・・今回、認証デバイスとして（内臓センサーではなく）外部デバイスを利用するので、QRコードの読み取りが必要だったわけですが、追加の認証方式としてはワンタイムパスワード（OTP）のほうが簡単で手間は少ないです。もちろん、OTPはネットワークに（使い捨てのパスワードとは言え）認証クレデンシャルが流れるし、フィッシングサイトに誘導された場合の事を考えると、“パスキーの方がより安全です”という理屈は分かります。それとパスキーを使った認証、FIDO認証はそれ単体でも利用ができるセキュリティ強度を持っているので、OTPと比較するのもちょっと違うなとも思いますけどね（OTPは「パスワード認証+OTP」という形で利用され、OTP単体の認証のみではセキュリティ強度は高くないとされています）。

■認証デバイス検出の仕組み

認証時にブラウザが「Bluetooth」で近くの認証デバイスと通信する仕組みは、図のようになっているようです。「caBLE（Cloud-Asisted BLE）：今は”hybird”って呼ばれている？」について詳しくないので、何となくのシーケンスです。もともとはGoogleが作った仕組みで、Googleの2段階認証プロセスにて、スマートフォンを利用する方式（「ログイン済みGoogleアプリを起動」するなど）があったと思いますが、その技術を拡張したものらしいです。

■使った感想

パスキーの利用は現時点では微妙な印象でした。パスキーのコンセプトは認証に利用する鍵をアカウントと紐づけて、そのアカウントでログインしている端末であれば鍵を共有できる、ってところが大きなポイントだと思っていますが、「鍵はデバイス間で共有されさまざまなデバイスから利用できると組織として困る」と思う方もいると思います。

なんとOktaではPasskeyの利用をブロックする仕組みがありました！
https://help.okta.com/en-us/Content/Topics/Security/mfa-webauthn.htm

Okta Help Center

また、プラットフォーマ（Google、Apple、Microsoft）間でのパスキー相互利用の問題などはこれから決まってくると思うので、現時点でパスキーを積極的に利用するモチベーションはないです・・・まだまだ仕様も変更になるようですし、時期尚早かなと思いました。

今回の検証でFIDOデバイスとしてWindows Hello/Apple FaceID/Apple TouchIDが利用できれば、パスキーを利用しなくてもしばらくは良いと感じました。

■参考資料
【Apple社サポートページ：iPhoneでパスキーを使ってサインインする】
https://support.apple.com/ja-jp/guide/iphone/iphf538ea8d0/ios

【Add registration/authentication extensions for cloud-assisted BLE #909】
https://github.com/w3c/webauthn/pull/909

今話題？のISMAP（イスマップ）って何！？

ISMAP（イスマップ）とは、「Information system Security Management and Assessment Program」の略称で、官公庁、自治体など政府がシステムを調達するときに、指標となるセキュリティ評価の制度です。ISMAPに登録されてる製品、サービスであれば、政府調達のためのセキュリティ基準を満たしているので、安心して購入ができます。

また、政府は、「原則としてISMAP取得企業からクラウドサービスを調達するように」と言っています。あくまで「原則」なので、ISMAPを取得していると有利に働くものの、取得していないからと言って全く土台に乗れないということではありませんが・・・。

更に、官公庁、自治体だけでなく、大学や教育委員会などの文教市場でも「ISMAPに対応していること」などの条件が入札仕様に（今後）入ってくることが予想されます。実際、案件の問い合わせで「ISMAPのリストに載っていますか？」って聞かれたことがありました。

■取得にかかる費用はすごく高いらしい

ISMAPの取得自体、審査がかなり厳しく、取得にかかる費用も結構高いらしいです。聞いたところによると「取得までに2,000万ぐらいかかった」とか、それ以上かかった話も聞きました。マジかよ・・・。そして資格には有効期限があるので更新する必要があるのですが、その費用も高額との話でした。ウソでしょ・・・。

サイボウズ社のサービスはISMAPに登録されていますが、登録までの苦労話を資料にまとめて公開してくれています（ありがてぇ！）。

【サイボウズ様のISMAP登録挑戦苦労話】
https://www.cloudsecurityalliance.jp/site/wp-content/uploads/2021/12/congress2021_akeo.pdf

【ISMAP対応のクラウドサービス一覧】
https://www.ismap.go.jp/csm?id=cloud_service_list

■中小クラウンドベンダーからの視点

ISMAP取得は相当高いハードルがあるな、という印象です。この手のものって「今後はISMAPを取得していることが大きな優位点なる！」とその時はHot！になるのですが、2～3ヶ月後には話題にもあがらなくなる、と言うのが多いので、慌てずに様子をみましょう。実際、この記事の下書きをしたのが、2022年10月頃なのですが、今は2023年2月でして、やっぱり最近はあまり聞かないワードになっています。ISMAPに対応したサービスもそれほど増えてないし、周りで騒いでいた方も最近ではめっきりですね。

という事で、ISMAPについてはいったん離れます。また再燃したら記事にしようと思います。

AzureADをIdPにしてGoogle WSとSAML連携する

AzureADをIdPとしてGoogle WSとSAML連携をしようと思って設定をしました。SAML連携なので特に問題ないと思って設定しましたが、ちょっとだけつまづいたのでメモとして残しておきます。また、主だった設定の流れは検索すればすぐに情報が出てくるので割愛します。

■SSO連携設定

AzureADの管理コンソールの「エンタープライスアプリケーション」から「Google Cloud / G Suite Connector by Microsoft」を検索して追加します。プラグインの追加を求められるのですが、一般的なSAML連携なので「プラグインって必要なの？」と思いつつ、追加しておきます。実はこれがワナでした。

■ポイント①：識別子（エンティティID）の設定

SAMLの詳細な設定にて、識別子（エンティティID）は以下を設定してください。
・https://google.com/a/ your-domain
・https://google.com
・google.com/a/your-domain
・google.com

この設定に間違いや不足があると、SSOログイン時に以下のエラーが発生します。

■ポイント②：送信属性はNameIDのみ

プラグインを追加した関係で「送信属性とクレーム」の「追加の要求」に余計な属性が追加されています。これがワナでして、Google WSとのSSO連携では「一意のユーザー識別子 (名前 ID)」（NameID）のみ設定すればOKです。余計な設定をしているとSSOログイン時に以下のエラーが発生します。

SAML Responseに不要な属性があっても無視するSPが多いなか、Googleさんは厳密にチェックしているようです。そのため、不要な属性をSAML Responseに含めないようにしてください。必要な「送信属性とクレーム」は「一意のユーザー識別子 (名前 ID)」だけです。

—2022年11月追記—
根本的な原因は「Attribute」に2バイト文字（姓名）が含まれているからでした。日本の場合、姓名に2バイト文字は含まれると思いますよ！ということで認証には不要なので「ユーザー識別子」だけでいいですね。

ちなみに、「一意のユーザー識別子 (名前 ID)」にはUPN以外にカスタム属性なども設定できますので、UPNとは全く別の値も利用できます。AzureADアカウントのUPNが「test001@test.com」だけど、Google WSのアカウントは「Hideo@kojipro.jp」とか、結構こんなケースは多いのでは。。。

■ポイント③：ログアウトURLはちょっと違うよ

Google WS側のSSO設定画面にある「ログアウトURL」の設定ですが、AzureAD側に表示される「https://login.microsoftonline.com/xxxx/saml2」だとうまくいきません。以下のURLを設定してください。

・https://login.windows.net/common/wsfederation?wa=wsignout1.0

■まとめ

ということで「つまづきポイント」をメモっておきました。Googleのプラグインって何なんでしょうね？自動IDプロビジョニングとか、その辺の機能を使うための設定が省力化できるってことかな。。。

【参考：チュートリアル:Azure Active Directory シングル サインオン (SSO) と Google Cloud (G Suite) Connector の統合】
https://docs.microsoft.com/ja-jp/azure/active-directory/saas-apps/google-apps-tutorial

AzureAD SAMLのクレーム変換機能が秀逸

昨今、認証基盤にAzureADを選択するお客様が増えており、様々なサービスとSSO連携設定を行っています。SSO連携先のサービスでは、ユーザーIDがサービスごとに違っているケースがとても多いです。（AサービスのユーザーIDはメールアドレスだが、Bサービスは「社員番号@ドメイン」がユーザーIDになっている、など。）そのような場合、AzureADで使っていない属性に値を入れて「ユーザー識別子」として返す、とかやってますが、「値の変換」もWebGUIから設定出来ちゃいます。

という事で今回、AzureADにSAML SPを登録する流れを簡単にまとめてみました。

■「エンタープライス アプリケーション」への登録

まず最初はAzureADにSSO連携する「アプリケーション」を登録します。

1.「Azureポータル」にログイン、「Azure Active Directory」の管理メニューを表示
2.左メニューの「エンタープライス アプリケーション」を表示し、上部メニューの
　「＋新しいアプリケーション」をクリック
3.上部メニューの「+独自のアプリケーションの作成」をクリック
4.アプリ名称の入力と「ギャラリーに見つからないその他のアプリケーションを統合します
　 (ギャラリー以外)」を選択し、「作成」ボタンをクリック

ちなみに登録したアプリケーションの削除はどこからできるのかな？と思ったら「プロパティ」を表示すると「削除」ボタンがありました。

■シングルサインオンの設定

1.登録したアプリを表示し、左メニューの「シングル サインオン」をクリック
2.「SAML」を選択

「SAMLによるシングルサインオンのセットアップ」メニューが表示されます。手順も①～⑤（最後の⑤は簡易テストなので実質は④まで）と分かり易いGUIで、とても良くできていますね。さすがマイクロソフトさん。以降で順番に細かく見ていきます。

■基本的なSAML構成

AzureAD側（IdP）にSAML SPの情報を入力することで信頼関係を結びます。必要な情報はSAML SPの情報ですのでSP側から情報を聞いて入力してください。

・識別子（エンティティID）：SAML SPには必ずある値です。サービスを一意に識別する値です。
・応答URL（ACS）： これもSAML SPには必ずある値です。もしわからなければ、エンティティIDと
　同じ値を入れましょう。
・サインオンURL：SAML SP側のログインURLを入力します。「省略可」となってますが、
　基本入力しないとうまく動作しません。
・リレー状態：SAML RelayState パラメーターを指定できます。ほとんどの場合、入力する必要は
　ないと思います。（省略可）
・ログアウトURL：そのままですね。値があれば入力に迷うことはないと思います（省略可）

SAML SP側から「メタデータ」がダウンロードできる場合、そのファイルに上記事項は全て記載されていると思います。

■ユーザー属性とクレーム

ユーザー識別子「NameID」に何の値をいれるか？を設定します。また、AttributeととしてAzureADが持つ属性を設定することができます。

ここで面白いのは、SAMLレスポンスに含める値を加工できる機能です。例えば「ExtractMailPrefix関数」ではメール アドレスまたはユーザー プリンシパル名からドメイン サフィックスを除去することができます。これにより、渡されたユーザー名の最初の部分のみが抽出されます。
(例: joe_smith@contoso.com ではなく “joe_smith” のみ)。」

【参考：エンタープライズ アプリケーションの SAML トークンで発行された要求のカスタマイズ】
https://docs.microsoft.com/ja-jp/azure/active-directory/develop/active-directory-saml-claims-customization#editing-nameid

この機能が秀逸で「すごい！」と思いました。AzureADは様々なアプリケーションと連携できるように設計されていて、その機能がWeb GUIから操作できる、っていうのが本当に素晴らしいですね。

■SAML 署名証明書（IdP証明書）

SAML SP側に登録する「IdP証明書」をダウンロードします。SAML SP側に登録する箇所が必ずあるのと思うのでそちらにアップロードしてください。IdP証明書はSPがSAMLアサーションを検証するために必要です。ちなみに「Subject」は「Microsoft Azure Federated SSO Certificate」となっています。

■SAML SP側に設定する情報

ここにはSAML SP側に設定すべき情報が表示されています。SAML SP側に設定する箇所があるのでのコピーして貼り付けてください。

・ログインURL：SAML SP側でも大体「ログインURL」と記載されています。
・Azure AD 識別子： こちらは「エンティティID」を記載されているものもありました。
・ログアウトURL：そのままですね。入力場所に迷うことはないと思います。

■まとめ

SAML SPの登録はとても簡単にできてしまいますね。素晴らしいです。SAMLに対応していないWebアプリケーションは「AzureAD Application Proxy」を使えばSSO連携することができますので、あらゆるWebアプリケーションとのSSO連携が可能な機能を備えているのがAzureADです。もちろんIDプロビジョニング機能もあるのでIDaaSとしての完成度はかなり高いと思いますし、何よりもセキュリティ面で安心できる点が大きと思います。（Microsoftさんでセキュリティ・インシデントがあっても「仕方ないよね」ってなるでしょ？）

今回はここまで。

AzureAD BtoB が便利ですごい

Microsoft Teamsを利用していて、グループ会社やパートナー会社さんのメンバーとTeamsを利用して気軽にチャットやビデオ会議したいなぁ～と思うことありませんか？

AzureAD BtoB（※）機能を利用すればできるんです。AzureADの管理者が外部アカウントの招待を許容していれば、利用者は特に意識することなく招待が可能です。

※TwitterやFacebookなどSNSアカウントを利用 する「AzureAD BtoC」機能もありますが、今回はAzureADにアカウントを持つ企業同士のコラボレーション、という想定で話を進めす。

■アカウント招待の流れと裏の動作

Microsoft Teamsから他企業のアカウントを招待して、チャットや会議を行うための流れです。（自分でも実際に試してみました。）

①「株式会社STechV」の社員Aさんが「株式会社XYZ」の「テスト一郎」さんをTeamsで招待
②「テスト一郎」さんが招待を承諾（認証が必要）
③「株式会社STechV」のAzureADテナントにゲストアカウントが作成される。

・「テスト一郎」さんの「パスワード」情報は同期されない。
・「テスト一郎」さんが認証が必要な場合、元のAzureAD（ホームテナント）にリダイレクトされる。

「株式会社STechV」 のAzureADに招待したゲストアカウントが作成されますが、「#EXT#@ドメイン名」というアカウント名となりますので、AzureADの管理画面でもすぐに分かります。

【注意事項】
「テスト一郎」さんがホームテナントから削除されても、 「株式会社STechV」のAzureADテナントに作成されたゲストアカウントは有効のまま維持されます。ただしホームテナントから削除されているので認証時にリダイレクトされてもアカウントが存在しないから認証はできません。

■Microsoft Teams からはどう見えるか？

招待された側のMicrosoft Teamsアプリではどのように見えるか？組織の切り替えは？という疑問ですが、実際にはTeamsアプリのメニューで「アカウントと組織」から切り替えられることを確認しました。

■まとめ

やっぱりAzureADはすごいなと思いました。単なるIdPとしての機能だけではなくて、企業間連携も念頭に置いて設計されているんですね。もっと言うと、Microsoft365のようなグループウェアだけではなくて、絶対無くならないであろうMicrosoft Officeアプリケーション、IaaSやPaaSを提供するAzure、IdP（SSO）、多要素認証やアクセスコントロールを提供するAzureAD、そしてWindowsというOS・・・これらを相互に（ある意味ブラックボックス的に）連携して提供できるのはマイクロソフト社ならではだなぁ～、と感じました。

皆さんの会社はMicrosoft Teamsを使ってますか？AzureADを利用した企業間コラボレーションしてますか？　私の周囲もTeamsを利用している、AzureADを基盤としている企業が多いです。もはやAzureADを活用しないとビジネス的に一歩乗り遅れるんじゃないかな？、とすら感じるようなインパクトを受けました。

以下の動画がとても分かりやすく参考になりましたので、お時間ある方は一度ご覧になってみては。

【日本マイクロソフト株式会社 公式チャンネル】
Azure AD による Azure 環境管理リファレンスアーキテクチャについて
https://www.youtube.com/watch?v=H7TKjAGT7pA

フェデレーション環境下のおける「Adobe CC のデスクトップアプリ」の挙動について

最近、「Adobe Creative Cloud」とのフェデレーション案件が多く、いろいろと触る機会が多くなってきました。その中で、「Adobe CC のデスクトップアプリ」ってWebアプリじゃないけどフェデレーション環境下でどのように動くのか？という質問が多いため、以下に挙動（画面遷移）をまとめておきます。

 

■アプリケーション パッケージの作成

管理者は「Illustrator」や「Photoshop」などのアプリケーションを1つのインストールパッケージにしてユーザに提供することが多いと思います。「Adobe Admin Console」でパッケージを作成する際、「ブラウザベースのログインを有効化」する項目にチェックを入れてください。デフォルトではチェックは入っていません。ここを有効化すると、「Creative Cloud Desktop Application」のログイン時にブラウザを経由して認証を行うフローになります。逆に無効だと「Creative Cloud Desktop Application」のログインはアプリ内に組み込まれたWebViewで行われます。

 

■実際の認証フロー

例えば、

・Adobe CCがフェデレーション対象
・認証サーバ（IdP）で認証済み状態（OS既定ブラウザのCookieに認証情報を保持している）

という状態ですと、「Creative Cloud Desktop Application」起動し、Adobe IDを入力（ここの入力は必要です）→IdPにリダイレクト、OSの既定ブラウザが起動、認証済みなので、そのまま「Creative Cloud Desktop Application」にログインできます。

 

ブラウザで認証後、自動的に「Creative Cloud Desktop Application」へ戻っていきます。良くできてますね。

「Creative Cloud Desktop Application」にログイン済みであれば、「Illustrator」や「Photoshop」などのアプリケーションを単独で起動してもログイン済み状態となっています。アプリ間では認証情報を共有しているってことですね。では、未認証状態で最初から「Illustrator」や「Photoshop」などのアプリケーションを単独で起動した場合はどうなるか？というと・・・アプリはOS既定のブラウザを立ち上げないので、アプリ内のWebViewで認証を行います。

↑アプリに組み込まれたログイン画面です。OS既定のブラウザではありませんので、仮にOS既定ブラウザに認証情報を保持（OS既定ブラウザのCookieに認証情報を保持）している状態でも、ここからIdPにリダイレクト、「ID/Pass」などの入力をして認証を行う必要があります。まあ、ユーザ操作として、アプリの単独起動から始めるのではなく、まずは「Creative Cloud Desktop Application」を起動して更新情報などいろいろ見てね！って事なんでしょう。もちろん、アプリ単独起動でも認証を行えば、認証情報はアプリ間で共有されているので、「Creative Cloud Desktop Application」も認証済みとなっています。

 

■Adobe アプリケーションからのログアウトについて

Adobeアプリケーションを「×」ボタンで終了しても認証情報は消えません。再びアプリを起動すれば（認証済み状態で）そのまま利用を開始できます。認証情報を破棄したい場合にはアプリから意図的にログオフする必要があるので注意が必要です。

Adobeさんっていち早くソフトウェアパッケージの提供方式から（サブスクリプション方式の）クラウドサービスに移行して成功している企業さんですよね。すごいなぁ~と思ってますが、そもそもAdobeさんが提供しているソフトウェアって競合もあるんだろうけど唯一無二的な感じもあったからなぁ~。必要なものはどのような提供形態でも必要とされるのでしょうね。

Office365の動的グループなどについて

Office365のグループって幾つか種類があり、用途も被っているように見えるため（実際、同じことが複数のグループで出来ます）、ちょっと分かり難いですよね。

作ったグループがどのサービス（Microsoft OneDriveやMicrosoft Teamsなど）から利用できるのか、アプリ側で操作すると裏でグループが作られているとか・・・そんな事にも絡んでくるため、更に分かり難い状況になっています。

また、PowerShellのコマンドレットが用意されているので、要件が複雑な場合にはスクリプトを作って動かそう！と思っても、動的グループを作成するためのコマンドレットが含まれているPowerShellのバージョンが「プレビュー」状態であるなど、まだ発展の途中でいろいろ変わりそうな雰囲気がしています。

なので、この状況でスクリプトなどで作り込むのはまだやめましょう（笑）！きちんと整理されてベストプラクティスが確立するまでもうちょっと待ったほうが良さそうです。

***************************
2020年11月6日　追記
こちらの記事にOffice365動的グループに関する具体的なPowerShellコマンドを記載しました。
実際にいろいろ試したので、そのまま利用できると思います。
****************************

■Office365のグループの種類

Office365管理画面からグループ作成を開始すると最初に「種類の選択」画面が表示されます。

大きく分けると3種類ですかね。「セキュリティグループ」は”メールアドレス：あり / なし”がありますが、基本は一緒ですね。

【参考：Microsoft グループを比較する】
https://docs.microsoft.com/ja-jp/microsoft-365/admin/create-groups/compare-groups?view=o365-worldwide

■Office365グループの作成

リモートワークでMicrosoft Teamsを利用するユーザが増えてきていますね。Microsoft Teamsに表示される「チーム」はOffice365グループと連携しています。管理者がOffice365グループを作成するときにMicrosoft Teamsの「チーム」と連携させることや、ユーザがMicrosoft Teamsの画面で「チーム」を作成するとOffice365グループが作成されます（ここの制御をしたい企業が多いと思いますが、詳細は後半で記載しています）。

Microsoft Teamsアプリの画面ですが、「教育チーム」と表示されているところが「チーム」と言われて実態は「Office365グループ」です。その下に「チャネル」というカテゴリ分けみたいなものがぶら下がります。デフォルトでは「一般」が作成されているはずです。

話を元に戻します。Office365管理画面から「Office365グループ」を作成するときにはポイントがあります。

グループには「所有者の割り当て」という設定があり、ここに設定したユーザはグループの管理者となり、メンバーの追加や削除などの管理者権限を持ちます。

「所有者」は複数ユーザの設定も可能ですが、「Microsoft Teams」のライセンスを持つユーザじゃないと、次の「グループへのMicrosoft Teamsの追加」というチェックボックスがグレーアウトして設定できないので注意してください。

私も最初、Teamsのライセンスを付与されていないユーザを設定してしまい、「グループへのMicrosoft Teamsの追加」というチェックボックスがグレーアウトしており、ちょっと悩みました。ライセンスを付与してもちょっと時間がかかったり、一度ログオフして再度、管理画面にログインしないとチェックボックスがグレーアウトしたままになっていたりするので注意です。

ちなみに付与するライセンスは「Microsoft Teams Exploratory」でも大丈夫です。Microsoft Teams「Exploratoryライセンス」は、Microsoft Teamsを含まないOffice 365の各プランをご契約されているお客様だけが利用申し込みができる特別なMicrosoft Teams試用版のことです。「Exploratory」の利用期間（期限）は2021年1月まで、となっております。それ以降は、Teamsを含むプランに移行する必要があります。

【参考：Office 365 Businessだけを契約してTeamsが使えるのか？その真相を解説します】
https://licensecounter.jp/office365/blog/2020/03/office365business-teams-exploratory-license.html

グループ作成の最後に「設定の編集」がありますが、「グループへのMicrosoft Teamsの追加」のチェックボックスがここにあります。

このチェックボックスが有効だと、Microsoft Teamsの「チーム」として表示されるようになります。グループの一覧表示で「Teamsの状態」というカラムにアイコンが表示されていればMicrosoft Teamsからも見えるようになっています。

この「グループへのMicrosoft Teams の追加」ですが、PowerShellで「Office365グループ」を作成するときに引数で持たせることができるか調査しましたが、どうも無いようです。PowerShellで「Office365グループ」を作成し、対象グループの「ObjectID」を取得、この値を引数として「New-Team」コマンド（Microsoft Teams関連のPowerShellモジュールが必要）で「チーム」を作成する必要があります。

メンバーは「Office365グループ」の作成後にグループの編集画面から追加します。「メンバー」タブをクリックして「+メンバーの追加」ボタンを押してからユーザを入力、追加してください。「+メンバーの追加」ボタンを押さずに「メンバー検索」のテキストボックスに値を入力しても既に追加済みメンバーを検索するだけなので、（メンバーが居ないと）何も検索できませんので注意です。

■Azure Active Directoryの動的グループ

グループの管理で一番面倒なのはメンバー管理です。組織変更がある度にメンバーの入替作業を行う必要があり、大変手間です。また、Microsoft Teamsではユーザーがチームのメンバーを編集したり、自分からチームを脱退することができてしまいます。しかもMicrosoft Teams側の基本設定では、これらを制御することはできません。

Azure Active Directoryの動的グループを使うと、設定した条件に従ってユーザーを自動的にグループのメンバーに含める、或いはグループメンバーから自動的に削除できるなど、大変便利な機能となっています。また、Microsoft Teamsではこの動的グループと連動している場合、メニューの「チームから脱退」と「メンバーを追加」が非表示になります（デフォルトで所属している組織全体のチームからはそもそも脱退できません。また「チャネル」の制御はできません）。そのため、ユーザーは勝手にチームから脱退することやメンバーを追加することが出来なくなります。

**** 2020年10月追記 ****
この時点で試したところ、「チームから脱退」メニューは表示されたが、実際に脱退はできませんでした。
↓こんなポップアップが表示されます。

*****************************

が、利用するには、「Azure AD Premium P1」ライセンスをグループメンバー分用意し、各ユーザーに割り当てる必要があります。

動的グループは、Azure Active Directory 管理センター (https://aad.portal.azure.com/)からグループ作成時に設定することができます。

【参考：動的グループによるMicrosoft Teamsのチームメンバー管理】
テクノバンBlog_Office365動的グループによるMicrosoft Teamsのチームメンバー管理

なお、動的グループとして利用可能なグループの種類は「Office365」と「セキュリティ」の2種類です。

■動的グループをPowerShellで操作する

さて、便利な動的グループですが、この機能を利用する規模になるとID管理システムからグループを作成する、ワークフローシステムと連携して（承認されたら）グループを作成するなど、外部から操作する必要が出てきます。そのため、PowerShellを駆使することになりますが、動的グループを操作するには「Azure AD PowerShell バージョン 2」 のプレビュー バージョンのコマンドレット（New-AzureADMSGroup,Set-AzureADMSGroup など）を使用する必要があります、と記載がありまして、（2020年6月現在）まだプレビューとのことです。

【参考：Azure Active Directory で静的なグループメンバーシップを動的に変更する】
https://docs.microsoft.com/ja-jp/azure/active-directory/users-groups-roles/groups-change-type

【参考：New-AzureADMSGroup】
https://docs.microsoft.com/en-us/powershell/module/azuread/new-azureadmsgroup?view=azureadps-2.0

PowerShellを駆使すればいろいろ出来そうですが、グループの整理整頓も今後行われそう（？）ですし、PowerShellもプレビューなので、このタイミングではまだ作り込まない方が賢明かと思います。

~~~出展、参考サイト~~~

マイクロソフト
【Office365管理センターのヘルプ：グループを比較する】
https://docs.microsoft.com/ja-jp/microsoft-365/admin/create-groups/compare-groups?view=o365-worldwide

【Azure Active Directory で静的なグループメンバーシップを動的に変更する】
https://docs.microsoft.com/ja-jp/azure/active-directory/users-groups-roles/groups-change-type

【PowerShell New-AzureADMSGroup】
https://docs.microsoft.com/en-us/powershell/module/azuread/new-azureadmsgroup?view=azureadps-2.0

SB C&S株式会社
【Office 365 Businessだけを契約してTeamsが使えるのか？その真相を解説します】
https://licensecounter.jp/office365/blog/2020/03/office365business-teams-exploratory-license.html

テクノバン株式会社
【動的グループによるMicrosoft Teamsのチームメンバー管理】
https://blogs.techvan.co.jp/microsoft/2018/11/28/%E5%8B%95%E7%9A%84%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%97%E3%81%AB%E3%82%88%E3%82%8Bmicrosoft-teams%E3%81%AE%E3%83%81%E3%83%BC%E3%83%A0%E3%83%A1%E3%83%B3%E3%83%90%E3%83%BC%E7%AE%A1%E7%90%86/

Adobe CC とのシングルサインオン設定

今回は「Adobe Creative Cloud」とのシングルサインオン（フェデレーション）設定を行ったときのメモです。久しぶりにAdobe CCを触ってみたところ、以前よりも設定が簡単になっていました。

■Adobe Admin Console へログイン

まずは、アドビの管理コンソール（https://adminconsole.adobe.com/）にログインしましょう。

■フェデレーションドメインの追加

次にフェデレーションで利用する独自ドメインを登録します。ログイン後、上部メニューの「詳細」-「設定」をクリックします。
デフォルトでは「ディレクトリ」が表示されているので、「ドメイン」タブで移動します。
※「ディレクトリ」は認証連携を行うIdPの登録やフェデレーションドメインの”リンク”を行うので後で作成します。

「ドメインを追加」ボタンが表示されているので追加します。

フェデレーションドメインを追加するだけですので、迷うことは無いと思います。ドメインの追加が完了すると以下のような「検証」と表示されていると思います。当然ながら指定したドメインの持ち主であることを確認するために利用しているドメインサービスに管理者としてログインし、該当ドメインに対して「txtレコード」を追加する必要があります。

「検証」ボタンを押すとtxtレコードに入力する値が表示されてますので、「adobe-idp-site〜」をコピーしてDNSのtxtレコードに設定してください。

設定したフェデレーションドメインの（所有権の）「検証」が完了すると、以下のように「検証」から「ディレクトリにリンク」と表示が変わります。

フェデレーションドメインの追加はいったん完了です。

■「ディレクトリ」の作成

フェデレーションドメインを追加した後は、「ディレクトリ」を作成します。この「ディレクトリ」という表記はアドビ独自の呼び方なので最初は何だろう？と思いましたが、ここで認証連携を行うIdP情報を設定して、更にフェデレーションドメインと関連付けする（リンクする）、というオブジェクトです。

「ディレクトリ」タブから「ディレクトリを作成」ボタンを押して作成に取り掛かります。

任意の名前を入力し、「Federated ID」を選択、次に進みます。ちなみに「Enterprise ID」を選択すると、フェデレーションは行わないがID作成やメンテナンスなどの操作は管理者が行う、というものらしいです。

詳しくはこちらを参照してください。

【アドビエンタープライズ製品でのIDタイプの管理】
https://helpx.adobe.com/jp/enterprise/using/identity.html

次の画面では認証連携を行うIdPの情報の設定に入ります。今回は「他のSAMLプロバイダー」を選択し、次に進みます。

そうすると、アドビ側（SP側）の「メタデータ」のダウンロードと、認証側（IdP側）の「メタデータ」のアップロードができるようになっています。しっかり作り込まれているIdPなら、SP側のメタデータを読み込んで必要な設定を自動化できますし、IdPのメタデータを出力することもできますので、ここでお互いの設定をメタデータファイルの読み込みで行います。（とても簡単ですね！）
※Adobeのメタデータファイルの中身については最後に参考情報として掲載しておきます。

「ディレクトリ」が作成されると以下のように表示されます。「編集」ボタンがあり、間違いがあれば後からいくらでも再設定できます。

以上で「ディレクトリ」の作成は完了です。

■「フェデレーションドメイン」を「ディレクトリ」にリンク

これ忘れないでください。作成した「ディレクトリ」に追加したフェデレーションドメインを”リンク”します。

先に「ディレクトリ」を作成してからドメインを追加する手順を踏めば、画面を行ったり来たりしなくて良いと思うのですが、ドメインの検証には時間がかかる可能性があるので、最初にドメインを追加することから始めました・・・というぐらいの意図しかないので、お好きな手順でどうぞ。

「ディレクトリにリンク」ボタンを押すと以下のような画面が表示されるので、リンクする「ディレクトリ」を選択してください。

ドメインとディレクトリの紐付けが完了すると「ディレクトリにリンク」から「アクティブ」に表記が変わります。

以上でフェデレーションのための設定は全て完了です。最後にフェデレーションユーザの作成を行います。

■「フェデレーションユーザー」の作成

Adobeには3種類のIDタイプがありますが、フェデレーションを行うIDタイプは「Federated ID」です。新規にユーザーを作成する場合、「IDのタイプ」で「Federated ID」を選択してください。

ユーザーの作成は画面上部メニューの「ユーザー」-「ユーザの追加」から行います。入力欄にユーザID（メールアドレス）を入力します。

ユーザーIDを入力すると、恐らく重複チェックなどを行い、作成可能なIDなら「IDのタイプ」や「SSOユーザー名」、「国/地域」などの設定項目が表示されます。「IDのタイプ」を「Federated ID」に設定して作成してください。

ちなみにですが、ユーザードメインと「ディレクトリ」にリンクした「ドメイン」が一致していると、自動的に「ディレクトリのユーザー」に追加されていることが分かります。なので、ユーザーを作成するだけでフェデレーションユーザーとなります。

実際にログイン画面（https://www.adobe.com/jp/）にてユーザーIDを入力（Office365同様、ドメインしかみてませんので＠前は適当な文字列でOKです）して、IdPにリダイレクトされるか確認してください。

それと、既存ユーザーの「IDタイプ」を変更する場合、管理画面から簡単にはできないようです。調べたところ、CSVファイルを利用した一括変更で対応するしかないようです。画面からポチポチできれば良いのに・・・。

【アドビエンタープライズ製品でのIDタイプの管理】
https://helpx.adobe.com/jp/enterprise/using/identity.html
※「IDタイプを一括編集」の項を参照。

■ 参考：メタデータについて

Adobeのメタデータファイルの中身を見てみました。

IdP側の設定に最低限必要な「entityID」、「NameIDFormat」、「AssertionCOnsumerService」の情報は含まれています。ユーザー識別子「Nameid」には当然ですがAdobeのユーザーIDをセットする必要があります。

<md:EntityDescriptor>
entityID=”https://federatedid.services.adobe.com/federated/saml/metadata/alias/・・・”

<md:SPSSODescriptor>
<md: NameIDFormat>
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
<md:AssertionConsumerService Binding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST” Location=”https://federatedid.services.adobe.com/federated/saml/SSO/alias/・・・”

ログアウトの情報がないんですよね・・・シングルログアウトには対応してないと思うので、終了時にはブラウザを「閉じる」という運用になると思います。

以上。

リモートワークと多要素認証とOffice365と。

世の中いろいろ大変ですが、頑張って乗り切りましょう！

さて、そんな最中ですが私は通常よりも忙しい毎日を過ごしています。

リモートワークを行う人が増えたため、認証サーバへのアクセス数増加の対応や、ZoomやWebEXなどのサービスの認証連携（シングルサインオン）をしたいなどの要望が急激に増えました。

一方で今まで外部アクセスは多要素認証を行なっていたが、リモートワークを行う人が増え、OTPの設定に関する問い合わせが増えておりまして、あるサービスへのアクセスは一時的にパスワード認証に戻して欲しい、或いは、一部の人だけパスワード認証に戻して欲しい、などと言うセキュリティレベルを下げる依頼も多くありました。

後者は絶対にやってはいけないのですが、どうしてもやって欲しいという事で対応はしましたが、以下の点を覚悟してくださいと伝えてます。

・多要素認証を一部だけ解除することは、セキュリティに穴をあけることになる。
・メール機能を持つOffice365などはアカウント奪取後、スパムメールの踏み台にされることが多い。
・社内に侵入されなくても、1つのメールアカウントが漏洩するだけで、その被害は広範囲に渡る。

これらは実際に私が経験したことでもあります。悪意のあるハッカーは企業内に侵入し、機密情報を奪うという高度なことをする人よりも、シンプルに取得したメールアカウントを踏み台に大量のSPAMメールを送信するとか、アドレス帳から関連している企業に対して更なるアタックを仕掛けようとする、ことが圧倒的に多いです。

そのため、（企業なら）一般社員なら大丈夫だろう、（教育機関なら）学生は一時的に多要素認証を解除してもやむを得ない、何かあっても影響範囲が限定的だろう、という考えはとても危険だなと感じました。

Googleは8年も前から「あらゆるネットワークを信頼しない、ゼロトラスト セキュリティモデル（Beyond Corp）」を研究、実践してきました。そのため、コロナ騒動でリモートワークが増えても、特別な対応をすることなく、高いセキュリティレベルを維持しています。

「VPNを介さなくても業員や契約業者などのユーザーがほぼどこからでもより安全に働けるようにします。」ってとてもカッコイイ！！ですよね。

【Google 企業セキュリティに対する新しいアプローチ：Beyond Corp】
https://cloud.google.com/beyondcorp?hl=ja

まあ、Chrome bookeやChromeブラウザのみの利用を前提としたりしているので一般の企業で実践するにはまだまだ考えなくてはいけないことが多いのですが、方向性（ゼロトラストをベースにする）としてはこれからの流れに即しているのではないかな、と思います。

 

Azure AD Connect インストールと初期設定

■Azure AD Connect ダウンロード

https://www.microsoft.com/en-us/download/details.aspx?id=47594
※言語が「English」ですが、インストール後に起動するウィザードは日本語です（OSの言語設定に依存）。

■初期設定

インストール完了後、設定ウィザードが起動します。

①ライセンス条項への同意

②「簡単設定を使う」or 「カスタマイズ」の選択（今回は簡単設定を選択します。）

③Azure ADへの接続アカウントを入力（●●●@●●●.onmicrosoft.comアカウントを入力します。）

④Active Directoryに接続
接続が完了すると、自動的に「Active DirectoryのUPNサフィックス」を取得、表示してくれます。
更に、Office365に登録されているドメインと比較し、一致しているか？を確認してくれます。
（ADのUPNサフィックスがOffice365にドメインに登録されているか？ということです。）

「一部のUPNサフィックスが確認済みドメインに一致しなくても続行する」にチェックを入れて「次に」進みます。

⑥構成の確認

⑦完了！

とても簡単ですね。ただ、このままですとADの情報を全て同期してしまうので、特定のOU配下を同期対象にするなど、オプション設定をお勧めします。「ADConnect」を起動すると「追加のタスク」画面が表示されます。

「同期オプションのカスタマイズ」で、同期対象OUなどを指定することができます。

その他、パスワードの書き戻しや拡張属性を同期対象とするなど、細かい設定ができます。

■その他メモ

Azure AD Connectを導入したサーバにて、PowerShellから同期停止、同期開始が実行できます。

・同期を開始する場合

Start-ADSyncSyncCycle

・同期を停止する場合

Stop-ADSyncSyncCycle

ADConnectの同期を停止しただけでは、Office365側は同期の非アクティブ化がされません。PowerShellからOffice365へ「connect-MsolService」で接続、以下のコマンドで「同期の非アクティブ化」をしてください。なお、反映にはかなり時間がかかるようです。

Set-MsolDirSyncEnabled –EnableDirSync $false

非アクティブ化がされていない状態でID管理製品などからID同期を行おうとすると、以下のようなメッセージが表示されるようです。また、Office365の管理画面よりアカウントの作成はできるようですが、Exchange属性の編集を行おうとすると同様なエラーが発生することを確認しています。

選択されたユーザー アカウントは、テナント ‘●●●●’ に存在しないため、そのテナントのアプリケーション ‘●●●●’ にアクセスできません。最初に、アカウントをテナントの外部ユーザーとして追加してください。別のアカウントをお使いください。

PowerShellからOffice365へ「connect-MsolService」で接続、以下のコマンドで同期のアクティブ/非アクティブが確認できます。

Get-MsolCompanyInformation | Select-Object DirectorySynchronizationEnabled

 

昔に比べてとても使いやすくなっていると感じました。次回はADFSがない環境でもADで認証を行う「パススルー認証」機能について検証してみたいと思います。「Azure AD Connect」をちゃんと使いこなせば、「社内ADでアカウント管理 + Officew365の多要素認証」という環境が出来上がるので、お金をかけずにOffice365に対するセキュリティを高めることができると思います。