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

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

적용 대상

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

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

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

클라이언트에 필수 권한이 없습니다.

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

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

솔루션

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

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

파일 공유를 탑재하려고 하면 다음 오류가 표시될 수 있습니다.

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

원인: 공유 수준 권한이 잘못됨

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

참고 항목

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

솔루션

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

• AD DS(Active Directory 도메인 서비스)는 공유 수준 권한 할당을 참조하세요.

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

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

Azure 파일에 대한 Microsoft Entra Domain Services 인증 사용 설정 시 AadDsTenantNotFound 오류 "테넌트 ID Microsoft Entra tenant-id로 활성 테넌트를 찾을 수 없음"

원인

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

솔루션

스토리지 계정이 배포된 구독의 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에서 반환된 Set-AD cmdlet을 실행하여 SPN을 구성합니다.
3. CheckDomainJoined: 클라이언트 컴퓨터가 AD에 가입된 도메인인지 확인합니다. 컴퓨터가 AD에 도메인에 가입되어 있지 않은 경우 도메인 가입 지침은 컴퓨터를 도메인 에 가입하는 방법을 참조하세요.
4. CheckPort445Connectivity: 포트 445가 SMB 연결에 대해 열려 있는지 확인합니다. 포트 445가 열려 있지 않으면 Azure Files의 연결 문제에 대한 문제 해결 도구 AzFileDiagnostics 를 참조하세요.
5. CheckSidHasAadUser: 로그온한 AD 사용자가 Microsoft Entra ID와 동기화되었는지 확인합니다. 특정 AD 사용자가 Microsoft Entra ID와 동기화되는지 여부를 조회하려는 경우 입력 매개 변수에서 -UserName -Domain 지정할 수 있습니다. 지정된 SID의 경우 연결된 Microsoft Entra 사용자가 있는지 확인합니다.
6. CheckAadUserHasSid: 로그온한 AD 사용자가 Microsoft Entra ID와 동기화되었는지 확인합니다. 특정 AD 사용자가 Microsoft Entra ID와 동기화되는지 여부를 조회하려는 경우 입력 매개 변수에서 -UserName -Domain 지정할 수 있습니다. 지정된 Microsoft Entra 사용자의 경우 해당 SID를 확인합니다. 이 검사를 실행하려면 Microsoft Entra 사용자의 개체 ID와 함께 매개 변수를 제공해야 -ObjectId 합니다.
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

Microsoft Entra Kerberos를 사용하여 Azure 파일 공유를 탑재할 수 없음

자체 진단 단계

먼저 Microsoft Entra Kerberos 인증을 사용하도록 설정하는 단계를 수행했는지 확인합니다.

둘째, cmdlet을 Debug-AzStorageAccountAuth 실행하여 기본 검사 집합을 수행할 수 있습니다. 이 cmdlet은 AzFilesHybrid v0.3.0 이상 버전에서 Microsoft Entra Kerberos 인증에 대해 구성된 스토리지 계정에 대해 지원됩니다.

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

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

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

1. CheckPort445Connectivity: 포트 445가 SMB 연결에 대해 열려 있는지 확인합니다. 포트 445가 열려 있지 않으면 Azure Files의 연결 문제에 대한 문제 해결 도구 AzFileDiagnostics 를 사용합니다.
2. CheckAADConnectivity: Entra 연결을 확인합니다. 클라이언트가 Entra에 연결할 수 없는 경우 Kerberos 인증을 사용하는 SMB 탑재가 실패할 수 있습니다. 이 검사에 실패하면 네트워킹 오류(방화벽 또는 VPN 문제)가 있음을 나타냅니다.
3. CheckEntraObject: Entra에 스토리지 계정을 나타내고 올바른 SPN(서비스 사용자 이름)이 있는 개체가 있는지 확인합니다. SPN이 올바르게 설정되지 않은 경우 스토리지 계정에서 Entra Kerberos 인증을 사용하지 않도록 설정하고 다시 사용하도록 설정합니다.
4. CheckRegKey: 레지스트리 키가 사용하도록 설정되어 있는지 CloudKerberosTicketRetrieval 확인합니다. 이 레지스트리 키는 Entra Kerberos 인증에 필요합니다.
5. CheckRealmMap: 사용자가 계정을 다른 Kerberos KERBEROS.MICROSOFTONLINE.COM영역에 조인하는 영역 매핑을 구성했는지 확인합니다.
6. CheckAdminConsent: Kerberos 티켓을 가져오는 데 필요한 Microsoft Graph 권한에 대한 관리자 동의가 Entra 서비스 주체에 부여되었는지 확인합니다.
7. CheckWinHttpAutoProxySvc: Microsoft Entra Kerberos 인증에 필요한 WinHTTP 웹 프록시 자동 검색 서비스(WinHttpAutoProxySvc)를 확인합니다. 해당 상태는 .로 Running설정해야 합니다.
8. CheckIpHlpScv: Microsoft Entra Kerberos 인증에 필요한 IP 도우미 서비스(iphlpsvc)를 확인합니다. 해당 상태는 .로 Running설정해야 합니다.
9. CheckFiddlerProxy: Microsoft Entra Kerberos 인증을 방지하는 Fiddler 프록시가 있는지 확인합니다.
10. CheckEntraJoinType: 컴퓨터가 Entra 도메인에 가입되어 있는지 또는 하이브리드 Entra 도메인에 가입되어 있는지 확인합니다. Microsoft Entra Kerberos 인증을 위한 필수 구성 요소입니다.

이전 검사의 하위 선택을 실행하려는 경우 쉼표로 구분된 검사 목록과 함께 매개 변수를 사용하여 -Filter 실행할 수 있습니다.

Windows 파일 탐색기를 사용하여 디렉터리/파일 수준 권한(Windows ACL)을 구성할 수 없습니다.

증상

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

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

솔루션

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

파일 탐색기 파일/디렉터리 소유자의 UPN(UserPrincipalName)을 볼 수 없습니다.

증상

파일 탐색기 파일/디렉터리 소유자의 SID(보안 식별자)를 표시하지만 UPN은 표시하지 않습니다.

원인

파일 탐색기는 RPC API를 서버(Azure Files)에 직접 호출하여 SID를 UPN으로 변환합니다. Azure Files는 이 API를 지원하지 않으므로 UPN이 표시되지 않습니다.

솔루션

도메인에 가입된 클라이언트에서 다음 PowerShell 명령을 사용하여 UPN을 포함하여 디렉터리와 해당 소유자의 모든 항목을 봅니다.

Get-ChildItem <Path> | Get-ACL | Select Path, Owner

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

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

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

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

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

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

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 인증을 사용하도록 설정하지 않은 경우 이 지침에 따라 설정합니다.

Important

이전에 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

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

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

포털

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

PowerShell

다음 스크립트는 스토리지 계정에 대한 두 키를 모두 회전합니다. 회전하는 동안 키를 교환하려면 스크립트에 추가 논리를 제공해 이 시나리오를 처리해야 합니다. <resource-group> 및 <storage-account>를 사용자 환경에 적합한 값으로 바꿔야 합니다.

$resourceGroupName = "<resource-group>"
$storageAccountName = "<storage-account>"

# Rotate primary key (key 1). You should switch to key 2 before rotating key 1.
New-AzStorageAccountKey `
    -ResourceGroupName $resourceGroupName `
    -Name $storageAccountName `
    -KeyName "key1"

# Rotate secondary key (key 2). You should switch to the new key 1 before rotating key 2.
New-AzStorageAccountKey `
    -ResourceGroupName $resourceGroupName `
    -Name $storageAccountName `
    -KeyName "key2"

Azure CLI

다음 스크립트는 스토리지 계정에 대한 두 키를 모두 회전합니다. 회전하는 동안 키를 교환하려면 스크립트에 추가 논리를 제공해 이 시나리오를 처리해야 합니다. <resource-group> 및 <storage-account>를 사용자 환경에 적합한 값으로 바꿔야 합니다.

RESOURCE_GROUP_NAME="<resource-group>"
STORAGE_ACCOUNT_NAME="<storage-account>"

# Rotate primary key (key 1). You should switch to key 2 before rotating key 1.
az storage account keys renew \
    --resource-group $RESOURCE_GROUP_NAME \
    --account-name $STORAGE_ACCOUNT_NAME \
    --key "primary"

# Rotate secondary key (key 2). You should switch to the new key 1 before rotating key 2.
az storage account keys renew \
    --resource-group $RESOURCE_GROUP_NAME \
    --account-name $STORAGE_ACCOUNT_NAME \
    --key "secondary"

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

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

1. Microsoft Entra ID를 엽니다.
2. 왼쪽 창에서 앱 등록을 선택합니다.
3. 오른쪽 창에서 모든 애플리케이션을 선택합니다.
4. 이름이 [Storage Account] $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: 스토리지 계정에 대한 애플리케이션이 이미 있습니다.

이전에 수동 제한된 미리 보기 단계를 통해 Microsoft Entra Kerberos 인증을 사용하도록 설정한 경우에도 이 오류가 발생할 수 있습니다. 기존 애플리케이션을 삭제하려면 고객 또는 해당 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에서 서비스 주체 암호가 만료되었습니다.

이전에 수동 제한된 미리 보기 단계를 통해 Microsoft Entra Kerberos 인증을 사용하도록 설정한 경우 스토리지 계정의 서비스 주체에 대한 암호는 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 다시 구성

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

오류 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 Account] $storageAccountName.file.core.windows.net과 일치하는 애플리케이션을 선택합니다.

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

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

7. JSON 매니페스트를 편집합니다. 모든 <storageAccount>.file.core.windows.net 항목에 대해 해당 <storageAccount>.privatelink.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"
   ],
   

   그런 다음 필드를 다음으로 편집 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 Files 성능 문제 해결
• Azure Files 연결 문제 해결(SMB)
• Linux에서 일반적인 Azure Files SMB 문제 해결
• Linux에서 일반적인 Azure Files NFS 문제 해결
• Azure 파일 동기화 문제 해결

도움을 요청하십시오.

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