반응형

Office 365 Azure AD 존재하며 각각의 계정은 Azure AD 계정으로 볼수 있습니다.

이미 AD Onpremise 존재할 경우 AAD DirSync 통해서 AD 개체와 AzureAD 동기화를 진행하여 기존 사용자들을 그대로 AD에서 관리할 있습니다. 단순하게 표형 하면 방향을 AD -> Azure AD 사용자 개체를 동기화 하는 개념입니다.

그런데 경우에 따라서 이미 생성된 Office 365 Account(AAD Account) AD 등록된 사용자와 Match 시켜야하는 같은 시나리오가 있습니다.

1. 재해복구시나리오. Domain Controller 완전히 망가져서 AD 새롭게 구축하는경우
2. AD Sync 전에 Office 365 계정을 먼저 만들어서 이용하다가, 나중에 AD Sync 도입하여 동기화해야하는 경우

만약 어찌어찌 해서 기존 사용자 리스트 정보를 백업한 , AD DC 다시 구축한다음 사용자들을 불러와도 AD Sync , 이미 계정들이 존재하기 때문에 덮어 씌우는 개념으로 동기화 없습니다.

 

이러한 경우 Hardmatch 통해서 동기화 진행이 필요하고, objectGUID, ImmutableID 대한 개념이해가 필요합니다.

 

sourceAnchor
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.


The attribute is used for the following scenarios:


  1. 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.
  2. 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.
  3. 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.

Using msDS-ConsistencyGuid as sourceAnchor
By default, Azure AD Connect (version 1.1.486.0 and older) uses objectGUID as the sourceAnchor attribute. ObjectGUID is system-generated. You cannot specify its value when creating on-premises AD objects. As explained in section sourceAnchor, there are scenarios where you need to specify the sourceAnchor value. If the scenarios are applicable to you, you must use a configurable AD attribute (for example, msDS-ConsistencyGuid) as the sourceAnchor attribute.


Azure AD Connect (version 1.1.524.0 and after) now facilitates the use of msDS-ConsistencyGuid as sourceAnchor attribute. When using this feature, Azure AD Connect automatically configures the synchronization rules to:


  1. Use msDS-ConsistencyGuid as the sourceAnchor attribute for User objects. ObjectGUID is used for other object types.


  1. 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.

Reference

Azure AD Connect: Design concepts

 

이미 DC 소실되어 다시 구성이 필요한 경우 Reference 자료를 참고하여 차근차근 진행하면 됩니다.

저는 이미 Cloud  계정이 있는 경우 AD 계정과 Sync 하는 방법에 대해서 다뤄보겠습니다.

 

그리고 Cloud 계정에서 테스트 계정을 생성합니다.

Powershell   Azure 접속하여 immutableid 조회시 없는 것으로 확인됩니다.

 

 

이미 동기화 계정의 경우 아래와 같이 확인할 있습니다.

 

그런데 AD 상에서 ObjectGUID 확인하면 Immutableid 일치하지 않는 것이 확인됩니다. 일치하지 않는다기보단 변환이 필요한 것으로 보입니다.

 

 

아래의 테크넷 블로그에 변환과정이 자세히 나와 있습니다.

How to do Hard match in Dirsync?

How to do Hard Match- Part 2 ?

 

DC에서 2번째 자료에서 제시된 명령어로 진행

ldifde -f export.txt -r "(Userprincipalname=*)" -l "objectGuid, userPrincipalName"

 

TXT 파일에서 move1@contoso.kr 값이 일치하는 것을 확인할 있습니다.

dn: CN=Move 2010,OU=EXOnpremise-AAD,DC=contoso,DC=kr
changetype: add
objectGUID:: s4BkdtFIVkO/nVqsfBHnOg==
userPrincipalName: move1@contoso.kr

 

AD에서 hardmatch 계정을 생성합니다.

 

명령어로 ObjectGUID 확인합니다.

 

Powershell Azure 접속하여 아래와 같이 Immmutableid 설정합니다.

Set-MsolUser -UserPrincipalName 1stcloud@kor1.onmicrosoft.com -ImmutableId 5fgGGM2IjES/0Yw5Ry7+4Q==

 

 

AD Sync 이뤄진 것을 확인할 있습니다.

 

 

반응형

+ Recent posts