Windows Server/Microsoft Azure의 장치 등록 서비스(Device Registration Service)를 이용하여 Workplace Join(작업 공간 가입) 활용 (장치 인증/사용자 SSO 처리)
Windows 8.1의 네트워크 설정 항목에 보면, 회사라는 설정이 존재합니다. 이 설정이 현재 사용하는 디바이스에 대해서 회사 네트워크에 연결하고, 관리를 해주기 위한 무언가의 기능이다라는 사실은 많은 분들께서 예상(?)하실 수 있는 부분입니다. 오늘은 해당 기술, 다시 말해 Workplace Join(작업 공간 가입)에 대해서 살펴보도록 하겠습니다.
일반적인 PC 시절에 조직내 PC들을 중앙에서 관리하고자 한다면, 액티브 디렉터리(AD, Active Directory)를 구현했을 것입니다. 해당 AD에 모든 PC를 가입시키고, 중앙에서 생성한 그룹 정책에 의해서 PC들을 관리하는 형태이죠. 이 역사는 Microsoft 기술에서는 매우 오래된 역사를 가지고 있습니다. AD를 사용하는 이유는 또 한가지 더 있죠. 바로 IDENTITY에 대한 중앙 관리, 즉, SSO(Single Sign On, 싱글 사인 온)때문입니다. 개별적으로 자원을 관리하는 형태의 작업 그룹(Workgroup)은 IDENTITY에 대한 관리 역시, 개별 자원에서 진행해야 합니다. 적은 숫자의 PC가 있는 경우라면, 개별 관리가 가능하겠지만, PC의 숫자가 많아졌거나, 개별 관리로 인한 보안 감소를 걱정하는 경우에 AD에서 생성한 IDENTITY를 기반으로 PC를 로그인하고, 원격 자원 접근시, 이에 대한 보안 토큰(Security Token)을 이용해서 접근하는 형태 구현이 가능합니다.
AD에 대한 기본 개념은 [동영상 세션] Active Directory(액티브 디렉터리)란 도대체 무엇인가? 에서 살펴보실 수 있습니다.
스마트폰, 태블릿의 증가는 도메인 가입을 기반으로 관리하는 PC 관리의 확장을 요구하게 되었습니다. 모든 스마트폰, 태블릿이 도메인에 가입할 수 있다면, 관리나 SSO에 대한 처리가 가능하겠지만, Microsoft 계열이 아닌 경우(Microsoft 계열이더라도, 기업 SKU를 사용하는 에디션이 아니라면, 더불어 Windows RT도 도메인 가입이 안됩니다.), 도메인 가입을 할 수 없는 형태입니다.
사용자 입장에서 살펴보면, 개별적인 디바이스(이 포스팅에서는 디바이스란 단어에 PC, 태블릿, 스마트폰을 모두 포함합니다.)에 대한 관리도 중요하지만, 이용 시나리오 상에서는 사내, 혹은 클라우드에 구현된 조직의 기간계(LOB) 응용 프로그램(서비스)에 대해서 SSO가 처리되었음 좋겠다는 생각을 할 수 있습니다. 한번 ID/암호를 입력하면, 차후, 조직의 인프라에 연결시에는 SSO 형태로 처리가 되는 것이죠.
IT 관리자 입장에서 살펴보면, 개별적인 디바이스에 대한 중앙 관리는 물론이고, 조직에서 허가된 디바이스에서만 조직의 인프라에 연결 권한을 부여하고 싶을 수 있습니다. 일반적인 인증은 사용자가 ID와 암호를 입력하여, 인증을 받는 형태이지만, 사용자는 물론이고, 허가된 디바이스에 대해서 접근을 허가하고 싶은 경우가 있죠. 허가된 디바이스라는 뜻은 조직의 규정(Compliance) 및 필요 설정이 반영되어진 기기라고 생각할 수 있기 때문입니다. 이러한 형태 인증 처리를 장치(디바이스) 인증이라고 합니다.
사용자 인증, 장치 인증, 그리고 MFA 형태의 인증까지 이용하여 인증을 처리할 수 있게 됩니다. (Microsoft Azure, Active Directory에 대해서… (5), 다단계 인증(MFA, Multi-Factor Authentication) 참고)
Microsoft Azure, Active Directory에 대해서… (4), AAD 프리미엄(Premium) 기술을 활용한 클라우드 사용자 암호 재설정 포스팅에서 AAD를 활용하여, 사용자의 암호를 재설정하는 기술을 살펴보았습니다. 해당 포스팅내에서 살짝 언급했던 이야기가 바로 장치 인증이었습니다. AD에 대한 페더레이션 서비스를 제공하는 ADFS에서도 사용자가 외부에서 암호를 변경할 수 있습니다만, 해당 서비스는 장치 인증이 되는 디바이스에서만 사용이 가능합니다. (구성 방법은 ADFS의 암호 업데이트를 참고하세요.)
이러한 형태로 장치 인증을 하기 위해 디바이스를 등록하는 서비스를 Windows Server 2012 R2에서 제공하고 있습니다. 장치 등록 서비스(Device Registration Service, DRS)이며, 이는 ADFS의 세부 서비스로 구성되어져 있습니다. DRS에 현재의 디바이스를 등록하고, 장치 인증을 처리할 수 있도록 구성하는 것을 Workplace Join이라고 합니다.
또한, Windows Server 2012 R2 기반으로 DRS를 구성하지 않고, Microsoft Azure AD Premium에서 제공하는 장치 등록을 활용할 수도 있습니다.
현재 Workplace Join은 Windows 8.1(RT 포함) 이상, iOS 6이상, KNOX 기반의(삼성) Android, Windows 7 Professional(도메인에 가입된)에서 지원하고 있습니다.
기본적인 구성 가이드 링크
- Walkthrough Guide: Workplace Join with a Windows Device
- Walkthrough Guide: Workplace Join with an iOS Device
- Workplace Join for Windows 7
일단, Windows Server 2012 R2에서 DRS를 사용하려면, ADFS를 구성해야 합니다. (ADFS 설치 가이드 링크) ADFS에 대한 기술 포스팅은 여기에서 살펴보실 수 있습니다. 외부 네트워크에 배치된 디바이스에서 등록을 요청하는 경우가 많을 것이므로, 외부 네트워크에서 접속할 수 있도록, ADFS를 인터넷으로 바로 노출 또는 보안을 위해 ADFS 프록시(Proxy)를 구성합니다. Windows Server 2012 R2에서 ADFS 프록시는 웹 응용 프로그램 프록시(Web Application Proxy)가 그 역할을 같이 하고 있습니다. (WAP에 대한 포스팅)
중요한 부분은 Workplace Join을 위해서는 디바이스에서 전자 메일 주소를 입력해야 한다는 것입니다. SJBAEK@KOALRA.COM과 같은 형태로 입력을 하게 됩니다. 이 때, DRS 서비스 주소를 메일 주소의 DNS 부분을 이용해서 찾게 됩니다. 이를 DRS Discovery라고 부릅니다. DRS에 대한 호스트 주소는 enterpriseregistration.도메인 이름이 됩니다. KOALRA.COM의 경우에는 EnterpriseRegistration.Koalra.Com이 되는 형태죠. ADFS는 SSL 기반으로 서비스를 하기 때문에, ADFS 서버 주소의 이름과 함께, EnterpriseRegistration.도메인 이름 형태의 주체 이름(Subject Name)이 인증서에 있어야 합니다. 이를 위해 * 형태의 와일드카드 인증서나, 주소 대체 이름(Subject Alternative Name, SAN) 인증서가 필요합니다. ADFS 서비스는 하나의 웹 서비스로 동작하므로, 2개의 인증서를 발급받아, 하나의 서비스에 등록할 수 없습니다.
인증서 구성이 완료되었다면, 외부/내부 네트워크의 DNS에 EnterpriseRegistration A 호스트 레코드 또는 CNAME 레코드를 만들어주고, 이를 내부 네트워크에선 바로 ADFS 서버로, 외부 네트워크에선 WAP으로 바라보게 설정합니다. (Windows Server 2012 R2 DRS 관련 DNS 가이드)
사내 Windows Server 2012 R2의 DRS가 아닌 Microsoft Azure AD Premium의 DRS를 사용하려면, Azure Device Registration 주소를 DNS 서버에 만들어주면 됩니다. (Azure 관련 가이드)
ADFS에서 DRS를 구동하기 위해서는 Windows PowerShell Cmdlet을 실행해야 합니다.
이 중, Initialize-ADDeviceRegistration Cmdlet을 실행합니다.
ADFS 서비스 계정을 물어오게 됩니다. ADFS 설치시 사용했던 서비스 계정을 입력해주면 됩니다. 이후 Enable-AdfsDeviceRegistration Cmdlet을 입력합니다.
DRS를 구성하는 방법은 이렇게 매우 간단합니다. 이후 DRS Discovery URL이 정상적으로 동작하는지 명령 프롬프트에서 NETSH HTTP SHOW SSL 명령어로 확인할 수 있습니다.
ADFS 또는 WAP(ADFS 프록시)에 EnterpriseRegistration.도메인 이름의 주제 이름이 없는 경우엔 DRS Discovery URL이 생성되지 않습니다.
자, 이제 ADFS에서 장치 인증을 사용하도록 설정하면 Workplace Join을 위한 구성이 완료됩니다.
Workplace Join을 지원하는 플랫폼을 가진 디바이스에서 Workplace Join을 시도하면, ADFS 로그인과 동일한 형태의 로그인 창이 나타납니다.
iOS 6이상에서는 아래와 같은 형태로 진행되게 됩니다.
이렇게 Workplace Join을 통해 현재 장치를 등록하면, 액티브 디렉터리내 등록된 디바이스에 대한 개체가 생성됩니다.
장치 등록된 디바이스는 장치 인증이 가능하다고 하였습니다. 장치 인증은 상호 TLS 인증으로 진행됩니다. ADFS에서 사용하는 SSL 인증서와 디바이스에 장치 등록시 인증서가 생성됩니다.
해당 인증서는 디바이스의 개인 사용자 인증서 저장소에 저장됩니다. 인증서에 대한 정보가 AD에 저장된 케이스입니다.
AD의 디바이스 개체에는 인증서에 대한 손도장, 공개 키 정보등이 저장되어 있습니다.
Microsoft Azure의 DRS를 사용하는 경우에, 해당 장치에 대한 정보가 사내 AD로 동기화되어 저장되길 원할 수 있습니다. 이를 위해서는 디렉터리 동기화시 장치 정보에 대해서 Microsoft Azure에서 사내 AD로 쓰기 처리를 해줄 수 있게 구성해야 합니다. 이에 대한 정보는 여기의 링크에서 Configure DirSync to allow device object write-back 섹션을 참고하세요.
SSO로 시작된 이야기가 매우 길어졌습니다. PC를 사용하는 사용자가 AD IDENTITY에 대해서 한번의 로그인으로 보안 토큰을 받은 후, 이를 이용해서 자원에 SSO 처리가 되는 형태입니다. 자원에서 SSO를 처리하기 위해서는 커베로스나 NTLM 형태의 Windows 인증을 지원해야 합니다. 이를 통해서 사용자는 별도의 ID/암호 입력 없이 로그인 처리가 되는 것이죠.
Workplace Join의 경우에는, ADFS를 기반으로 하는 클레임 기반 응용 프로그램에 대해서 SSO를 처리해줄 수 있는 형태입니다. Workplace Join을 통해 모든 자원에 대한 SSO를 처리하는 형태가 아니라는 것을 명심해야 합니다. (대부분 잘못아실 수 있는 형태가 커베로스나 NTLM 형태의 인증을 Workplace Join으로 진행할 수 있다고 생각하는 것입니다.) 디바이스가 등록된 기기에서 클레임 기반의 응용 프로그램에 로그인을 하게 되면, 7일이 기본값으로 되어 있는 형태의 PSSO(Persistent SSO)를 처리받게 됩니다. 이를 이용해서 지속적인 SSO 처리가 가능한 것입니다.
Windows 기반의 PC는 당연히 도메인 가입이 가장 좋은 방법입니다. 그렇지만, 개인이 디바이스를 다양하게 소유하기 시작하면서부터, 디바이스에 대한 인증 및 관리 구성이 매우 중요해졌습니다. 이러한 면에서는 Workplace Join이 매우 괜찮은 기술이 될 수 있습니다. 이렇게 IDENTITY 및 장치 관리의 근간을 마련해놓으면, 다른 솔루션과의 결합, 확장도 매우 용이해집니다. 