Partilhar via

SharePoint 2010에서 계정 ID를 변경하기 위한 SPMigrateUsers 도구

  • Artigo

최초 문서 게시일: 2012년 6월 3일 일요일

SharePoint를 사용할 때 계정 ID를 변경하려는 경우가 있습니다. SAML 클레임을 사용하는 경우가 대표적인 예에 해당합니다. 제 경우에는 사용자에 대한 ID 클레임으로 전자 메일 주소를 사용하는데요. 그 이유는 a) 대부분의 사용자에게 전자 메일 주소가 있고 b) 대부분의 사용자가 전자 메일 주소를 이해할 수 있기 때문입니다. 그러나 사용자들이 전자 메일 주소를 언제든지 변경할 가능성도 있기 때문에 가끔 곤란한 경우도 있습니다. 전자 메일 주소를 변경하면 이전에 사용했던 모든 사용 권한이 없어지니까요. 솔직히 이러한 시나리오가 자주 발생하는 것도 아니고, 아예 전자 메일 주소를 사용하지 않는 방법도 있습니다. 그러나 이러한 상황이 실제로 발생하는 경우도 있기 때문에, 이 게시물에서는 SharePoint의 모든 작업을 전자 메일 주소로 보호하는 경우를 살펴보도록 하겠습니다.

이러한 상황을 제어하는 데 있어서 핵심적인 요소는 이전에 IMigrateUserCallback 인터페이스에 대해 다루었던 블로그 게시물인 https://blogs.msdn.com/b/sharepoint_ko/archive/2011/03/08/windows-saml.aspx에 설명되어 있습니다. 이 게시물에서는 해당 인터페이스를 사용하여 ID를 마이그레이션하는 방법과, Windows 클레임 ID를 SAML 클레임 ID로 변환하는 방법의 예제를 제시한 바 있습니다. 여기서는 간단한 Windows 응용 프로그램을 작성하여 자격 증명을 입력한 다음, 해당 자격 증명을 응용 프로그램에서 자동으로 수정하도록 해 보았는데요. 이 응용 프로그램은 이러한 변경을 수행하기 위한 간단한 일회용 도구로 사용하기 위한 것이었지만, 해당 소스 코드(이 게시물에 포함되어 있음)를 쉽게 변경하여 파일이나 데이터베이스의 사용자 목록에서 사용자를 읽은 다음 비교를 수행하는 등의 좀 더 독창적인 작업을 수행하는 도구로 수정할 수 있습니다.

이 도구의 또 다른 유용한 점은 실제로 여러 시나리오에 사용할 수 있다는 것입니다. 즉, 전자 메일 주소를 변환하는 데 사용할 수 있을 뿐 아니라 그룹 이름을 변환하는 데도 사용할 수 있습니다. 그런데, 이미 아시는 분들도 계시겠지만 그룹 이름에는 SID를 사용해야 합니다(예: SAML의 역할 클레임). 그룹 이름을 바꿔도 SID는 그대로 유지되기 때문입니다. 그렇기는 하지만 a) 그룹 이름이 바뀌는 경우는 거의 없고, b) 그룹 SID 이름을 입력하여 SharePoint 그룹에 SID 이름을 추가하는 사용자도 거의 없으며(이런 방식을 사용하고 계신다면 더 쉬운 방법이 있으므로 사용하지 마시기 바랍니다.), c) SID는 로컬 Active Directory 외부에서는 아무런 의미가 없습니다. Azure, Google, Yahoo, Facebook 등의 클라우드 기반 서비스로 이동하면 SID는 쓸모가 없습니다.

뿐만 아니라 이 도구는 단일 공급자 유형 내에서만 변경할 수 있도록 제한하지도 않습니다. Windows 그룹을 SMAL 역할 클레임으로 변경할 수도 있고, SAML ID 클레임을 FBA 멤버 사용자로 변경할 수도 있으며, FBA 역할을 AD 그룹으로 변경할 수도 있습니다. 무슨 말인지 아시겠죠? 제가 각 공급자 간에 서로 다른 "사용자"와 "그룹"의 거의 모든 조합을 시험해 본 결과 지금까지는 모든 변환이 정상적으로 수행되었습니다.

도구 자체는 간단하게 사용할 수 있습니다. 아래에 그림이 나와 있습니다.

이 응용 프로그램을 처음으로 시작하면 모든 웹 응용 프로그램의 목록이 로드됩니다. 그런 다음 각 웹 응용 프로그램에 대해 아래쪽의 콤보 상자 두 개에 해당 웹 응용 프로그램에서 사용되고 있는 모든 공급자의 목록이 채워집니다. SAML 공급자 또는 FBA 공급자가 여러 개인 경우 각 공급자가 드롭다운 목록에 포함됩니다. 여기서 마이그레이션 원본 공급자와 대상 공급자를 선택하면 됩니다. 클레임 값(Claim Value) 섹션에는 마이그레이션 원본 값 및 대상 값을 입력합니다. 일반 텍스트 값(Plain Text Value) 편집 필드에 값을 입력하고 왼쪽의 ID 클레임(ID Claim) 단추나 오른쪽의 그룹 클레임(Group Claim) 단추를 클릭합니다. 이 과정에 대한 모든 내용이 텍스트의 설명에 포함되어 있으며, 단추의 텍스트는 사용 중인 ID 공급자에 따라 적절하게 변경됩니다.

예를 들어 SAML 인증만 사용하며 전자 메일 주소 "steve@contoso.com"을 "stevep@contoso.com"으로 마이그레이션하려는 경우를 가정해 보겠습니다. 먼저 웹 응용 프로그램을 선택하면 각 드롭다운에서 SAML 인증 공급자가 기본적으로 선택됩니다. 그런 다음 이전 값(Before Values) 섹션의 일반 텍스트 값(Plain Text Value) 편집 필드에 "steve@contoso.com"을 입력하고 ID 클레임(ID Claim) 단추를 클릭합니다. 그러면 올바르게 인코딩된 클레임 값이 인코딩된 값(Encoded Value) 편집 필드에 입력됩니다. 다음으로 이후 값(After Values) 섹션의 일반 텍스트 값(Plain Text Value) 편집 필드에 "stevep@contoso.com"을 입력합니다. 이제 ID 클레임(ID Claim) 단추를 다시 클릭하면 올바른 값이 인코딩된 값(Encoded Value) 편집 상자에 표시됩니다.(참고: 위의 그림에서 이후 값(After Values) 섹션의 단추에는 "ID 클레임(ID Claim)"이 아닌 "사용자(User)"가 표시되어 있는데, 해당 예제에서는 SAML 클레임에서 Windows 클레임으로 마이그레이션하기 때문입니다.) 모든 값이 입력되면 마이그레이션(Migrate) 단추를 클릭하여 프로세스를 완료합니다. 마이그레이션이 완료되면 완료를 알리는 메시지 상자가 나타납니다.

여러 웹 응용 프로그램 및 인증 유형에 대해 마이그레이션을 테스트하는 과정에서 몇 가지 문제가 발생했으므로 여기서 설명하고 넘어가겠습니다. 먼저, 특정 웹 응용 프로그램에 대해 사용자를 마이그레이션할 때 액세스 거부 오류 메시지가 표시되었습니다. 이 오류가 발생한 이유를 추적할 수가 없었으므로 해당 웹 응용 프로그램에 문제가 있었다고밖에 말씀드릴 수가 없는데요, 팜에서 다른 웹 응용 프로그램 4~5개에 대해 마이그레이션을 시도했을 때는 모두 정상적으로 완료되었으므로 어떤 문제인지는 알 수가 없었습니다.

둘째로, 마이그레이션이 정상적으로 완료되었다는 메시지는 표시되었는데 마이그레이션된 사용자로 로그인할 수는 없는 경우도 있었습니다. 이 문제를 자세히 살펴본 결과 마이그레이션 원본 계정이 IMigrateUserCallback 함수를 통해 푸시되지 않았음이 확인되었습니다. 즉, 이 문제는 응용 프로그램의 코딩 문제가 아니라 SharePoint 자체의 문제입니다. 이러한 상황이 발생하는 경우에는 소스 코드와 Visual Studio를 사용하여 디버거를 단계별로 수행해 마이그레이션 원본 계정이 호출되는지를 확인하는 것이 좋습니다. 제 경우에는 FBA 멤버 사용자 하나에서만 문제가 발생했습니다.

마지막으로, 값 간에 계정을 마이그레이션한 후 새 사용자로 로그인했는데 페이지 오른쪽 위의 시작 컨트롤에 이전 계정 이름이 나타나는 경우도 있습니다. 마이그레이션 함수는 계정 이름만 변경합니다. 다른 사용자 정보도 변경하는 경우에는 사용자 프로필을 업데이트하면 프로필 시스템과의 다음 동기화 시에 올바른 정보가 모든 사이트 모음으로 푸시됩니다.

이상으로 게시물을 마치겠습니다. 여러분께 도움이 되었으면 합니다. 앞서 말씀드린 것처럼, 전체 소스 코드가 아래에 포함되어 있으므로 여러분의 시나리오에 따라 자유롭게 수정하여 사용하시기 바랍니다.

이 문서는 번역된 블로그 게시물입니다. 원본 문서는 The SPMigrateUsers Tool for Changing Account Identities in SharePoint 2010을 참조하십시오.