エンタープライズアイデンティティと認証の活用

こんにちは　WWDCにようこそ “エンタープライズアイデンティティと 認証の活用” シニアコンサルティングエンジニアの マイク･ボイランです 今日は同僚のスダカールと一緒に エンタープライズIDと認証の話をします Appleでは単なるソフト ハード サービスを 越えたセキュリティに注力しています Apple端末を展開する組織にとって デバイス ウェブサイト アプリケーション サービスのユーザ認証にはIDが最も重要です 基盤をまたいでセキュリティを 担保する際に欠かせません IDと認証がより複雑になるのは当然です エンタープライズのアプリケーションや ウェブサイトは全てユーザ認証が必須です そのアプリケーションが クラウドかオンプレミスかまたは両方の 基幹系システムにアクセスします 企業に対応策はあるでしょうか？ 既存のものを補完する目的で Appleが作ったツールや技術では デバイス ウェブサイト サービスを またいだ IDの活用を効率化します IDは オペレーティングシステムに 密接に結合されるべきと考えます ユーザが気づかないような シームレスな体験を提供するためです ユーザはどこででも仕事ができる上 可視性があり 制御が効くため IT部門は安心して管理できます このセッションでは３つの技術を 組み合わせた使い方と 今年の新機能をご紹介します デバイス認証 macOSアカウントタイプ SSO拡張機能 Managed Apple IDと フェデレーション認証などです まずはデバイス認証です 当社デバイスのIDは ロック画面のログインから始まります 共有のiPadとMacの例では ユーザは自分のアカウントを選び 認証情報を入力後 自分用の画面になります iPadOSではManaged Apple IDで実現します macOS上ではアカウントはローカル またはネットワーク経由が可能です この例ではデバイスを１人のユーザに 割り当てる最初の段階でも IDが役割を果たすことがわかります 昨年Enrollment Customizationという 新機能を追加しました このようなウェブページを セットアップ中に読み込む機能です また最新の認証方法を使用した 認証も可能です 認証プロセスのユーザ情報を使用して ユーザのローカルアカウント名と省略名を macOS設定アシスタントに自動入力し オプションでロックできます これはユーザがローカルアカウントを 使用していることが前提です Macにはローカルアカウントと ネットワークかモバイルアカウントがあり モバイルアカウントは ネットワークアカウントの一種です 長年利用してきた組織ではケース次第で 両方使用することもありました モバイルアカウントとネットワークアカウントの 組織のIDはMacで最初に作られました iPhoneやiPadなどのモバイルデバイスが 普及する何年も前のことです 主にコンピューターラボなどで 共有デバイスを使うためのものでした しかし１人１台の現代で この使用はあまり意味がありません １人１台では可能な限り macOSで ローカルアカウントをご使用ください ユーザ記録はMac上にローカルで保存されます また 認証のための信頼できる情報源は ローカルのmacOSディレクトリサービスです これにより 不必要なログイン遅延がなく パスワード管理はMacのローカルで行われます さて １人１台の展開では Macをディレクトリサービスに いつバインドするのかという 質問が寄せられます １人１台の展開で MacをActive Directoryや 別のディレクトリサービスに バインドしてきた組織は バインドの解除をお勧めします 代わりに ビルドインのKerberos拡張機能か その他のSSO拡張機能の使用をご検討ください ディレクトリ接続のMDMベンダー提供の サードパーティの付加価値付きの機能もあります 後ほど ビルトインのKerberos拡張機能と SSO拡張機能について説明します オンプレミスのActive Directory環境に ビルトインのKerberos拡張機能を使用すると ユーザはKerberosチケット許可チケットを 取得できます 別名TGTは ファイルサーバーやプリンターなど ディレクトリリソースにアクセスします 拡張機能は ユーザのパスワードを ディレクトリ内と同期させるのにも役立ち パスワード変更時 新しいパスワードが 組織の複雑な要件に沿うようにもできます Active Directory DFSの 分散ファイルシステムをトラバースしたり MDMからのAD証明書ペイロードを使用して ADマシン証明書を取得したりしますね その際は Mac自体をActive Directoryに バインドする必要があります ただし Mac自体がバインドされていて ADマシンのレコードがあっても Macのログインにドメインアカウントを 使用する必要はありません 前述のとおりローカルアカウントを使うのが 理想的です macOSで最高のエクスペリエンスを提供する ローカルアカウントを可能な限り ご使用ください もう１つのアカウントは ネットワークアカウントです これらのアカウントでは 信頼できる情報源はディレクトリサーバーです ホームフォルダーはオプションで ネットワークボリューム上にあり macOSにログインするとコンテンツに ネットワーク経由で直接アクセスできます アプリケーションのコンテンツ保存先の データベースも含め アプリケーション ファイルサイズ ファイルタイプは最新です しかし モビリティ固有の課題が ネットワークアカウントと ネットワークホームフォルダーにあります 私たちはこの種のアカウントをレガシーと見なし 使用をすすめません しかし非推奨ではなく どうしても必要な場合には使用できます

可能な限りローカルアカウントを使い どうしても必要な場合は モバイルアカウントを検討してください モバイルアカウントは ネットワークアカウントの一種であり ネットワークアカウントより 使用頻度がはるかに高いです 認証に信頼できる情報源は ディレクトリサーバーであり 認証情報もローカルにキャッシュされます ホームフォルダーも Macのローカルに作成されます ローカルにキャッシュされた認証情報と ローカルのホームフォルダーがあるので ディレクトリサーバーが利用できない場合でも ユーザはMacを使用できます ただし ユーザ認証の信頼できる情報源は ディレクトリサーバーであるため ディレクトリサーバーへのアクセスを試行する際 ログインの遅延が発生することがあります 原因はさまざまですが 多くはDNSの構成ミスか または予期しないリダイレクトが 公衆Wi-Fiネットワーク上などで 起きるからです

パスワードは外部で変更でき その後Macで更新する必要があるため パスワードの同期はさらに複雑です 特にFileVaultを使用する場合です １人１台の展開時モバイルアカウントは macOSでサポートされますが推奨していません ただし 共有ラボ環境では モバイルアカウントが適することが多く 必要に応じ 一定の期間後に 失効するようにもできます

以上がデバイス認証の要約と 共有デバイスと個人デバイス間で 展開中も展開後も アカウントと認証を管理する方法でした 次に SSO拡張機能について説明します

おさらいすると SSO拡張機能は昨年 iPadOS iOS 13およびmacOS Catalinaに 導入されました ネイティブアプリケーションとWebKitは今後より シームレスなSSOエクスペリエンスを提供します 独自のID管理システムにシングルサインオンを する際に 内部でSSO拡張機能を使用します MicrosoftやOktaなどの大手IDプロバイダも 製品を提供しています SSO拡張機能により 組織は既存の認証情報を活用できます モバイルデバイス管理(MDM)が構成し ネイティブUIやウェブUIを提供できるので ユーザの認証体験は完全に透過的です ネイティブアプリケーションと同様に SafariとWebKitが― SSO拡張機能を呼び出す この構図のように 組織のIDプロバイダに対し認証します 今年 SSO拡張機能にいくつかの新機能と 拡張機能を導入します １つは共有iPadを使用し macOSとiPadOSの両方の ユーザチャネルでSSO拡張機能を 構成する機能です SSO拡張機能がアプリケーションごとに VPN構成とやり取りする方法を改善しました アプリケーションに組み込まれたURLと一致する リストにワイルドカードを使用する機能を追加し 認証要求している呼び出し元アプリケーションの 追加情報を拡張機能に提供します そして 拡張機能を構成する MDMプロファイルが削除されると オペレーションが呼び出され 必要なクリーンアップタスクを行います 最後に ファーストパーティ実装の Kerberos拡張機能をいくつかの拡張しました これらの変更を詳しく見ましょう まずユーザチャネルプロファイル配信です

共有iPadを使用して macOSとiPadOSの両方のユーザチャネルで SSO拡張機能を設定する機能を今年導入します MDMデベロッパはSSO拡張の構成を 製品に簡単に統合できるようになり この機能はすべてのSSO拡張に対して有効です ユーザチャネルで構成された設定は システムレベルで構成された設定よりも優先され この改善でユーザ名の設定など ユーザごとのSSO設定も簡単になります またSSO拡張機能がアプリケーションごとのVPNで 機能する方法も大幅に改善されました 今年新しく関連ドメインがアプリケーションごと VPNで動作するようになります その結果 SSOリダイレクト拡張機能で オンプレミスのIDプロバイダの トラフィックをリダイレクト できるようになります オンプレミスIDPにはインターネットベースの IDPと同じ証明書制限があります つまり 証明書は信頼するCA機関から 発行される必要があります この機能を使用するにはアプリケーションごとの VPNペイロードに関連ドメインを追加し iOSの管理対象アプリケーション属性を介し ドメインの直接ダウンロード機能を有効にします またはmacOSのManaged Associated Domains ペイロードです 関連ドメインの変更については あとで説明します

オンプレミスIDプロバイダに拡張機能で アプリケーションごとのVPNの使い方を見ます アプリケーションがインストールされた時 関連ドメインがあると OSはアプリケーションごとのVPNを通じて サイト関連付けファイルを要求します ネイティブアプリケーションは “ログイン”などを拡張機能に送ります リクエストはアプリケーションごとのVPN経由で オンプレミスネットワーク上の IDプロバイダに送信されます アプリケーションごとのVPNを経由し 拡張機能に応答をします そして 応答とトークンが ネイティブアプリケーションに返送されます

SSO拡張機能はホストアプリケーションの アプリケーションごとのVPN設定を継承します ホストアプリケーションにアプリケーションごと VPNが割り当てられている場合 ホストと拡張機能のトラフィックは すべてアプリケーションごとのVPNを使用します 一部のリソースがクラウドにある場合でも すべてのトラフィックがVPNを経由するため 拡張機能のパフォーマンスに影響しえたのです 今年から新たにアプリケーションごとのVPN除外 ドメインリストを使用できます クラウドIDPトラフィックはデバイスからIDPに 直接送信されるようにすれば 負荷分散やリージョナルインスタンスを 活用できます 信頼できるクラウドと オンプレミスにあるリソースに アプリケーションが同時にアクセスする 必要がある際に役立ちます 除外リストはデバイスに対してグローバルです 以前は SSO拡張機能またはアプリケーションが クラウドリソースに接続するには アプリケーションごとのVPN経由トラフィックを オンプレミスネットワークに送信していました そして そこからインターネットに送られました これではインターネットリソースに グローバルCDNや リージョナルロードバランシングを活用できず 非効率です 今は除外ドメインを使用し 信頼できる インターネットリソースに直接アクセスできます SSO拡張機能はAppごとのVPNを介し オンプレミスに送信しています 除外ドメインリストを使用すれば 指定ドメインのクラウドリソースに トラフィックを直接送信できます ログインやパスワード変更のリクエスト時にも アプリケーションごとのVPNに接続するので httpなどへのリクエストは必要なくなります 他のプラットフォームも同様です 昨年発表した SSO拡張機能に対応の 関連ドメインについてですが iOSでは 管理対象アプリケーションの設定を介し 拡張機能のアプリケーションと共に構成されます macOSでは MDMからの構成ペイロードを介して インストールされます SSO拡張機能と使用すれば ホスト名を分けているIDプロバイダは MDMを介しホストの指定が可能です App Storeに登録するために 顧客をURLに追加せずに済みます 関連ドメインと一緒に使用するには エンタイトルメントが必要です MDMがアプリケーションの関連ドメインを 補足できるようになります 今年から― com.apple.developer.associated- domains.mdm-managedが公開され デベロッパテクニカルサポートの 承認が不要になりました

アプリケーション内の関連ドメインは Apple App Site Associationファイルと ペアにします ファイルにはアプリケーションIDと アプリケーションキーが含まれており ウェブサイトや 特定のサービスタイプで使用できます Apple App Site Associationファイルは 今年より デバイスからの直接アクセスではなく Appleが運営する関連ドメイン専用の CDNからアクセスされます サーバの負荷が減るので デバイスは高速で接続されるのです

パブリックインターネットを利用できない 関連ドメインの管理対象デバイスは アプリケーション内のドメインに パラメータを追加し デバイス上でドメインを指定できます 詳細は WWDCの 関連セッションをご覧ください 今年は SSO拡張機能に関する アプリケーション情報を増やしました 具体的には ローカライズされた 呼び出しアプリケーション名 アプリケーションのチーム識別子や isCallerManagedフラグです SSO拡張機能のアプリケーション名はシンプルで ユーザエクスペリエンスが向上します さらにチーム識別子と“is managed”フラグで より詳細なセキュリティ判断が可能です 次は操作についてです 昨年の拡張機能には ログインや更新など よく使う操作を含めました デベロッパには おなじみでしょう

今年追加した configurationRemovedは 拡張機能を構成するプロファイルが 削除された時に呼び出されます これにより デベロッパは ログアウトの時間や ファイルのクリーンアップ トークン取り消しなどの時間を短縮できます iOS 14またはmacOS Big Sur SDKで SSO拡張のビルドが必要です

拡張機能に使用するURL一致リストに 埋め込みワイルドカード機能を追加しました 共通のURLスキームを使用する 大規模なIDプロバイダでも URLが微妙に違う顧客の識別が 簡単に行えます ログインURLがauth.pretendco.com/ CUSTOMER NAME/loginの場合 埋め込みリストにauth.pretendco.com/ STAR/loginを含めます これは全ドメインが違う 関連ドメインではありません ワイルドカードを含むURLは 関連ドメインと連携して機能します 似たURLやホスト名が同じ大量の顧客を 簡単に照合できるので 拡張機能のデベロッパに注目されています Kerberos拡張機能の改善点も紹介しましょう メニューエクストラのステータス表示が より詳細になりました 拡張機能には認証情報やネットワーク DNSとKerberos認証チケットが必要です これらに不備があればメニューエクストラに 表示するようプログラムされています IDに使う名称は組織内で同じとは限りません アソシエイトIDやADアカウント 組織名を表すPretendCO IDなど様々です 今年のKerberos拡張機能では ラベルをカスタマイズできるので 組織とID名のマッチが可能になりました ユーザログイン時のトラブルに対する ヘルプテキストは サインイン画面に表示できます ID名をヘルプテキスト上に カスタマイズし 並べた例です

こちらはメニューエクストラのステータスです 左のユーザはサインインしていないか ネットワークが無効 中央はサインイン済みですが ネットワーク無効です 右はサインイン済みでネットワークと認証が有効 キーアイコンはメニューバーに固定されています

拡張機能はiOS iPadOS macOSでの要求に対し AppごとのVPNに接続します 別のネットワークリクエストや 手動でVPNに接続する必要ありません Kerberos拡張機能はmacOSの app-to-per-app VPNに対応可能です AppSSOAgentとKerberosMenuExtraを app-to-per-app VPNのペイロードに追加します ユーザチャネルプロファイル配信は Kerberos拡張機能にも対応しています MDMを介したユーザレベルの認証ID参照や 認証ベースのKerberosやPKINITのために 大規模なドライバを使用しました

もちろん ユーザレベルの認証ID参照は Kerberos拡張機能を構成するコンテキストで 常にサポートされていました 今回の改善は設定と認証を一括で行う MDMベンダーにとって非常に有効です 最初のユーザログイン時の管理者には より多くの選択肢を用意しました 以前はApp-SSO-Agentが 変更や資格情報のプロンプトを聞いていました 新オプションではプロンプト表示を 管理者によるコマンド実行後や 認証のチャレンジ後に設定できます また iOSに追加した Managed App Access Controlは ソースのアプリケーションが 管理されていないと 認証できないよう設定します 以上がSSO拡張機能と ビルトインのKerberos拡張機能の要点でした 次はスダカールが Managed Apple IDについてお話します ありがとう　マイク 私はスダカール･マンバッカム シニアエンジニアマネージャーです Managed Apple IDと フェデレーション認証について説明します Apple Business Managerと Apple School Managerに共通する機能ですが Apple Business Managerを例に説明しましょう もし機能に違いがある場合は 分けてお話しします

まず Managed Apple IDとは 組織が所有 管理する Appleのユーザアカウントです 作成や消去 パスワードなどを扱う アカウント管理は ITアドミニストレータ または自動システムによって行われます デバイス管理やアプリケーションなどに 使うのがManaged Apple IDです アプリケーションにはManaged Apple IDだけが 有効となるものがあります ITチームはIDで Apple Business Managerにサインインし デバイス管理や アプリケーションの購入などを行います User Enrollmentや共有iPad等は このIDでのみ使用可能です

教育をサポートするためのIDには 200GBの無料iCloudストレージが提供されます

最も重要なことは フェデレーション認証に対応していることです 詳しい内容と その重要性を見ていきましょう

フェデレーション認証は組織全体に及ぶ シンプルで安全なID管理構成です 組織内でApple Bussiness Managerが 接続するのは Microsoft Azure Active Directoryの 既存IDシステムです アクセスすると 自動的にユーザ設定されます

Appleサービスへは 新しい認証を作る必要がなく 組織内で使用する他のアプリケーションと 同じ認証でアクセスできます これは組織がユーザに定める認証ポリシーで フェデレーション機能の主な目的です

フェデレーション認証後 初めてサインインする時には Managed Apple IDが自動的に作成されます

ITチームとエンドユーザの両方にとって アカウント関連の処理が減りますし 組織内で使用する 全てのサービスにおいて IDポリシーが確実に守られるのです

では 仕組みを見ていきましょう まず Azure Active Directoryと Apple間での設定が必要です これは Apple Bussiness Managerと Apple School Managerに共通します 設定が完了すると組織のユーザは サインイン認証で 全てのアプリケーションにアクセスできます

フェデレーションは ドメインごとに構成されます この例ではacme.comに フェデレーションが設定されました

acme.comのユーザが Appleのサービスにアクセスすると Appleは認証のため デバイスをAzure ADにリダイレクトします

認証後 デバイスは認証トークンで Appleにリダイレクトを返します プロトコルはSAMLで トークンは Azure ADで作られたSAML認証応答です Appleは設定時の情報からトークン署名を検証し ユーザにアクセスを許可します

フェデレーション認証は IDシステムがAzure ADではなく オンプレミスのADFSやIDプロバイダなど 他のシステムにあっても機能します 他のIDプロバイダとの統合は Appleに透過されるので Azure ADを経由し認証トークンを受け取れます

設定のプロセスを説明しましょう フェデレーションの設定に必要な ユーザの管理能力は Apple Business Managerと Azure Active Directoryで同じです 組織内で両方の管理者であると仮定し プロセスを追ってみましょう

フェデレーション設定時 ドメインが複数あれば 連携用のドメインを決める必要があります

Appleサービスにアクセスするユーザ全ての ドメインを連携すると最大の利益になります

ドメイン検証はApple Business Managerと Apple School Managerに今年導入の新機能です Managed Apple IDを作成するためのドメインは 所有権を検証する必要があります

そのプロセスを見るために まず連携したい ドメインを入力し“continue”を選びます そのドメインが未検証のステートに保存され 検証プロセスが始まります ドメイン検証機能は標準のDNSの検証メソッドの TXTレコードを使用します 検証コードを生成するために “verify”ボタンを使います

次に このコードを使って ドメインにTXTレコードを作成します コードは生成時から14日間有効でこの期間内に プロセスを完了する必要があります DNSレコードの更新後に手動DNSチェックを実行 もしくは自動で定期的なプロセスを実行させます DNSレコードのプロパゲーションは更新後 ２～３時間かかる可能性をご留意ください

TXTレコードがApple Bussiness Managerに表示後 ドメインのオリジナル生成コードにチェックされ マッチしているならドメインは検証済みと記され フェデレーション認証に使用できます

federated authentication下のconnectボタンで フェデレーション認証プロセスをスタートし

Azure ADの管理者としてサインインします これでグローバルアドミニストレータ アプリケーションアドミニストレータ　または クラウドアプリケーションアドミニストレータと 共にユーザになれます

Azure ADとApple Bussiness Manager間の 統合を承認します これでユーザはAzure AD認証で Appleサービスにサインインできます またAzure ADに従業員のEメールアドレスや 名前などのユーザ情報をAppleと共有させます このステップは１機関に１度のみ必要です 規約を読み同意してください

一度許可を与えてから連携しているドメインに 属するユーザとしてサインインします これは許可の付与が成功したことを 確認するテストサインインであり ユーザがAzure ADの認証情報を使いApple Servicesにサインインできることの確認です

後でセカンドドメインを連携する場合は 統合の許可がすでに下りているので 直接このステップに進むことになります

次にAppleはデータベース上で ユーザ名の競合をスキャンします これらはそのドメインに属する ユーザ名を持つ既存のアカウントです Apple IDデータベースに既存のユーザ名で Managed Apple IDの新規作成はできません そのため競合を取り除く 解決のプロセスがあります Appleでは新たなユーザネームを選択し 異なるドメインで使用するよう通知します 60日後解消されず残っているユーザ名は全て Appleにより一時ドメインに自動更新されます この処理が完了すると連携しているドメイン内の 任意のユーザ名でManaged Apple IDを作成でき

仮に競合があっても 連携を有効にするために 60日間待つ必要はありません スキャンが完了し競合の結果が分かれば いつでも連携を有効にすることができます ユーザ名が競合しない使用者は組織の認証情報で Apple Serviceをすぐに利用することができます

連携を有効にするために必要な手順を 簡単にまとめてみましょう まずドメインを確認します それから管理者としてサインインし同意し

そのドメインのユーザとしてサインインします

必要に応じてユーザ名の競合と 最初の解決ステップを再度確認してください

それから連携を有効にします

Federated Authenticationにより アカウント管理で生ずる問題の大部分特に 最も困難な課題のひとつである 認証情報管理の問題を解消できます しかしまだお話すべき 重要な問題がいくつかあります

あるユーザが組織を辞めたら 何が起こるでしょうか？ そのユーザからのアクセスはセキュリティと 規制を守るため 即座に取り消す必要があります もちろん連携されていればそのユーザが組織を 辞めた後にサインインすることはできませんが そのようなユーザがサインインしたままの デバイスやアプリをどうすべきでしょうか？ どのようにセッションが終了したことを 確認すればよいのでしょうか？

アカウントを長期間使用するうちに ユーザの所属部署や氏名が変わることもあります 全てのサービスでユーザのプロフィール情報に 一貫性を持たせる最適な方法とは何でしょうか？

Managed Apple IDは多くのユーザにおいて サインイン時に自動的に作成されます しかしあるユーザに要求される特定のサービス 固有の許可が必要な場合はどうなるでしょうか？ 許可前に作成されたアカウントに対し前もって 権限を付与するにはどうしたらいいでしょうか？

SCIMはこのような問題を全て解決する 標準的なソリューションです 今年後半にAzure Active Directory搭載のSCIM インテグレーションの導入を発表します これはApple Business Managerと Apple School Managerの両方に対応しています

SCIMとは何か また どのように役立つのか見てみましょう

SCIMはIDプロバイダとサービスプロバイダの間で 情報を交換するための自動化されたプロセスです これはAzure ADとAppleの間で アカウントデータを同期するものです

アカウントの全ライフサイクルをカバーする 標準ベースのデータ交換です これでアカウントの作成 編集 削除の全てを 同期させることができます Apple Business ManagerとApple School Managerを連携済みの全機関で利用できます アカウント情報をApple School Managerに インポートする処理を既に行っている教育機関は SISやSFTPプロセス経由のみならず 今後はSCIMが別のオプションとなるでしょう ではSCIMプロセスの概要を見てみましょう SCIM接続がその機関で一度セットアップされれば Azure ADがユーザディレクトリの変更を監視し Apple Business Managerに 変更内容が自動的に公開されます

時間の経過に伴いユーザが追加され あるユーザのプロフィールは更新され 別のユーザは削除されるでしょう Azure ADはこれらの変更を監視し SCIMインターフェースを使用して その変更を判別し Apple Business Managerに送信します

Apple Business Managerはこのデータを処理して そのデータベースに適用しAzure ADと同期します

２つのリポジトリを同期させることで SCIMは連携されたアーキテクチャの セキュリティと使いやすさを向上させます

ではSCIMのセットアッププロセスの 流れを見ましょう Federated Authenticationと同様に SCIMの設定もApple Business Managerと Azure ADの両方の管理者である必要があります

Apple Business ManagerにSCIMを構成するための 新しいデータソースオプションが追加されます Apple School ManagerはSISとSFTPの データソース設定をすでにサポートしています これで別のオプションとして SCIMを提供することになります

“接続する”を選択して設定処理を開始します

これでAzure Active Directoryにアップロード時 必要なSCIMトークンが生成されます 後で使用するためこのトークンをコピーします 一度生成されたSCIMトークンは４日以内に 使用しないと有効期限が切れます

トークンを生成時 ユーザインターフェイスに テナントURLも表示されます トークンとURLの両方がAzure ADの設定に 必要なのでテナントURLにも注意してください

管理者としてAzure ADにサインインします Enterprise Applicationsセクションに移動し Apple Business Managerアプリを選択します アプリ内のプロビジョニングセクションに移動し Apple Business Managerから取得した情報を入力 ディレクトリ内の全てのユーザのデータを 同期するように選択することもできますし Apple Business Managerに割り当てたユーザの サブセットデータのみを同期する選択も可能です 同期する内容を選択して “保存”をクリックしてください Azure ADが自動で接続のテストを行い データの同期を開始します

アクティビティサイドバーを使いApple Business Manager内のSCIMの検証もできます SCIM経由でインポートしたアカウントの 接続状況や数を確認できます SCIMインターフェース経由で同期したアカウント ラベルにはデータソースのSCIMが表示されます 今後Azure ADとApple Business Managerの間で アカウント情報が自動で同期されます 連携とSCIMを併用することで アカウント管理プロセスが大幅に簡素化され SCIMインテグレーションを利用いただけることは 私たちにとっても大きな喜びです Managed Apple IDがあればニーズに合わせて Apple Serviceを使うことができます Federated AuthenticationとSCIMを使うことで ID管理プロセスは自動化 簡素化され ユーザにシームレスな体験を提供し さらに Apple Serviceの価値を最大限に得られます それではマイクにお返しします 私からは連携とSSOについて 少し詳しく説明いたします これらは私たちのエコシステムの中では 補完的な技術です IDプロバイダはSSO拡張をサポートしています MicrosoftやOktaなどの大規模プロバイダによる SSO拡張機能の市場投入はご存じのとおりです SSO拡張機能を使用することで Apple以外のアプリケーションやウェブサイトで プロバイダと直に統合しSSO体験版を使えます 一方でAppleのアプリケーションやサービスは Managed Apple IDでのみ作動するため IDプロバイダと直接統合するために SSO拡張機能を使用することはありません Appleのアプリケーションは 認証時にAppleと統合した後 Microsoft Azure Active Directoryと連携でき Microsoft Azure Active Directoryを実際に 裏付けIDプロバイダとして使うかは任意です 前述の通りAzure Active Directoryは 他のIDプロバイダとの連携もサポートしています そのためApple Business ManagerはAzure Active Directorとの連動を必要としますが IDの裏付けとなるソースは 別のIDプロバイダである可能性があります このディスカッションを要約し行動喚起をもって 締めくくりたいと思います １:１デプロイを行う際には可能な限り常に macOSでローカルアカウントを使用してください 内蔵のKerberos拡張機能経由や以下の経由で ディレクトリ接続性テストを可能にする時もです また他のSSO拡張機能を経由するときや MDMベンダーが提供するサードパーティの 付加機能を追加するときにも 常にローカル環境で行います １:１デプロイを行う際にはmacOS上での モバイルアカウントの使用は推奨されていません 共有ラボ環境ではモバイルアカウントの使用が 適切であることが多く その場合は必要に応じて 一定期間後に有効期限が 切れるように設定することもできます 今年はSSO拡張と内蔵システムであるKerberos 拡張機能に多くの新しい改善をしました これらを活用してシングルサインオン体験を さらに向上させることをお勧めします 企業や教育機関向けに構築されたManaged Apple IDをぜひ法人でご利用ください 作成と管理ができデータプライバシーを守り かつApple Serviceへのアクセスを提供します Apple School ManagerとApple Business Managerでドメインを認証することで 既存の Microsoft Azure Active Directory認証 情報に裏付けされたアカウントを 簡単に作成するための 連携の使用を可能にします 新しいSCIMサポートは今年後半には Apple School Managerと Apple Business Managerで開始予定です これはMicrosoft Azure Active Directoryから Appleに直接データをフィードバックし アカウントの作成 編集 削除の補助を 提供するものです WWDC2020 EnterpriseセッションはITのプロに 特化しているので 全てにご注目ください 昨年も拡張可能なSSOについて技術的に 深く掘り下げていますのでぜひご覧ください 引き続きWWDC 2020がお送りする 素晴らしいコンテンツをお楽しみください