在物件存留期間不會變更的屬性。

來源 : Azure AD Connect：設計概念 - sourceAnchor

而它會在什麼樣的情況使用呢？官方文件裡又這麼說

1. 在建置新的同步處理引擎伺服器，或在災害復原案例後進行重建時，這個屬性會連結 Azure AD 中的現有物件與內部部署的物件。
2. 如果您從僅限雲端的身分識別移至已同步處理的身分識別模型，則這個屬性可讓物件「完全比對」Azure AD 中的現有物件與內部部署的物件。
3. 如果您使用同盟，則這個屬性會與 userPrincipalName 一起用於宣告來唯一識別使用者。

來源 : Azure AD Connect：設計概念 -- sourceAnchor

講了很多，但如果將以上說明精簡化的話，我認為重點就是以下兩點。

1. 使用者的同步時，這屬性要確保同步雙方的物件都是從同一個來源來的。
2. 在使用 Azure AD 同盟 (Federation) 功能的登入驗證時，除了 userPrincipalName 以外，還會去檢查 Identity Provider (以下簡稱 IdP) 方所擁有的 immutableId 是否跟 Azure AD 上所擁有的值一致。

這部分會跟將 Azure AD 與加強資安防護的第三方 IdP 建立同盟關係 (Federation) 的時候有很大的關聯。以下讓我以 HENNGE Access Control 為實體的例說明一下實際的使用情境。

1. 使用者的同步

為了要達到同盟 (Federation) 關係，IdP 跟 Service Provider (以下簡稱 SP) 雙方必須要擁有同樣的使用者資訊。這時為了確保盡可能在使用者登入時都是 IdP 方跟 SP 方的資訊是一致的，通常我們會建構一個定期同步的關係。

在 HENNGE Access Control 與 Azure AD 建立同步關係的時候，HENNGE Access Control 會同步每個使用者的姓、名、顯示名稱、userPrincipalName 和 immutableId 到 Azure AD 上。此時，因為 HENNGE Access Control 會是使用者物件是同步的來源，將會由 HENNGE Access Control 生成 immutableId 同步至 Azure AD。

而如果公司將員工的使用者資訊都使用地端的 Active Directory 伺服器時，可以將其 Active Directory 設置為使用者物件的同步來源，將使用者資訊同步到 Azure AD 和 HENNGE Access Control。此時的 immutableId 一般來說會選用 Active Directory 上的 objectGUID (或是 ms-DS-ConsistencyGuid) 經過 Base64Encode 處理過後的值。

2. 有同盟 (Federation) 關係時的登入驗證

第一部分所提到的使用者屬性中，尤其重要的就是最後面的兩個值， userPrincipalName 和 immutableId 。因為如同微軟官方文件所說的一樣，在同盟 (Federation) 關係中經由 HENNGE Access Control 的驗證登入至 Azure AD 時，雙方所擁有的這兩個屬性的值必須要一致才有辦法完全的去參照 HENNGE Access Control 上成功驗證的使用者是 Azure AD 上的哪一個使用者，再讓此使用者登入至 Azure AD。

不知道這樣有沒有讓你對 immutableId 有一些了解呢? 下次在類似情況下發生錯誤的話不妨檢查一下 immtuableId 值的狀態吧!

如果想了解更進一步 immutableId 的細節的話，請參考微軟官方文件。

而關於包含 HENNGE Access Control 的 HENNGE One 的問題，歡迎與我們聯繫。