Azure AD Connect (AADC) を SQL Server Express で利用する場合の制限値の確認方法
こんにちは。
最近はオンプレ AD と Azure AD を Azure AD Connect (AADC) を利用して同期しているっていう環境をよく見かけます。
AADC では、 別途購入した SQL Server を利用することも可能ですが、 AADC に同梱される SQL Server Express Local DB を利用するといったケースも多いかと思います。
しかし、 SQL Server Express Local DBを利用する際には、以下の制限があります。
- Azure AD Connect には、ID データを格納する SQL Server データベースが必要です。 既定では、SQL Server 2019 Express LocalDB (SQL Server Express の簡易バージョン) がインストールされます。 SQL Server Express のサイズ制限は 10 GB で、約 100,000 オブジェクトを管理できます。 さらに多くのディレクトリ オブジェクトを管理する必要がある場合は、インストール ウィザードで別の SQL Server インストール済み環境を指定します。 SQL Server のインストールの種類により、Azure AD Connect のパフォーマンスに影響することがあります。
ここで疑問に思ったのが、 サイズ制限 10GB で役 100,000 オブジェクト管理できるというところ！
SQL Express のサイズ上限が 10 GB というのはよく聞きますが (聞かれてない方はすみません、、、そういう制約なのです)、約 100,000 オブジェクトとは？？？ってところにも手を出してみます。
というわけで！今回は
「AADC にて Local DB を利用する際の制約」について記載します。
上記に記載の制約とのことだったので、以下 3 つに分けて確認していきます。
- SQL Express のサイズ上限 10 GB はどこをみたらよいのか
- 約 100,000 オブジェクトとはどこをみたらよいのか
- 約 100,000 オブジェクトとはどういうことか
========================================
1. SQL Express のサイズ上限 10 GB はどこをみたらよいのか
========================================
標準設定にて AADC をインストールすると、AADC のバージョンにもよりますが、以下のパスにデータベース ファイルが配置されます。
※ AADC Version 2.xx で確認しています。
C:\Program Files\Microsoft Azure AD Sync\Data\ADSync2019
このパスに ADSync.mdf というファイルがあり、これが実際のデータです。
このファイルが 10 GB 以内であれば OK ということですね！
結構簡単なお話です。
========================================
2. 約 100,000 オブジェクトとはどこをみたらよいのか
========================================
次に約 100,000 オブジェクトってなんだろうってことなのですが、
これは、 AD から Azure AD に同期をおこなっているユーザーやグループのオブジェクト総数ではないという点に注意です！！！！！
同期する数が 100,000 を切っていたらいいというわけではないんですね！
それは、 AADC が以下の構成になっていることに起因するようです。
AADC の Sync サービスでは、上記のとおり、各ディレクトリ(AD や Azure AD)と接続する [コネクタ スペース] とコネクタ スペースの情報をマージする [メタバース] に分かれています。
細かい情報が知りたい方は、以下の URL を見てみてください。
なので！！！！！純粋に自分が同期していると思っているオブジェクトだけでなくそれ以外にもオブジェクトがいるよ！！ってことなんだそうです！
そのため、メタバースとコネクタ スペースのオブジェクト数をカウントする必要があるみたいですね～！
- オブジェクト数のカウント方法
1. AADC で Synchronization Service を起動します。
2. Tools から Statistics をクリックします。
3. コネクタ スペースごとのオブジェクト数やメタバースのオブジェクト数が確認できます。
下図の赤枠がオブジェクトの総数です。
これが 約 100,000 まで OK ということですね！！！
========================================
3. 約 100,000 オブジェクトとはどういうことか
========================================
なぜ約 100,000 オブジェクトになっているのか、、、、、超えたらどうなるの？って思いますね！
これは、SQL Server Express の 10 GB のサイズ制限によるもののようです！
つまり、 だいたい 100,000 オブジェクトだとデータベースのサイズが 10 GB くらいになるよってことのようです！
なので、 100,000 オブジェクト超えていたとしてもデータベース サイズが 10 GB 以内なら特に問題ないようです！！
- まとめ
今回は AADC について調べてみました。
Azure AD への同期数が オブジェクト数と思っていると意外と違う！！ってことにびっくりしますね！
最初はコネクタ スペース とか メタバースってなんやねん！！！！！！って思うかもですが、そうやってできているんだなあ～っとぼんやり思っていただくだけでもよいかも！
興味がある方は、公開情報に細かく記載があるのでぜひ読んでみてください。
- 最後に！
Twitterでも情報発信したいと思いますので、興味があったらフォローしてください！
Azure AD と Salesforce のプロビジョニングでのエラー
こんにちは。
今回は Azure AD を利用した Salesforce とのプロビジョニングの設定でのエラーについて記載します。
プロビジョニングは簡単にいうと Azure AD のユーザーを Salesforce に同期するよってことですね。
その際にエラーが発生したので、対応した内容を記録しておきます。
- 発生したエラー
今回、Azure AD のプロビジョニング ログに以下のエラーが発生していました。
・エラーコード
AzureActiveDirectoryDuplicateAppRoleForValueProperty
・エラーメッセージ
All application roles must have unique Id, Name and Claim in Azure AD. Attempt to update application roles resulted in a number of duplicated entries and will be aborted. This is most commonly caused by having non-unique role names in the directory of import. Application roles with non-unique values: [Id: 0921073b-b00d-40d7-be96-ac30921e3599, Name: Authenticated Website, Claim: ] [Id: 6808f7a0-09e8-42f5-a681-8cc0f60709cd, Name: Authenticated Website, Claim: ] . This operation was retried 0 times. It will be retried again after this date: 2021-11-04T09:46:54.4614788Z UTC
- 設定方法
1. Azure AD にアクセスをしてエンタープライズアプリケーションをクリック
2. 新しいアプリケーションをクリック
3. 検索ボックスに salesforce と入力し、表示されたアイコンをクリック
4. 任意の名前を入力して、作成をクリック
5. 作成されたアプリケーションに移動し、プロビジョニングをクリック
6. 作業の開始をクリック
7. 自動を選択
8. Salesforce に管理者でログオンして、画面右上から設定をクリック
9. 私のセキュリティトークンのリセットからセキュリティトークンのリセットをクリック
10. 9で設定していたユーザーのメールアドレス宛に以下のメールが届きます。
その中のセキュリティトークンをコピーします。
10. Azure AD の画面に戻り、以下の情報を入力してテスト接続をクリック
管理ユーザー名 : Salesforce の管理アカウント
管理者パスワード : 上記ユーザーのパスワード
シークレットトークン : 10 で確認した値
テナントの URL : ガバメントのテナント以外であれば空欄
※ちなみに私は空欄
11. テストが成功したら保存をクリック
12. 表示されたマッピングから Provision Azure Active Directory Users をクリック
13. 必要に応じてマッピングを変更
saleforce のユーザー名を Azure AD のほかの属性にする場合は、Username の行をクリック
14. ソース属性より変更可能
Azure AD の規定属性に加え、オンプレ ADからディレクトリ拡張した値も利用可能
設定が終わったら保存をクリック
- 動作確認
再度プロビジョニングのブレードを確認すると、下図の状態になっています。
プロビジョニングが開始していない場合は、プロビジョニングの開始ボタンをクリック
今回はエラーが発生していたので、以下からログを確認しました。
冒頭に記載したとおり、以下のログが確認できてプロビジョニングが失敗していることが確認できます。
なにこれ！？！？！？！
ってなったわけですが、調べていくと、記載の通りロールが重複しているってことがわかります。
重複するロール名は「Authenticated Website」とあるので、 Salesforce 側のロール (プロファイル) を確認すると.........
おったあああああ～～～～～～～～～～
なんで同じ名前のプロファイルが２つあるや！！笑
これが原因と思われます！
ってことでこれを削除したいのだが。。。。。。。。
削除できん！！！笑
Salesforce のコミュニティを確認してみると、どうやらサポートに問い合わせて削除してもらわないといけないらしい。。。。。
これはめんどくさいぞ！！！！！！！笑
まあでもとりあえず問合せってことで以下のリンクより問合せ
ログイン後、以下からケースを作成可能です。
問合せをしてしばらくすると、開発環境ではサポートできないとのこと。。。。。詰んだ。。。。
- 他の方法を検討してみた
Azure AD にてプロビジョニングのマッピングを再確認してみると、 Profilename にマッピングしているものがいた！！
これを変更したらプロビジョニングできるのでは？？と思ったのですが、削除できません。
なので一回上記赤枠の属性をクリックして対象の属性を他の値に変更します。
すると削除ボタンがアクティブになるので、削除！！！！
本来は、Profilename に値が入らなくなるのでやめたほうがいいのですが、検証環境のためこれで一時しのぎしました。
皆様ちゃんとサポートに問い合わせして対応してくださいね！
あくまでも一時しのぎです。ごめんなさい。
プロビジョニング ログを確認すると、プロビジョニングが成功したことが確認できます。
やはり、上記の Profilename 属性が原因だったことが分かりました。
- 最後に！
Twitterでも情報発信したいと思いますので、興味があったらフォローしてください！
AzureADを利用してガルーンクラウドにシングルサインオンする(ドメイン参加端末のみアクセス許可)
こんにちは。
この間、前職の先輩社員から下記みたいなことってできるよね？
と相談を受けました。せっかくなので先輩社員とともに検証してみましたのでその内容を記録します。
※実際に構築する際のお役にたてば何よりです！
- ガルーンクラウドと Microsoft365 にそれぞれシングルサインオン
- ドメイン参加している端末のみアクセス可能
- Windows にログオンしたらガルーンクラウドと Microsoft365 へのシングルサインオンも完了させる
これを利用するために今回AzureADを利用しています。
大まかに以下の内容を利用します。
- オンプレADと AzureADをAzureADConnect で同期設定( Hybrid Azure AD Join )
- AzureADにてガルーンクラウドにシングルサインオン設定
- ガルーンクラウドに対してAzureADの条件付きアクセスを設定
イメージだと下図の感じです。
※こちらの環境の都合上 Intune とか入ってしまっていますが無視してください。
- 必要ライセンス
今回必要なライセンスは Azure AD Premium P1 以上です。
内訳は下記の感じです。
1. オンプレADと AzureADをAzureADConnect で同期設定( Hybrid Azure AD Join )
→AzureAD Freeで可能 ( SLAはないけど )
2. AzureADにてガルーンクラウドにシングルサインオン設定
→AzureAD Freeで可能 ( SLAはないけど )
3. ガルーンクラウドに対してAzureADの条件付きアクセスを設定
→AzureAD Premium P1以上が必要
- 今回の前提
今回の構成ではHybrid AzureAD Join端末が必要となります。
Hybrid Azure AD Join構成は過去に方法を書いたので今回は省略します。
また、下記に記載していますが、オンプレADのExtensionAttribute1という値を利用しています。
この値をAzureADに同期する設定をAzureADConnect内で実施していますが、今回は手順を省略しています。
今回のブログでは上記が完了した前提で、以下2点を記載します。
1. AzureADを利用してガルーンクラウドとシングルサインオンを設定
2. AzureADの条件付きアクセスを設定
- 事前検討事項
シングルサインオンを実施する際にだいたいいつも検討することになると思いますが、
以下を検討しましょう。
1. ガルーンクラウドにアクセスしてよい人をどのように制御するか
2. AzureADとガルーンクラウドのIDが違う場合、どのようにマッピングするか
3. AzureADを経由せず、ガルーンクラウドにアクセスさせてよいか
4. どの認証プロトコルを利用するか
今回はそれぞれこんな感じで対応します。
1. AzureAD内でユーザーを指定
→実運用だとグループとかで指定したほうがよいかと！
2. 以下の図の通りマッピング
※AzureADのIDと利用SaaSのIDが違うってことが多々あるため、、、
今回はExtension Attribute1という場所を使ってサインインするようにします。
3. 今回はガルーンクラウドに直接アクセスもOKにします。
※NGにするときもチェックボックスにチェック入れるだけなので
4. ガルーンクラウドはSAML2.0に対応しているのでSAML認証で設定します。
- 設定方法
AzureADポータルよりエンタープライズアプリケーションを開きます。
新しいアプリケーションをクリック
検索画面にKintoneと入力し、表示されたKintoneをクリック
※ガルーンクラウドなのになんで？と思うかもしれませんが、Kintoneとガルーンクラウドは共通のポータルになっているようだ。。。。
これってつまりガルーンクラウドのSSO設定したらKintoneにもSSOされるってことでは・・・・？？逆も然り・・・笑
まあいいか・・・・(知らん顔)
名前を入力して作成をクリック
ユーザーとグループの割り当てをクリック
ユーザーまたはグループの追加をクリック
選択されていませんをクリック
対象のグループやユーザーを選択
割り当てをクリック
ガルーンクラウド側に移り、cybozu.com共通管理をクリック
その後、ログインをクリック
SAML認証を有効にするにチェックを入れる
Service Prividerメタデータのダウンロードをクリックしてxmlファイルをダウンロード
AzureAD側に戻り、メタデータをアップロードするをクリックして上記でダウンロードしたxmlファイルをアップロード
※エンティティIDは*がデフォルトで入りますが、*だとエラーになるのでドメイン名に修正
なお、一回エラー起きると保存できなくなるのでやりなおし、、、笑
ユーザー属性とクレームの編集をクリック
必要な要求の値をクリック
ソース属性から今回ガルーンクラウドにアクセスするときに利用する値の場所を選択して保存
user.msds_cloudextentsionattribute1を選択しました。
証明書(Base64)のダウンロードをクリックして証明書をダウンロード
ログインURLとログアウトURLをメモ
ガルーンクラウド側の画面に戻り、SSOエンドポイントURLにログインURLをログアウト後に遷移するURLにログアウトURLを入力し、先ほどダウンロードした証明書をアップロードして保存
ちなみにこれにチェックボックスいれるとかならずAzureADからサインインするように制限できます。
ただし、ドキュメントみると、これにチェックいれるとKintoneのAPIが使えなくなるみたいなこと書いてあった。。。。。まじっすか！！！
検証してないのでほんとかわからないのですが、、、、一応
AzureADに戻りTestをクリック
対象ユーザーを選択
無事入れました。
AzureADから発行するURLだとここがログインURLになっているのですが、
ガルーンクラウドはSP-Iniciate対応なので、「https://xxx.cybozu.com/g/」でアクセスすれば、予定表画面にアクセス可能です。
ここまでで、シングルサインオンの設定は完了！
ここからは条件付きアクセスを使ってHybridAzureADJoinした端末からのみアクセス可能にします。
エンタープライズアプリケーション内の作成したアプリから条件付きアクセスを選択し新しいポリシーをクリック
※先ほどまでと同じブレードです。
名前を入力
今回はHybrid AzureAD JoinのみOKとするので、こんな設定にしました。
本来はアクセス可能としたグループとかを割り当てることになるかと思います。
※アクセスできなくなった時のことを考えて対象外のユーザーを作成しておくことも重要
また、今回はとりあえずで作成したので考慮していませんが、
この設定をしていないので、スマホからのアクセスが不可となります。
スマホからもアクセスしたい場合、この条件から対象外として、スマホ用の条件付きアクセスを作成すると良いと思います。
※Intuneにて準拠済みならOKみたいなのをスマホ用として作成するとよいかも！
Intuneライセンスいるけどね。。。。
設定が終わったら、作成ボタンをクリックしますが、デフォルトだとレポート専用となっています。
※レポートは出すけど、実際にブロックしたりしないよってことね！
慎重にやるならこれで稼働したのちオンに切り替えるとよいと思います。
ポリシーが作成されたのち、ちゃんと適応されるか確認するために、What ifを利用します。
条件を指定してWhat ifを実行すると
どのポリシーが適用されるか確認できます。
実際にアクセスすると
ブロックされました！！！
Hybrid Azure AD Join端末から試すと！
WindowsにサインインしただけでAzureADのログオン画面もでることなくアクセスできました！
ちなみに今回Chromium Edgeで実施していますが、Chromeとかだとデフォルトはこうなるのでご注意ください。
- まとめ
条件付きアクセスとかを色々変えると様々なパターンのアクセス条件が作成できるので、ライセンスお持ちの方はぜひ利用してみては？？
- 最後に！
Twitterでも情報発信したいと思いますので、興味があったらフォローしてください！
