AD RMS를 이용한 파일 보안/암호화2

Microsoft Information Protection Viewer(이하 IPViewer)라는 훌륭한 RMS 클라이언트 도구를 사용해보니

이것을 이용하면 어떤 기업 환경이라 하더라도 AD RMS 서버만 하나 잘 구축해 놓으면

자체적인 DRM 문서 보안 용도로 아주 유용하게 잘 활용할 수 있을 것 같다는 어떤 "강력한 느낌"이 와서

도메인, 비도메인 등 여러 환경으로 설치하고 테스트를 진행해 보게 되었다.

그런데, 불행히도, 예상치 않게도,

별로 어렵지도 까다롭지도 않은 AD RMS가, 희한하게도,

어떤 특수한 환경 하에서는 정상적으로 동작하지 않는 몹시 황당한 경우를 접하게 된 것이었다.

똑같이 구성한 멀쩡한 환경인데도 어느 도메인에서는 정상 동작하고, 어느 도메인에서는 아예 실행도 되지 않고,

또 재부팅을 하면 정상 동작하다가 어느 순간 다시 해보면 또 안되는 등

참으로 이해할 수 없는 일들이 계속 벌어져서 심각한 멘붕을 일으키게 된 것이었다.

참조할 만한 문서도, 인터넷 사이트도 하나 없이 나홀로 고군분투한 끝에

마침내 숱한 우여곡절을 뒤로 하고 하나하나 다 해결하게 되었다. 우~쓰!

그래서 이번에는 AD RMS 서버를 구축하면서 실제로 겪었던 문제들에 대해 정리해보도록 하겠다.

크게 보면 다음의 세 가지 유형으로 구분할 수 있겠다.

1. 0x80040201 오류 발생

한 마디로 표현하면, 컴퓨터 전체이름(FQDN)을 따로 지정하지 않은 경우 AD RMS 서비스가 GC를 찾지 못하여 발생한 오류.

즉, 예를 들자면, "ADRMSTEST" 라는 이름의 컴퓨터에 "contoso.com" 이라는 Active Directory 도메인을 설치하고,

거기에다 또 AD RMS를 설치한 다음, 컴퓨터 이름을 바꾸지 않고 그냥 사용하는 경우

IPViewer 클라이언트로 파일을 Protect/Unprotect 하는 경우 0x80040201 오류가 발생하였다.

그 때 AD RMS 서버에서는 이벤트 로그에 다음 그림과 같은 오류를 기록하였다.

Topology.Initialize

GlobalCatalogServersFound: 0 MinimumGCsNeeded: 1

Microsoft.RightsManagementServices.UnableToInitializeTopologyException

뭐 이런 오류가 기록되어 있었는데, 아무리 찾아봐도 해결책은 찾을 수 없었다.

Microsoft 커뮤니티 사이트에도 비슷한(증상은 똑같은) 오류가 보고되어 있기만 하고 역시 해결책은 없었다.

>> 참고: http://social.technet.microsoft.com/Forums/en-US/rms/thread/d01c0393-2895-4799-b41a-2a14a8fff389/

그러다가... 

수없이 테스트를 반복하고 여기저기 로그를 뒤진 끝에 다행히 이벤트 뷰어의 DNS 서버 로그에서 힌트를 얻을 수 있었다.

위 그림에서 보듯, 컴퓨터에 도메인 이름이 없으면 문제가 생길 수 있단다.

그래서 혹시나 하고 컴퓨터 속성으로 들어가서 컴퓨터 전체이름을 "ADRMSTEST.contoso.com"으로 설정하고 재부팅했더니

문제가 깔끔히 해결되었다. (그런데 지금도 여전히 좀... 이해하기 힘든 희한한 오류 같다는 생각이 든다. 도메인 컨트롤러를 AD RMS 서버로 겸해서 사용하는 경우에만 이런 문제가 생기는 것일까?)

참고로 위 오류코드를 다음 URL에서 참조해보니...

>> 참조: http://www.lifeasbob.com/code/errorcodes.aspx

80040201 2147746305 CO_E_FAILEDTOGETSECCTX: Unable to obtain server's security context

서버의 보안 컨텍스트를 얻을 수 없다는 오류란다. 역시... 잘 모르겠다. 컴퓨터 전체이름이랑 무슨 상관인지...

2. 0x8004020A 오류 발생

다음으로, 죽음의 오류 0x8004020A.

처음 이 오류를 접하고 완전 멘붕이 되었다. 이 오류 덕분에 다크서클이 10cm는 더 내려왔을게다.

이노무 오류는 서버에 오류 로그도 남지 않고, HTTP 접속 로그조차도 없고...

대체 왜, 무슨 이유에서 오류가 발생하는지 알 방법이 없었다.

오류코드 URL에서 찾아보니

8004020A 2147746314 CO_E_INVALIDSID: one of the security identifiers provided by the user was invalid

이렇다는데,
사용자가 제공한 보안ID 중 하나가 잘못됐...? 응? 대체 이게 무슨 말인지... 인증에 사용된 사용자는 아무 이상이 없는데 말이다.
왜냐하면 AD RMS 서버의 SSL 인증서만 다른 CA에서 발급한 놈으로 바꿔봤더니 똑같은 사용자로 잘만 동작했기 때문이다.

결국 따지고 따져보니, SSL 인증서가 문제라는 것인데,
아무리 살펴봐도 정상 동작하는 인증서와 오류를 발생시키는 인증서가 별 차이가 없었다.

RSA 공개키도 1024로도 해보고 2048로도 해봤지만 문제와는 상관이 없고,
주체(Subject) 대신 주체 대체이름(SAN; Subject Alternative Name)을 만들어 넣어보기도 했지만 그것도 상관이 없었다.
심지어는 두 CA를 샅샅이 비교하면서 대체 무엇이 다른가 면밀히 비교해보기도 했다.

오리무중...

그러다,
지나가는 생각으로,
설마 CDP(CRL 배포지점) 옵션이 상관이 있으랴 하고 생각하다가
두 CA간의 유일한 차이가 그것 뿐이기에 혹시나 하고 CDP 게시 옵션을 건드려봤다.

아뿔싸!
그것이 정답이었다.

CDP가 인증서로 게시되면 AD RMS가 비정상 동작하는 것이었다.
즉, AD RMS용 SSL 서버 인증서에는 CDP가 있으면 안되는 것이었다.
무슨 이런 황당한!!!


비교를 위해 아래에 두 인증서 화면을 올린다.


< 0x8004020A 오류를 발생시키는 SSL 인증서 >



< AD RMS가 정상 동작하는 SSL 인증서 >



정상 동작하는 SSL 인증서에서처럼 CDP를 인증서에 게시하지 않으려면 CA 서버에서 아래와 같이 설정해야 한다.
(CA 서버의 기본 설정은 원래 CDP를 인증서에 게시하지 않도록 되어 있으니,
CA 서버를 별도로 사용하고 있지 않은 경우 굳이 손대지 않아도 된다.
내 경우에는 CDP 게시를 활성화한 CA 서버를 사용하고 있었기 때문에 맞닥뜨린 재수없는 경우 되겠다... 킁. -_-a)



위 빨간 테두리 부분의 체크를 비활성화해야 한다.
(둘 중 아래의 옵션만 체크 해제해도 된다.)



역시 위 빨간 테두리의 체크 부분을 비활성화해야 한다.
(역시 "발급된 인증서의 CDP 확장에 포함" 옵션만 체크 해제해도 된다.)


위 CA 설정은 AD RMS 서버용 SSL 인증서를 발급할 때만 잠시 체크 해제했다가 발급이 끝난 후 다시 원상 복구하면 된다.
사용자 인증서 발급 등 다른 용도로 사용할 경우 CDP가 꼭 필요할 수도 있으니까.


그러나, 역시 도대체 이해할 수가 없다.
SSL 인증서라면 SSL만 정상 동작되면 되는 것 아닌가?
인증서에 CDP가 있으면 CRL 목록을 받아서 확인해보고, 인증서가 정상이라면 정상 동작해야 할 것 아닌가?
혹시 몰라 HTTP로 정상 다운로드할 수 있는 CRL 경로로 잘 설정해 줬음에도 불구하고
아예 CDP 옵션만 있으면 AD RMS가 오류를 발생하고 정상 동작하지 않는 것은 아무리 생각해도 이해가 되지 않는다.

3. 기타 오류

기타 SSL 인증서를 신뢰할 수 없는 경우, 또 사용자 계정 패스워드가 틀린 경우 등등 다양한 경우에도 오류가 발생하는데

그런 경우에는 오류 메시지와 오류 코드를 보면 문제를 파악할 수 있으므로 어렵지 않게 수정할 수 있다. 그래서 생략.

(귀차니즘 발동... ㅎㅎ 중요한 오류는 위에서 다 다뤘으니깐 뭐. ^^;)

딱 하나만.

Visual Studio로 RMS 응용 프로그램을 만들어서 디버깅하려고 할 때 이런 오류를 만날 수 있다.

뭐 당연하게도 응용 프로그램 서명이 안되어 있기 때문인데, ISV Hierarchy와 Production Hierarchy일 때에 따라 대처하는 요령이 다르다.

대처하는 방법은 아래 사이트 참조.

>> 참조: http://msdn.microsoft.com/en-us/library/windows/desktop/hh971319(v=vs.85).aspx

참조만 남겨두고 넘어가려니 발걸음이 떨어지지 않는다...

그래서 간단하게 덧붙이자면,

%MSIPCSdkDir%\Tools\Genmanifest.exe

%MSIPCSdkDir%\bin\Isvtier5appsigningprivkey.dat

%MSIPCSdkDir%\bin\Isvtier5appsigningpubkey.dat

%MSIPCSdkDir%\bin\Isvtier5appsignsdk_client.xml

%MSIPCSdkDir%\bin\YourAppName.isv.mcf

이 다섯 개의 파일을 응용 프로그램이 있는 폴더에 복사하고 나서,

.mcf 파일을 수정하고,

아래 명령을 실행하면 된다.

genmanifest.exe -chain isvtier5appsignsdk_client.xml MyApp.exe.mcf MyApp.exe.man

생성된 .man 파일을 응용 프로그램이 있는 폴더에 항상 함께 두면 위 오류는 더 이상 발생하지 않는다.

다만, 응용 프로그램을 다시 빌드한다든가 해서 응용 프로그램의 해시값이 바뀌면(이건 추측이다)

기존의 응용 프로그램 서명이 무효화되므로 다시 위의 서명 과정을 거쳐야 오류가 발생하지 않는다.

(Visual Studio의 빌드 후 이벤트 등으로 자동으로 실행되도록 넣어주면 편리할 듯.)

4. 보안 옵션

추가. 보안 옵션 설정. AD RMS 서비스 계정이 보안 감사 생성 권한을 가져 보안 감사 로그를 기록할 수 있게 하려면 아래와 같이 설정한다.

(이 설정은 Identity Federation 연동 지원을 위해서는 필수라고 한다. 해당 근거/출처는 여기 참조.)

관리 도구에 있는 [그룹 정책 관리] 편집기를 실행하고 그림의 부분[Default Domain Controllers Policy - 컴퓨터 구성 - 정책 - Windows 설정 - 보안 설정 - 로컬 정책 - 사용자 권한 할당]을 찾아 들어가서 "보안 감사 생성" 목록에 AD RMS 서비스 계정(예: adrmssvc)을 추가해 주면 된다.

5. Kerberos 인증

다음으로,

도메인 환경(또는 서버 로컬)에서 사용자 인증을 Kerberos 인증으로 동작되게 하려면 몇 가지 설정을 더 해줘야 한다. 이 설정을 하지 않으면 AD RMS 서버 로컬이나 도메인에 소속된 컴퓨터에서는 인증이 되지 않는다.

>> 참조: http://technet.microsoft.com/en-us//library/dd759186.aspx

간략하게 베껴와 보면 아래와 같다.

appcmd.exe set config -section:system.webServer/security/authentication/windowsAuthentication -useAppPoolCredentials:true

위 명령어를 그대로 복사해서 실행하고,

setspn -a HTTP/<ServerName> <ServiceAccountDomain>\<ServiceAccount>

setspn -a HTTP/<ServerFQDN> <ServiceAccountDomain>\<ServiceAccount>

setspn -a HTTP/<ClusterName> <ServiceAccountDomain>\<ServiceAccount>

setspn -a HTTP/<ClusterFQDN> <ServiceAccountDomain>\<ServiceAccount>

이렇게 명령어를 실행해서 AD RMS 서비스 계정의 SPN을 설정하면 된다고 한다.

실제로,

AD RMS 서비스 계정이 "adrmssvc"이고,

HTTPS 환경이고,

컴퓨터 이름이 "ADRMSTEST", 도메인이 "contoso.com" 이라면

아래와 같이 하면 된다.

(단일 서버 환경인 경우 RMS 클러스터 이름이나 클러스터 전체이름은 보통 컴퓨터 이름과 같으므로 생략해도 된다)

setspn -a https/ADRMSTEST contoso\adrmssvc

setspn -a https/ADRMSTEST.contoso.com contoso\adrmssvc

해당 계정에 SPN이 정상 설정되었는지 확인(Listing)하려면 아래와 같은 명령어를 쓰면 된다.

(사용자 계정 앞에 도메인 이름을 꼭 쓸 필요는 없다.)

setspn -L adrmssvc

또, SPN 설정을 삭제(Delete)하려면 아래와 같이 쓰면 된다.

setspn -D https/ADRMSTEST adrmssvc

setspn -D https/ADRMSTEST.contoso.com adrmssvc

물론 윈도 환경에서 어지간한 경우가 아니면 대소문자를 가리지 않으므로 위 명령어들 모두 다 소문자, 혹은 다 대문자로 써도 된다.

6. AD RMS 클라이언트 환경 초기화

마지막으로,

클라이언트에서 여러 AD RMS를 이용하는 경우(실제로는 없겠지만, 테스트를 위해)

환경을 초기화하기 위해서는 아래의 작업을 해줘야 한다.

(1) 레지스트리 초기화

아래 레지스트리 등록 파일의 내용을 일단 들여다 보자.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSDRM\ServiceLocation]

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSDRM\ServiceLocation\Activation]

@="https://<SERVER_DOMAIN>/_wmcs/Certification"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSDRM\ServiceLocation\EnterprisePublishing]

@="https://<SERVER_DOMAIN>/_wmcs/Licensing"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSIPC]

"Hierarchy"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSIPC\ServiceLocation]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSIPC\ServiceLocation\EnterpriseCertification]

@="https://<SERVER_DOMAIN>/_wmcs/Certification"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSIPC\ServiceLocation\EnterprisePublishing]

@="https://<SERVER_DOMAIN>/_wmcs/Licensing"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\uDRM]

"Hierarchy"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSIPC]

"Hierarchy"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSIPC\ServiceLocation]

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSIPC\ServiceLocation\EnterpriseCertification]

@="https://<SERVER_DOMAIN>/_wmcs/Certification"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSIPC\ServiceLocation\EnterprisePublishing]

@="https://<SERVER_DOMAIN>/_wmcs/Licensing"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\uDRM]

"Hierarchy"=dword:00000000

[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Common\DRM]

"CorpCertificationServer"="https://<SERVER_DOMAIN>/_wmcs/certification"

"CorpLicenseServer"="https://<SERVER_DOMAIN>/_wmcs/licensing"

[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Common\DRM\LicenseServers]

"https://<SERVER_DOMAIN>/_wmcs/licensing"=dword:00000000

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\<_DOMAIN>]

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\<_DOMAIN>\<HOST>]

"https"=dword:00000001

[HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\MSIPC]

"AC"=-

"MSIPP-MK"=-

"MSIPP-SK"=-

"RK"=-

"DefaultIdentityServer"=-

>> 파일 다운로드:

AD_RMS_Client.reg

위에서 <SERVER_DOMAIN> 부분을 실제 RMS 서비스 공개 도메인 이름으로 바꾸고 실행하면 새 AD RMS 환경으로 클라이언트 환경이 초기화된다. 또, <HOST>와 <_DOMAIN>부분은 <SERVER_DOMAIN>에서 호스트명과 도메인 부분으로 나눠서 쓰면 된다. 예를 들어 <SERVER_DOMAIN>이 "adrms.contoso.com"이라면 <HOST>는 "adrms"가 되고 <_DOMAIN>은 "contoso.com"이 된다.

(또, 만약 테스트할 환경이 Production Hierarchy가 아니라 ISV Hierarchy라면 위에서 "Hierarchy"라고 된 부분의 값을 모두 "1"로 설정해주면 된다. 단, 그럴 경우 오피스 IRM과 호환되지 않는다는 점은 이미 앞 게시물에서 말한 바 있으니 참고하도록 한다.)

아쉽게도 그것이 끝은 아니고, ㅎㅎ

그 다음으로 아래 레지스트리 키로 찾아가서 한 가지 작업을 더 해줘야 한다.

[HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\MSIPC]

위 레지스트리 키의 하위에는 테스트를 진행한 각 RMS 공개 도메인 이름으로 된 레지스트리 키들이 추가되어 있는데

해당 키들을 모두 삭제하면 끝. 단, "discover.aadrm.com" 으로 된 레지스트리 키는 삭제하지 않는 것이 좋겠다.

(Microsoft DRM online을 사용하지 않는다면 굳이 남겨둘 필요는 없다. 그래도 원래 있었던 것이니 어지간하면 놔둔다.)

(2) 권한 정책 템플릿 캐시 파일 삭제

그 다음으로, AD RMS 클라이언트가 한 번 이상 AD RMS 서버에 접속해서 권한 정책 템플릿을 다운로드받았다면

아래 폴더에 해당 템플릿 캐시 파일들이 이미 저장되어 있어 다른 AD RMS로 변경할 때 잘못된 정책 목록을 표시하는 등 문제가 될 수 있다.

따라서, AD RMS를 변경하는 경우에는 템플릿 파일들도 수동으로 지워줘야 한다.

%LOCALAPPDATA%\Microsoft\MSIPC\Templates

(Windows 7의 경우, 보통 c:\Users\{사용자이름}\AppData\Local\Microsoft\MSIPC\Templates)

위 폴더 안에 있는 파일들을 모두 삭제하면 된다.

그런데, 위 폴더의 바로 상위 폴더인 %LOCALAPPDATA%\Microsoft\MSIPC 폴더에도 .drm, CLC-..., GIC-..., EUL-... 등의 여러 파일들이 생기는데 이 폴더의 파일들은 AD RMS에 접속함에 따라 자동으로 생성/삭제가 이루어지므로 굳이 수동으로 삭제할 필요는 없다. (또 CLC-... 로 시작하는 파일은 파일명이 너무 길다며 지워지지도 않는다.)

혹시라도 이 폴더도 수작업으로 지우고 싶다면 명령 프롬프트를 실행해서 아래와 같이 실행하면 깨끗이 지워진다.

cd /d %LOCALAPPDATA%\Microsoft

rd /s MSIPC

(3) DRM 캐시 파일 삭제

마지막 단계, AD RMS 클라이언트를 이용해 파일 보호나 암호화 작업을 한 번 이상 한 적이 있다면

아래 폴더에 DRM 캐시 파일들이 저장되어 있어 다른 AD RMS로 변경할 때 예상치 못한 오류가 발생하는 등 문제가 될 수 있다.

따라서, AD RMS를 변경하는 경우에는 DRM 캐시 파일들도 수동으로 모두 지워줘야 한다.

%LOCALAPPDATA%\Microsoft\DRM

(Windows 7의 경우, 보통 c:\Users\{사용자이름}\AppData\Local\Microsoft\DRM)

위 폴더 안에 있는 파일들을 하나도 남김없이 모두 삭제하면 된다.

끝.

이상과 같은 작업만 해주면 AD RMS를 언제든 변경해가면서 테스트할 수 있다.

7. 추가정보: RMS Toolkit

>> 참조: Rights Management Services Administration Toolkit with SP2

이 RMS Toolkit을 설치하면 여러가지 RMS와 관련된 부가 기능 수행이 가능한데

내가 실제로 유용하게 활용한 도구는 두 가지다.

하나는 ADScpRegister, 또 하나는 IRMCheck.

ADScpRegister는, AD RMS 서버를 설치/재설치할 때 AD에 이미 등록되어 있는 SCP 때문에

설치가 제대로 되지 않고 실패하는 경우를 자주 당하다 보니

아예 AD RMS를 설치 제거할 때 미리 SCP를 먼저 제거하고 설치 제거를 하곤 했는데

그것도 까먹고 재설치를 하게 되는 경우가 가끔 있다 보니 필요하게 된 도구였다.

ADScpRegister.exe unregisterscp

이렇게 실행하면 AD에 등록되어 있는 SCP를 삭제해준다.

IRMCheck는, AD RMS 클라이언트 도구인데,

현재 클라이언트에 설정된 오피스 및 기타 RMS 관련 설정들이 모두 정상인지 체크해서

HTML 파일로 보고서를 작성해준다. RMS를 처음 접해서 뭔가 잘 안될 때 아주 유용했다.

IRMCheck.exe auto extended -o irmcheck.htm

이렇게 실행하면 자동으로 알아서 ISV Hierarchy 인지 Production Hierarchy 인지 판단해서

그에 맞게 설정이 잘 되어 있는지 검사한 결과를 HTML 문서로 뽑아 보여준다.

ISV Hierarchy로 고정해서 검사하려면 "auto" 부분을 "isv"로 바꿔서 실행하면 된다.