Power BI 서비스에서 온-프레미스 데이터 원본으로 Kerberos 기반 SSO 구성

SSO를 사용하도록 설정하면 Power BI 보고서 및 대시보드가 온-프레미스 원본에 구성된 사용자 수준 권한을 준수하면서 원본의 데이터를 손쉽게 새로 고칠 수 있습니다. Kerberos 제한 위임을 사용하여 원활한 SSO 연결을 사용하도록 설정합니다.

이 문서에서는 Kerberos 기반 SSO를 Power BI 서비스 온-프레미스 데이터 원본으로 구성하기 위해 수행해야 하는 단계를 설명합니다.

필수 조건

Kerberos 제한 위임이 제대로 작동하려면 *SPN(서비스 사용자 이름) 및 서비스 계정의 위임 설정을 포함한 여러 항목을 구성해야 합니다.

참고 항목

DNS 별칭을 SSO와 함께 사용하는 기능은 지원되지 않습니다.

구성 개요

게이트웨이 Single Sign-On을 구성하는 데 필요한 단계는 아래에 설명되어 있습니다.

  1. 섹션 1: 기본 구성의 모든 단계를 완료합니다.

  2. Active Directory 환경 및 사용된 데이터 원본에 따라 섹션 2: 환경별 구성에 설명된 구성의 일부 또는 전부를 완료해야 할 수 있습니다.

    추가 구성이 필요할 수 있는 가능한 시나리오는 다음과 같습니다.

    시나리오 이동
    Active Directory 환경은 보안이 강화되었습니다. Windows Authorization 및 Access Group에 게이트웨이 서비스 계정 추가
    게이트웨이 서비스 계정 및 게이트웨이에서 가장할 사용자 계정이 별도의 도메인 또는 포리스트에 있습니다. Windows Authorization 및 Access Group에 게이트웨이 서비스 계정 추가
    사용자 계정 동기화가 구성된 Microsoft Entra 커넥트 없으며 사용자용 Power BI에서 사용되는 UPN이 로컬 Active Directory 환경의 UPN과 일치하지 않습니다. 게이트웨이 머신에서 사용자 매핑 구성 매개 변수 설정
    SSO에서 SAP HANA 데이터 원본을 사용할 계획입니다. 데이터 원본 관련 구성 단계 완료
    SSO에서 SAP BW 데이터 원본을 사용할 계획입니다. 데이터 원본 관련 구성 단계 완료
    SSO에서 Teradata 데이터 원본을 사용할 계획입니다. 데이터 원본 관련 구성 단계 완료
  3. 섹션 3: 구성 유효성 검사에 설명된 대로 구성의 유효성을 검사하여 SSO가 올바르게 설정되었는지 확인합니다.

섹션 1: 기본 구성

1단계: Microsoft 온-프레미스 데이터 게이트웨이 설치 및 구성

온-프레미스 데이터 게이트웨이는 현재 위치 업그레이드 및 기존 게이트웨이의 설정 적용을 지원합니다.

2단계: SPN(SetSPN) 및 Kerberos 제한 위임 설정을 구성하기 위한 도메인 관리자 권한 얻기

SPN 및 Kerberos 위임 설정을 구성하기 위해 도메인 관리자가 도메인 관리자 권한이 없는 사용자에게 권한을 부여하면 안 됩니다. 다음 섹션에서는 권장되는 구성 단계를 자세하게 다룹니다.

3단계: 게이트웨이 서비스 계정 구성

Microsoft Entra 커넥트 구성되고 사용자 계정이 동기화되지 않는 한 아래 옵션 A는 필수 구성입니다. 이 경우 옵션 B를 사용하는 것이 좋습니다.

옵션 A: SPN을 통해 게이트웨이 Windows 서비스를 도메인 계정으로 실행

표준 설치에서 게이트웨이는 머신-로컬 서비스 계정(NT Service\PBIEgwService)으로 실행됩니다.

컴퓨터 로컬 서비스 계정

Kerberos 제한 위임을 사용하도록 설정하려면 Microsoft Entra 인스턴스가 이미 로컬 Active Directory 인스턴스와 동기화되어 있지 않은 경우(Microsoft Entra DirSync/커넥트 사용) 게이트웨이가 do기본 계정으로 실행되어야 합니다. 도메인 계정으로 전환하려면 게이트웨이 서비스 계정 변경을 참조하세요.

게이트웨이 서비스 계정에 대해 SPN 구성

먼저 게이트웨이 서비스 계정으로 사용된 도메인 계정에 대해 SPN이 이미 생성되어 있는지 확인합니다.

  1. 도메인 관리자로, Active Directory 사용자 및 컴퓨터 MMC(Microsoft Management Console) 스냅인을 시작합니다.

  2. 왼쪽 창에서 도메인 이름을 마우스 오른쪽 단추로 클릭하고 찾기를 선택한 다음, 게이트웨이 서비스 계정의 계정 이름을 입력합니다.

  3. 검색 결과에서 게이트웨이 서비스 계정을 마우스 오른쪽 단추로 클릭하고 속성을 선택합니다.

  4. 속성 대화 상자에 위임 탭이 표시되는 경우 SPN이 이미 생성된 것이므로 Kerberos 제한 위임 구성으로 건너뛸 수 있습니다.

  5. 속성 대화 상자에 위임 탭이 없는 경우, 계정에서 SPN을 수동으로 만들어 사용하도록 설정할 수 있습니다. Windows와 함께 제공되는 setspn 도구를 사용합니다(SPN을 만드는 도메인 관리자 권한 필요).

    예를 들어 게이트웨이 서비스 계정이 Contoso\GatewaySvc이고, 게이트웨이 서비스가 MyGatewayMachine이라는 머신에서 실행되고 있다고 가정합니다. 게이트웨이 서비스 계정의 SPN을 설정하려면 다음 명령을 실행합니다.

    setspn -S gateway/MyGatewayMachine Contoso\GatewaySvc

    Active Directory 사용자 및 컴퓨터 MMC 스냅인을 사용하여 SPN을 설정할 수도 있습니다.

옵션 B: Microsoft Entra 커넥트 대한 컴퓨터 구성

Microsoft Entra 커넥트 구성되고 사용자 계정이 동기화된 경우 게이트웨이 서비스는 런타임에 로컬 Microsoft Entra 조회를 수행할 필요가 없습니다. 대신 게이트웨이 서비스에 대한 로컬 서비스 SID를 사용하여 Microsoft Entra ID에서 필요한 모든 구성을 완료할 수 있습니다. 이 문서에 설명된 Kerberos 제한 위임 구성 단계는 Microsoft Entra 컨텍스트에 필요한 구성 단계와 동일합니다. 이 개체는 do기본 계정 대신 Microsoft Entra ID에서 게이트웨이의 컴퓨터 개체(로컬 서비스 SID로 식별됨)에 적용됩니다. NT SERVICE/PBIEgwService에 대한 로컬 서비스 SID는 다음과 같습니다.

S-1-5-80-1835761534-3291552707-3889884660-1303793167-3990676079

Power BI Gateway 컴퓨터에 대해 이 SID에 대한 SPN을 만들려면 관리 명령 프롬프트에서 다음 명령을 실행해야 합니다(<COMPUTERNAME>을 Power BI Gateway 컴퓨터의 이름으로 바꿈).

SetSPN -s HTTP/S-1-5-80-1835761534-3291552707-3889884660-1303793167-3990676079 <COMPUTERNAME>

참고 항목

로컬 보안 설정에 따라 게이트웨이 서비스 계정인 NT SERVICE\PBIEgwService를 게이트웨이 머신의 로컬 관리istrators 그룹에 추가한 다음 게이트웨이 앱에서 게이트웨이 서비스를 다시 시작해야 할 수 있습니다. Active Directory는 전체 포리스트에 고유한 SPN을 적용하므로 게이트웨이가 여러 개 있는 시나리오에서는 이 옵션이 지원되지 않습니다. 이러한 시나리오의 경우 A 옵션을 대신 사용합니다.

4단계: Kerberos 제한 위임 구성

표준 Kerberos 제한 위임 또는 리소스 기반 Kerberos 제한 위임의 위임 설정을 구성할 수 있습니다. 두 가지 위임 방법의 차이점에 대한 자세한 내용은 Kerberos 제한 위임 개요를 참조하세요.

다음 서비스 계정이 필요합니다.

  • 게이트웨이 서비스 계정: 3단계에서 구성된 SPN을 사용하여 Active Directory에서 게이트웨이를 나타내는 서비스 사용자입니다.
  • 데이터 원본 서비스 계정: 데이터 원본에 매핑된 SPN을 사용하여 Active Directory에서 데이터 원본을 나타내는 서비스 사용자입니다.

참고 항목

게이트웨이 및 데이터 원본 서비스 계정은 별도로 이루어져야 합니다. 동일한 서비스 계정을 사용하여 게이트웨이와 데이터 원본을 모두 나타낼 수는 없습니다.

사용하려는 방법에 따라 다음 섹션 중 하나를 진행합니다. 두 섹션을 모두 완료하면 안 됩니다.

옵션 A: 표준 Kerberos 제한 위임

이제 게이트웨이 서비스 계정에 대한 위임 설정을 설정하겠습니다. 이러한 단계를 수행할 수 있는 여러 도구가 있습니다. 여기서는 Active Directory 사용자 및 컴퓨터 MMC 스냅인을 사용하여 디렉터리의 정보를 관리하고 게시합니다. 도메인 컨트롤러에서는 이 스냅인을 기본적으로 사용할 수 있으며, 다른 머신에서는 Windows 기능 구성을 통해 사용하도록 설정할 수 있습니다.

프로토콜 전송을 사용하여 Kerberos 제한 위임을 구성해야 합니다. 제한된 위임을 사용하여 게이트웨이가 위임된 자격 증명을 제공할 수 있도록 허용할 서비스를 명시적으로 지정해야 합니다. 예를 들어, SQL Server 또는 SAP HANA 서버만 게이트웨이 서비스 계정에서 위임 호출을 수락합니다.

이 섹션에서는 기본 데이터 원본에 대해 이미 SPN을 구성했다고 가정합니다(예: SQL Server, SAP HANA, SAP BW, Teradata 또는 Spark). 이러한 데이터 원본 서버 SPN을 구성하는 방법을 알아보려면 해당 데이터베이스 서버에 대한 기술 설명서 및 My Kerberos Checklist(내 Kerberos 검사 목록) 블로그 게시물의 ‘앱에 필요한 SPN’ 섹션을 참조하세요.

다음 단계에서는 이미 Kerberos 기반 SSO에 대해 구성된 SQL Server를 실행 중인 데이터베이스 서버와 게이트웨이 컴퓨터라는 두 컴퓨터가 동일한 도메인에 있는 온-프레미스 환경을 가정합니다. 데이터 원본이 이미 Kerberos 기반 Single Sign-On에 대해 구성된 경우에는 지원되는 다른 데이터 원본 중 하나에 대해 이 단계를 채택할 수 있습니다. 이 예제에서는 다음 설정을 사용합니다.

  • Active Directory 도메인(Netbios): Contoso
  • 게이트웨이 컴퓨터 이름: MyGatewayMachine
  • 게이트웨이 서비스 계정: Contoso\GatewaySvc
  • SQL Server 데이터 원본 컴퓨터 이름: TestSQLServer
  • SQL Server 데이터 원본 서비스 계정: Contoso\SQLService

위임 설정을 구성하는 방법은 다음과 같습니다.

  1. 도메인 관리자 권한으로 Active Directory 사용자 및 컴퓨터 MMC 스냅인을 엽니다.

  2. 게이트웨이 서비스 계정(Contoso\GatewaySvc)을 마우스 오른쪽 단추로 클릭하고 속성을 선택합니다.

  3. 위임 탭을 선택합니다.

  4. 지정한 서비스에 대한 위임용으로만 이 컴퓨터 신뢰>모든 인증 프로토콜 사용을 차례로 선택합니다.

  5. 이 계정이 위임된 자격 증명을 표시할 수 있는 서비스에서 추가를 선택합니다.

  6. 새 대화 상자에서 사용자 또는 컴퓨터를 선택합니다.

  7. 데이터 원본의 서비스 계정을 입력하고 확인을 선택합니다.

    예를 들어 SQL Server 데이터 원본에는 Contoso\SQLService와 같은 서비스 계정이 있을 수 있습니다. 이 계정에는 데이터 원본에 적절한 SPN이 이미 설정되어 있어야 합니다.

  8. 데이터베이스 서버에 대해 만든 SPN을 선택합니다.

    예제에서 SPN은 MSSQLSvc로 시작합니다. 데이터베이스 서비스에 대해 FQDN 및 NetBIOS SPN 모두를 추가한 경우 둘 다 선택합니다. 하나만 표시될 수도 있습니다.

  9. 확인을 선택합니다.

    이제 게이트웨이 서비스 계정에서 위임된 자격 증명을 제공할 수 있는 서비스 목록에 SPN이 표시됩니다.

    게이트웨이 커넥트or 속성 대화 상자

  10. 설정 프로세스를 계속하려면 게이트웨이 서비스 계정에 게이트웨이 머신에 대한 로컬 정책 권한 부여를 계속 진행합니다.

옵션 B: 리소스 기반 Kerberos 제한 위임

리소스 기반 Kerberos 제한 위임을 사용하여 Windows Server 2012 이상 버전에 대해 Single Sign-On 연결을 사용하도록 설정합니다. 이 위임 유형을 사용하면 프런트 엔드 서비스와 백 엔드 서비스가 서로 다른 도메인에 있을 수 있습니다. 제대로 작동하려면 백 엔드 서비스 도메인이 프런트 엔드 서비스 도메인을 신뢰해야 합니다.

다음 단계에서는 이미 Kerberos 기반 SSO에 대해 구성된 SQL Server를 실행 중인 데이터베이스 서버와 게이트웨이 머신이라는 두 머신이 서로 다른 도메인에 있는 온-프레미스 환경을 가정합니다. 데이터 원본에 Kerberos 기반 Single Sign-On이 이미 구성되어 있기만 하면, 다른 지원되는 데이터 원본 중 하나에서 이 단계를 수행할 수 있습니다. 이 예제에서는 다음 설정을 사용합니다.

  • Active Directory 프런트 엔드 도메인(Netbios): ContosoFrontEnd
  • Active Directory 백 엔드 도메인(Netbios): ContosoBackEnd
  • 게이트웨이 컴퓨터 이름: MyGatewayMachine
  • 게이트웨이 서비스 계정: ContosoFrontEnd\GatewaySvc
  • SQL Server 데이터 원본 컴퓨터 이름: TestSQLServer
  • SQL Server 데이터 원본 서비스 계정: ContosoBackEnd\SQLService

다음 구성 단계를 완료합니다.

  1. ContosoFrontEnd 도메인의 도메인 컨트롤러에서 Active Directory 사용자 및 컴퓨터 MMC 스냅인을 사용하고 게이트웨이 서비스 계정에 대해 위임 설정이 적용되지 않았는지 확인합니다.

    게이트웨이 커넥터 속성

  2. ContosoBackEnd 도메인의 도메인 컨트롤러에서 Active Directory 사용자 및 컴퓨터를 사용하고 백 엔드 서비스 계정에 대해 위임 설정이 적용되지 않았는지 확인합니다.

    SQL 서비스 속성

  3. 계정 속성의 특성 편집기 탭에서 msDS-AllowedToActOnBehalfOfOtherIdentity 특성이 설정되지 않았는지 확인합니다.

    SQL 서비스 특성

  4. Active Directory 사용자 및 컴퓨터에서 ContosoBackEnd 도메인의 도메인 컨트롤러에 그룹을 만듭니다. GatewaySvc 게이트웨이 서비스 계정을 ResourceDelGroup 그룹에 추가합니다.

    신뢰할 수 있는 도메인의 사용자를 추가하려면 이 그룹의 범위가 도메인 로컬이어야 합니다. 그룹 속성

  5. 명령 프롬프트를 열고 ContosoBackEnd 도메인의 도메인 컨트롤러에서 다음 명령을 실행하여 백 엔드 서비스 계정의 msDS-AllowedToActOnBehalfOfOtherIdentity 특성을 업데이트합니다.

    $c = Get-ADGroup ResourceDelGroup
    Set-ADUser SQLService -PrincipalsAllowedToDelegateToAccount $c
    
  6. Active Directory 사용자 및 컴퓨터에서 백 엔드 서비스 계정 속성의 특성 편집기 탭에 업데이트가 반영되었는지 확인합니다.

5단계: 서비스 계정에서 AES 암호화 사용

게이트웨이 서비스 계정과 게이트웨이가 위임할 수 있는 모든 데이터 원본 서비스 계정에 다음 설정을 적용합니다.

참고 항목

서비스 계정에 정의된 기존 enctype이 있는 경우 Active Directory 관리자에게 문의하세요. 아래 단계를 따르면 기존 enctypes 값을 덮어쓰고 클라이언트가 중단될 수 있기 때문입니다.

  1. 도메인 관리자 권한으로 Active Directory 사용자 및 컴퓨터 MMC 스냅인을 엽니다.

  2. 게이트웨이/데이터 원본 서비스 계정을 마우스 오른쪽 단추로 클릭하고 속성을 선택합니다.

  3. 계정 탭을 선택합니다.

  4. 계정 옵션에서 다음 옵션 중 하나 이상(또는 둘 다)을 사용하도록 설정합니다. 모든 서비스 계정에 대해 동일한 옵션을 사용하도록 설정해야 합니다.

    • 이 계정은 Kerberos AES 128비트 암호화를 지원합니다.
    • 이 계정은 Kerberos AES 256비트 암호화를 지원합니다.

참고 항목

어떤 암호화 체계를 사용해야 할지 잘 모르겠으면 Active Directory 관리자에게 문의하세요.

6단계: 게이트웨이 서비스 계정에 게이트웨이 머신에 대한 로컬 정책 권한 부여

마지막으로, 게이트웨이 서비스를 실행 중인 머신(예제에서는 MyGatewayMachine)에서 게이트웨이 서비스 계정에 로컬 정책 인증 후 클라이언트 가장운영 체제의 일부로 작동(SeTcbPrivilege)을 부여합니다. 로컬 그룹 정책 편집기(gpedit.msc)를 사용하여 이 구성을 수행합니다.

  1. 게이트웨이 머신에서 gpedit.msc를 실행합니다.

  2. 로컬 컴퓨터 정책>컴퓨터 구성>Windows 설정>보안 설정>로컬 정책>사용자 권한 할당으로 이동합니다.

    로컬 컴퓨터 정책 폴더 구조

  3. 사용자 권한 할당의 정책 목록에서 인증 후 클라이언트 가장을 선택합니다.

    클라이언트 정책 가장

  4. 정책을 마우스 오른쪽 단추로 클릭하고 속성을 연 다음, 계정 목록을 봅니다.

    목록에는 게이트웨이 서비스 계정(제한된 위임 유형에 따라 Contoso\GatewaySvc 또는 ContosoFrontEnd\GatewaySvc)이 포함되어 있어야 합니다.

  5. 사용자 권한 할당 아래의 정책 목록에서 운영 체제의 일부로 작동(SeTcbPrivilege)을 선택합니다. 게이트웨이 서비스 계정이 계정 목록에 포함되어 있는지 확인합니다.

  6. 온-프레미스 데이터 게이트웨이 서비스 프로세스를 다시 시작합니다.

7단계: Windows 계정이 게이트웨이 컴퓨터에 액세스할 수 있음

SSO는 Windows 인증을 사용하므로 Windows 계정이 게이트웨이 머신에 액세스할 수 있어야 합니다. 확실하지 않으면 로컬 머신 "사용자" 그룹에 NT-AUTHORITY\인증된 사용자(S-1-5-11)를 추가합니다.

섹션 2: 환경별 구성

Windows Authorization 및 Access Group에 게이트웨이 서비스 계정 추가

다음 상황이 적용되는 경우 이 섹션을 완료합니다.

  • Active Directory 환경은 보안이 강화되었습니다.
  • 게이트웨이 서비스 계정 및 게이트웨이에서 가장할 사용자 계정이 별도의 도메인 또는 포리스트에 있는 경우

도메인/포리스트가 강화되지 않은 상황에도 Windows Authorization and Access Group에 게이트웨이 서비스 계정을 추가할 수 있지만 반드시 필요한 것은 아닙니다.

자세한 내용은 Windows Authorization and Access Group을 참조하세요.

이 구성 단계를 완료하려면 게이트웨이 서비스 계정이 가장할 수 있는 Active Directory 사용자를 포함하는 각 도메인에 대해 다음을 수행합니다.

  1. 도메인의 컴퓨터에 로그인하고 Active Directory 사용자 및 컴퓨터 MMC 스냅인을 시작합니다.
  2. Windows Authorization and Access Group 그룹을 찾습니다(일반적으로 Builtin 컨테이너에 있음).
  3. 그룹을 두 번 클릭하고 구성원 탭을 클릭합니다.
  4. 추가를 클릭하고 도메인 위치를 게이트웨이 서비스 계정이 있는 도메인으로 변경합니다.
  5. 게이트웨이 서비스 계정 이름을 입력하고 이름 확인을 클릭하여 이 게이트웨이 서비스 계정에 액세스할 수 있는지 확인합니다.
  6. 확인을 클릭합니다.
  7. 적용을 클릭합니다.
  8. 게이트웨이 서비스를 다시 시작합니다.

게이트웨이 머신에서 사용자 매핑 구성 매개 변수 설정

다음과 같은 경우 이 섹션을 완료합니다.

  • 사용자 계정 동기화가 구성된 Microsoft Entra 커넥트 AND가 없습니다.
  • 사용자용 Power BI에서 사용되는 UPN이 로컬 Active Directory 환경의 UPN과 일치하지 않습니다.

이러한 방식으로 매핑된 각 Active Directory 사용자는 데이터 원본에 대한 SSO 권한이 있어야 합니다.

  1. 기본 게이트웨이 구성 파일 Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll을 엽니다. 기본적으로 이 파일은 C:\Program Files\On-premises data gateway에 저장됩니다.

  2. ADUserNameLookupProperty를 사용하지 않는 Active Directory 특성으로 설정합니다. 이후 단계에서는 msDS-cloudExtensionAttribute1을 사용합니다. 이 특성은 Windows Server 2012 이상에서만 사용할 수 있습니다.

  3. ADUserNameReplacementPropertySAMAccountName으로 설정하고 구성 파일을 저장합니다.

    참고 항목

    다중 도메인 시나리오에서는 사용자의 도메인 정보를 유지하려면 ADUserNameReplacementPropertyuserPrincipalName으로 설정해야 할 수 있습니다.

  4. 작업 관리자의 서비스 탭에서 게이트웨이 서비스를 마우스 오른쪽 단추로 클릭하고 다시 시작을 선택합니다.

    작업 관리자 서비스 탭의 스크린샷

  5. Kerberos SSO를 사용하도록 설정할 각 Power BI 서비스 사용자에 대해 로컬 Active Directory 사용자(데이터 원본에 대한 SSO 권한 포함)의 msDS-cloudExtensionAttribute1 속성을 Power BI 서비스 사용자의 전체 사용자 이름(UPN)으로 설정합니다. 예를 들어 Power BI 서비스에 test@contoso.com으로 로그인하고 이 사용자를 SSO 권한이 있는 로컬 Active Directory 사용자(예: test@LOCALDOMAIN.COM)로 매핑하려면, 이 사용자의 msDS-cloudExtensionAttribute1 특성을 test@contoso.com으로 설정합니다.

    Active Directory 사용자 및 컴퓨터 MMC 스냅인을 사용하여 msDS-cloudExtensionAttribute1 속성을 설정할 수 있습니다.

    1. 도메인 관리자로 Active Directory 사용자 및 컴퓨터를 시작합니다.

    2. 도메인 이름을 마우스 오른쪽 단추로 클릭하고 찾기를 선택한 다음, 매핑할 로컬 Active Directory 사용자의 계정 이름을 입력합니다.

    3. 특성 편집기 탭을 선택합니다.

      msDS-cloudExtensionAttribute1 속성을 찾아 두 번 클릭합니다. Power BI 서비스에 로그인하는 데 사용할 사용자의 전체 사용자 이름(UPN)으로 값을 설정합니다.

    4. 확인을 선택합니다.

      문자열 특성 편집기 창

    5. 적용을 선택합니다. 열에 올바른 값이 설정되었는지 확인합니다.

데이터 원본 관련 구성 단계 완료

SAP HANA, SAP BW 및 Teradata 데이터 원본의 경우 게이트웨이 SSO와 함께 사용하려면 추가 구성이 필요합니다.

참고 항목

다른 SNC 라이브러리도 BW SSO에 사용할 수 있지만 Microsoft에서 공식적으로 지원하지는 않습니다.

섹션 3: 구성 유효성 검사

1단계: Power BI에서 데이터 원본 구성

모든 구성 단계를 완료한 후에는 Power BI의 게이트웨이 관리 페이지를 사용하여 SSO에 사용할 데이터 원본을 구성할 수 있습니다. 게이트웨이가 여러 개인 경우 Kerberos SSO에 대해 구성한 게이트웨이를 선택해야 합니다. 그런 다음, 데이터 원본의 설정에서 DirectQuery 기반 보고서의 경우 DirectQuery 쿼리에 Kerberos를 통한 SSO 사용 또는 DirectQuery를 위해 Kerberos를 통한 SSO 사용 및 쿼리 가져오기가 선택되고, 가져오기 기반 보고서의 경우 DirectQuery를 위해 Kerberos를 통한 SSO 사용 및 쿼리 가져오기가 선택되어 있는지 확인합니다.

 Single Sign-On에 대한 설정 추가 스크린샷.

DirectQuery 쿼리에 대해 Kerberos를 통한 SSO 옵션 사용DirectQuery 및 가져오기 쿼리에 대해 Kerberos를 통한 SSO 옵션 사용 설정은 DirectQuery 기반 보고서 및 가져오기 기반 보고서에 대해 서로 다른 동작을 제공합니다.

DirectQuery 쿼리에 대해 Kerberos를 통한 SSO 옵션 사용:

  • DirectQuery 기반 보고서의 경우 사용자의 SSO 자격 증명을 사용합니다.
  • 가져오기 기반 보고서의 경우 SSO 자격 증명을 사용하지 않고, 사용한 데이터 원본 페이지에 입력한 자격 증명을 사용합니다.

DirectQuery 및 가져오기 쿼리에 대해 Kerberos를 통한 SSO 옵션 사용:

  • DirectQuery 기반 보고서의 경우 사용자의 SSO 자격 증명을 사용합니다.
  • 가져오기 기반 보고서의 경우 가져오기를 실행한 사용자와 상관없이 의미 체계 모델 소유자의 SSO 자격 증명을 사용합니다.

2단계: Single Sign-On 테스트

SSO(Single Sign-On) 구성 테스트로 이동하여 구성이 올바르게 설정되었는지 신속하게 확인하고 일반적인 문제를 해결합니다.

3단계: Power BI 보고서 실행

게시할 때 여러 게이트웨이가 있는 경우 SSO에 대해 구성한 게이트웨이를 선택합니다.

온-프레미스 데이터 게이트웨이 및 DirectQuery에 대한 자세한 내용은 다음 리소스를 참조하세요.