AzureADConnectの連携が妙なので調べてみた。(調査編）
調べ方の参考になればという程度で残します。
連携をしてみたら、以下の症状があったので、妙に思いつつ調べる。
・Azure ADにないグループは連携されない。
・Azure ADにないユーザは自動的にランセンスが付与される。
・有効なユーザはUPNの設定がXXX.localでも連携される。
その際にはライセンスは付与されない。
向き合うDocsはこのあたりか
まずはをSynchronization Service Manger実行
Azure AD Connectと同時にインストールされたSyanchorinization Seriveを起動する。
起動するとこんな画面。30分毎ぐらいに同期しているのがわかる。
「Status」でエラーを見つけたので見てみた。
問題は「disableuser2」がうまいこと言ってないよというエラー。
このユーザはUPNは合わせているけど、アカウントは「無効」にしているのであえて連携しなくていいアカウント。
とは言え、中を見てみると、「この操作を実行するための十分なアクセス権がありません」とでた。
他のユーザとの差がわからないので、「disableuser2」を「onmicrosoft.com」から「.local」に変更したが、エラーに変化なし。
「Permission-issue」 、「Error Code ; 8344」を検索してみたら以下に回答が
対応時にはpowershellを使うので以下の記事のPowerShell部分も参照
今回はうまくいった。
Powershellの部分はインストールの記事に更新をしておかねば。
MS365側を見ると
なんと、無効にしているユーザが全部が出来ていた。
違和感を感じた部分は直ってないけど、うまいこと作成されていなかったユーザは出来上がった。
idfixツールで調査する
Azure AD Connectにあたっておかしなアカウントが無いか調べてくれるツールがあるので導入する。下記よりidfixを入手し、インストールする。
https://github.com/microsoft/idfix
ソフト起動後、「Query」をクリックすると以下のような画面が出てくる。
特定のオブジェクトの属性(ATTRIBUTE)に対してERRORが出ているので、以下を参考に見ていく
・TopLevelDomain
こちらはAzureAD Connectように作ったユーザ
ユーザプリンシパルネームがメールの形式じゃない。
意図的にやっているものばかりなのでこちらは問題ない。
・Blank
必要な箇所が空欄とのこと。
OU1-1は連携できているから問題ないはずと改めてAzure ADを見てみると、あらかじめ作成しておいたグループが連携できないMS365グループだったため、ランダムな数字が入った「メールが有効なセキュリティグループ」が出来ていることが分かった。
とは言え、idfixはローカルのADの中身を指摘するソフトなので、今回は関係ない。
idfxi側の「ACTION」を「EDIT」にし、画面上部の「Apply」をクリックした。
EDITしていないグループと見比べてみる。
AD側のグループの属性エディター内の「displayName」を入れないと怒られることが分かった。しかし、Azure AD側には連携したのだから問題ないのでは？
・Duplicate
他のアカウントで同じ値がある。
こちらはまだ連携させていないので、いずれ調べてみる。
今回はここまで
今後について
一度各ユーザやグループを消して今一度作成しなおしてみる。
MS365グループがAzure AD Connectでは連携対象でなかったと実際に見て覚えられたのはよかった。
Docsと向き合えばすぐだったんだろうけど。