ADFS 2.0 데모 사이트 구축

먼저, ADFS(Active Directory Federation Service)가 뭔지 잘 모르거나 아예 모르는 사람은 이 글 봐봐야 골치만 아플 것이므로 뒤로 가기 버튼을 빨리, 잽싸게, 후딱, 어여어여 누르시고...

들어가기에 앞서 간략히 ADFS 2.0을 사용해 본 소감을 적어 본다면...

ADFS 2.0은 ADFS 1.0에 비해 사용자 관점에서 훨씬 편리하게 관리할 수 있도록 완전히 새로 만들어졌다. 그래서 ADFS 1.0 기준으로 만들어진 예제를 ADFS 2.0에서는 절대로 그대로 따라할 수 없다. 메뉴나 UI, 기능 등이 완전히 달라졌으므로. 그런데 살짝 한꺼풀 까보면 내부 기능 상으로는 큰 차이 없이 거의 유사하다는 점을 느낄 수 있는데, MSDN에서 찾아봐도 인증 위임(대리 인증?)을 비롯한 몇 가지 기능이 추가된 것이 특징이고 1.0 버전과 거의 동일하다고 되어 있다. 겉보기에는 완전히 다른데 거의 동일한 것... 좀 희한하다. 아무튼 새로 추가된 특징이라는 인증 위임 기능은 아직 못 써봤다. 곧 써 볼 예정이다.

각설하고,

ADFS 2.0의 단계별 따라하기 예제 중에서 "오피스 SharePoint 2007을 이용한 문서 협업 사이트 연합 구축(Federated Document Collaboration Using Microsoft Office SharePoint Server 2007 and AD FS 2.0)"이 있다.

그런데, 그 예제 그대로 따라하면 잘 되어야 할텐데 불행히도 잘 안되는 부분이 몇 군데 있는데, 우여곡절 끝에 되도록 하는 방법을 수많은 삽질 끝에 찾았기에 공유해 본다.

(그나저나, ADFS를 사용할 사람이 있긴 있을까......? 내가 나중에 참고하기 위한 목적이니 뭐, 별 상관은 없다.)

1. SQL 서버 연결 문자열에 "Integrated Security=True"를 쓰면 안 된다. 예제에 따라 ADFS 실행 계정을 adfssrvc라는 계정으로 지정했기 때문에 해당 계정이 SQL 서버에 접근할 수 있도록 별도로 권한을 부여하지 않은 이상, 이런 옵션으로는 연결할 수 없다. 그대로 따라 하는 경우, 별다른 에러도 나지 않고 그냥 동작하지 않기 때문에 당황할 수 있는데, 바로 연결이 안된 이유이다. 동작하게 만들려면 SQL 연결 계정을 직접 지정해야 한다. (관련 항목 - Step 8: Configure the Contoso federation server to get values from a SQL data store,To add a local SQL database as an attribute store for the Contoso federation server 단계의 5번 항목)

내 경우는 sa/P@ssw0rd로 지정했다.

2. 샘플용 AD 계정 생성 시 메일 주소를 정확하게 입력해야 한다. 즉, "danielw@contoso.com"라고 써야 하는 것을 "danielw@cotoso.com"과 같이 오타쳐서 잘못 입력해놓으면 왜 안되는지도 모른채 계속 인증이 실패하는 경험을 하게 된다. 그것도 Active Directory 인증에서는 잘 되는데(당연히...직접 읽어서 바로 쓰는 거니까.), SQL 서버 인증에서만 안되는 환장하는 경험을 하게 되는데, 문제는 이와 같은 매우 간단한 실수에서 비롯되는 경우가 많다. (관련 항목 - Step 8: Configure the Contoso federation server to get values from a SQL data store, To verify revisions in access policy to the SharePoint site from within Contoso 단계의 4번 항목)

참고로, 위와 같이 메일 주소가 잘못되어 있었다는 것을 어떻게 알 수 있을까? ADFS나 SharePoint에서는 그런 것을 친절하게 알려주지 않는데? 이것 역시 수많은 삽질 끝에 알아낸 건데, 쉽게 알 수 있는 방법이 있었다! 바로 이벤트 뷰어를 통한 감사 기능! 그러나 ADFS는 기본적으로 디버깅, 감사 등등의 기능이 꺼져있기 때문에 무언가 잘못되었다 하더라도 기본적으로는 아무런 이유를 확인할 방법이 없다. 감사 기능을 수작업을 통해 켠 이후에야 이벤트 로그에서 설정한 대로 제대로 동작하는지 확인할 수 있다.

감사 기능을 켜는 방법은 다음과 같다.

  - 감사 기능을 활성화할 계정을 지정한다.

  - 응용 프로그램에서 감사 기능을 사용할 수 있도록 설정한다.

먼저, 위 그림과 같이 로컬 보안 정책을 열고 [보안 설정] - [로컬 정책] - [사용자 권한 할당]에서 "보안 감사 생성"을 찾아 ADFS 실행 계정을 등록해야 한다.

예제에서 시키는 대로 ADFS 실행계정을 adfssrvc로 지정했다면 해당 계정을 등록해주면 된다.

다음으로는 응용 프로그램 수준에서 감사 기능을 사용할 수 있게 보안 설정을 하는 작업이 남았다. 아래와 같이 auditpol.exe 실행 프로그램을 이용한다.

C:\>auditpol /set /subcategory:"응용 프로그램 생성됨" /failure:enable /success:enable

(영문 버전에서는 "Application Generated"인데 영문으로 그대로 쓰면 한글 윈도우에서는 동작하지 않는다. "응용 프로그램 생성됨"으로 써야 한다.)

확인은

C:\>auditpol /get /sucategory:"응용 프로그램 생성됨" /r

로 하면 된다. (시간이 난다면, auditpol 명령에 대해 이것저것 옵션을 주고 입력해서 확인해 보면 재미있는 기능들이 많다.)

이상까지 절차가 완료되면 이벤트 뷰어의 "보안" 부분에서 감사 로그를 곧바로 확인할 수 있다.

너무 많은 감사 로그가 기록되므로 특별히ADFS의 감사로그만 필터링해서 보고 싶다면 이벤트 원본을 "AD FS 2.0 Auditing"으로 설정하든가, 아니면 이벤트 ID를 "500"으로 설정해서 보면 원하는 정보만 딱 볼 수 있다.

이 이벤트에 최종 발급된 각 클레임에 대한 클레임 유형 및 값이 기록되므로 오동작 시 디버깅에 활용하면 좋다.

이벤트에 기록된 내용에 대한 상세한 설명은 생략한다. (참조 원본 출처: Configure auditing for AD FS 2.0)

3. 클레임 규칙 작성 시 "보내는 클레임 유형" 선택에 주의해야 한다. 영문으로 된 예제를 보고 따라하다 보면 한글판 ADFS에서는 "Name"에 해당하는 항목이나 "Given name"에 해당하는 항목이나 모두 동일한 "이름"으로 표시되어 있기 때문에 고르기가 쉽지 않고 어떤 것을 선택해야 하는지 당황할 수 있는데 결론적으로, 순서 상으로 따져, 무조건 나중에 있는 "이름"을 선택해야 한다. (관련 항목 -Step 3: Configure the Contoso federation server to issue tokens to the SharePoint site, To configure the claims to be sent to the SharePoint site 단계의 3번 항목)

위 화면과 같이.

그러면, 이렇게 선택한 "이름"이 맞는지 어떻게 확인하느냐고? 해당 클레임 규칙 편집 화면("추가" 화면 말고 "편집" 화면)에 [규칙 언어 보기]라는 버튼이 있다. 그걸 눌러보면 선택한 각 "이름"이 어떤 클레임 유형 URI로 지정되는지 확인할 수 있다.

  - 첫 번째 이름은 http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname이고

  - 두 번째 이름이 http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name임을 확인할 수 있다.

"이름"뿐만 아니라 화면을 통해 작성한 클레임 규칙이 제대로 작성되었는지는 이와 같이 클레임 규칙 언어를 보면 자세히 알 수 있다.

(클레임 규칙 편집 화면에서는 클레임 유형을 어떤 "이름"으로 선택하든 name으로만 선택된다! 추가 화면에서만 문제인 것인가...? 어떤 경우에 givenname이 선택되는지 다시 재연하는데 실패했다! 헐... 분명히 첫 번째 "이름"으로 선택했다가 제대로 인증이 안되는 낭패를 봤는데...)

4. SharePoint에서 새 사이트 만들 때 "처리되지 않은 예외"가 발생하면 SharePoint 제품 및 기술 구성 마법사(SPPT)를 한번 더 실행해주면 된다. SharePoint 역시 오류가 발생한 경우 오류 내용을 친절하게 알려주지 않는다. 몹시 당황스럽고 답답하다. 오류의 원인은 커녕 오류 상세 내용이라도 알면 좋겠는데 "처리되지 않은 예외"라는 딱 한 줄 말고는 아무 것도 알려주지 않으니 답답할 노릇.

이런 경우, 일단 오류의 상세 내용부터 출력하게 하는 것이 첫 번째 순서다.

web.config 파일에서 /configuration/system.web/customErrors 노드의 mode 속성을 "Off"로 바꾸면 상세한 오류를 출력하게 한다는 사실은 ASP.NET 개발 좀 해봤다면 어지간하면 다 아는 사실일텐데, 희한하게도 docs.contoso.com 사이트의 web.config를 백 날 수정해봐도 상세 오류 출력이 안된다. 혹시나 하고 그 옆에 있는 관리 사이트의 web.config를 수정해도 안된다. 귀신이 곡할 노릇.

거기가 아니라 바로 아래 경로에 있는 web.config을 수정해야 한다.

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\LAYOUTS

수정하고 나면 우리에게 친숙한 상세 .NET 오류 화면이 나타난다.

위 사이트 생성 시 오류는 Access Denied였다. 사이트 생성 권한이 없다는 건데, 보통 윈도우 상에서 발생할 수 있는 권한 문제는 파일/폴더 접근 권한 아니면 IIS 접근 권한 둘 중 하나다. 그런데 아무리 뜯어봐도 특별한 문제가 없어 보였고, 소스코드를 보고 직접 디버깅을 해보지 않는 이상 알 수가 없는 문제로 판단되었다. 또다시 오리무중... 인터넷을 아무리 검색해도 비슷한 내용조차 보이지 않았다.

그러다 우연히 SharePoint 로그 파일의 존재를 알게 되었는데, 바로

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS 폴더에 보면 "{서버명}-{날짜-시각}.log" 형식으로 SharePoint 관련 상세 로그가 찍히고 있었다. 온갖 잡다한 로그가 다 찍히고 있어 특별히 얻을 수 있는 정보는 없었지만 거기에서 일단 발생한 오류에 대한 힌트를 얻을 수는 있었다. 있어야 할 파일이 없고, 있어야 할 가상 디렉터리가 없다는 로그들이 곳곳에 보였던 것이다. 결국, 도저히 사용자 과실(설정 미숙 또는 오타 등)이 아니라고 판단되어 밀고 새로 설치하려다 혹시나 하고 SharePoint 제품 및 기술 구성 마법사(SPPT)를 다시 실행해봤다. 요게 요물인 것이, 이렇게만 해도 어지간한 SharePoint 자체 오류는 알아서 다 잡아준다. 결국 문제 해결. (왜 이런 문제가 생기는 지는 알 수 없으나, 내 경우에는 SharePoint가 설치될 때의 계정-로컬 관리자-과 실행할 때의 계정-도메인 관리자-이 달라서 이런 문제가 발생한 것으로 추정한다.)

5. 단계별 인증(Step-Up authentication; Smartcard)이 안되는 경우 아래 방법을 따라야 한다. 예제대로 따라하면 절대로 단계별 인증을 시연해볼 수가 없다. 그 이유는 Step-Up Authentication Scenario Package에서 다운받은 파일의 워드 문서에 있는 설정 내용이 이 예제에 앞서 우선적으로 적용되어 있어야 하는데 그것이 대부분 안되어 있을 것이기 때문이다. (아마도 다른 예제를 실행하는 과정에서 해당 내용이 설정되는 것이 아닐까 추측된다.)

다시 말하자면, 워드 문서를 읽어보고 필요한 것을 다 설정해주면 된다는 것? 맞다. 그런데 그러기엔 귀찮으니까 여기서 어떻게 설정하면 되는지 일일이 살펴보도록 하겠다. (관련 항목 - Step 10: Configure a SharePoint document library for stronger authentication, 두 번째 web.config 수정 단계)

먼저, 해당 단계를 실행하기에 앞서 위 Step-Up Authentication Scenario Package에서 다운받은 파일의 압축을 풀고, 안에 들어있는 소스를 컴파일해서 ClaimsAuthorization.dll을 생성해야 한다. 이 과정은 Visual Studio를 실행해서 정상적으로 빌드해도 되고, Visual Studio 명령 프롬프트를 실행한 다음 소스 폴더로 이동한 상태에서

C:\Temp\Claims Authorization Sample>msbuild /p:Configuration=Debug /p:Platform="Any CPU"

라고 실행해도 된다. (msbuild의 이와 같은 강력한 기능을 혹 모르시는 분들을 위해 맛보기로... ㅎㅎ)

생성된 dll은 CONTOSOSRV02 컴퓨터에 C:\StepUpAuthentication 폴더를 만들고 그 안에 붙여넣는다.

그러면 이제 1번 단계부터 진행할 수 있게 된다.

그 다음으로, 예제에서 시키는 대로 따라 6번 단계까지는 그대로 진행한 다음, 7번 단계를 진행할 때 "ClaimsAuthorizationModule" 및 "StepUpAuthenticationModule" 두 개를 모두 등록하는 것을 까먹으면 안된다. "ClaimsAuthorizationModule" 항목이 사각형 코드 영역 앞에 빠져나와 있기 때문에 입력하는 것이 아닌가 하고 빼먹으면 낭패.

그 다음, 8번 단계에서 StrongAuthenticationTypes에는 아래와 같이 네 가지 항목이 들어있어야 한다.

   <strongAuthenticationTypes>
      <authenticationType type="urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient"/>
      <authenticationType type="http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/tlsclient"/>
      <authenticationType type="http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/x509"/>
      <authenticationType type="http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/smartcard"/>
   </strongAuthenticationTypes>

마지막으로, 그 아랫부분의 policy 부분의 path="/confidential"은 아래와 같이 바뀌어야 한다.

      <policy path="/SiteDirectory/confidential" >
         <allow claimType="*" strongAuthentication="true"/>
      </policy>

path 앞에 "/SiteDirectory"를 넣어주는 이유는, ClaimsAuthorization 모듈에서 URL 검사를 맨 앞에서부터 StartsWith 방식으로 하기 때문이다. "/confidential"로만 설정하면 SharePoint 2007에서는 실제 사이트 URL인 "/SiteDirectory/confidential"과 일치하지 않게 되므로 원하는 동작을 하지 않는다.

휴... 이상과 같은 부분을 제대로 맞춰주면, 끝.

(엄훠 엄훠, 쓰다봉께 엄청 길어졌넹... 아까운 내 시간... ㅜㅜ)