Azure Files ID 기반 인증 및 권한 부여 문제 해결(SMB)

  • 아티클

이 문서에서는 ID 기반 인증과 함께 SMB Azure 파일 공유를 사용할 때 발생하는 일반적인 문제를 나열합니다. 또한 이러한 문제에 대한 가능한 원인과 해결 방법도 제공합니다. ID 기반 인증은 현재 NFS Azure 파일 공유에 대해 지원되지 않습니다.

적용 대상

파일 공유 형식 SMB Nfs
표준 파일 공유(GPv2), LRS/ZRS
표준 파일 공유(GPv2), GRS/GZRS
프리미엄 파일 공유(FileStorage), LRS/ZRS

AzFilesHybrid 모듈을 실행할 때 오류 발생

AzFilesHybrid 모듈을 실행하려고 하면 다음 오류가 발생할 수 있습니다.

필요한 권한은 클라이언트에서 보유하지 않습니다.

원인: AD 권한이 부족합니다.

이 문제는 모듈을 실행하는 데 필요한 AD(Active Directory) 권한이 없기 때문에 발생합니다.

해결 방법

필요한 권한을 제공하려면 AD 권한을 참조하거나 AD 관리자에게 문의하세요.

Azure 파일 공유를 탑재할 때 오류 5

파일 공유를 탑재하려고 하면 다음 오류가 발생할 수 있습니다.

시스템 오류 5가 발생했습니다. 액세스가 거부되었습니다.

원인: 공유 수준 권한이 잘못되었습니다.

최종 사용자가 Active Directory Domain Services(AD DS) 또는 Microsoft Entra Domain Services 인증을 사용하여 Azure 파일 공유에 액세스하는 경우 공유 수준 권한이 올바르지 않으면 "액세스 거부됨" 오류와 함께 파일 공유에 대한 액세스가 실패합니다.

참고

이 오류는 잘못된 공유 수준 권한 이외의 문제로 인해 발생할 수 있습니다. 다른 가능한 원인 및 솔루션에 대한 자세한 내용은 Azure Files 연결 및 액세스 문제 해결을 참조하세요.

해결 방법

권한이 올바르게 구성되었는지 확인합니다.

  • Active Directory Domain Services(AD DS)는 공유 수준 권한 할당을 참조하세요.

    공유 수준 권한 할당은 Microsoft Entra Connect Sync 또는 Microsoft Entra Connect 클라우드 동기화를 사용하여 AD DS에서 Microsoft Entra ID 동기화된 그룹 및 사용자에 대해 지원됩니다. 공유 수준 권한이 할당된 그룹 및 사용자가 지원되지 않는 "클라우드 전용" 그룹이 아닌지 확인합니다.

  • Microsoft Entra Domain Services공유 수준 권한 할당을 참조하세요.

"테넌트 ID Microsoft Entra tenant-id를 사용하여 활성 테넌트를 찾을 수 없음" Azure Files 대해 Microsoft Entra Domain Services 인증을 사용하도록 설정하는 동안 AadDsTenantNotFound 오류가 발생했습니다.

원인

오류 AadDsTenantNotFound는 Microsoft Entra Microsoft Entra Domain Services 만들어지지 않은 스토리지 계정에서 Azure Files 대해 Microsoft Entra Domain Services 인증을 사용하도록 설정하려고 할 때 발생합니다. 연결된 구독의 테넌트입니다.

해결 방법

스토리지 계정이 배포된 구독의 Microsoft Entra 테넌트에서 Microsoft Entra Domain Services 사용하도록 설정합니다. 관리되는 도메인을 만들려면 Microsoft Entra 테넌트 관리자 권한이 필요합니다. Microsoft Entra 테넌트의 관리자가 아닌 경우 관리자에게 문의하고 단계별 지침에 따라 Microsoft Entra Domain Services 관리되는 도메인을 만들고 구성합니다.

AD 자격 증명을 사용하여 Azure 파일 공유를 탑재할 수 없음

자체 진단 단계

먼저 Azure Files AD DS 인증을 사용하도록 설정하는 단계를 수행했는지 확인합니다.

둘째, 스토리지 계정 키를 사용하여 Azure 파일 공유를 탑재해 보세요. 공유가 탑재되지 않으면 AzFileDiagnostics 를 다운로드하여 클라이언트 실행 환경의 유효성을 검사합니다. AzFileDiagnostics는 Azure Files 대한 액세스 실패를 일으킬 수 있는 호환되지 않는 클라이언트 구성을 검색하고, 자체 수정에 대한 규범적인 지침을 제공하고, 진단 추적을 수집할 수 있습니다.

셋째, cmdlet을 Debug-AzStorageAccountAuth 실행하여 로그온한 AD 사용자를 사용하여 AD 구성에 대한 기본 검사 집합을 수행할 수 있습니다. 이 cmdlet은 AzFilesHybrid v0.1.2 이상 버전에서 지원됩니다. 대상 스토리지 계정에 대한 소유자 권한이 있는 AD 사용자와 함께 이 cmdlet을 실행해야 합니다.

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Debug-AzStorageAccountAuth `
    -StorageAccountName $StorageAccountName `
    -ResourceGroupName $ResourceGroupName `
    -Verbose

cmdlet은 이러한 검사를 순서대로 수행하고 실패에 대한 지침을 제공합니다.

  1. CheckADObjectPasswordIsCorrect: 스토리지 계정을 나타내는 AD ID에 구성된 암호가 스토리지 계정 kerb1 또는 kerb2 키와 일치하는지 확인합니다. 암호가 올바르지 않으면 Update-AzStorageAccountADObjectPassword 를 실행하여 암호를 재설정할 수 있습니다.
  2. CheckADObject: Active Directory에 스토리지 계정을 나타내고 올바른 SPN(서비스 주체 이름)이 있는 개체가 있는지 확인합니다. SPN이 올바르게 설정되지 않은 경우 디버그 cmdlet에 반환된 cmdlet을 실행 Set-AD 하여 SPN을 구성합니다.
  3. CheckDomainJoined: 클라이언트 컴퓨터가 AD에 가입된 도메인인지 확인합니다. 컴퓨터가 AD에 도메인에 가입되지 않은 경우 도메인 가입 지침은 도메인에 컴퓨터 조인 을 참조하세요.
  4. CheckPort445Connectivity: SMB 연결에 대해 포트 445가 열려 있는지 확인합니다. 포트 445가 열려 있지 않으면 문제 해결 도구 AzFileDiagnostics에서 Azure Files 연결 문제를 참조하세요.
  5. CheckSidHasAadUser: 로그온한 AD 사용자가 Microsoft Entra ID 동기화되어 있는지 확인합니다. 특정 AD 사용자가 Microsoft Entra ID 동기화되는지 여부를 조회하려는 경우 입력 매개 변수에서 및 -Domain 를 지정할 -UserName 수 있습니다. 지정된 SID의 경우 연결된 Microsoft Entra 사용자가 있는지 확인합니다.
  6. CheckAadUserHasSid: 로그온한 AD 사용자가 Microsoft Entra ID 동기화되어 있는지 확인합니다. 특정 AD 사용자가 Microsoft Entra ID 동기화되는지 여부를 조회하려는 경우 입력 매개 변수에서 및 -Domain 를 지정할 -UserName 수 있습니다. 지정된 Microsoft Entra 사용자의 경우 해당 SID를 확인합니다. 이 검사 실행하려면 매개 변수와 -ObjectId Microsoft Entra 사용자의 개체 ID를 제공해야 합니다.
  7. CheckGetKerberosTicket: 스토리지 계정에 연결하기 위해 Kerberos 티켓을 가져오려고 시도합니다. 유효한 Kerberos 토큰이 없는 경우 cmdlet을 klist get cifs/storage-account-name.file.core.windows.net 실행하고 오류 코드를 검사하여 티켓 검색 실패의 원인을 확인합니다.
  8. CheckStorageAccountDomainJoined: AD 인증이 사용하도록 설정되어 있고 계정의 AD 속성이 채워져 있는지 확인합니다. 그렇지 않은 경우 Azure Files AD DS 인증을 사용하도록 설정합니다.
  9. CheckUserRbacAssignment: AD ID에 Azure Files 액세스하기 위한 공유 수준 권한을 제공하는 적절한 RBAC 역할 할당이 있는지 확인합니다. 그렇지 않은 경우 공유 수준 권한을 구성합니다. (AzFilesHybrid v0.2.3 이상 버전에서 지원됨)
  10. CheckUserFileAccess: AD ID에 Azure Files 액세스할 수 있는 적절한 디렉터리/파일 권한(Windows ACL)이 있는지 확인합니다. 그렇지 않은 경우 디렉터리/파일 수준 권한을 구성합니다. 이 검사 실행하려면 액세스를 디버그하려는 탑재된 파일의 경로와 함께 매개 변수를 제공해야 -FilePath 합니다. (AzFilesHybrid v0.2.3 이상 버전에서 지원됨)
  11. CheckAadKerberosRegistryKeyIsOff: Microsoft Entra Kerberos 레지스트리 키가 꺼져 있는지 확인합니다. 키가 켜진 경우 관리자 권한 명령 프롬프트에서 를 실행 reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 0 하여 끄고 컴퓨터를 다시 부팅합니다. (AzFilesHybrid v0.2.9 이상 버전에서 지원됨)

이전 검사의 하위 선택을 실행하려는 경우 매개 변수와 쉼표로 구분된 검사 목록을 사용하여 -Filter 실행할 수 있습니다. 예를 들어 RBAC(공유 수준 권한)와 관련된 모든 검사를 실행하려면 다음 PowerShell cmdlet을 사용합니다.

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Debug-AzStorageAccountAuth `
    -Filter CheckSidHasAadUser,CheckUserRbacAssignment `
    -StorageAccountName $StorageAccountName `
    -ResourceGroupName $ResourceGroupName `
    -Verbose

에 파일 공유가 탑재되어 X:있고 파일 수준 권한(Windows ACL)과 관련된 검사 실행하려는 경우 다음 PowerShell cmdlet을 실행할 수 있습니다.

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"
$FilePath = "X:\example.txt"

Debug-AzStorageAccountAuth `
    -Filter CheckUserFileAccess `
    -StorageAccountName $StorageAccountName `
    -ResourceGroupName $ResourceGroupName `
    -FilePath $FilePath `
    -Verbose

Windows 파일 탐색기 디렉터리/Windows ACL(파일 수준 권한)을 구성할 수 없음

증상

탑재된 파일 공유에서 파일 탐색기 사용하여 Windows ACL을 구성하려고 할 때 아래에 설명된 증상 중 하나가 발생할 수 있습니다.

  • 보안 탭에서 권한 편집 을 클릭하면 권한 마법사가 로드되지 않습니다.
  • 새 사용자 또는 그룹을 선택하려고 하면 도메인 위치에 올바른 AD DS 도메인이 표시되지 않습니다.
  • 여러 AD 포리스트를 사용하고 있으며 다음과 같은 오류 메시지가 표시됩니다. "다음 도메인에서 선택한 개체를 찾는 데 필요한 Active Directory 도메인 컨트롤러를 사용할 수 없습니다. Active Directory 도메인 컨트롤러를 사용할 수 있는지 확인하고 개체를 다시 선택하세요."

해결 방법

Windows 파일 탐색기 사용하는 대신 icacls를 사용하여 디렉터리/파일 수준 권한을 구성하는 것이 좋습니다.

Join-AzStorageAccountForAuth cmdlet을 실행할 때 발생하는 오류

오류: "디렉터리 서비스에서 상대 식별자를 할당할 수 없습니다."

이 오류는 RID 마스터 FSMO 역할을 보유하는 도메인 컨트롤러를 사용할 수 없거나 도메인에서 제거되어 백업에서 복원된 경우에 발생할 수 있습니다. 모든 도메인 컨트롤러가 실행 중이고 사용 가능한지 확인합니다.

오류: "이름이 지정되지 않아 위치 매개 변수를 바인딩할 수 없습니다."

이 오류는 명령의 구문 오류에 Join-AzStorageAccountforAuth 의해 트리거될 가능성이 높습니다. 명령에서 맞춤법 오류 또는 구문 오류를 확인하고 최신 버전의 AzFilesHybrid 모듈(https://github.com/Azure-Samples/azure-files-samples/releases)이 설치되어 있는지 확인합니다.

AES-256 Kerberos 암호화에 대한 온-프레미스 AD DS 인증 지원 Azure Files

Azure Files AzFilesHybrid 모듈 v0.2.2부터 AD DS 인증을 위한 AES-256 Kerberos 암호화를 지원합니다. AES-256은 권장되는 암호화 방법이며 AzFilesHybrid 모듈 v0.2.5부터 시작하는 기본 암호화 방법입니다. 모듈 버전이 v0.2.2보다 낮은 AD DS 인증을 사용하도록 설정한 경우 최신 AzFilesHybrid 모듈을 다운로드 하고 아래 PowerShell을 실행해야 합니다. 스토리지 계정에서 아직 AD DS 인증을 사용하도록 설정하지 않은 경우 이 지침을 따르세요.

중요

이전에 RC4 암호화를 사용하고 AES-256을 사용하도록 스토리지 계정을 업데이트한 경우 클라이언트에서 를 실행 klist purge 한 다음 파일 공유를 다시 탑재하여 AES-256으로 새 Kerberos 티켓을 가져와야 합니다.

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Update-AzStorageAccountAuthForAES256 -ResourceGroupName $ResourceGroupName -StorageAccountName $StorageAccountName

업데이트의 일부로 cmdlet은 AES-256으로 전환하는 데 필요한 Kerberos 키를 회전합니다. 두 암호를 모두 다시 생성하려는 경우가 아니면 다시 회전할 필요가 없습니다.

이전에 소유자 또는 기여자 역할 할당이 있는 사용자 ID에는 여전히 스토리지 계정 키 액세스 권한이 있습니다.

스토리지 계정 소유자 및 기여자 역할은 스토리지 계정 키를 나열하는 기능을 부여합니다. 스토리지 계정 키를 사용하면 파일 공유, Blob 컨테이너, 테이블 및 큐를 비롯한 스토리지 계정의 데이터에 대한 전체 액세스와 FileREST API를 통해 노출된 레거시 관리 API를 통해 Azure Files 관리 작업에 대한 제한된 액세스를 사용할 수 있습니다. 역할 할당을 변경하는 경우 소유자 또는 기여자 역할에서 제거되는 사용자가 저장된 스토리지 계정 키를 통해 스토리지 계정에 대한 액세스를 계속 유지할 수 있음을 고려해야 합니다.

해결 방법 1

스토리지 계정 키를 회전하여 이 문제를 쉽게 해결할 수 있습니다. 키를 한 번에 하나씩 회전하고, 회전할 때 한 키에서 다른 키로 액세스를 전환하는 것이 좋습니다. 스토리지 계정에서 제공하는 공유 키에는 스토리지 계정의 데이터에 대한 슈퍼 관리자 액세스를 제공하는 스토리지 계정 키와 스토리지 계정과 Windows Server Active Directory 도메인 컨트롤러 간의 공유 비밀로 작동하는 Kerberos 키의 두 가지 유형이 있습니다Windows Server Active Directory 시나리오.

스토리지 계정의 Kerberos 키를 회전하려면 AD DS에서 스토리지 계정 ID의 암호 업데이트를 참조하세요.

Azure Portal 원하는 스토리지 계정으로 이동합니다. 원하는 스토리지 계정에 대한 목차의 보안 + 네트워킹 제목 아래에서 액세스 키를 선택합니다. 액세스 키 창에서 원하는 키 위에 있는 키 회전을 선택합니다.

'액세스 키' 창을 보여 주는 스크린샷

새로 만든 애플리케이션에 대한 API 권한 설정

Microsoft Entra Kerberos 인증을 사용하도록 설정한 후에는 구성을 완료하려면 Microsoft Entra 테넌트에서 등록된 새 Microsoft Entra 애플리케이션에 관리자 동의를 명시적으로 부여해야 합니다. 다음 단계에 따라 Azure Portal API 권한을 구성할 수 있습니다.

  1. Microsoft Entra ID 엽니다.
  2. 왼쪽 창에서 앱 등록 선택합니다.
  3. 오른쪽 창에서 모든 애플리케이션 을 선택합니다.
  4. 이름이 [Storage 계정] $storageAccountName.file.core.windows.net 일치하는 애플리케이션을 선택합니다.
  5. 왼쪽 창에서 API 권한을 선택합니다.
  6. 페이지 아래쪽에서 권한 추가 를 선택합니다.
  7. "DirectoryName"에 대한 관리자 동의 부여를 선택합니다.

하이브리드 사용자에 Microsoft Entra Kerberos 인증을 사용하도록 설정할 때 발생할 수 있는 오류

하이브리드 사용자 계정에 Microsoft Entra Kerberos 인증을 사용하도록 설정할 때 다음과 같은 오류가 발생할 수 있습니다.

오류 - 관리자 동의 허용 사용 안 함

경우에 따라 Microsoft Entra 관리자가 Microsoft Entra 애플리케이션에 대한 관리자 동의를 부여하는 기능을 사용하지 않도록 설정할 수 있습니다. 다음은 Azure Portal 어떻게 생겼는지에 대한 스크린샷입니다.

사용 권한으로 인해 일부 작업을 사용하지 않도록 설정할 수 있다는 경고를 표시하는 '구성된 권한' 블레이드를 보여 주는 스크린샷

이 경우 Microsoft Entra 관리자에게 새 Microsoft Entra 애플리케이션에 대한 관리자 동의를 부여하도록 요청합니다. 관리자를 찾아 보려면 역할 및 관리자를 선택한 다음 클라우드 애플리케이션 관리자를 선택합니다.

오류 - "코드 BadRequest로 Azure AD Graph에 대한 요청이 실패했습니다."

원인 1: 애플리케이션 관리 정책으로 인해 자격 증명이 생성되지 않습니다.

Microsoft Entra Kerberos 인증을 사용하도록 설정할 때 다음 조건이 충족되면 이 오류가 발생할 수 있습니다.

  1. 애플리케이션 관리 정책의 베타/미리 보기 기능을 사용하고 있습니다.
  2. 사용자(또는 관리자)가 다음과 같은 테넌트 전체 정책을 설정했습니다.
    • 시작 날짜가 없거나 2019년 1월 1일 이전의 시작 날짜가 있습니다.
    • 사용자 지정 암호를 허용하지 않거나 최대 암호 수명을 365.5일 미만으로 설정하는 서비스 주체 암호에 대한 제한을 설정합니다.

현재 이 오류에 대한 해결 방법은 없습니다.

원인 2: 스토리지 계정에 대한 애플리케이션이 이미 있음

이전에 수동 제한된 미리 보기 단계를 통해 Kerberos 인증을 Microsoft Entra 사용하도록 설정한 경우에도 이 오류가 발생할 수 있습니다. 기존 애플리케이션을 삭제하려면 고객 또는 IT 관리자가 다음 스크립트를 실행할 수 있습니다. 이 스크립트를 실행하면 수동으로 만든 이전 애플리케이션이 제거되고 새 환경이 새로 만든 애플리케이션을 자동으로 만들고 관리할 수 있습니다. Microsoft Graph에 대한 연결을 시작한 후 디바이스에서 Microsoft Graph 명령줄 도구 애플리케이션에 로그인하고 앱에 권한을 부여합니다.

$storageAccount = "exampleStorageAccountName"
$tenantId = "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"
Install-Module Microsoft.Graph
Import-Module Microsoft.Graph
Connect-MgGraph -TenantId $tenantId -Scopes "User.Read","Application.Read.All"

$application = Get-MgApplication -Filter "DisplayName eq '${storageAccount}'"
if ($null -ne $application) {
   Remove-MgApplication -ObjectId $application.ObjectId
}

오류 - Microsoft Entra ID 서비스 주체 암호가 만료되었습니다.

이전에 수동 제한된 미리 보기 단계를 통해 Kerberos 인증을 Microsoft Entra 사용하도록 설정한 경우 스토리지 계정의 서비스 주체에 대한 암호는 6개월마다 만료되도록 설정됩니다. 암호가 만료되면 사용자는 파일 공유에 대한 Kerberos 티켓을 가져올 수 없습니다.

이를 완화하려면 6개월마다 Microsoft Entra 서비스 주체 암호를 회전하거나, 다음 단계에 따라 Microsoft Entra Kerberos를 사용하지 않도록 설정하고, 기존 애플리케이션을 삭제하고, Microsoft Entra Kerberos를 다시 구성하는 두 가지 옵션이 있습니다.

Windows 파일 탐색기 사용하여 디렉터리 및 파일 수준 권한을 구성하려는 경우 재구성하는 동안 필요하므로 Microsoft Entra Kerberos를 사용하지 않도록 설정하기 전에 도메인 속성(domainName 및 domainGUID)을 저장해야 합니다. 도메인 속성을 저장하지 않은 경우에도 해결 방법으로 icacls를 사용하여 디렉터리/파일 수준 권한을 구성할 수 있습니다.

  1. Microsoft Entra Kerberos 사용 안 함
  2. 기존 애플리케이션 삭제
  3. Azure Portal 통해 Microsoft Entra Kerberos 다시 구성

Kerberos를 Microsoft Entra 다시 구성하면 새 환경이 새로 만든 애플리케이션을 자동으로 만들고 관리합니다.

오류 1326 - 프라이빗 링크를 사용할 때 사용자 이름 또는 암호가 잘못되었습니다.

Microsoft Entra Kerberos 인증을 사용하여 프라이빗 엔드포인트/프라이빗 링크를 통해 스토리지 계정에 연결하는 경우 또는 다른 방법을 통해 net use 파일 공유를 탑재하려고 할 때 클라이언트에 자격 증명을 묻는 메시지가 표시됩니다. 사용자가 자격 증명을 입력할 가능성이 높지만 자격 증명은 거부됩니다.

원인

이는 SMB 클라이언트가 Kerberos를 사용하려고 했지만 실패했기 때문에 NTLM 인증 사용으로 돌아가고 Azure Files 도메인 자격 증명에 NTLM 인증 사용을 지원하지 않기 때문입니다. 프라이빗 링크 FQDN이 기존 Microsoft Entra 애플리케이션에 등록되지 않았기 때문에 클라이언트는 스토리지 계정에 대한 Kerberos 티켓을 가져올 수 없습니다.

해결 방법

솔루션은 파일 공유를 탑재하기 전에 스토리지 계정의 Microsoft Entra 애플리케이션에 privateLink FQDN을 추가하는 것입니다. 다음 단계에 따라 Azure Portal 사용하여 애플리케이션 개체에 필요한 identifierUris를 추가할 수 있습니다.

  1. Microsoft Entra ID 엽니다.

  2. 왼쪽 창에서 앱 등록 선택합니다.

  3. 모든 애플리케이션을 선택합니다.

  4. 이름이 [Storage 계정] $storageAccountName.file.core.windows.net 일치하는 애플리케이션을 선택합니다.

  5. 왼쪽 창에서 매니페스트 를 선택합니다.

  6. 중복 복사본이 있도록 기존 콘텐츠를 복사하여 붙여넣습니다.

  7. JSON 매니페스트를 편집합니다. 모든 <storageAccount>.file.core.windows.net 항목에 대해 해당 <storageAccount>.privatelink.file.core.windows.net 항목을 추가합니다. instance 경우 매니페스트에 에 대한 다음 값이 있는 경우 입니다identifierUris.

    "identifierUris": [
    "api://<tenantId>/HOST/<storageaccount>.file.core.windows.net",
    "api://<tenantId>/CIFS/<storageaccount>.file.core.windows.net",
    "api://<tenantId>/HTTP/<storageaccount>.file.core.windows.net",
    "HOST/<storageaccount>.file.core.windows.net",
    "CIFS/<storageaccount>.file.core.windows.net",
    "HTTP/<storageaccount>.file.core.windows.net"
],

    그런 다음 필드를 다음으로 편집 identifierUris 해야 합니다.

    "identifierUris": [
    "api://<tenantId>/HOST/<storageaccount>.file.core.windows.net",
    "api://<tenantId>/CIFS/<storageaccount>.file.core.windows.net",
    "api://<tenantId>/HTTP/<storageaccount>.file.core.windows.net",
    "HOST/<storageaccount>.file.core.windows.net",
    "CIFS/<storageaccount>.file.core.windows.net",
    "HTTP/<storageaccount>.file.core.windows.net",

    "api://<tenantId>/HOST/<storageaccount>.privatelink.file.core.windows.net",
    "api://<tenantId>/CIFS/<storageaccount>.privatelink.file.core.windows.net",
    "api://<tenantId>/HTTP/<storageaccount>.privatelink.file.core.windows.net",
    "HOST/<storageaccount>.privatelink.file.core.windows.net",
    "CIFS/<storageaccount>.privatelink.file.core.windows.net",
    "HTTP/<storageaccount>.privatelink.file.core.windows.net"
],

  8. 콘텐츠를 검토하고 저장 을 선택하여 애플리케이션 개체를 새 identifierUris로 업데이트합니다.

  9. 프라이빗 링크를 가리키도록 내부 DNS 참조를 업데이트합니다.

  10. 공유 탑재를 다시 시도합니다.

오류 AADSTS50105

다음 오류 AADSTS50105 요청이 중단되었습니다.

관리자가 애플리케이션에 대한 액세스 권한을 특별히 부여(할당)하지 않는 한 사용자를 차단하도록 애플리케이션 "엔터프라이즈 애플리케이션 이름"을 구성했습니다. 로그인한 사용자 '{EmailHidden}'은 액세스 권한이 있는 그룹의 직접 구성원이 아니거나 관리자가 직접 할당한 액세스 권한이 없기 때문에 차단됩니다. 이 애플리케이션에 대한 액세스 권한을 할당하려면 관리자에게 문의하세요.

원인

해당 엔터프라이즈 애플리케이션에 대해 "할당 필요"를 설정한 경우 Kerberos 티켓을 가져올 수 없으며, Microsoft Entra 로그인 로그는 사용자 또는 그룹이 애플리케이션에 할당된 경우에도 오류를 표시합니다.

해결 방법

요청자에게 다시 반환되는 Kerberos 티켓의 자격을 채우지 않으므로 스토리지 계정에 대한 Microsoft Entra 애플리케이션에 필요한 할당을 선택하지 마세요. 자세한 내용은 오류 AADSTS50105 - 로그인한 사용자가 애플리케이션의 역할에 할당되지 않음을 참조하세요.

참고 항목

도움을 요청하십시오.

질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.