パーソルクロステクノロジーの内田です。
Azureというクラウドサービスを支える主たるサービスであるEntra ID。これの同期処理について解説します。

認証について

本題に入る前にディレクトリサービスの認証について話しましょう。
認証とはその行為を行う人物が、正しく本人であるかどうかを確認するためのステップです。
映画やドラマなどで秘密裏に何かを企てている人たちが合言葉で組織に属している仲間であるかを確認する行為も認証と言えます。ITの世界では合言葉の代わりにパスワードや証明書、それから一時的に発行したトークンなどを用いて認証を行うことになります。これらは認証方式と呼びます。
そして認証行為を行う主体のことをプリンシパルと呼び、そのプリンシパルが提示した認証方式の内容が適切であるかを判断するものがディレクトリサービスであり、認証機関と呼びます。

ITの世界では認証を行うのは人だけではありません。アプリケーションも認証することがあります。そのためEntra IDは認証行為を行う主体であるアプリケーションのことをサービスプリンシパルと呼んだりしています。

 簡単に説明するためにパスワードを用いた認証を例に挙げていきましょう。
プリンシパルはまず自分が誰であるかを提示します。
人に限った場合、メールアドレスだったり社員番号などを提示することになると思いますが、この時提示する内容はユーザープリンシパル名と呼ばれるものです。ユーザープリンシパル名に何を用いるかは組織にて設定しているため、メールアドレスだったり社員番号だったり、組織によって異なります。
アプリケーションすなわちサービスプリンシパルの場合は、ユーザープリンシパル名の代わりにクライアントIDを提示します。
続けてプリンシパルは自分が正しく自分であることをディレクトリサービスに示すためにパスワードを提示することになります。
ディレクトリサービスはUPNやクライアントIDとパスワードを照らし合わせて、プリンシパルが正規のユーザ、アプリケーションであることを確かめその認証行為を許可/拒否します。

なお認可についても補足しましょう。認証はその行為を行った人が本当にその人自身であるかを確かめる行為です。一方で認可とは何をしてよいかを定めたものであり、アクセス制御と呼ばれるものです。条件付きアクセスによるサービスに対するアクセス許可であったり、RBACによる所有者・共同作成者、セキュリティグループに属しているか、ファイルサーバにおけるNFTSアクセス権などが認可にあたります。

IDについて

 ここからはIDについて話していきましょう。ディレクトリサービス内でプリンシパルを一意に識別するための属性値を通称IDと私たちは呼んでいます。IDはプリンシパルを一意に識別する必要がありますので、重複することは許されません。重複を許さない値を生成する際に用いられるものがGUIDと呼ばれるものです。これは128ビット(16バイト)で構成される値であり、文字列で表す際には先頭から4ビット毎に16進数に変換し、合計32桁の文字列を以下の形式で表します。
8桁-4桁-4桁-4桁-12桁

ここで実際にActive Directory上のユーザのIDを確認してみましょう。ADSIエディタでユーザのプロパティを確認すると「ObjectGUID」という属性値が存在することを確認できます。私の検証環境で作成したユーザのObjectGUIDは以下の値でした。

859eaaaa-bfbf-4d21-9ccc3-fb8ad8da22a7

この値は上述した通り合計32桁の文字列で表しているわけですが、実際のデータとしては128ビットのバイナリ長で保管されています。というわけでバイナリ長で実際のデータを見てみると以下のようになっています。

10101010 10101010 10011110 10000101 10111111 10111111 00100001 01001101 10011100 11000011 11111011 10001010 11011000 11011010 00100010 10100111

確かに128ビット(16バイト)で構成されていることが確認できます。このままだとよくわからないので、16進数へ変換してみましょう。上述した通り先頭から4ビット毎に16進数へ変換することになります。最初の8ビット(1バイト)を例に取り上げると、「1010」と「1010」に分割できます。1010ですので2^3+2^1=8+2=10であり、これはAとなることから、最初の8ビットはAAと表せます。この要領で計算してくと次のように表せます。

AA AA 9E 85 BF BF 21 4D 9C C3 FB 8A D8 DA 22 A7

先ほどのObjectGUIDと比較してみましょう。

ObjectGUID：859eaaaa-bfbf-4d21-9ccc3-fb8ad8da22a7
計算した値：AA AA 9E 85 BF BF 21 4D 9C C3 FB 8A D8 DA 22 A7

8桁-4桁-4桁-4桁-12桁の先頭3つがリトルエンディアン形式（コンピュータが処理しやすいように逆から読む形式）、後半2つがビックエンディアン形式（人が直感的に把握しやすい形式）で表記されていることが確認できます。

Entra IDとADの同期について

さてここまでActive DirectoryのユーザIDについて紐解いていきました。この内容をベースにEntra IDのユーザとの関係性を紐解いていきましょう。
Active DirectoryとEntra IDの同期を構成するということは、Active Directory上の一意のユーザと、Entra ID上の一意のユーザが1対1の関係で紐づくということです。この紐づけにはアンカーを用います。アンカーには、Active Directory上のユーザの「ms-DS-ConsistencyGUID」という属性値と、Entra ID上のユーザーの「ImmutableID（オンプレミスの不変ID）」という属性値が用いられます。
要はこれらの値が同じオブジェクトが1対1で紐づけされることになります。

デフォルト値を採用しているのであれば、Entra ID Connectによる同期処理によってImmutableIDにはObjectGUIDをBase64エンコーディング([A-Z][a-z][0-9]+/の64文字)した値がセットされます。ms-DS-ConsistencyGUIDにはObjectGUIDがそのままセットされます。

実際に先ほどのObjectGUIDをBase64エンコーディングすると、Entra ID上のImmutableIDに等しい値が設定されていることが確認できます。

$Guid = "859eaaaa-bfbf-4d21-9cc3-fb8ad8da22a7"
$ParseGuid = [System.Guid]::Parse($Guid)
$GuidBytes = $ParseGuid.ToByteArray()
$Base64Guid = [System.Convert]::ToBase64String($GuidBytes)
Write-Host $Base64Guid
#qqqehb+/IU2cw/uK2Noipw==

ソフトマッチとハードマッチについて

Entra ID上にはオブジェクトが存在していない場合には、同期処理によってEntra ID上にユーザオブジェクトが新規に作成されるとともに、ImmutableIDとms-DS-ConsistencyGUIDに同じ値がセットされることによって、オブジェクト同士が1対1で紐づけられます。

ただし環境によってはEntra IDに既にユーザオブジェクトが存在していて、その既存オブジェクトと紐づけを行いたいというケースが存在します。その時のマッチングの方式として、ソフトマッチとハードマッチの2種類が存在します。
ソフトマッチとは、ID以外のユーザーを一意に識別する属性としてメールアドレスを用います。ADとEntra IDのユーザオブジェクトでメールアドレスが合致するものを同期対象として処理を行い、ImmutableIDとms-DS-ConsistencyGUIDに適切な値をセットする方式です。
ハードマッチとは、ImmutableIDに予め適切な値をセットしておくことによって、強制的にマッチングさせる方式です。

これらのマッチングの特性からEntra ID Connectによる同期処理には以下に示すような優先順位が存在します。
①ImmutableIDが等しいオブジェクトは存在する→ハードマッチによる同期処理
②メールアドレスが等しいオブジェクトは存在する→ソフトマッチによる同期処理
③①、②に該当するオブジェクトが存在しない→同期処理によって新規オブジェクト作成

蛇足：なぜBase64エンコーディングを行うのか

個人的な見解です。
そもそもObjectIDはバイナリ形式で保管されているデータとなりますが、バイナリのままやり取りを行うには何かと不整合が生じるため、何らかの形式に変換することが望ましいと言えます。
コンピュータの歴史的背景から、バイナリデータの送信時にはBase64エンコーディングするのが標準的です。実際GUID形式だと16進数36桁(ハイフン含む)であるところが、Base64形式だと64進数24桁であり、データ量として1/3の削減であり効率的であるといえます。