SharePoint Server에서 사용자 인증 방법 계획Plan for user authentication methods in SharePoint Server

적용 대상: 예2013 예2016 yes2019 SharePointOnline 없음APPLIES TO: yes2013 yes2016 yes2019 noSharePoint Online

SharePoint Server에서 지원하는 사용자 인증 유형 및 방법과 웹 응용 프로그램 및 영역에 대해 사용할 유형 및 방법을 어떻게 결정할지에 대해 설명합니다.Learn the user authentication types and methods that are supported by SharePoint Server and how to determine which ones to use for web applications and zones.

소개Introduction

사용자 인증은 사용자의 자격 증명을 포함하며 사용자가 해당 자격 증명을 올바르게 제출했는지 확인할 수 있는 디렉터리 또는 데이터베이스인 인증 공급자에 대해 사용자 ID의 유효성을 검사하는 작업입니다. 인증 공급자의 예로는 AD DS(Active Directory 도메인 서비스)가 있습니다. 인증 공급자는 사용자 디렉터리, 특성 저장소라고도 합니다.User authentication is the validation of a user's identity against an authentication provider, which is a directory or database that contains the user's credentials and can confirm the user submitted them correctly. An example of an authentication provider is Active Directory Domain Services (AD DS). Other terms for authentication provider are user directory and attribute store.

인증 방법은 사용자의 ID를 나타내는 계정 자격 증명 및 기타 정보를 특정 방식으로 교환하는 것입니다. 인증 방법을 사용하면 인증 공급자가 사용자를 인증했다는 증명(대개 클레임을 포함하는 토큰 형식)이 제공됩니다.An authentication method is a specific exchange of account credentials and other information that assert a user's identity. The result of the authentication method is proof, typically in the form of a token that contains claims, that an authentication provider has authenticated a user.

인증 유형은 하나 이상의 인증 공급자에 대해 자격 증명의 유효성을 검사하는 특정 방식으로, 업계 표준 프로토콜을 사용하기도 합니다. 하나의 인증 유형에서 여러 인증 방법을 사용할 수 있습니다.An authentication type is a specific way of validating credentials against one or more authentication providers, sometimes using an industry standard protocol. An authentication type can use multiple authentication methods.

사용자 ID의 유효성을 검사한 후에는 권한 부여 프로세스에서 사용자가 액세스할 수 있는 사이트, 콘텐츠 및 기타 기능을 결정합니다.After a user's identity is validated, the authorization process determines which sites, content, and other features the user can access.

사용자 인증 유형 계획에서는 다음 사항을 결정해야 합니다.Your planning for user authentication types and methods should determine the following:

  • 각 웹 응용 프로그램 및 영역에 대한 사용자 인증 유형 및 방법The user authentication types and methods for each web application and zone

  • 결정된 인증 유형 및 방법을 지원하는 데 필요한 인증 인프라The authentication infrastructure needed to support the determined authentication types and methods

    참고

    Windows 클래식 모드 인증이 SharePoint Server 2016에서 더 이상 지원되지 않습니다.Windows classic mode authentication is no longer supported in SharePoint Server 2016.

클레임 기반 인증Claims-based authentication

AD DS의 사용자 ID는 사용자 계정을 기반으로 합니다. 사용자는 인증을 정상적으로 수행할 수 있도록 계정 이름 및 암호를 알고 있다는 증명을 제공합니다. 리소스 액세스를 결정하기 위해 응용 프로그램은 AD DS에서 계정 특성 및 기타 정보(예: 네트워크의 역할 또는 그룹 멤버 자격)를 쿼리해야 할 수 있습니다. 이 방식은 Windows 환경에서는 문제 없이 진행되지만 인터넷, 파트너 또는 클라우드 기반 컴퓨팅 모델을 지원하는 타사 인증 공급자 및 다중 공급업체 환경에서는 사용할 수 없습니다.User identity in AD DS is based on a user account. For successful authentication, the user provides the account name and proof of knowledge of the password. To determine access to resources, applications might have to query AD DS for account attributes and other information, such as group membership or role on the network. While this works well for Windows environments, it does not scale out to third-party authentication providers and multi-vendor environments that support Internet, partner, or cloud-based computing models.

클레임 기반 ID를 소유한 사용자는 일반적으로 신뢰할 수 있는 ID 공급자로부터 디지털 서명된 보안 토큰을 받습니다. 이 토큰에는 클레임 집합이 포함되어 있습니다. 각 클레임은 사용자의 이름, 멤버 자격, 네트워크의 역할과 같은 사용자 관련 특정 데이터 항목을 나타냅니다. 클레임 기반 인증은 클레임 기반 ID 기술 및 인프라를 사용하는 사용자 인증입니다. 클레임 기반 인증을 지원하는 응용 프로그램은 자격 증명이 아닌 사용자로부터 보안 토큰을 받은 다음 클레임 내의 정보를 사용하여 리소스 액세스를 결정합니다. 이 경우 AD DS 등의 디렉터리 서비스를 별도로 쿼리할 필요가 없습니다.With claims-based identities, a user obtains a digitally signed security token from a commonly trusted identity provider. The token contains a set of claims. Each claim represents a specific item of data about a user such as his or her name, group memberships, and role on the network. Claims-based authentication is user authentication that uses claims-based identity technologies and infrastructure. Applications that support claims-based authentication obtain a security token from a user, rather than credentials, and use the information within the claims to determine access to resources. No separate query to a directory service such as AD DS is needed.

Windows의 클레임 기반 인증은 클레임 기반 ID를 구현하는 데 사용되는 .NET Framework 클래스 집합인 Windows Identity Foundation(WIF)에 따라 작성되었습니다. 클레임 기반 인증에는 WS-Federation, WS-Trust 등의 표준과 SAML(Security Assertion Markup Language) 등의 프로토콜이 사용됩니다.Claims-based authentication in Windows is built on Windows Identity Foundation (WIF), which is a set of .NET Framework classes that is used to implement claims-based identity. Claims-based authentication relies on standards such as WS-Federation, WS-Trust, and protocols such as the Security Assertion Markup Language (SAML).

클레임 기반 인증에 대한 자세한 내용은 다음 리소스를 참조하세요.For more information about claims-based authentication, see the following resources:

사용자 인증, 서버 간 인증 및 앱 인증에는 클레임 기반 인증이 널리 사용되고 있으므로 SharePoint Server 팜의 모든 웹 응용 프로그램 및 영역에 대해 클레임 기반 인증을 사용하는 것이 좋습니다. 자세한 내용은 SharePoint Server에서 서버 간 인증 계획을 참조하세요. 클레임 기반 인증을 사용하는 경우 지원되는 모든 인증 방법을 웹 응용 프로그램에서 사용할 수 있으며 서버 간 인증 및 앱 인증을 사용하는 SharePoint Server의 새로운 기능과 시나리오를 활용할 수 있습니다.Due to the widespread use of claim-based authentication for user authentication, server-to-server authentication, and app authentication, we recommend claims-based authentication for all web applications and zones of a SharePoint Server farm. For more information, see Plan for server-to-server authentication in SharePoint Server. When you use claims-based authentication, all supported authentication methods are available for your web applications and you can take advantage of new features and scenarios in SharePoint Server that use server-to-server authentication and app authentication.

클레임 기반 인증에서는 SharePoint Server가 모든 사용자 계정을 클레임 ID로 변경하며, 그러면 각 사용자에 대해 보안 토큰(클레임 토큰이라고도 함)이 생성됩니다. 클레임 토큰에는 사용자 관련 클레임이 포함되어 있습니다. Windows 계정은 Windows 클레임으로 변환되고 양식 기반 멤버 자격이 있는 사용자는 양식 기반 인증 클레임으로 변환됩니다. SharePoint Server에서는 SAML 기반 토큰에 포함된 클레임을 사용할 수 있습니다. 또한 SharePoint 개발자 및 관리자는 추가 클레임으로 사용자 토큰을 확장할 수 있습니다. 예를 들어 Windows 사용자 계정 및 양식 기반 계정은 SharePoint Server에서 사용되는 추가 클레임을 통해 확장할 수 있습니다.For claims-based authentication, SharePoint Server automatically changes all user accounts to claims identities. This results in a security token (also known as a claims token) for each user. The claims token contains the claims pertaining to the user. Windows accounts are converted into Windows claims. Forms-based membership users are transformed into forms-based authentication claims. SharePoint Server can use claims that are included in SAML-based tokens. Additionally, SharePoint developers and administrators can augment user tokens with additional claims. For example, Windows user accounts and forms-based accounts can be augmented with additional claims that are used by SharePoint Server.

클레임을 직접 만들지 않아도 SharePoint Server에서 클레임 인증을 사용할 수는 있지만, SAML 토큰 기반 인증을 구현하려면 SAML 토큰 기반 인증 계획에 설명된 대로 해당 클레임 기반 환경 관리자와 협력해야 합니다.You do not have to be a claims architect to use claims-based authentication in SharePoint Server. However, implementing SAML token-based authentication requires coordination with administrators of your claims-based environment, as described in Plan for SAML token-based authentication.

SharePoint Server 2013의 클래식 모드 인증Classic mode authentication in SharePoint Server 2013

SharePoint 2013에서는 중앙 관리에서 웹 응용 프로그램을 만들 때 클레임 기반 인증용 인증 유형 및 방법만 지정할 수 있습니다. 이전 버전의 SharePoint에서는 중앙 관리에서 웹 응용 프로그램에 대해 클래식 모드 인증도 구성할 수 있습니다. 클래식 모드 인증에서는 Windows 인증을 사용하며 SharePoint 2013는 사용자 계정을 AD DS 계정으로 처리합니다.In SharePoint 2013, when you create a web application in Central Administration, you can only specify authentication types and methods for claims-based authentication. In previous versions of SharePoint, you could also configure classic mode authentication for web applications in Central Administration. Classic mode authentication uses Windows authentication and SharePoint 2013 treats the user accounts as AD DS accounts.

웹 응용 프로그램이 클래식 모드 인증을 사용하도록 구성하려면 New-SPWebApplication PowerShell cmdlet을 사용하여 해당 인증을 작성해야 합니다. 클래식 모드 인증을 사용하도록 구성된 SharePoint 2010 제품 웹 응용 프로그램의 경우 SharePoint 2013으로 업그레이드할 때 인증 설정이 유지됩니다. 그러나 SharePoint 2013으로 업그레이드하기 전에 웹 응용 프로그램을 클레임 기반 인증으로 마이그레이션하는 것이 좋습니다.To configure a web application to use classic mode authentication, you must use the New-SPWebApplication PowerShell cmdlet to create it. SharePoint 2010 Products web applications that are configured for classic mode authentication retain their authentication settings when you upgrade to SharePoint 2013. However, we recommend that you migrate your web applications to claims-based authentication before upgrading to SharePoint 2013.

단일 SharePoint 2013 팜에 두 모드를 사용하는 웹 응용 프로그램이 모두 포함되어 있을 수 있습니다. 기존 Windows 계정에 해당하는 사용자 계정과 Windows 클레임 계정을 구분하지 않는 서비스도 있습니다.A SharePoint 2013 farm can include a mix of web applications that use both modes. Some services do not differentiate between user accounts that are traditional Windows accounts and Windows claims accounts.

업그레이드 전에 마이그레이션하는 방법에 대한 자세한 내용은 클래식 모드에서 클레임 기반 인증으로 마이그레이션을 참조하세요.For more information about migrating before upgrading, see Migrate from classic-mode to claims-based authentication.

업그레이드 후에 마이그레이션하는 방법에 대한 자세한 내용은 Migrate from classic-mode to claims-based authentication in SharePoint Server을 참조하세요.For more information about migrating after upgrading, see Migrate from classic-mode to claims-based authentication in SharePoint Server.

SharePoint 2013에서 클래식 모드 인증을 사용하는 웹 응용 프로그램을 만드는 방법에 대한 자세한 내용은 SharePoint Server에서 클래식 모드 인증을 사용 하는 웹 응용 프로그램 만들기를 참조하세요. 클레임 기반 인증을 사용하는 웹 응용 프로그램을 클래식 모드 인증을 사용하도록 마이그레이션할 수는 없습니다.For information about how to create web applications that use classic mode authentication in SharePoint 2013, see Create web applications that use classic mode authentication in SharePoint Server. Note that you cannot migrate a web application that uses claims-based authentication to use classic mode authentication.

중요

Office Online는 클레임 기반 인증을 사용하는 SharePoint 2013 웹 응용 프로그램에서만 사용할 수 있습니다. Office Online 렌더링 및 편집 기능은 클래식 모드 인증을 사용하는 SharePoint 2013 웹 응용 프로그램에서 작동하지 않습니다. 클래식 모드 인증을 사용하는 SharePoint 2010 웹 응용 프로그램을 SharePoint 2013으로 마이그레이션하는 경우에는 Office Online에서 작동하도록 해당 응용 프로그램을 클레임 기반 인증으로 마이그레이션해야 합니다.Office Online can be used only by SharePoint 2013 web applications that use claims-based authentication. Office Online rendering and editing will not work on SharePoint 2013 web applications that use classic mode authentication. If you migrate SharePoint 2010 web applications that use classic mode authentication to SharePoint 2013, you must migrate them to claims-based authentication to allow them to work with Office Online.

지원되는 인증 유형 및 방법Supported authentication types and methods

SharePoint Server에서는 다음과 같은 인증 유형에 대해 다양한 인증 방법 및 인증 공급자를 지원합니다.SharePoint Server supports a variety of authentication methods and authentication providers for the following authentication types:

  • Windows 인증Windows authentication

  • 양식 기반 인증Forms-based authentication

  • SAML 토큰 기반 인증SAML token-based authentication

Windows 인증Windows authentication

Windows 인증 유형에서는 Windows 환경에서 연결하는 클라이언트의 자격 증명 유효성을 검사하는 데 사용하는 기존 Windows 인증 공급자(AD DS) 및 인증 프로토콜을 활용합니다. 클레임 기반 인증에서 사용되는 Windows 인증 방법은 다음과 같습니다.The Windows authentication type takes advantage of your existing Windows authentication provider (AD DS) and the authentication protocols that a Windows domain environment uses to validate the credentials of connecting clients. Windows authentication method, which is used by both claims-based authentication include the following:

  • NTLMNTLM

  • KerberosKerberos

  • 다이제스트Digest

  • 기본Basic

자세한 내용은 이 문서의 Windows 인증 계획을 참조하세요.For more information, see Plan for Windows authentication in this article.

SharePoint 2013 및 SharePoint Server 2016의 Windows 클레임 인증 동영상 보기Watch the Windows claims authentication in SharePoint 2013 and SharePoint Server 2016 video

SharePoint Server에서는 Windows 인증 유형은 아니지만 익명 인증도 지원합니다. 사용자는 자격 증명의 유효성을 검사하지 않고도 SharePoint 콘텐츠에 액세스할 수 있습니다. 익명 인증은 기본적으로 사용하지 않도록 설정됩니다. SharePoint Server를 사용하여 공개 인터넷 웹 사이트 등 보안이 필요하지 않으며 모든 사용자가 사용 가능한 콘텐츠를 게시할 때 보통 익명 인증을 사용합니다.Although not a Windows authentication type, SharePoint Server also supports anonymous authentication. Users can access SharePoint content without validating their credentials. Anonymous authentication is disabled by default. You typically use anonymous authentication when you use SharePoint Server to publish content that does not require security and is available for all users, such as a public Internet website.

익명 인증을 사용하도록 설정할 때는 사이트 및 사이트 리소스에 대한 익명 액세스(사용 권한)도 구성해야 합니다.Note that in addition to enabling anonymous authentication, you must also configure anonymous access (permissions) on sites and site resources.

참고

웹 응용 프로그램 서비스를 위해 SharePoint에서 만들어진 IIS(인터넷 정보 서비스) 웹 사이트는 익명 및 양식 인증에 대한 SharePoint 설정이 사용되지 않도록 설정되어 있어도 항상 익명 인증 및 양식 인증 방법이 사용되도록 설정됩니다. 이것은 의도적인 설정이며 IIS 설정에서 직접 익명 또는 양식 인증을 사용하지 않도록 설정하면 SharePoint 사이트에서 오류가 발생합니다.Internet Information Services (IIS) websites that are created by SharePoint for serving web applications always have the Anonymous Authentication and Forms Authentication methods enabled, even when the SharePoint setting for Anonymous and Forms Authentication are disabled. This is intentional and disabling Anonymous or Forms Authentication directly in the IIS settings will result in errors in the SharePoint site.

양식 기반 인증Forms-based authentication

양식 기반 인증은 ASP.NET 멤버 자격 및 역할 공급자 인증을 기반으로 하는 클레임 기반 ID 관리 시스템입니다. 다음과 같은 인증 공급자에 저장된 자격 증명에 대해 양식 기반 인증을 사용할 수 있습니다.Forms-based authentication is a claims-based identity management system that is based on ASP.NET membership and role provider authentication. Forms-based authentication can be used against credentials that are stored in an authentication provider, such as the following:

  • AD DSAD DS

  • 데이터베이스(예: SQL Server 데이터베이스)A database such as a SQL Server database

  • LDAP(Lightweight Directory Access Protoco) 데이터 저장소(예: Novell eDirectory, NDS(Novell Directory Services), Sun ONE)An Lightweight Directory Access Protocol (LDAP) data store such as Novell eDirectory, Novell Directory Services (NDS), or Sun ONE

양식 기반 인증에서는 사용자가 로그온 양식(대개 웹 페이지)에 입력하는 자격 증명을 기반으로 사용자의 유효성을 검사합니다. 인증되지 않은 요청은 로그온 페이지로 리디렉션되며 사용자는 이 페이지에 유효한 자격 증명을 제공하고 양식을 전송해야 합니다. 시스템에서는 인증된 요청에 대해 후속 요청용으로 ID를 다시 설정하기 위한 키가 포함된 쿠키를 발급합니다.Forms-based authentication validates users based on credentials that users type in a logon form (typically a web page). Unauthenticated requests are redirected to a logon page, where a user must provide valid credentials and submit the form. The system issues a cookie for authenticated requests that contains a key for reestablishing the identity for subsequent requests.

SharePoint 2013 및 SharePoint Server 2016의 양식 기반 클레임 인증 동영상 보기Watch the forms-based claims authentication in SharePoint 2013 and SharePoint Server 2016 video

참고

양식 기반 인증을 사용하는 경우 사용자 계정 자격 증명은 일반 텍스트로 전송됩니다. 따라서 SSL(Secure Sockets Layer)을 사용하여 웹 사이트 트래픽을 암호화하는 경우가 아니면 양식 기반 인증을 사용해서는 안 됩니다.With forms-based authentication, the user account credentials are sent as plaintext. Therefore, you should not use forms-based authentication unless you are also using Secure Sockets Layer (SSL) to encrypt the website traffic.

자세한 내용은 양식 기반 인증 계획을 참조하세요.For more information, see Plan for forms-based authentication.

SAML 토큰 기반 인증SAML token-based authentication

SharePoint Server의 SAML 토큰 기반 인증은 SAML 1.1 프로토콜 및 WS-F PRP(WS-Federation Passive Requestor Profile)를 사용합니다. SAML 토큰 기반 인증을 사용하려면 고유한 내부 환경이든 파트너 환경이든 관계없이 클레임 기반 환경의 관리자와 협력해야 합니다. AD FS(Active Directory Federation Services) 2.0을 사용하는 경우에는 SSAML 토큰 기반 인증 환경이 제공됩니다.SAML token-based authentication in SharePoint Server uses the SAML 1.1 protocol and the WS-Federation Passive Requestor Profile (WS-F PRP). It requires coordination with administrators of a claims-based environment, whether it is your own internal environment or a partner environment. If you use Active Directory Federation Services (AD FS) 2.0, you have a SAML token-based authentication environment.

SAML 토큰 기반 인증 환경에는 IP-STS(ID 공급자 Security Token Service)가 포함되어 있습니다. IP-STS는 해당 계정이 연결된 인증 공급자에 포함된 사용자를 대신하여 SAML 토큰을 발급합니다. 토큰에는 사용자 이름 및 사용자가 속한 그룹 같은 사용자에 대한 클레임이 수에 제한 없이 포함될 수 있습니다. IP-STS의 예로는 AD FS 2.0 서버가 있습니다.A SAML token-based authentication environment includes an identity provider security token service (IP-STS). The IP-STS issues SAML tokens on behalf of users whose accounts are included in the associated authentication provider. Tokens can include any number of claims about a user, such as a user name and the groups to which the user belongs. An AD FS 2.0 server is an example of an IP-STS.

SharePoint Server에서는 IP-STS에서 권한이 부여된 사용자에게 발급하는 토큰에 포함된 클레임을 활용합니다. 클레임 환경에서 SAML 토큰을 받아들이는 응용 프로그램을 RP-STS(신뢰 당사자 STS)라고 합니다. 신뢰 당사자 응용 프로그램에서는 SAML 토큰을 수신하고 내부의 클레임을 사용하여 요청된 자원에 대해 클라이언트 액세스를 부여할지 여부를 결정합니다. SharePoint Server에서 SAML 공급자를 사용하도록 구성된 각 웹 응용 프로그램은 IP-STS에 별도의 RP-STS 항목으로 추가됩니다. 단일 SharePoint 팜이 IP-STS의 여러 RP-STS 항목을 나타낼 수 있습니다.SharePoint Server takes advantage of claims that are included in tokens that an IP-STS issues to authorized users. In claims environments, an application that accepts SAML tokens is known as a relying party STS (RP-STS). A relying party application receives the SAML token and uses the claims inside to decide whether to grant the client access to the requested resource. In SharePoint Server, each web application that is configured to use a SAML provider is added to the IP-STS server as a separate RP-STS entry. A SharePoint farm can represent multiple RP-STS entries in the IP-STS.

SharePoint 2013 및 SharePoint Server 2016의 SAML 기반 클레임 인증 동영상 보기Watch the SAML-based claims authentication in SharePoint 2013 and SharePoint Server 2016 video

SAML 토큰 기반 인증용 인증 공급자 집합은 클레임 환경의 IP-STS에 따라 달라집니다. AD FS 2.0을 사용하는 경우에는 AD FS 2.0의 특성 저장소라고도 하는 인증 공급자가 다음을 포함할 수 있습니다.The set of authentication providers for SAML token-based authentication depends on the IP-STS in your claims environment. If you use AD FS 2.0, authentication providers (known as attribute stores for AD FS 2.0) can include the following:

  • Windows Server 2003 Active Directory 및 Windows Server 2008의 AD DSWindows Server 2003 Active Directory and AD DS in Windows Server 2008

  • SQL Server 2005 및 SQL Server 2008의 모든 버전All editions of SQL Server 2005 and SQL Server 2008

  • 사용자 지정 특성 저장소Custom attribute stores

자세한 내용은 SAML 토큰 기반 인증 계획을 참조하세요.For more information, see Plan for SAML token-based authentication.

LDAP 환경을 위한 인증 유형 선택Choosing authentication types for LDAP environments

양식 기반 인증 또는 SAML 토큰 기반 인증에서는 LDAP 환경을 사용할 수 있습니다. 현재 LDAP 환경과 일치하는 인증 유형을 사용해야 합니다. 아직 LDAP 환경이 없는 경우에는 좀 더 단순한 양식 기반 인증을 사용하는 것이 좋습니다. 그러나 인증 환경에서 WS-Federation 1.1 및 SAML 1.1을 이미 지원하는 경우에는 SAML을 사용하는 것이 좋습니다. SharePoint Server에서는 LDAP 공급자가 기본적으로 제공됩니다.Forms-based authentication or SAML token-based authentication can use LDAP environments. You should use the authentication type that matches your current LDAP environment. If you do not already have an LDAP environment, we recommend that you use forms-based authentication because it is less complex. However, if your authentication environment already supports WS-Federation 1.1 and SAML 1.1, then we recommend SAML. SharePoint Server has a built-in LDAP provider.

Windows 인증 계획Plan for Windows authentication

Windows 인증 방법을 계획하고 구현하는 과정은 클레임 기반 인증에서 비슷합니다. 웹 응용 프로그램에 대해 클레임 기반 인증을 사용하더라도 Windows 인증 방법을 구현하는 과정이 더 복잡해지지는 않습니다. 이 섹션에서는 Windows 인증 방법 계획 과정을 간략히 설명합니다.The process of planning and implementing Windows authentication methods is similar for claims-based authentication. Claims-based authentication for a web application does not increase the complexity of implementing Windows authentication methods. This section summarizes the planning for the Windows authentication methods.

NTLM 및 Kerberos 프로토콜NTLM and the Kerberos protocol

NTLM 및 Kerberos 프로토콜은 모두 Windows 통합 인증 모드로, 자격 증명에 대한 메시지를 표시하지 않고 사용자가 원활하게 인증을 수행할 수 있도록 합니다. 예를 들면 다음과 같습니다.Both NTLM and the Kerberos protocol are Integrated Windows authentication methods, which let users seamlessly authenticate without prompts for credentials. For example:

  • Internet Explorer에서 SharePoint 사이트에 액세스하는 사용자는 Internet Explorer 프로세스 실행에 사용되는 자격 증명을 사용하여 인증합니다. 이러한 자격 증명은 기본적으로 사용자가 컴퓨터에 로그온하는 데 사용한 자격 증명입니다.Users who access SharePoint sites from Internet Explorer use the credentials under which the Internet Explorer process is running to authenticate. By default, these credentials are the credentials that the user used to log on to the computer.

  • Windows 통합 인증 방법을 사용하여 SharePoint 리소스에 액세스하는 서비스 또는 응용 프로그램은 실행 중인 스레드의 자격 증명(기본적으로 프로세스의 ID)을 사용하여 인증합니다.Services or applications that use Integrated Windows authentication methods to access SharePoint resources attempt to use the credentials of the running thread, which by default is the identity of the process, to authenticate.

NTLM은 Windows 인증을 가장 단순한 형태로 구현한 것으로, 대개 인증 인프라를 추가로 구성할 필요가 없습니다. 웹 응용 프로그램을 만들거나 구성하는 경우에는 이 옵션만 선택하면 됩니다.NTLM is the simplest form of Windows authentication to implement and typically requires no additional configuration of authentication infrastructure. Simply select this option when you create or configure the web application.

Kerberos 프로토콜은 티켓 인증을 지원합니다. Kerberos 프로토콜을 사용하려면 환경을 추가로 구성해야 합니다. Kerberos 인증을 사용하도록 설정하려면 클라이언트 컴퓨터와 서버 컴퓨터에 도메인 KDC(키 배포 센터)에 대한 트러스트된 연결이 있어야 합니다. Kerberos 프로토콜을 구성하려면 SharePoint Server를 설치하기 전에 AD DS에서 SPN(서비스 사용자 이름)을 설정해야 합니다.The Kerberos protocol supports ticketing authentication. Use of the Kerberos protocol requires additional configuration of the environment. To enable Kerberos authentication, the client and server computers must have a trusted connection to the domain Key Distribution Center (KDC). Configuring the Kerberos protocol involves setting up service principal names (SPNs) in AD DS before you install SharePoint Server.

Kerberos 인증을 고려해야 하는 이유는 다음과 같습니다.The reasons why you should consider Kerberos authentication are as follows:

  • Kerberos 프로토콜은 가장 강력한 Windows 통합 인증 프로토콜이며 AES(Advanced Encryption Standard) 암호화 및 클라이언트와 서버의 상호 인증을 비롯한 고급 보안 기능을 지원합니다.The Kerberos protocol is the strongest Integrated Windows authentication protocol, and supports advanced security features including Advanced Encryption Standard (AES) encryption and mutual authentication of clients and servers.

  • Kerberos 프로토콜을 사용하는 경우 클라이언트 자격 증명을 위임할 수 있습니다.The Kerberos protocol allows for delegation of client credentials.

  • 사용 가능한 여러 보안 인증 방법 중에서 AD DS 도메인 컨트롤러에 대해 필요한 네트워크 트래픽의 양이 가장 적은 방법이 Kerberos입니다. Kerberos를 사용하면 페이지 대기 시간이 감소하는 경우도 있고, 프런트 엔드 웹 서버가 처리할 수 있는 페이지 수가 증가하는 경우도 있습니다. 또한 Kerberos는 도메인 컨트롤러에 대한 로드도 줄일 수 있습니다.Of the available secure authentication methods, Kerberos requires the least amount of network traffic to AD DS domain controllers. Kerberos can reduce page latency in certain scenarios, or increase the number of pages that a front-end web server can serve in certain scenarios. Kerberos can also reduce the load on domain controllers.

  • Kerberos 프로토콜은 다수의 플랫폼과 공급업체에서 지원하는 개방형 프로토콜입니다.The Kerberos protocol is an open protocol that many platforms and vendors support.

Kerberos 인증이 적합하지 않을 수 있는 이유는 다음과 같습니다.The reasons why Kerberos authentication might not be appropriate are as follows:

  • Kerberos 인증이 정상적으로 작동하려면 다른 인증 방법과 달리 인프라와 환경에서 추가 구성을 수행해야 합니다. 대부분의 경우에는 Kerberos 프로토콜을 구성하려면 도메인 관리자 권한이 필요합니다. Kerberos 인증은 설정 및 관리하기가 어려울 수 있습니다. Kerberos를 잘못 구성하는 경우 사이트에 올바르게 인증하지 못할 수 있습니다.Kerberos authentication requires more configuration of infrastructure and environment than other authentication methods to function correctly. In many cases, domain administrator permission is required to configure the Kerberos protocol. Kerberos authentication can be difficult to set up and manage. Misconfiguring Kerberos can prevent successful authentication to your sites.

  • Kerberos 인증을 사용하려면 클라이언트 컴퓨터를 KDC 및 AD DS 도메인 컨트롤러에 연결해야 합니다. Windows 배포에서는 KDC가 AD DS 도메인 컨트롤러입니다. 조직 인트라넷에서는 이러한 네트워크 구성이 흔히 사용되지만, 인터넷 연결 배포는 보통 이러한 방식으로 구성되지 않습니다.Kerberos authentication requires client computer connectivity to a KDC and to an AD DS domain controller. In a Windows deployment, the KDC is an AD DS domain controller. While this is a common network configuration on an organization intranet, Internet-facing deployments are typically not configured in this manner.

다음 단계에는 Kerberos 인증 구성 방법이 요약되어 있습니다.The following steps summarize configuring Kerberos authentication:

  1. AD DS에 SQL Server 서비스 계정의 SPN을 만들어 SQL Server 통신에 대해 Kerberos 인증을 구성합니다.Configure Kerberos authentication for SQL Server communications by creating SPNs in AD DS for the SQL Server service account.

  2. Kerberos 인증을 사용할 웹 응용 프로그램의 SPN을 만듭니다.Create SPNs for web applications that will use Kerberos authentication.

  3. SharePoint 서버 팜을 설치합니다.Install the SharePoint Server farm.

  4. 팜 내의 특정 서비스가 특정 계정을 사용하도록 구성합니다.Configure specific services within the farm to use specific accounts.

  5. Kerberos 인증을 사용할 웹 응용 프로그램을 만듭니다.Create the web applications that will use Kerberos authentication.

다이제스트 및 기본Digest and Basic

다이제스트 인증 방법을 사용하는 경우 사용자 계정 자격 증명이 웹 응용 프로그램이나 영역을 호스팅하는 웹 서버의 IIS(인터넷 정보 서비스) 서비스에 MD5 메시지 다이제스트로 전송됩니다. 기본 인증 방법을 사용하는 경우 사용자 계정 자격 증명은 일반 텍스트로 전송됩니다. 따라서 SSL을 사용하여 웹 사이트 트래픽을 암호화하려는 경우가 아니면 기본 인증 방법을 사용해서는 안 됩니다.With the Digest authentication method, the user account credentials are sent as an MD5 message digest to the Internet Information Services (IIS) service on the web server that hosts the web application or zone. With the Basic authentication method, the user account credentials are sent as plaintext. Therefore, you should not use the Basic authentication method unless you are also using SSL to encrypt the website traffic.

환경에서 웹 사이트에 대한 다이제스트 또는 기본 인증만 지원하는 웹 브라우저나 서비스를 사용하는 경우에는 이러한 이전 인증 방법을 사용해야 할 수 있습니다.You might have to use these older authentication methods if your environment uses web browsers or services that only support Digest or Basic authentication to websites.

NTLM, Kerberos 및 익명 인증과는 달리 다이제스트 및 기본 인증 방법은 IIS(인터넷 정보 서비스) 스냅인에서 웹 응용 프로그램 또는 영역에 해당하는 웹 사이트의 속성을 통해 구성합니다.Unlike the NTLM, Kerberos, and Anonymous authentication methods, you configure Digest and Basic authentication methods from the properties of the web site that corresponds to the web application or zone in the Internet Information Services (IIS) snap-in.

클레임 기반 인증을 사용하는 경우 다음 항목을 참조하세요.If you are using claims-based authentication, see the following:

양식 기반 인증 계획Plan for forms-based authentication

양식 기반 인증을 사용하여 외부에 있거나 Windows를 기반으로 하지 않는 ID 관리 시스템에 대해 사용자를 인증하려면 Web.config 파일에 멤버 자격 공급자 및 역할 관리자를 등록해야 합니다. SharePoint Server에서는 표준 ASP.NET 역할 관리자 인터페이스를 사용하여 현재 사용자에 대한 그룹 정보를 수집합니다. 각 ASP.NET 역할은 SharePoint Server의 권한 부여 프로세스에서 도메인 그룹으로 간주됩니다. 인증을 위해 멤버 자격 공급자를 등록하는 것과 정확히 같은 방법으로 Web.config 파일에 역할 관리자를 등록합니다.To use forms-based authentication to authenticate users against an identity management system that is not based on Windows or that is external, you must register the membership provider and role manager in the Web.config file. SharePoint Server uses the standard ASP.NET role manager interface to collect group information about the current user. Each ASP.NET role is treated as a domain group by the authorization process in SharePoint Server. You register role managers in the Web.config file exactly as you register membership providers for authentication.

중앙 관리 웹 사이트에서 멤버 자격 사용자 또는 역할을 관리하려면 멤버 자격 공급자 및 역할 관리자를 중앙 관리 웹 사이트의 Web.config 파일은 물론 콘텐츠를 호스팅하는 웹 응용 프로그램의 Web.config 파일에도 등록해야 합니다.If you want to manage membership users or roles from the Central Administration website, you must register the membership provider and the role manager in the Web.config file for the Central Administration website. You must also register the membership provider and the role manager in the Web.config file for the web application that hosts the content.

양식 기반 인증을 구성하는 자세한 단계는 SharePoint Server에서 클레임 기반 웹 응용 프로그램에 대해 양식 기반 인증 구성을 참조하세요.For detailed steps to configure forms-based authentication, see Configure forms-based authentication for a claims-based web application in SharePoint Server

SAML 토큰 기반 인증 계획Plan for SAML token-based authentication

SAML 토큰 기반 공급자를 구현하기 위한 아키텍처에는 다음 구성 요소가 포함되어 있습니다.The architecture for implementing SAML token-based providers includes the following components:

  • SharePoint Security Token Service 이 서비스에서는 팜에서 사용되는 SAML 토큰을 만듭니다. 이 서비스는 서버 팜에 있는 모든 서버에서 자동으로 만들어지고 시작됩니다. 모든 팜 간 통신에는 클레임 기반 인증이 사용되므로 이 서비스는 팜 간 통신에 사용됩니다. 또한 이 서비스는 Windows 인증, 양식 기반 인증 및 SAML 토큰 기반 인증 같은 클레임 기반 인증을 사용하는 웹 응용 프로그램에 대해 구현되는 인증 방법에도 사용됩니다.SharePoint Security Token Service This service creates the SAML tokens that the farm uses. The service is automatically created and started on all servers in a server farm. The service is used for inter-farm communication because all inter-farm communication uses claims-based authentication. This service is also used for authentication methods that are implemented for web applications that use claims-based authentication. This includes Windows authentication, forms-based authentication, and SAML token-based authentication.

  • 토큰 서명 인증서(ImportTrustCertificate) 이 인증서는 IP-STS에서 내보낸 다음 팜의 단일 서버에 복사하고 팜의 신뢰할 수 있는 루트 기관 목록에 추가하는 인증서입니다. 이 인증서를 사용하여 SPTrustedIdentityTokenIssuer를 한 번 만든 후에는 해당 인증서를 사용하여 또 다른 SPTrustedIdentityTokenIssuer를 만들 수 없습니다. 이 인증서를 사용하여 다른 SPTrustedIdentityTokenIssuer를 만들려면 먼저 기존 항목을 삭제해야 합니다. 기존 항목을 삭제하기 전에 이를 사용할 수 있는 모든 웹 응용 프로그램에서 해당 항목의 연결을 해제해야 합니다.Token-signing certificate (ImportTrustCertificate) This is the certificate that you export from an IP-STS and then copy to one server in the farm and add it to the farm's Trusted Root Authority list. Once you use this certificate to create an SPTrustedIdentityTokenIssuer, you cannot use it to create another one. To use the certificate to create a different SPTrustedIdentityTokenIssuer, you must delete the existing one first. Before you delete an existing one, you must disassociate it from all web applications that may be using it.

  • ID 클레임 ID 클레임은 사용자의 고유한 식별자에 해당하는 SAML 토큰의 클레임입니다. IP-STS의 소유자만이 토큰의 값(각 사용자에 대해 항상 고유함)을 알고 있습니다. ID 클레임은 모든 필요한 클레임을 매핑하는 동안 정규 클레임 매핑으로 만들어집니다. SPTrustedIdentityTokenIssuer가 만들어지면 ID 클레임 역할을 하는 클레임이 선언됩니다.Identity claim The identity claim is the claim from a SAML token that is the unique identifier of the user. Only the owner of the IP-STS knows which value in the token will always be unique for each user. The identity claim is created as a regular claims mapping during the mapping of all desired claims. The claim that serves as the identity claim is declared when the SPTrustedIdentityTokenIssuer is created.

  • 기타 클레임 이러한 클레임은 사용자에 대해 설명하는 SAML 티켓의 추가 클레임으로 구성되며 여기에는 사용자 역할, 사용자 그룹 또는 다른 유형의 클레임(예: 나이)이 포함될 수 있습니다. 모든 클레임 매핑은 SharePoint Server 팜의 서버 간에 복제되는 개체로 만들어집니다.Other claims These claims consist of additional claims from a SAML ticket that describe users. These can include user roles, user groups, or other kinds of claims such as age. All claims mappings are created as objects that are replicated across the servers in a SharePoint Server farm.

  • 영역 SharePoint 클레임 아키텍처에서 SAML 토큰 기반 공급자를 사용하도록 구성된 SharePoint 웹 응용 프로그램과 연결되는 URI 또는 URL은 영역을 나타냅니다. 팜에 SAML 기반 인증 공급자를 만드는 경우 IP-STS에서 인증하도록 할 영역(즉, 웹 응용 프로그램 URL)을 한 번에 하나씩 지정합니다. 첫 번째 영역은 SPTrustedIdentityTokenIssuer를 만들 때 지정됩니다. SPTrustedIdentityTokenIssuer를 만든 후 영역을 더 추가할 수 있습니다. 영역은 $realm = "urn:sharepoint:mysites" 같은 구문을 사용하여 지정합니다. SPTrustedIdentityTokenIssuer에 영역을 추가한 후에는 IP-STS 서버에서 영역 식별자와의 RP-STS 트러스트를 작성해야 하는데, 이 과정에서 웹 응용 프로그램의 URL을 지정합니다.Realm In the SharePoint claims architecture, the URI or URL that is associated with a SharePoint web application that is configured to use a SAML token-based provider represents a realm. When you create a SAML-based authentication provider on the farm, you specify the realms, or web application URLs, that you want the IP-STS to recognize, one at a time. The first realm is specified when you create the SPTrustedIdentityTokenIssuer. You can add more realms after you create the SPTrustedIdentityTokenIssuer. Realms are specified by using syntax similar to the following: $realm = "urn:sharepoint:mysites". After you add the realm to the SPTrustedIdentityTokenIssuer, you must create an RP-STS trust with the realm identifier on the IP-STS server. This process involves specifying the URL for the web application.

  • SPTrustedIdentityTokenIssuer SharePoint 팜에서 작성되는 개체로, IP-STS와 통신하고 IP-STS로부터 토큰을 수신하는 데 필요한 값을 포함합니다. SPTrustedIdentityTokenIssuer를 만들 때 사용하려는 토큰 서명 인증서, 첫 번째 영역, ID 클레임을 나타내는 클레임 및 추가 클레임을 지정합니다. STS의 토큰 서명 인증서는 하나의 SPTrustedIdentityTokenIssuer에만 연결할 수 있습니다. 하지만 SPTrustedIdentityTokenIssuer를 만든 후 추가 웹 응용 프로그램용으로 영역을 더 추가할 수 있습니다. SPTrustedIdentityTokenIssuer에 영역을 추가한 후에는 IP-STS에도 해당 영역을 신뢰 당사자로 추가해야 합니다. SPTrustedIdentityTokenIssuer 개체는 SharePoint Server 팜의 서버 간에 복제됩니다.SPTrustedIdentityTokenIssuer This is the object that is created on the SharePoint farm that includes the values necessary to communicate with and receive tokens from the IP-STS. When you create the SPTrustedIdentityTokenIssuer, you specify which token-signing certificate to use, the first realm, the claim that represents the identity claim, and any additional claims. You can only associate a token-signing certificate from an STS with one SPTrustedIdentityTokenIssuer. However, after you create the SPTrustedIdentityTokenIssuer, you can add more realms for additional web applications. After you add a realm to the SPTrustedIdentityTokenIssuer, you must also add it to the IP-STS as a relying party. The SPTrustedIdentityTokenIssuer object is replicated across servers in the SharePoint Server farm.

  • RP-STS(신뢰 당사자 Security Token Service) SharePoint Server에서는 SAML 공급자를 사용하도록 구성된 각 웹 응용 프로그램이 IP-STS 서버에 RP-STS 항목으로 추가됩니다. SharePoint Server 팜 하나에 여러 개의 RP-STS 항목이 포함될 수 있습니다.Relying party security token service (RP-STS) In SharePoint Server, each web application that is configured to use a SAML provider is added to the IP-STS server as an RP-STS entry. A SharePoint Server farm can include multiple RP-STS entries.

  • IP-STS(ID 공급자 Security Token Service) 이 서비스는 연결된 사용자 디렉터리에 포함된 사용자를 대신하여 SAML 토큰을 발급하는 클레임 환경의 Security Token Service입니다.Identity provider security token service (IP-STS) This is the secure token service in the claims environment that issues SAML tokens on behalf of users who are included in the associated user directory.

다음 다이어그램에서는 SharePoint Server SAML 토큰 클레임 아키텍처를 보여줍니다.The following diagram shows the SharePoint Server SAML token claims architecture.

SAML 토큰 클레임 아키텍처SAML token claims architecture

SharePoint 클레임 인증 구성 요소

SPTrustedIdentityTokenIssuer 개체는 다음을 비롯한 여러 매개 변수를 사용하여 만듭니다.The SPTrustedIdentityTokenIssuer object is created with several parameters, which include the following:

  • 단일 ID 클레임A single identity claim.

  • 단일 SignInURL 매개 변수A single SignInURL parameter.

    SignInURL 매개 변수는 IP-STS에 인증하기 위해 사용자 요청을 리디렉션할 URL을 지정합니다.The SignInURL parameter specifies the URL to redirect a user request to in order to authenticate to the IP-STS.

  • 단일 Wreply 매개 변수A single Wreply parameter.

    일부 IP-STS 서버에는 true 또는 false로 설정된 Wreply 매개 변수가 필요합니다. 기본값은 False입니다. IP-STS에 필요한 경우에만 Wreply 매개 변수를 사용하세요.Some IP-STS servers require the Wreply parameter, which is set to either true or false. False is the default. Use the Wreply parameter only if it is required by the IP-STS.

  • 여러 영역Multiple realms.

  • 여러 클레임 매핑Multiple claims mappings.

SharePoint Server에 대해 SAML 토큰 기반 인증을 구현하려면 다음과 같은 단계를 사전에 계획하여 수행합니다.To implement SAML token-based authentication with SharePoint Server, use the following steps which require planning in advance:

  1. IP-STS에서 토큰 서명 인증서를 내보낸 다음 SharePoint Server 팜의 서버에 복사합니다.Export the token-signing certificate from the IP-STS. Copy the certificate to a server in the SharePoint Server farm.

  2. 사용자의 고유 식별자로 사용할 ID 클레임이라는 클레임을 정의합니다. UPN(사용자 계정 이름) 또는 사용자 전자 메일 이름이 사용자 식별자로 사용되는 경우가 많습니다. IP-STS 소유자만이 사용자별로 항상 고유한 토큰의 값을 알고 있으므로 IP-STS 관리자와 협력하여 올바른 식별자를 확인해야 합니다. 사용자의 고유한 식별자를 확인하는 것은 클레임 매핑 프로세스의 일부입니다. 클레임 매핑은 Microsoft PowerShell을 사용하여 만듭니다.Define the claim that will be used as the unique identifier of the user. This is known as the identity claim. The user principal name (UPN) or user e-mail name is frequently used as the user identifier. Coordinate with the administrator of the IP-STS to determine the correct identifier because only the owner of the IP-STS knows the value in the token that will always be unique per user. Identifying the unique identifier for the user is part of the claims-mapping process. You use Microsoft PowerShell to create claims mappings.

  3. 추가 클레임 매핑을 정의합니다. SharePoint Server 팜에서 사용할 받는 토큰의 추가 클레임을 정의합니다. SharePoint Server 팜의 리소스에 대한 사용 권한을 할당하는 데 사용할 수 있는 클레임의 예로는 사용자 역할을 들 수 있습니다. 매핑이 없는 받는 토큰의 모든 클레임은 삭제됩니다.Define additional claims mappings. Define the additional claims from the incoming token that the SharePoint Server farm will use. User roles are an example of a claim that can be used to assign permissions to resources in the SharePoint Server farm. All claims from an incoming token that do not have a mapping will be discarded.

  4. PowerShell에서 새 인증 공급자를 만들어 토큰 서명 인증서를 가져옵니다. 이 프로세스를 수행하면 SPTrustedIdentityTokenIssuer가 만들어집니다. 이 프로세스를 수행하는 도중 매핑한 ID 클레임 및 추가 클레임을 지정합니다. 또한 SAML 토큰 기반 인증을 사용하도록 구성하는 첫 번째 SharePoint 웹 응용 프로그램과 연결되는 영역을 만들고 지정해야 합니다. SPTrustedIdentityTokenIssuer를 만든 후에는 추가 SharePoint 웹 응용 프로그램을 만들고 해당 응용 프로그램용으로 영역을 더 추가할 수 있습니다. 이렇게 하면 여러 웹 응용 프로그램에서 동일한 SPTrustedIdentityTokenIssuer를 사용하도록 구성됩니다.Use PowerShell to create a new authentication provider to import the token-signing certificate. This process creates the SPTrustedIdentityTokenIssuer. During this process, you specify the identity claim and additional claims that you have mapped. You must also create and specify a realm that is associated with the first SharePoint web applications that you are configuring for SAML token-based authentication. After you create the SPTrustedIdentityTokenIssuer, you can create and add more realms for additional SharePoint web applications. This is how you configure multiple web applications to use the same SPTrustedIdentityTokenIssuer.

  5. SPTrustedIdentityTokenIssuer에 추가하는 각 영역에 대해 IP-STS에 RP-STS 항목을 만들어야 합니다. 이 작업은 SharePoint 웹 응용 프로그램이 만들어지기 전에 수행할 수 있습니다. 아울러 이와 관계없이 웹 응용 프로그램을 만들기 전에 URL을 계획해야 합니다.For each realm that you add to the SPTrustedIdentityTokenIssuer, you must create an RP-STS entry on the IP-STS. You can do this before the SharePoint web application exists. Regardless, you must plan the URL before you create the web applications.

  6. 기존/신규 SharePoint 웹 응용 프로그램이 새로 만든 인증 공급자를 사용하도록 구성합니다. 인증 공급자는 웹 응용 프로그램을 만들 때 중앙 관리에 신뢰할 수 있는 ID 공급자로 표시됩니다.For an existing or new SharePoint web application, configure it to use the newly created authentication provider. The authentication provider is displayed as a trusted identity provider in Central Administration when you create a web application.

여러 SAML 토큰 기반 인증 공급자를 구성할 수 있지만 토큰 서명 인증서는 팜에서 한 번만 사용할 수 있습니다. 구성된 모든 공급자는 중앙 관리에서 옵션으로 표시됩니다. 클레임은 각기 다른 트러스트된 STS 환경에 있어도 서로 충돌하지 않습니다.You can configure multiple SAML token-based authentication providers. However, you can only use a token-signing certificate once in a farm. All configured providers are displayed as options in Central Administration. Claims from different trusted STS environments will not conflict.

파트너 회사에 대해 SAML 토큰 기반 인증을 구현하는 경우 사용자 환경에 IP-STS가 포함되어 있으면 내부 클레임 환경 관리자와 함께 내부 IP-STS에서 파트너 STS로의 단방향 트러스트 관계를 설정하는 것이 좋습니다. 이 방식을 수행하기 위해 SharePoint Server 팜에 인증 공급자를 추가할 필요는 없습니다. 또한 이 방식을 사용하면 클레임 관리자가 전체 클레임 환경을 관리할 수 있습니다.If you implement SAML token-based authentication with a partner company and your own environment includes an IP-STS, we recommend that you and the administrator of your internal claims environment establish a one-way trust relationship from your internal IP-STS to the partner STS. This approach does not require you to add an authentication provider to your SharePoint Server farm. It also enables your claims administrators to manage the whole claims environment.

중요

이제는 SharePoint Server에서 클레임 기반 인증을 사용할 때 더 이상 네트워크 부하 분산을 단일 선호도로 설정할 필요가 없습니다.You no longer have to set network load balancing to single affinity when you are using claims-based authentication in SharePoint Server.

참고

웹 응용 프로그램이 SAML 토큰 기반 인증을 사용하도록 구성된 경우 SPTrustedClaimProvider 클래스는 사용자 선택 컨트롤에 대해 검색 기능을 제공하지 않습니다. 사용자 선택 컨트롤에 입력한 텍스트는 유효한 사용자, 그룹 또는 클레임인지 여부에 관계없이 확인된 것처럼 자동으로 표시됩니다. SharePoint Server 솔루션에서 SAML 토큰 기반 인증을 사용할 예정인 경우에는 사용자 지정 검색 및 이름 확인을 구현하는 사용자 지정 클레임 공급자를 만들도록 계획하세요.When a web application is configured to use SAML token-based authentication, the SPTrustedClaimProvider class does not provide search functionality to the People Picker control. Any text entered in the People Picker control will automatically be displayed as if it resolves, regardless of whether it is a valid user, group, or claim. If your SharePoint Server solution uses SAML token-based authentication, plan to create a custom claims provider that implements custom search and name resolution.

AD FS를 사용하여 SAML 토큰 기반 인증을 구성하는 자세한 단계는 SharePoint Server에서 AD FS를 사용하여 SAML 기반 클레임 인증 구성을 참조하세요.For detailed steps to configure SAML token-based authentication using AD FS, see Configure SAML-based claims authentication with AD FS in SharePoint Server.

웹 응용 프로그램의 영역 계획Planning zones for web applications

영역은 웹 응용 프로그램의 동일한 사이트에 액세스하기 위한 각기 다른 논리적 경로를 나타냅니다. 각 웹 응용 프로그램에는 영역을 5개까지 포함할 수 있습니다. 웹 응용 프로그램을 만들면중앙 관리에서 '기본' 영역을 만듭니다. 영역을 추가로 만들려면 웹 응용 프로그램을 확장하고 나머지 영역 이름(인트라넷, 엑스트라넷, 인터넷 또는 사용자 지정) 중 하나를 선택합니다.Zones represent different logical paths to gain access to the same sites in a web application. Each web application can include as many as five zones. When you create a web application, Central Administration creates the zone named default. To create additional zones, extend the web application and select one of the remaining zone names: intranet, extranet, Internet, or custom.

영역 계획은 다음 항목에 따라 달라집니다.Your plan for zones will depend on the following:

  • 클레임 기반 인증(권장) - 한 영역에서 여러 인증 공급자를 구현할 수 있으며 여러 영역을 사용할 수도 있습니다.Claims-based authentication (recommended) — You can implement multiple authentication providers on a single zone. You can also use multiple zones.

단일 영역에서 두 개 이상의 인증 유형 구현Implementing more than one type of authentication on a single zone

클레임 기반 인증을 사용하며 둘 이상의 인증 방법을 구현하는 경우에는 기본 영역에서 여러 인증 방법을 구현하는 것이 좋습니다. 그러면 모든 사용자가 동일한 URL을 사용하게 됩니다.If you use claims-based authentication and implement more than one authentication method, we recommend that you implement multiple authentication methods on the default zone. The result is the same URL for all users.

동일한 영역에서 여러 인증 방법을 구현하는 경우에는 다음과 같은 제한이 적용됩니다.When you implement multiple authentication methods on the same zone, the following restrictions apply:

  • 영역당 하나의 양식 기반 인증 인스턴스만 구현할 수 있습니다.You can implement only one instance of forms-based authentication on a zone.

  • 중앙 관리에서는 Windows 통합 방법과 기본 인증을 동시에 사용할 수 있습니다. 이 방법 외에는 한 영역에서 둘 이상의 Windows 인증 유형을 구현할 수 없습니다.Central Administration allows you to use both an Integrated Windows method and Basic at the same time. Otherwise, you cannot implement more than one type of Windows authentication on a zone.

팜 하나에 여러 개의 SAML 토큰 기반 인증 공급자가 구성되어 있는 경우 웹 응용 프로그램이나 새 영역을 만들면 이러한 공급자가 모두 옵션으로 나타납니다. 동일한 영역에 여러 개의 SAML 공급자를 구성할 수 있습니다.If multiple SAML token-based authentication providers are configured for a farm, all appear as options when you create a web application or a new zone. You can configure multiple SAML providers on the same zone.

다음 다이어그램에서는 파트너 공동 작업 사이트의 기본 영역에 구현된 여러 인증 유형을 보여줍니다.The following diagram shows multiple types of authentication implemented on the default zone for a partner collaboration site.

기본 영역에서 구현되는 여러 인증 유형Multiple types of authentication implemented on the default zone

한 영역에 있는 여러 인증 유형

다이어그램에서는 각기 다른 디렉터리 저장소의 사용자가 동일한 URL을 사용하여 파트너 웹 사이트에 액세스합니다. 파트너 회사 주위의 파선으로 된 상자는 사용자 디렉터리와 기본 영역에 구성된 인증 유형 간의 관계를 보여 줍니다.In the diagram, users from different directory stores use the same URL to access the partner web site. The dashed box that surrounds partner companies shows the relationship between the user directory and the authentication type that is configured in the default zone.

콘텐츠 크롤링 계획Planning to crawl content

크롤링 구성 요소에서는 NTLM을 사용하여 콘텐츠에 액세스해야 합니다. 하나 이상의 영역이 NTLM 인증을 사용하도록 구성해야 합니다. NTLM 인증이 기본 영역에 구성되어 있지 않으면 크롤링 구성 요소에서는 NTLM 인증을 사용하도록 구성된 다른 영역을 사용할 수 있습니다.The crawl component requires NTLM to access content. At least one zone must be configured to use NTLM authentication. If NTLM authentication is not configured on the default zone, the crawl component can use a different zone that is configured to use NTLM authentication.

두 개 이상의 영역 구현Implement more than one zone

웹 응용 프로그램에 대해 두 개 이상의 영역을 구현하려는 경우에는 다음 지침을 따르세요.If you plan to implement more than one zone for web applications, use the following guidelines:

  • 기본 영역을 사용하여 가장 안전한 인증 설정을 구현합니다. 요청을 특정 영역과 연결할 수 없는 경우 기본 영역의 인증 설정 및 기타 보안 정책이 적용됩니다. 기본 영역은 웹 응용 프로그램을 만들 때 작성되는 영역입니다. 일반적으로 가장 안전한 인증 설정은 최종 사용자 액세스용으로 디자인됩니다. 따라서 최종 사용자는 보통 기본 영역에 액세스합니다.Use the default zone to implement your most secure authentication settings. If a request cannot be associated with a specific zone, the authentication settings and other security policies of the default zone are applied. The default zone is the zone that is created when you create a web application. Typically, the most secure authentication settings are designed for end-user access. Consequently, end-users are likely to access the default zone.

  • 사용자가 액세스할 수 있도록 하는 데 필요한 최소 영역 수만 사용합니다. 각 영역은 웹 응용 프로그램 액세스를 위해 새 IIS 사이트 및 도메인에 연결됩니다. 새 액세스 지점은 필요한 경우에만 추가하세요.Use the minimum number of zones that are required to provide access to users. Each zone is associated with a new IIS site and domain for accessing the web application. Only add new access points when they are required.

  • 하나 이상의 영역이 크롤링 구성 요소에 대해 NTLM 인증을 사용하도록 구성되어 있는지 확인합니다. 필요한 경우가 아니면 인덱스 구성 요소에 대해 전용 영역을 만들지 마세요.Ensure that at least one zone is configured to use NTLM authentication for the crawl component. Do not create a dedicated zone for the index component unless it is necessary.

다음 다이어그램에서는 파트너 공동 작업 사이트에 대한 서로 다른 인증 유형을 수용하도록 구현된 여러 개의 영역을 보여줍니다.The following diagram shows multiple zones that are implemented to accommodate different authentication types for a partner collaboration site.

인증 유형당 하나의 영역One zone per authentication type

인증 유형당 하나의 영역

이 다이어그램에서 기본 영역은 원격 직원용으로 사용됩니다. 각 영역은 서로 다른 URL과 연결되어 있습니다. 직원은 근무 장소가 사무실인지 아니면 원거리 위치인지에 따라 각기 다른 영역을 사용합니다.In the diagram, the default zone is used for remote employees. Each zone has a different URL associated with it. Employees use a different zone depending on whether they are working in the office or are working remotely.