AD ConnectでオンプレADからAzure ADへユーザを同期する ※躓いた所を中心に説明します

# 概要
オンプレミスのサーバでActive Directoryを運用している組織でも、Azure ADにユーザ情報を同期すれば、クラウドサービスとのシングルサインオンは可能です。
この記事では、その手順を解説したいと思いますが、具体的な手順はインターネット検索等で入手しやすい印象です。
なので、筆者が実際にやってみた時に躓いた所や、苦戦した所を中心に解説してみようと思います。

# 前提
今回は、下記のケースを想定します。

- オンプレミスのActive Directoryでは、ドメイン名を`.local`で運用している
- Azure ADでは、「ユーザープリンシパル名」にメールアドレスを使いたい
- オンプレミスで登録されているユーザのうち、メールアドレスが設定してあるユーザのみ同期したい

オンプレミスのユーザをAzure ADに同期したいとき、多くのケースで問題になるのは、ユーザプリンシパルのドメイン名だと思います。
Azure ADでは、ユーザを一意に特定する「ユーザプリンシパル名」には、グローバルに名前解決できるドメインを使う必要があります。
したがって、オンプレミスでドメイン名を`.local`で運用している場合は、そのままではAzure ADへ同期することができません。Azure ADへユーザを同期する際、「メールアドレス」を「ユーザープリンシパル名」に読み替えるように設定する事が必要になります。
もちろん、この場合のメールアドレスは、自社のドメイン(自分たちでDNSレコードを変更できる)である必要があります。

# 手順
## Azure ADにドメインを登録する
Azure Portalの「Azure Active Directory」に「カスタム ドメイン名」という項目があるので、ここで自社のドメインを登録します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/230422/0d3b2e91-0736-380b-c7a1-7f740a5dd8a5.png)

登録後、申請者が本当にそのドメインを利用している組織であるのかを確認するため、DNSに指定されたレコードを追加する必要があります。
TTLも指定されますが、これは別の値でも問題ないみたい。私はゾーンのデフォルトのままにしちゃいましたが、問題ありませんでした。
(ただ、TTLを長くしてしまうと、Azure ADが設定したレコードを確認するのが遅くなると思うので、そのへんは自分たちの都合に合わせて設定すると良いでしょう)

### 躓きポイント
DNSにレコードを追加した後、いざ登録しようとしたところ、「このドメインはOffice365で既に使用されている」旨のエラーが出ました。
Office365やその他のサービスを自社ドメインで試用した時などに、意図せずAzure ADにドメインの設定が入ってしまう事があるらしく、実際社内に確認しましたが、誰も心当たりがありませんでした。

この場合は、「ドメインの強制引き継ぎ」をする事で、それらの設定をこっちに移行してしまう事ができます。
当社の場合、これを実施しても誰も困らない(はず)である事が確認できていたので、先に進む事ができました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/230422/316cc436-9d34-de56-8d0f-81f3386c23f2.png)

## オンプレミスサーバにAzue AD Connectをインストールする
次に、オンプレミスADに登録されているユーザをAzure ADに同期するため、Azure AD Connectをインストールします。(ドメインコントローラ以外のサーバにインストールする必要があります)
インストーラをダウンロードして、画面の指示に従っていけば、あまり迷う事はないと思います。

今回は、Azure ADでのユーザプリンシパル名にメールアドレスを使う事にしましたので、「Azure ADサインインの構成」のセクションでは、「ユーザプリンシパル名」に「mail」を指定するようにしてください。これにより、オンプレミスADの「メールアドレス」がAzure ADの「ユーザプリンシパル」として同期されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/230422/4b2bbb0e-de2a-65b9-245e-f19daa660020.png)

無事インストールが済めば、ユーザがドサっと同期されるはずです。

### 躓きポイント
途中で下記のような「スクリプトの実行が無効になっている」旨のエラーが出て、進めなくなってしまいました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/230422/c834c88c-0f94-ccfb-534c-ad83c94de064.png)

これは、サーバでPowerShellの実行が制限されているためです。特に、Windows Server2012以降ではデフォルトで制限されるようになっているので、このポリシーを変更しなければなりません。

PowerShellで`Get-ExecutionPolicy`を実行してみると、やはり`Restricted`(一切実行しない)に設定されていました。

```powershell
Get-ExecutionPolicy
Restricted
```

`Set-ExecutionPolicy`で`RemoteSigned`以下のポリシーに変更する事で、このエラーを回避できます。(`AllSigned`だとダメです)

```powershell
Set-ExecutionPolicy RemoteSigned
```

PowerShellの実行ポリシーについては、下記の記事が参考になりました。
[WindowsでPowerShellスクリプトの実行セキュリティポリシーを変更する](https://www.atmarkit.co.jp/ait/articles/0805/16/news139.html)

## メールアドレスを持つユーザだけ同期するようにする
上記までの設定で、オンプレADからAzure ADへユーザが同期されるようになりました。
ただ、できれば全ユーザではなく、SSOしたいユーザだけを同期したいです。
(実際にクラウドサービスへのSSOを設定する時には、どのユーザがどのサービスにSSOできるようにするか設定するので、関係ないユーザでもサインインできちゃうような事態にはならないと思いますが、使わないユーザはそもそも同期する必要はないはず)

このように、同期される条件等のルールを変更したい時は「Synchronization Rules Editor」というアプリを使用します。Azure AD Connectと一緒にインストールされているはずなので、スタートメニューから起動しましょう。

新しいルールを作って、「Scoping filter」に`mail` `ISNULL`の条件を`Add`します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/230422/e74f530c-00ef-3218-451f-6ca571567930.png)

「Transformations」に移動して、`cloudFiltered`を`True`に設定します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/230422/7d13b2cc-0348-9348-d64b-c4dccbf3fe76.png)

これで、次の同期が走った時には、メールアドレスがないユーザがAzure ADからごっそり削除されるはずです。

### 躓きポイント
特に躓いたわけではありませんが、「Synchronization Rules Editor」を編集する時には、Azure AD Connectの仕組みをしっかり理解してからにした方が良いでしょう。
特に、オンプレADとAzure ADの間には、「メタバース」という領域がある事を意識しておかないと、「Import」とか「Export」とかのアクションが、どの方向を指しているのか混乱してしまいます。
↓等でしっかり理解してから臨みましょう。
[Azure AD Connect 同期: 技術的概念](https://docs.microsoft.com/ja-jp/azure/active-directory/hybrid/how-to-connect-sync-technical-concepts)

# SSOするには、各クラウドサービスで設定が必要
これでAzure ADにユーザを同期する事ができました。
実際にクラウドサービスへのSSOを実現するには、この後各サービスごとに設定が必要です。
ヘルプなどを参照しながら設定を進めてください。