Office 365 는 Azure AD에 존재하며 각각의 계정은 Azure AD 계정으로 볼수 있습니다.
이미 AD Onpremise가 존재할 경우 AAD DirSync 를 통해서 AD 개체와 AzureAD 와 동기화를 진행하여 기존 사용자들을 그대로 AD에서 관리할 수 있습니다. 이 때 단순하게 표형 하면 방향을 AD -> Azure AD 로 사용자 개체를 동기화 하는 개념입니다.
그런데 경우에 따라서 이미 생성된 Office 365 Account(AAD Account) 를 AD에 등록된 사용자와 Match 시켜야하는 같은 시나리오가 있습니다.
만약 어찌어찌 해서 기존 사용자 리스트 정보를 백업한 뒤, AD DC 를 다시 구축한다음 그 사용자들을 불러와도 AD Sync 시, 이미 계정들이 존재하기 때문에 덮어 씌우는 개념으로 동기화 할 수 없습니다.
이러한 경우 Hardmatch 를 통해서 동기화 진행이 필요하고, objectGUID, ImmutableID 에 대한 개념이해가 필요합니다.
The sourceAnchor attribute is defined as an attribute immutable during the lifetime of an object. It uniquely identifies an object as being the same object on-premises and in Azure AD. The attribute is also called immutableId and the two names are used interchangeable.
The word immutable, that is "cannot be changed", is important to this document. Since this attribute’s value cannot be changed after it has been set, it is important to pick a design that supports your scenario.
When a new sync engine server is built, or rebuilt after a disaster recovery scenario, this attribute links existing objects in Azure AD with objects on-premises.
If you move from a cloud-only identity to a synchronized identity model, then this attribute allows objects to "hard match" existing objects in Azure AD with on-premises objects.
If you use federation, then this attribute together with the userPrincipalName is used in the claim to uniquely identify a user.
This topic only talks about sourceAnchor as it relates to users. The same rules apply to all object types, but it is only for users this problem usually is a concern.
For any given on-premises AD User object whose msDS-ConsistencyGuid attribute isn't populated, Azure AD Connect writes its objectGUID value back to the msDS-ConsistencyGuid attribute in on-premises Active Directory. After the msDS-ConsistencyGuid attribute is populated, Azure AD Connect then exports the object to Azure AD.
이미 DC가 소실되어 다시 구성이 필요한 경우 위 Reference 자료를 참고하여 차근차근 진행하면 됩니다.
저는 이미 Cloud 계정이 있는 경우 AD 계정과 Sync 하는 방법에 대해서 다뤄보겠습니다.
그리고 Cloud 계정에서 테스트 계정을 생성합니다.
Powershell 로 Azure 에 접속하여 immutableid 조회시 없는 것으로 확인됩니다.
이미 동기화 된 계정의 경우 아래와 같이 확인할 수 있습니다.
그런데 AD 상에서 ObjectGUID 를 확인하면 Immutableid 와 일치하지 않는 것이 확인됩니다. 일치하지 않는다기보단 변환이 필요한 것으로 보입니다.
아래의 테크넷 블로그에 변환과정이 자세히 나와 있습니다.
ldifde -f export.txt -r "(Userprincipalname=*)" -l "objectGuid, userPrincipalName"
TXT 파일에서 move1@contoso.kr 의 값이 일치하는 것을 확인할 수 있습니다.
AD에서 hardmatch 할 계정을 생성합니다.
Powershell 로 Azure 에 접속하여 아래와 같이 Immmutableid 를 설정합니다.
AD Sync가 이뤄진 것을 확인할 수 있습니다.