Microsoft Azure, Active Directory에 대해서… (2), AAD와 사내 AD와의 연계 첫번째 이야기
Microsoft Azure, Active Directory에 대해서… (1) 에서 기본적인 Microsoft Azure의 AD(AAD)에 대한 기본적인 개념은 살펴보았습니다. 인증을 위해서 제공하는 AAD의 경우에는 기본 구성시, 원하는 도메인.onmicrosoft.com의 형태를 취하게 됩니다. 이 후, 사용자를 새롭게 생성하여, AAD 인증을 받도록 설계된 응용 프로그램 또는 Microsoft Azure에서 제공하는 응용 프로그램 서비스를 이용할 수 있었습니다.
오늘은 그 이후, AAD에 대한 추가 사항을 살펴보겠습니다. 우선 계정이 사용하는 도메인에 대한 부분입니다. 외부에서 사용자가 사용하는 계정의 경우에는 “별칭@도메인.onmicrosoft.com”의 형태를 취하게 되는데요. 이보다는 회사의 도메인을 사용하게 만드는 것이 훨씬 더 사용자에게 편리할 것입니다. 회사의 도메인이 cloud.koalra.com을 사용하는 경우라면, “별칭@cloud.koalra.com”을 사용하는 것입니다. AAD의 경우에는 당연히 이러한 형태의 계정 구조도 지원하고 있습니다.
사용자 지정 도메인 추가를 클릭하면, 원하는 도메인을 추가할 수 있습니다.
도메인을 입력하는 것까지는 쉽게 이해가 되실 겁니다만, 하단의 체크 박스의 의미는 무엇일까요? 잠시 후 살펴볼 내용이기도 합니다. 해당 도메인이 AAD에서 생성해서 사용하는 형태의 계정이 아니라, 사내 AD에서 ADFS 형태로 인증을 하겠다는 의미입니다. 일단, 체크를 하지 않고 진행하겠습니다. 이를 선택하지 않으면, 모든 인증 처리는 AAD에서 진행되는 형태가 됩니다. 차후 Azure PowerShell을 이용하여, SSO의 형태도 변경 가능합니다.
- ADFS를 통해서 사내 AD 인증을 처리하는 도메인 : FederatedDomain
- AAD에서 사내 AD 인증 정보를 가지고 처리하는 도메인 : StandardDomain
기본적으로 아무나 해당 도메인을 사칭할 수 없게 하기 위해, 도메인의 실 소유자임을 DNS 레코드 생성을 통해 확인하고 있습니다. (Office 365에서도 동일한 절차를 밟아본 경험이 있는 분도 계실 것입니다.)
해당 레코드를 DNS 서버에 생성해줍니다.
이후 확인을 클릭하면, 상단에 확인되었음을 표시해줍니다.
이제, 새롭게 추가한 도메인의 형태로 신규 사용자가 생성 가능해집니다.
방금 전 시나리오에서, cloud.koalra.com 도메인을 추가해주었습니다. 이 경우, 계정의 생성은 AAD에서 모두 진행하게 됩니다. 조금 더, 이제 이야기를 발전시켜보죠. 바로 사내의 AD가 있는 경우입니다.
이 경우, 사내 AD의 정보(계정 및 그룹 등)를 AAD로 동기화한 후, 활용하는 시나리오가 가능합니다. 이러한 형태의 디렉터리 동기화(DirSync)를 위해서는 디렉터리 통합이라는 페이지로 가야 합니다.
해당 페이지에서 우선 디렉터리 동기화를 활성화합니다. 이 후, 하단에 표시되는 순서대로 작업을 완료합니다.
Microsoft Azure에서는 디렉터리 동기화를 위한 프로그램을 제공합니다. 다운로드 링크는 업데이트가 될 수 있으므로, Microsoft Azure 포탈에서 직접 진행하시는 것이 좋습니다. 해당 프로그램은 Forefront Identity Manager(FIM)의 구성 요소가 일부 포함되어 있어, AD와 AAD 사이의 동기화를 진행해줍니다. Microsoft Azure내 관련 링크를 이용하여 디렉터리 동기화 도구를 다운로드받은 후, 사내 AD 인프라내 서버에 설치합니다.
구성 요소의 설치가 완료되면, 실제 구성을 하기 위한 마법사가 시작됩니다. 또한 AAD와 AD의 연계를 위해서는 현재 AAD의 전역 관리자 계정이 필요합니다.
당연한 이야기지만, 사내 AD의 관리자 계정도 필요합니다.
앞서 언급한 바와 같이, 기본적인 동기화 방향은 사내 AD에서 AAD로 진행되게 됩니다. 다만 몇몇 기능(대표적으로 사용자가 사내 AD 계정 암호를 AAD 포탈에서 재설정하는 기술)등과 같이 AAD에서 사내 AD로 동기화를 설정할 수도 있습니다.(이후 포스팅에서 살펴볼 예정입니다.) 이 경우, 디렉터리 동기화 도구에 사내 AD에 쓰기 권한을 부여해줘야 합니다. 이 권한 부여를 하이브리드 배포 사용이라는 옵션에서 제공합니다.
마지막 옵션은 사내 AD 계정의 암호를 AAD로 동기화할지에 대한 부분입니다. 이 역시 앞선, 하이브리드 배포 옵션과 마찬가지로 시나리오에 따라서 설정해줘야 합니다. 사내 AD 계정에 대한 정보만을 AAD로 전송하여, AAD를 활용하는 응용 프로그램에서 사용할 경우(예를 들어, 주소록의 형태, 다시 말해, 인증 형태로 계정을 사용하지 않음), 암호 동기화는 필요하지 않습니다. 그러나, 내부 도메인 계정의 형태로 AAD에서 동일한 계정이 생성되어 있지 않고, 암호 동기화 옵션을 사용한다면, 사내 AD 계정 정보를 AAD로 동기화하여, AAD를 통한 인증 처리를 진행할 수도 있습니다.
암호 동기화에 대해서 보안상 우려가 있을 수 있습니다만, 아래의 설명과 같이, 보안을 지키면서 AAD와 동기화하게 됩니다.
- AD에서 암호화되지 않은 암호를 볼 수 없음
- 암호 자체가 아닌, 암호의 해시값을 전송함
- SHA256을 여러 단계로 적용하여 암호를 재 해시 처리함
- 다른 자원에서 암호의 해시값을 사용할 수 없음
- 동기화된 사용자에 대해서만 처리
- 기본적인 설정에서는 AD에서 AAD로만 동기화 처리(Push)
이 후, 동기화 설정 작업이 완료됩니다. 기본적으로 AD내 모든 사용자 및 그룹이 AAD로 동기화되게 됩니다. (정확한 복제 개체 유형은 아래 그림을 보시면 알 수 있습니다.)
만약 특정 OU(조직 구성 단위)를 기반으로 복제 범위를 지정하려면, AAD 동기화 도구 옵션을 변경해야 합니다. AAD 동기화 도구는 Microsoft Forefront Identity Manager를 기반으로 제공됩니다. 해당 FIM 클라이언트를 이용하여 설정을 변경할 수 있습니다. 해당 도구(MIISCLIENT)는 C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell 에 저장되어 있습니다.
Management Agent 버튼을 클릭 후, Active Directory Connector의 속성을 열면, Configure Directory Partitions 항목이 있습니다. 여기서 Containers를 클릭하면, 복제를 진행할 AD의 범위를 지정할 수 있습니다.
이 후, 복제에 대한 주기적인 형태 진행(기본값은 3시간)로 진행됩니다. 직접 진행을 하려면, Windows PowerShell을 사용해야 합니다.
디렉터리 동기화 도구용 Windows PowerShell Module은 설치 폴더내 DirSync의 모듈을 가져온 후 사용할 수 있습니다.
이 중, Start-OnlineCoexistenceSync Cmdlet이 동기화와 관련된 명령어입니다. 또한 기본값으로 되어 있는 3시간을 수정하려면, AAD 동기화 도구가 설치된 폴더에서 Microsoft.Online.Dirsync.Scheduler.exe.Config 파일을 수정하면 가능합니다.
Azure PowerShell을 이용하여, 연결된 도메인 정보를 확인하면, AAD에서 인증을 처리하는 Standard Domain(Authentication의 값이 Managed, ADFS로 구성된 형태라면, Federated라고 표시됩니다.)입니다.
동기화가 완료된 후, Microsoft Azure 관리 포탈에서 사용자 및 그룹 정보를 확인할 수 있습니다.
Azure PowerShell을 이용하여, AAD 계정과 사내 AD 계정에 대한 구분을 할 수 있습니다. 사내 AD 계정의 경우에는 ImmutableID 특성이 존재합니다.
기본 구성으로는 AAD에 존재하는 계정과 사내 AD 계정이 동일할 경우, 동기화되지 않고, 오류를 발생시킵니다. (관리자 메일로 전송됨) 시나리오적으로 AAD의 계정 정보(연락처나 주소등)를 사내 AD에서 제공하여 하나의 개체로 처리하고자 할 경우, 앞서 살펴본 동기화 도구에서 Management Agent 설정을 수정해야 합니다.
조금 복잡한 기술 내용이라고 생각합니다. 중요한 사항은 인증에 대한 위치가 어디인지에 대해서 결정하는 것이 중요합니다. Microsoft Azure내 AD에서 직접할 것인가, 사내 AD에서 ADFS를 통해서 진행할 것인가가 첫번째 결정이 되게 되며, 이후 결정에 따라서, 시나리오가 달라지게 됩니다. 다음 포스팅에서는 AAD와 사내 AD를 연계한 후, ADFS를 통해서 인증 처리하는 방안에 대해서 살펴보겠습니다.