열린 구름(Public Cloud), 닫힌 구름(Private Cloud)의 공존, Hybrid Cloud… Office 365 + 액티브 디렉터리, Exchange Server 2010

열린 구름(Public Cloud), 닫힌 구름(Private Cloud)의 공존, Hybrid Cloud… Office 365 + 액티브 디렉터리, Exchange Server 2010

  • Comments 2
  • Likes

클라우드 기술의 구체화를 통해, 다양한 형태로 서비스를 이용할 수 있는 기술 벤더의 클라우드 서비스가 시작되거나, 준비를 거듭하고 있습니다.

여러 세미나 장소나 IT 전문가 분들을 만나서 이야기를 나눠보면, 클라우드 서비스의 진행이 어떻게 될 것이냐에 대해서 생각을 많이들 하고 계시고, 어느 한쪽으로 치우지지는 않을 것이라는 것이 대부분의 생각입니다. 다시 말해, 비즈니스의 필요성에 따라 Public Cloud와 Private Cloud를 선택해서 사용할 수도 있으며, 이 둘에 대한 시스템 연계 또한, IT 전문가 분들에게 필요한 부분인 것 같습니다. (대표적으로 Federation 기술을 통한 Single Sign On 구성이나 도메인 설정, 전자 메일 흐름 등)

최근 Microsoft에서 Office 시스템에 대한 이용 형태에 대해 클라우드와 접목하여, 언제 어디서나, 손쉽게 업무 환경을 제공받을 수 있도록 Office 365라는 서비스에 대해 공개 베타를 발표하였습니다. Exchange, SharePoint, Lync의 서비스 버전으로 구성된 Office 365의 경우, 조직내 모든 사람이 다 서비스로 갈 수도 있지만, IT 인프라 구성상, 아님 비즈니스 상 서비스로 가야할 사람과 내부에 남아있어야 할 경우를 구분하는 경우가 훨씬 많을 것입니다.

Microsoft는 몇년전부터 Software + Service라는 컨셉을 제시하였습니다. 이 의미는 서비스와 소프트웨어는 적절한 시나리오에서 상호 공존하게 될 것이며, 이 둘 사이의 자연스러운 마이그레이션(양쪽 방향으로 모두)을 지원해야 한다는 것입니다.

Office 365의 경우에도 On-Premise의 액티브 디렉터리와 Exchange Server, Lync 등과 공존할 수 있는 시나리오를 제공합니다. (Office 365의 경우, 액티브 디렉터리 동기화, ADFS를 통한 SSO, Exchange Server 2010 Co-Exist 시나리오는 Enterprise Plan에서 지원합니다.)

오늘 포스팅에서는 공존 시나리오의 첫번째 Single Sign On 인증(ADFS) 및 액티브 디렉터리 연동에 대해서 가볍게(?) 살펴보겠습니다. 미소 Exchange Server 2010과의 공존 구성까지가 모든 작업의 완료지만, 이 포스팅을 작성하는 2011년 5월 6일 현재, Exchange Server 2010의 공존 구성을 도와줄 Deployment Assistant가 Exchange Server 2007 버전까지만을 지원하고 있습니다.

image

ADFS를 구성하게 되면, 사내 사용자가 본인의 계정으로 Office 365에 접근할 수 있게 됩니다. 많은 세미나나 포스팅에서 언급드린 것처럼, 클라우드 서비스의 증가는 자연스럽게 조직원의 계정 관리에 문제점을 가지게 하여, 보안 약화 및 편의성 하락으로 이어질 수 있습니다. 또한 클라우드 서비스내 사용자 속성과 액티브 디렉터리내 사용자 속성의 이중화로 관리자 역시 일괄적인 사용자 관리에도 어려움을 가지게 하죠. (참고 URL : 클라우드 시대(Cloud-Age)에 빠뜨리기 쉬운 보안 고려 사항에는 무엇이 있을까요?, [칼럼]ID와 끝나지 않은 고민 그리고 클라우드, [Journey to the Cloud 세션] IT 서비스 최적화와 Private Cloud, 개념을 넘어 실현으로, 온라인으로 살펴보세요~, Windows Server 2008이 나오면... (25) ? ADFS)

1. Office 365의 관리자 계정으로 포털에 접속하여, 사용 계획을 만들어야 합니다. 서비스만 이용할지, 서비스와 내부를 공존시킬지, 내부만 사용할지 등을 선언할 수 있습니다. 관리자 포탈내 왼쪽 Custom Plan을 사용하여 이를 완료합니다. 공존 시나리오도 사용자 경험 및 관리 레벨에 따라 Rich Co-existence와 Simple로 나눠집니다.

Snap23

Plan 설정을 완료하면, 차후 진행해야 할 작업 순서가 잘 정리되어 나옵니다.

image

2. 조직의 공식 도메인(대표적으로 전자 메일을 사용할 주소겠죠)을 추가합니다. 도메인 추가 작업시, 도메인 소유에 대한 확인으로 CNAME 레코드 추가를 일시적으로 요청받습니다. 이에 도메인을 직접 관리하는 경우가 가장 좋겠죠? 도메인 등록 완료 후, Exchange Online을 통한 전자 메일 송/수신과 Lync의 자동 로그인을 위해 MX, SRV 레코드, 또한 스팸 관련 설정을 위한 SPF 레코드 등록을 하게 됩니다.

image

3. 이제 ADFS를 통한 Single Sign On을 구성해야 합니다. (이부분이 가장 까다로울 것으로 예상됩니다.) Single Sign On을 사용하기 위해서는 Windows Server 2008, 혹은 2008 R2 기반의 ADFS 2.0 구성이 필요합니다. ADFS 2.0 구성 자체는 Office 365만을 위한 것이 아니라, 기본적인 WS-* 기반의 Federation을 사용할 때 필요한 것이므로, TechNet내 ADFS 관련 도움말 혹은 Office 365내 ADFS 도움말을 링크로 걸겠습니다.

중요한 사항 2가지는 다음과 같습니다.

  1. 인터넷 환경과의 연결에 보안이 중요하다면, Active Directory Federation Service의 Proxy를 구성해야 합니다. 해당 Proxy는 공인 IP 구성, 혹은 Forefront TMG등을 활용한 Reverse Proxy 형태로 구성되어져 있어야 합니다. (물론 Proxy 없이 직접 Federation Service를 외부로 오픈할 수도 있습니다.) Windows Server 2003 R2 시절 ADFS 1.0 Proxy를 구성했던 경험이 있으신 분들께서는 꼭 TechNet의 ADFS 2.0 Proxy 아티클을 읽어보시기 바랍니다. 1.0과 아키텍쳐가 약간 틀려, Split DNS를 구성하여 외부에선 ADFS Proxy로 내부에선 ADFS 서버로 직접 접속할 수 있게 구성해야 합니다. 다시 말해 ADFS DNS 이름은 Proxy나 서버나 동일해야 합니다. (이거 때문에 또 좀 고생했습니다. 미소)
  2. 공인 인증서가 필요합니다. (사설 CA가 아닌 Verisign등에서 발급한) 인증서는 신뢰된 인증 기관에서 발급했느냐 여부, 유효 기간, 그리고 일반 이름(Common Name)을 확인합니다. Office 365나 기타 타 클라우드 서비스의 경우, 실제 서비스를 운영하는 형태이므로, 사설 CA의 루트 인증서를 등록해주는 서비스는 하지 않습니다. 이에 별도의 인증서를 구입해야 하며, Koalra.Com과 Office 365와의 연결을 위해서는 저렴했던 인증서(1년에 55,000원)인 GlobalSign사의 인증서를 사용했습니다.

    image

ADFS 서버 혹은 ADFS Proxy 서버에 Microsoft Online 서비스와 Identity를 연결할 경우 필요한 모듈인 Microsoft Online Services Identity Federation Management Tool을 설치합니다.

이후 도움말내 PowerShell Cmdlet 순서에 따라 ADFS 등록 작업을 시작합니다. ADFS 서버에도 Microsoft Online Service와 연결하기 위한 Connector(Office 365 클라이언트 도구)가 필요합니다. 이를 설치하지 않고 진행하는 경우, 아래의 에러가 발생합니다.

image

ADFS 연결 작업 중, 도메인 추가시와 마찬가지로, DNS 설정에 대한 확인으로 CNAME 값의 등록을 요구합니다.

image

모든 등록 작업을 마쳤다면, 해당 도메인을 ADFS용으로 Convert하는 작업이 필요합니다. Convert 하기전까지는 일반 인증용으로 사용한다는 것이지, ADFS를 사용한다는 의미는 아닙니다. 아래의 빨간색의 에러가 해당 의미입니다.

Snap26

이를 Convert Cmdlet을 이용하면, 해당 Cmdlet이 ADFS 2.0 모듈내 구성까지 완료해줍니다. (어찌보면, 문제가 발생할 소지가 가장 많은 단계를 자동화해놔서, 간편히 설정이 완료됩니다. ADFS는 대소문자를 구분하는 모듈이기에, 이 설정에서 많은 엔지니어 분들께서 에러를 유발하셨죠.)

Snap29

차후 ADFS 관련 정보는 역시나 PowerShell을 통해서 확인할 수 있습니다.

image

4. ADFS를 통한 Single Sign On 구성이 끝났다면, 사내의 액티브 디렉터리 사용자, 그룹 정보를 Office 365의 사용자 정보와 동기화 하는 작업이 필요합니다. 동기화를 위한 액티브 디렉터리 요구 사항은 아래와 같습니다. 사설 도메인을 사용하는 경우, 사용자의 UPN 값을 수정해주실 필요가 있습니다. (동기화 전에 완료하는 것이 편합니다. 일차 동기화 완료후, UPN 구성을 변경하는 것은 해당 KB를 참고하세요.)

image

현재 액티브 디렉터리 동기화 모듈은 32비트 버전만을 제공하고 있기에, 64비트만 지원하는 Windows Server 2008 R2는 사용할 수 없습니다. 이에 별도의 Windows Server 2008 32비트 버전을 설치하여 구성하였습니다.

Snap2

역시나 Office 365내 설명에 따라 진행하면 무리없이 구성을 완료할 수 있습니다. 동기화 관련 프로그램이 설치되고, 마법사를 통해 구성을 완료합니다. 타 제품에 익숙하신 분들께서는 딱 감을 잡으실 수 있는데 바로 Forefront Identity Manager의 일부 모듈입니다. SharePoint 2010에서도 사용자 프로파일 동기화를 위해 사용하는 모듈이죠. 차후 강제 동기화를 위해 마법사를 다시 실행할 수도 있습니다.

Snap3Snap11

서비스 형태로 등록되어서, 주기적으로 사내 액티브 디렉터리와 Office 365내 사용자를 동기화합니다.

Snap17

동기화 방향은 대부분 사내에서 Office 365로의 방향이기에, 사용자 속성은 액티브 디렉터리에서만 변경할 수 있다는 메시지를 보실 수 있습니다. Office 365 포탈에선 라이선스와 사용 가능한 서비스 정도만 설정할 수 있습니다.

image

5. 모든 구성이 정상적으로 완료되었다면, Office 365 포탈 로그인 페이지에서 조직내 UPN값을 입력하면, 암호 박스가 비활성화 되면서 Federation 로그온을 한다는 메시지를 볼 수 있습니다.

image

스크린샷이 많아서 조금 길어졌네요. 구성에 대한 대부분의 참고 자료는 너무나 잘 정리된 Office 365 Enterprise 도움말을 참고했습니다.

사내와 서비스를 연결하여 Hybrid Cloud의 좋은 모습을 보여주는 예인 것 같습니다. 미소

차후 Exchange Server 2010 Deployment Assistant가 릴리즈되면, Office 365와 Exchange Server 2010을 왔다갔다 할 수 있는 사서함에 대한 구성 부분 및 이야기를 포스팅하겠습니다. 어찌보면, 유연한 이전이 가능한 모습에 IT 조직이나 비즈니스적으로는 기민한 대응에 도움이 되지 않을까? 라는 생각을 갖게 됩니다.

Comments
  • 좋은 정보 감사합니다 :)

  • Office365와 On-Premise 의 연결에 대해 문의하는 고객이 있었는데, 아주 좋은 참고가 되었습니다. 감사합니다.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment