Microsoft Azure, Active Directory에 대해서… (3), AAD와 사내 AD와의 연계 두번째 이야기

Microsoft Azure, Active Directory에 대해서… (1)에서 Microsoft Azure AD(AAD)에 대한 기본 개념, 그리고 Microsoft Azure, Active Directory에 대해서… (2), AAD와 사내 AD와의 연계 첫번째 이야기에서 AAD에서 조직과 관련된 추가 도메인을 생성하고, 사내 AD와 동기화하는 방안(인증은 AAD)을 살펴보았습니다.

이번 포스팅에서는 AAD와 AD의 인증 방안에 대한 연관을 살펴보려고 합니다.

두번째 포스팅내 그림인 조직과 관련된 도메인을 입력하는 페이지입니다. AAD는 기본적으로 <원하는 도메인>.onmicrosoft.com 형태의 주소를 가지게 되지만, 원할 경우, 추가적인 도메인을 입력하고, 이를 사용자 생성에 활용할 수 있다고 하였습니다. 더불어, 해당 계정이 사내 AD에 존재하는 경우에 디렉터리 동기화를 통해서, 사용자 계정 및 암호까지 동기화하여, 인증을 사내 AD에서 하지 않고, 필요시 AAD에서 사내 AD 계정을 인증할 수 있게 할 수 있었습니다.

위 그림의 체크 박스인, “내 로컬 Active Directory를 사용하여 이 도메인을 Single Sign-On용으로 구성할 계획입니다.” 옵션에 대한 것이 이번 포스팅의 핵심입니다. 이를 선택하지 않고, 도메인을 추가했을 경우, 모든 계정에 대한 인증을 AAD에서 처리하는 구조였습니다만, 해당 체크 박스를 선택하면, 사내 AD 계정의 경우에는 사내 AD 인프라에서 인증을 처리하게 됩니다. 커베로스 기반의 AD 인증을 하는 것이 아니라, ADFS(Active Directory Federation Services) 기반으로 인증을 처리한다는 것이죠.

Windows Server의 ADFS(Active Directory Federation Service), IDentity 처리에 대한 고려 및 클라우드 시대를 위한 확장 포스팅에서 ADFS를 먼저 살펴본 것도 이 포스팅을 위한 사전 지식이었습니다.

AAD와 AD에 대해서 디렉터리 동기화를 시키고, 인증을 AAD에서 일괄 처리하는 형태는 사내 AD 인프라내 디렉터리 동기화를 위한 서버만 필요로 하였지만, ADFS를 근간으로 사내 AD 계정은 별도의 인증 절차를 밟게하는 것은 추가적인 ADFS에 대한 구성이 필요합니다. 더불어, ADFS 서버는 모든 처리를 인증서 기반의 SSL 통신을 이용하고 있기 때문에, 인증서가 필요하고, Microsoft Azure(Office 365도 사실 똑같은 AAD를 사용)와 연계하려면, 사내 사설 CA에서 발급한 인증서를 사용할 수 없고, 외부 공인 인증 기관에서 구매한 인증서가 필요합니다.

AAD에 대한 2번째 포스팅내 디렉터리 통합 페이지의 작업 단계입니다. 1단계부터 4단계까지의 작업을 진행하여 AAD와 AD를 통합하고, 인증을 AAD에서 처리하게 하였지만, 추가 도메인에 대해서 사내 AD에서 처리한다는 체크 박스를 하고 진행하게 되면, 단계가 추가되게 됩니다.

이 경우, 도메인 추가 단계에서 도메인 확인 절차를 DNS 서버로 진행하는 페이지가 나타나지 않고, 디렉터리 통합 페이지에서 작업을 완료하라는 메시지가 표시됩니다.

2단계가 조금 달라진 모습을 볼 수 있습니다. 2단계에서 ADFS 형태의 페더레이션 서버와 연계하는 작업을 진행하라고 합니다. 해당 자세한 정보 링크는 ADFS의 구성 기술 페이지으로 연결됩니다.

기존 ADFS 서버를 기반으로 추가적으로 할 작업은 Install Windows PowerShell for single sign-on with AD FS와 Set up a trust between AD FS and Azure AD입니다. ADFS 입장에서는 AAD가 신뢰 당사자가 되는 형태로 연결이 필요합니다. (이해가 잘 안되는 분들은 ADFS 포스팅, Windows Server의 ADFS(Active Directory Federation Service), IDentity 처리에 대한 고려 및 클라우드 시대를 위한 확장를 참고하세요.) 이를 위해서, ADFS 서버나, 사내 AD 인프라내 서버에 Azure PowerShell을 설치해야 합니다.

Connect-MsolService를 통해, AAD 테넌트로 관리자 권한 접속을 진행합니다.

우선 도메인이 정상적으로 Microsoft Azure에서 확인되었는지를 위해, Get-MsolDomainVerificationDns Cmdlet을 이용하여, 생성할 TXT 레코드를 확인합니다.

MS=ms15610537이 생성되어 있어야 하는 형태입니다. 이를 DNS 서버에 TXT 레코드로 생성합니다.

Set-MsolADFSContext -computer <ADFS 서버 내부 이름>을 입력합니다.

마지막 Cmdlet은 New-MsolFederatedDomain입니다.

Get-MsolDomain Cmdlet을 통해 확인하면, 추가된 도메인이 Federated 상태이며, 확인되었음을 알 수 있습니다.

당연히 Microsoft Azure 관리 포탈에도 정상적으로 표시되어야 합니다.

사내 ADFS 서버의 신뢰 당사자 트러스트 항목에 Microsoft Office 365 Identity Platform이 ADFS 보안 토큰을 전달받을 수 있는 신뢰 당사자로 등록되게 됩니다.

이 후, 사내 AD 계정 정보에 대한 동기화를 위해 디렉터리 동기화 도구를 설치 및 구성해야 합니다. 이는 앞선 Microsoft Azure, Active Directory에 대해서… (2), AAD와 사내 AD와의 연계 첫번째 이야기 에서 살펴보았으므로, 이를 참고하셔서 동일하게 구성하면 됩니다. 디렉터리 동기화가 완료된 후, https://myapps.microsoft.com 형태의 AAD 인증을 사용하는 사이트에 접속하여, 사내 AD 계정을 입력하면, ADFS 로그온 페이지로 리디렉션되게 됩니다.

기존 AAD에서 사내 AD 도메인을 구성하고, ADFS 형태가 아니라, AAD 인증 형태로 사용하던 경우, 이를 ADFS 인증으로 사내 AD 인증을 처리하고 싶을 수 있습니다. (AAD 인증에서 ADFS 인증으로 변경) 이 경우에는 Convert-MsolFederatedDomain Cmdlet을 이용하면 기존 도메인을 변경할 수 있습니다.

반대로 Convert-MsolDomainToStandard Cmdlet을 이용하여, AAD 인증으로 변경이 가능합니다. 이 경우, 당연히 사내 AD 인프라에 설치된 디렉터리 동기화 도구에서 암호 동기화를 활성화해주어야 합니다.

이미 디렉터리 동기화를 구성해놓았다면(암호 동기화 사용을 하지 않은 상태), 디렉터리 동기화 도구 Windows PowerShell을 이용하면, Enable-MSOnlinePasswordSync으로 가능합니다.

Microsoft Azure AD 포스팅이 몇 회에 걸쳐 진행되는 이유는 구성 시나리오가 다양하기 때문에 그렇습니다. 큰 구성으로 나눠보면, 어디서 인증을 처리할 것이냐에 대한 구분입니다.

• AAD에서 인증할 것인가(Standard Domain, Get-MsolDomain에서 Authentication 항목이 Managed)
• ADFS를 통해 사내 AD에서 인증할 것인가(Federated Domain, Get-MsolDomain에서 Authentication 항목이 Federated)

다음 포스팅에서는 AAD 인증(Standard Domain) 이용시, AAD를 통해, 사용자가 암호를 재설정하고, 이 사항이 사내 AD로 반영되는 Password Write Back 기술을 살펴보도록 하겠습니다.