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