FSLogix 클라우드 전용 및 외부 ID: AVD 설정 가이드

Azure Virtual Desktop 사용자가 FSLogix 프로필을 로드할 수 있도록 하기 위해서만 존재하는 도메인 컨트롤러를 폐기하기를 기다리고 있었다면, 그 장애물은 사라졌습니다. 2026년 5월부터 클라우드 전용 및 외부 ID용 FSLogix 프로필 컨테이너가 일반 공급(GA)되었고, 전체 스택을 Microsoft Entra 조인 세션 호스트, Microsoft Entra Kerberos로 인증되는 Azure Files, 그리고 Active Directory 계정을 한 번도 가져본 적 없는 사용자로 구성할 수 있습니다. GA 발표가 나왔을 때 그 발표가 의미하는 것을 정리했습니다. 이 가이드는 실제로 구축하려는 팀에 지금 제가 건네는 단계별 절차로, 사람들이 넘어지는 부분인 앱 매니페스트 태그, icacls를 쓸 수 없을 때의 디렉터리 권한 모델, 조건부 액세스 제외까지 포함합니다. 아래의 모든 설정 경로와 값은 2026년 10월 기준 Microsoft Learn에서 가져온 것입니다.

AVD 세션 호스트의 ID 모델

Azure Virtual Desktop에서 세션 호스트를 조인하는 실질적인 방법은 네 가지이며, ID 모델이 FSLogix가 무엇에 대해 인증할 수 있는지를 결정합니다. Microsoft의 ID 및 인증 문서는 AD DS에만 존재하는 사용자는 전혀 지원되지 않는다고 명시합니다. 모든 AVD 사용자는 Microsoft Entra ID를 통해 검색 가능해야 합니다.

역사적으로 문제는 네 번째 행이었습니다. Entra 조인 호스트는 수년간 지원되었지만 FSLogix가 SMB 공유를 탑재하려면 Kerberos 티켓이 필요했고, 이를 발급할 수 있는 것은 AD DS 또는 Entra Domain Services만이었습니다. Entra Kerberos는 먼저 하이브리드 ID에 대해 이 간극을 메웠는데, Entra ID가 동기화된 온-프레미스 계정을 대신해 티켓을 발급할 수 있었기 때문입니다. 클라우드 전용 계정은 뒤를 받쳐줄 온-프레미스 계정이 없었으므로 로컬 또는 임시 프로필만 받았습니다.

클라우드 전용 FSLogix의 의미

Microsoft Entra Kerberos는 테넌트를 Kerberos 키 배포 센터(KDC)로 바꿉니다. 사용자가 Entra 조인 디바이스에 로그인하면 Entra ID는 기본 새로 고침 토큰(PRT)을 발급하고, 그와 함께 영역 KERBEROS.MICROSOFTONLINE.COM에 대한 클라우드 TGT(Ticket Granting Ticket)를 발급합니다. Azure Files에 액세스하는 클라우드 전용 사용자에 대해 Entra Kerberos 개요는 흐름을 이렇게 설명합니다. SMB 클라이언트가 cifs/<storageaccount>.file.core.windows.net에 대한 서비스 티켓을 요청하고, Entra Kerberos가 클라우드 TGT에서 사용자 ID와 그룹 클레임이 포함된 티켓을 발급하고, Azure Files가 이를 검증합니다. 온-프레미스 KDC는 전혀 관여하지 않습니다.

지원 대화에서는 타임라인이 중요합니다.

• 2025년 9월: AVD의 외부 ID 지원이 미리 보기로 들어왔고, FSLogix는 명시적으로 제외되었습니다.
• 2025년 11월: 외부 ID가 GA되었고, 클라우드 전용 및 외부 ID용 FSLogix가 미리 보기로 들어왔습니다.
• 2026년 5월: 클라우드 전용 및 외부 ID용 FSLogix 지원이 일반 공급되었습니다. AVD 새로운 기능 항목에는 이 기능이 “기존 FSLogix 버전에 이미 기본 제공된다"고 적혀 있습니다.

마지막 문장이 제가 가장 자주 받는 질문의 답입니다. 클라우드 전용 지원을 도입한 FSLogix 빌드 번호는 없습니다. 이를 가능하게 한 작업은 Entra Kerberos, Azure Files, Windows에서 이루어졌습니다. Microsoft의 릴리스 정보는 최신 버전 실행을 요구하며, 현재 릴리스인 FSLogix 26.08(3.26.826.17182, 2026년 8월 31일 게시)은 특히 한 가지 기능 때문에 설치할 가치가 있습니다. 세션 중과 VHD 재연결 시 사용자의 클라우드 Kerberos 티켓을 백그라운드에서 새로 고치는 것입니다. Microsoft는 이것이 10시간 티켓 수명을 바꾸지는 않는다고 언급하지만, 장시간 세션 후 로그아웃이 필요했던 스토리지 액세스 실패를 완화합니다.

외부 ID 지원이 다루는 범위와 한계

외부 ID는 인력 테넌트에 초대하는 B2B 사용자입니다. FSLogix 관점에서 Azure Files Entra Kerberos 문서가 경계를 정합니다. 외부 ID에 대한 Azure Files SMB 지원은 Azure Virtual Desktop의 FSLogix 시나리오로 제한되고, 퍼블릭 클라우드 테넌트에 초대된 사용자에게 적용되며, 크로스 클라우드 사용자(Azure Government 또는 21Vianet에서 초대된 사용자)는 제외되고, 정부 클라우드에서는 지원되지 않습니다. Entra Kerberos는 크로스 테넌트 액세스도 지원하지 않습니다. 인증하는 것은 여러분 테넌트의 게스트 개체입니다. 외부 ID는 세션 안에서 Kerberos나 NTLM으로 온-프레미스 리소스에 인증할 수 없고, 게스트에 할당된 Intune 디바이스 구성 정책은 적용되지 않습니다. 대신 디바이스에 할당합니다.

필수 조건

이 표에서 두 가지 세부 사항이 사람들을 걸려 넘어지게 합니다. 클라우드 전용 지원은 퍼블릭 클라우드 전용입니다. 하이브리드 방식은 Azure Government와 21Vianet에서 작동하지만 클라우드 전용은 그렇지 않습니다. 그리고 외부 ID의 OS 기준은 클라우드 전용 기준과 다릅니다. 게스트가 풀을 공유한다면 이미지를 고르기 전에 두 목록을 모두 확인하세요.

1단계: 스토리지 계정과 파일 공유

스토리지 계정과 프로필용 SMB 파일 공유를 만듭니다. FSLogix 방법 문서의 한 가지 규칙은 타협할 수 없습니다. 스토리지 계정은 Entra ID와 AD DS 또는 Entra Domain Services 같은 두 번째 방법으로 동시에 인증할 수 없습니다. AD DS에 조인되어 있던 계정을 재사용한다면 먼저 ID 원본을 변경하고, 온-프레미스 SID를 기준으로 작성된 기존 ACL을 검토하세요.

프로필 공유는 별도의 스토리지 계정에 두세요. 2단계의 조건부 액세스 제외는 전체 계정을 나타내는 앱에 적용되므로, 범용 데이터가 그 예외에 묻어가기를 원하지 않을 것입니다.

2단계: 스토리지 계정에서 Microsoft Entra Kerberos 사용

Azure Portal에서 스토리지 계정을 열고 Data storage > Classic file shares를 선택하고, Identity-based access 옆의 상태를 선택하고, Microsoft Entra Kerberos 아래에서 Set up을 선택하고, Microsoft Entra Kerberos 확인란을 선택한 뒤 Save를 누릅니다. 도메인 이름과 GUID 필드는 건너뜁니다. 이 필드는 파일 탐색기로 ACL을 편집하려는 하이브리드 ID용이며, 클라우드 전용 ID에서는 어차피 지원되지 않습니다.

Set-AzStorageAccount -ResourceGroupName <resourceGroupName> -StorageAccountName <storageAccountName> -EnableAzureActiveDirectoryKerberosForFile $true

az storage account update --name <storageaccountname> --resource-group <resourcegroupname> --enable-files-aadkerb true

이 기능을 사용하도록 설정하면 [Storage Account] .file.core.windows.net이라는 앱 등록이 자동으로 생성됩니다. 이 앱에 세 가지 작업이 반드시 필요하며, 하나라도 빠뜨리면 프로필이 조용히 로컬로 대체됩니다.

관리자 동의 부여. Microsoft Entra ID > App registrations > All Applications에서 스토리지 앱을 열고 API permissions를 선택한 뒤, 요청된 세 가지 권한(openid, profile, User.Read)에 대해 Grant admin consent for [Directory Name] 옵션을 선택합니다. 이 서비스 주체에서 다른 것은 변경하지 마세요. Microsoft는 문서화된 범위를 넘는 편집이 앱을 손상시킬 수 있다고 말합니다.

클라우드 그룹 태그 추가. Kerberos 티켓은 최대 1,010개의 그룹 SID를 담을 수 있고, 클라우드 전용 지원으로 인해 티켓에 클라우드 그룹 SID도 포함되어야 합니다. Microsoft는 이 단계를 클라우드 전용 ID에 필수로 표시합니다. 앱의 Manifest를 열고 tags 배열을 찾아 "kdc_enable_cloud_group_sids"를 추가한 뒤 저장합니다. 또는 Graph PowerShell로 수행합니다.

Connect-MgGraph -Scopes "Application.ReadWrite.All" -TenantId <tenantId>
Update-MgApplication -ApplicationId "<AppObjectId>" -Tags @("kdc_enable_cloud_group_sids")

유효 멤버 자격이 여전히 1,010개 SID를 초과하는 사용자는 서비스 티켓 시점에 로그인 로그 오류 140011 KerberosUsersGroupNumberExceeded로 실패합니다. 해결책은 해당 계정의 중첩 및 동적 멤버 자격을 줄이는 것입니다.

앱을 MFA에서 제외. Entra Kerberos에는 프로필 로드 중 단계 인증 프롬프트를 처리할 사용자 인터페이스가 없습니다. MFA를 요구하고 모든 리소스를 대상으로 하는 모든 조건부 액세스 정책은 스토리지 앱을 제외해야 합니다. 이를 놓치면 공유 탑재 시 “System error 1327: Account restrictions are preventing this user from signing in.“이 반환됩니다. 애플리케이션 관리 정책도 확인하세요. 대칭 키 추가를 차단하거나 키 수명을 366일 미만으로 제한하는 정책에는 Storage Resource Provider 서비스(앱 ID a6aa9161-5291-40bb-8c5c-923b567bee3b)에 대한 예외가 필요하며, 그렇지 않으면 Entra Kerberos 사용 설정이 Graph의 BadRequest로 실패합니다.

프라이빗 엔드포인트를 통해 공유에 접근한다면 <storageaccount>.privatelink.file.core.windows.net 항목을 앱의 identifierUris에 추가하세요. 그렇지 않으면 클라이언트가 NTLM으로 대체되어 오류 1326으로 실패합니다.

3단계: 공유 수준 RBAC

공유 수준 액세스는 Azure RBAC이며, 클라우드 전용 ID에 대해 Microsoft는 특정 RBAC 역할 할당이 Entra Kerberos에서만 지원되고 모든 퍼블릭 지역에서 가능하다고 문서화합니다. 관련 기본 제공 역할은 다음과 같습니다.

FSLogix 스토리지 권한 지침은 기본 공유 수준 권한을 모든 인증된 ID에 대해 Storage File Data SMB Share Contributor로 설정하고, 관리자 그룹에는 ACL을 관리할 수 있도록 Storage File Data SMB Share Elevated Contributor를 부여하라고 권장합니다. 포털에서는 Classic file shares > Identity-based access > Step 2: Set share-level permissions > Enable permissions for all authenticated users and groups입니다. 명시적 할당을 선호한다면 역할 범위를 공유로 한정합니다.

$scope = "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>/fileServices/default/fileshares/<share-name>"
New-AzRoleAssignment -SignInName <user-principal-name> -RoleDefinitionName "Storage File Data SMB Share Contributor" -Scope $scope

역할 할당은 보통 30분 이내에 전파됩니다. 기본 권한과 명시적 할당이 모두 적용되면 더 높은 권한이 우선합니다.

4단계: NTFS 도구 없는 디렉터리 권한

여기가 클라우드 전용 방식이 AVD 관리자가 알고 있는 것과 가장 다른 부분입니다. 디렉터리 및 파일 수준 권한 문서에는 도구 매트릭스가 있으며, 클라우드 전용 ID의 Microsoft Entra Kerberos에서는 Windows 파일 탐색기와 icacls 모두 지원되지 않는 것으로 표시됩니다. 두 가지 선택지는 Azure Portal과 RestSetAcls PowerShell 모듈이며, 둘 다 도메인 컨트롤러가 필요하지 않습니다.

포털에서 파일 공유를 열고 Browse를 선택한 뒤 상단 메뉴의 Manage access로 루트 ACL을 설정하거나, 디렉터리를 마우스 오른쪽 단추로 클릭하고 Manage access를 선택합니다. FSLogix 방법 문서는 이 탭을 클라우드 전용 및 외부 ID 사용자에게 권장되는 옵션이라고 부릅니다. 거부는 항상 허용보다 우선하고, 상속 가능한 변경은 이후 항목에만 적용되므로 첫 사용자가 로그인하기 전에 루트 ACL을 설정하세요.

PowerShell에서 문서화된 패턴은 다음과 같습니다.

Install-Module RestSetAcls
$context = New-AzStorageContext -StorageAccountName "<storage-account-name>" -StorageAccountKey "<storage-account-key>"
Add-AzFileAce -Context $context -FileShareName <share-name> -FilePath "/" -Type Allow -Principal "testUser@contoso.com" -AccessRights Read,Synchronize -InheritanceFlags ObjectInherit,ContainerInherit

권한 모델 자체는 다른 FSLogix 공유와 다르지 않습니다. Microsoft가 권장하는 ACL은 CREATOR OWNER에 하위 폴더 및 파일에만 수정, 관리자 그룹에 이 폴더, 하위 폴더 및 파일에 모든 권한, 사용자 그룹에 이 폴더에만 수정입니다. 새 Azure 파일 공유 루트에는 이미 NT AUTHORITY\Authenticated Users에 상속되는 수정 권한과 CREATOR OWNER에 자식 개체에 대한 모든 권한이 부여되어 있어 권장 모델보다 느슨하지만 파일럿에는 작동합니다. 공유 수준 RBAC와 Windows ACL은 둘 다 적용되고 더 제한적인 쪽이 우선하므로, 공유 수준에서 Reader인 사용자는 폴더에 모든 권한이 있어도 쓸 수 없습니다.

도구 없이 프로필 폴더 생성 시점에 ACL을 설정해야 한다면, FSLogix의 SIDDirSDDL 설정은 %sid% 자리 표시자가 포함된 SDDL 문자열을 받아 사용자 디렉터리 생성 시 적용합니다.

5단계: 세션 호스트 구성

모든 세션 호스트에서 세 가지 레지스트리 영역을 설정합니다. Windows가 클라우드 Kerberos 티켓을 가져올 수 있어야 하고, Entra 자격 증명 키가 프로필과 함께 로밍해야 하며, FSLogix가 공유를 가리켜야 합니다. 이를 이미지에 포함하거나 Intune으로 배포합니다.

클라우드 Kerberos 티켓 검색. Intune 설정 카탈로그의 Kerberos > CloudKerberosTicketRetrievalEnabled 설정을 Enabled로 지정합니다. Microsoft는 사용자 지정 OMA-URI 대신 설정 카탈로그를 사용하라고 명시하는데, OMA-URI 방식은 다중 세션 호스트에서 작동하지 않기 때문입니다. 그룹 정책 대응 항목은 Administrative Templates > System > Kerberos > Allow retrieving the Azure AD Kerberos Ticket Granting Ticket during logon입니다(이전 빌드에서는 “Allow retrieving the cloud kerberos ticket during the logon"으로 표시). 레지스트리 형식은 다음과 같습니다.

reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1

다시 시작 또는 정책 새로 고침이 필요합니다. 설정 후에는 호스트 이름-영역 매핑을 추가하지 않으면 호스트가 AD DS 인증을 사용하는 스토리지 계정에 더 이상 접근할 수 없습니다. 둘 다 운영한다면 각 AD DS 계정에 대해 Define host name-to-Kerberos realm mappings 또는 ksetup /addhosttorealmmap <storageaccount>.file.core.windows.net <REALM>을 구성합니다.

자격 증명 키 로밍. 자격 증명 관리자 키가 사용자가 처음 접촉한 호스트가 아니라 로드되는 프로필에 속하도록 합니다.

reg add HKLM\Software\Policies\Microsoft\AzureADAccount /v LoadCredKeyFromProfile /t REG_DWORD /d 1

FSLogix 설정. HKLM\SOFTWARE\FSLogix\Profiles 아래에서 Microsoft의 프로필 컨테이너 구성 지침은 다음과 같습니다.

$VHDLocations = "\\<storage-account>.file.core.windows.net\<share>"
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name Enabled -PropertyType dword -Value 1 -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name VHDLocations -PropertyType string -Value $VHDLocations -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name DeleteLocalProfileWhenVHDShouldApply -PropertyType dword -Value 1 -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name FlipFlopProfileDirectoryName -PropertyType dword -Value 1 -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name VolumeType -PropertyType string -Value vhdx -Force

RoamIdentity는 기본값 0으로 둡니다. Microsoft는 레거시 ID 로밍을 권장하지 않으며, 26.01 릴리스는 Entra 디바이스 ID 지침에 맞춰 기본 ID 제외 항목을 업데이트했습니다. 로깅은 HKLM\SOFTWARE\FSLogix\Logging 아래에 있으며, LoggingEnabled의 기본값은 2(모든 로그 사용), LogFileKeepingPeriod의 기본값은 2일이고, 저는 파일럿 중에 이 값을 늘립니다.

6단계: 호스트 풀 RDP 속성과 Single Sign-On

클라우드 전용 사용자는 사용자 이름과 암호로 Entra 조인 호스트에 로그인할 수 있지만, 외부 ID에는 Single Sign-On이 필수이며, SSO는 모두에게 올바른 기본값입니다. 암호 없는 인증과 타사 페더레이션을 세션까지 이어주기 때문입니다. SSO 구성에는 다섯 가지 작업이 있습니다.

1. Windows Cloud Login 서비스 주체(앱 ID 270efc09-cd0d-444b-a71f-39af4910ec45)에서 RDP용 Entra 인증을 사용하도록 설정합니다. 포털에서는 Microsoft Entra ID > Devices > Remote connection configuration > Windows Cloud Login으로 이동한 뒤 Entra ID 인증 프로토콜을 사용하도록 설정합니다. PowerShell에서는 해당 remoteDesktopSecurityConfiguration의 isRemoteDesktopProtocolEnabled를 true로 설정합니다.
2. Target device groups to enable SSO 아래에 세션 호스트의 동적 디바이스 그룹(최대 10개)을 추가하여 동의 프롬프트를 숨깁니다. 이것이 없으면 사용자는 연결 허용을 요청받고, Entra는 15개 호스트를 30일간 기억합니다.
3. AD DS가 환경의 일부인 경우에만 Kerberos 서버 개체를 만듭니다. 순수한 클라우드 전용 구성에는 AD DS가 없으므로 이 단계는 해당되지 않습니다.
4. 조건부 액세스를 검토합니다(7단계).
5. 호스트 풀에서 RDP 속성 Microsoft Entra single sign-on을 Connections will use Microsoft Entra authentication to provide single sign-on으로 설정합니다. PowerShell에서는 enablerdsaadauth:i:1입니다.

RDP 속성 참조는 enablerdsaadauth(기본값 0)를 targetisaadjoined의 대체 속성으로 문서화합니다. 이전 targetisaadjoined:i:1은 Windows 이외 클라이언트와 Entra 조인, 하이브리드 조인, 등록 중 어느 것도 되지 않은 Windows 디바이스를 위해 여전히 존재하지만, 연결을 사용자 이름과 암호로 제한하므로 암호 없는 인증과 외부 ID를 배제합니다. 이전 배포에서 설정해 두었다면 SSO를 사용하도록 설정할 때 제거하세요.

세션 호스트 구성이 없는 호스트 풀에서는 애플리케이션 그룹에 할당한 것과 동일한 사용자 그룹에 리소스 그룹 수준에서 Virtual Machine User Login 역할도 할당해야 합니다. 그렇지 않으면 사용자가 브로커에는 인증되지만 VM에서 거부됩니다. 세션 호스트 구성을 사용하는 호스트 풀에는 이 할당이 필요하지 않습니다.

7단계: 조건부 액세스 고려 사항

Microsoft의 AVD용 MFA 지침은 이제 하나가 아닌 두 개의 정렬된 정책을 권장합니다. 정책 1은 피드와 게이트웨이 인증을 위해 Azure Virtual Desktop 앱(9cdead84-a844-4324-93f2-b2e6bb768d07)을 대상으로 하고, 정책 2는 세션 호스트 로그인을 위해 Windows Cloud Login을 대상으로 합니다. 둘 다 MFA를 요구하며, Every time 로그인 빈도는 Windows Cloud Login에서만 지원됩니다. 빈도가 일치하지 않으면 세션 중간에 프롬프트가 발생합니다.

클라우드 전용 FSLogix 풀에서는 제외가 포함만큼 중요합니다.

• [Storage Account] .file.core.windows.net을 모든 MFA 정책에서 제외합니다(2단계).
• Azure Virtual Desktop Azure Resource Manager Provider 앱(50e95039-b200-4007-bc97-8d5790743a63)은 절대 정책에 추가하지 마세요. 피드 검색 전용입니다.
• Windows 365 앱(0af06dc6-e4b5-4f28-818e-e78e62d137a5)을 차단하지 마세요. Windows App은 AVD 전용 사용자라도 이 앱에 인증합니다.
• 모든 리소스에 대해 디바이스 규정 준수를 요구하는 정책을 확인하세요. Entra 조인 세션 호스트는 사용자 엔드포인트용으로 작성된 규정 준수 정책을 충족하지 못할 수 있습니다.
• AVD 사용자의 레거시 사용자별 MFA를 사용하지 않도록 설정합니다. 조건부 액세스와 함께 사용하도록 설정되어 있으면 Entra 조인 호스트가 “The sign-in method you’re trying to use isn’t allowed"를 반환합니다.
• Windows Hello for Business 같은 강력한 방법으로 로그인을 제한하지 않는다면, Entra 조인 호스트 문서에 설명된 대로 Azure Windows VM Sign-In 앱을 제외합니다.

조건부 액세스에는 Entra ID P1 또는 P2가 필요하며 보안 기본값과 공존할 수 없습니다. 이곳은 2026년 5월의 기본 암호 없는 인증 변경과 교차하는 지점이기도 합니다. Entra ID 기본 암호 없는 인증과 거버넌스 통합에서 이를 다뤘으며, SSO가 설정된 Entra 조인 AVD 풀이 바로 패스키와 Windows Hello for Business가 데스크톱까지 이어지는 환경이므로 함께 읽어볼 가치가 있습니다.

외부 ID: 같은 호스트 풀의 게스트

계약자를 초대하는 것은 일반적인 B2B입니다. Entra 관리 센터에서 최소 User Administrator로 Microsoft Entra ID > Users > New user > Invite external user로 이동하여 이메일과 표시 이름을 입력하고, Assignments 탭에서 AVD 사용자 그룹에 추가합니다. 게스트는 사용자 유형이 게스트인 emailaddress#EXT#@yourtenant.onmicrosoft.com으로 디렉터리에 등록되며, 다른 모든 것이 작동하기 전에 초대를 수락해야 합니다.

그 이후 게스트는 그룹의 다른 멤버와 동일하게 처리됩니다. 애플리케이션 그룹 할당, Virtual Machine User Login 역할, 공유 수준 RBAC, 디렉터리 ACL이 모두 그룹 멤버 자격에서 흘러나옵니다. 첫 게스트가 로그인하기 전에 확인할 사항은 다음과 같습니다.

1. 호스트의 OS 빌드. KB5065789 이상이 적용된 Windows 11 Enterprise 24H2 이상 또는 KB5073379 이상이 적용된 Windows Server 2025. Microsoft는 외부 ID가 클라우드 전용 사용자보다 더 엄격한 OS 요구 사항을 가진다고 명시합니다.
2. SSO 사용 중. 외부 ID는 레거시 사용자 이름과 암호 경로를 사용할 수 없습니다. enablerdsaadauth:i:1이 설정되어야 합니다.
3. 클라이언트. Windows, macOS, iOS, Android용 Windows App 또는 브라우저. iOS와 Android에서 지원되는 유일한 소셜 공급자는 Authenticator에서 연결된 계정으로 구성된 Microsoft 계정입니다. 일회성 암호 로그인은 지원되지 않습니다.
4. 라이선싱. Microsoft의 라이선싱 지침에 따르면 게스트의 홈 테넌트 라이선스는 여러분의 테넌트에서 AVD 권한을 부여하지 않습니다. 직원에게 사용하는 것과 같은 종류의 라이선스(예: Microsoft 365 E3)를 구매하여 테넌트의 게스트 개체에 할당하세요. 사용자별 액세스 가격은 SaaS 앱 판매와 같은 외부 상업적 목적을 위한 것이며, Microsoft는 이것이 게스트 계정을 사용하도록 설정하는 방법이 아니라고 명시합니다.
5. Microsoft 365 앱. 초대된 계정에 Microsoft 365 Apps 라이선스가 있고 홈 테넌트의 조건부 액세스가 차단하지 않는 경우에만 데스크톱 앱에 로그인할 수 있습니다. 그렇지 않으면 게스트는 세션 브라우저에서 웹 앱을 사용합니다.
6. 클라우드 경계. AVD 쪽은 퍼블릭 클라우드와 Azure for US Government이지만, FSLogix와 Azure Files 쪽은 퍼블릭 클라우드 전용이며 크로스 클라우드 초대는 지원되지 않습니다.

게스트는 멤버와 동일한 %username%_%sid% 폴더를 공유에서 받으며, 이것이 GA의 핵심입니다. 하나의 풀링된 호스트 풀, 하나의 프로필 모델, 내부 및 외부 사용자가 나란히 사용합니다.

검증

로그인한 적이 없는 테스트 사용자로 로그인한 뒤(또는 DeleteLocalProfileWhenVHDShouldApply를 설정한 뒤) 다음을 확인합니다.

• 호스트에서 C:\Program Files\FSLogix\Apps\frx.exe list-redirects를 실행합니다. 첫 줄에서 \Users\<user>가 탑재된 컨테이너의 \Device\HarddiskVolumeN\Profile에 매핑되어야 합니다.
• 포털에서 파일 공유를 열고 <username>_<SID>(FlipFlop이 없으면 <SID>_<username>)라는 디렉터리와 그 안의 Profile_<username>.vhdx를 확인합니다.
• 세션에서 klist cloud_debug가 클라우드 TGT를 표시하고 dsregcmd /status가 CloudTgt : YES를 보고합니다.
• 레지스트리 키 HKLM\Software\FSLogix\Profiles\Sessions<SID> 아래에서 Status 0과 Reason 0(컨테이너 연결됨)을 확인합니다.
• Microsoft Entra ID > Monitoring & health > Sign-in logs에서 사용자로 필터링합니다. Azure Virtual Desktop과 Windows Cloud Login 항목 모두 성공으로 표시되고 예상한 조건부 액세스 정책이 적용되어야 합니다. 실패 항목이 있다면 어떤 정책이 차단했는지 알려줍니다.

문제 해결

텍스트 로그가 먼저입니다. FSLogix는 C:\ProgramData\FSLogix\Logs\Profile\Profile_<date>.log에 기록합니다. LoadProfile: <username>을 검색하고 스레드 ID를 따라가며 [ERROR:xxxxxxxx] 줄을 읽습니다. 8자리 코드는 Windows 시스템 오류이므로 net helpmsg <decimal>로 해석할 수 있습니다. 이벤트 뷰어에는 Applications and Services Logs > FSLogix > Apps > Admin과 Operational이 있습니다. FSLogix 지원 도구는 이 모든 것을 지원 사례용으로 묶어 줍니다.

스토리지 쪽 진단에는 AzFilesHybrid 모듈(0.3.0 이상)의 Debug-AzStorageAccountAuth가 Entra Kerberos 검사를 실행합니다. 포트 445, Entra 연결, Entra 개체와 SPN, CloudKerberosTicketRetrieval 키, 영역 매핑, 관리자 동의, 두 필수 서비스, Fiddler 프록시, 조인 유형입니다.

AD 조인 스토리지가 여전히 올바른 선택인 경우

가능하다는 이유만으로 하이브리드 환경을 Entra Kerberos 스토리지로 옮기지는 않겠습니다. 다음 경우에는 프로필 공유에 AD DS 또는 Entra Domain Services 인증을 유지하세요.

• 사용자가 세션 안에서 Kerberos나 NTLM으로 온-프레미스 파일 서버, 인쇄 서버, 통합 인증 웹 앱에 접근해야 하는 경우. 외부 ID는 이를 전혀 할 수 없고, 클라우드 전용 사용자에게는 온-프레미스 계정이 없습니다.
• Azure Government 또는 21Vianet에서 운영하는 경우. 클라우드 전용 Entra Kerberos가 지원되지 않습니다.
• ID가 하이브리드이고 도구가 icacls, ACL을 보존하는 Robocopy 또는 Azure File Sync인 경우. 하이브리드 경로는 이 모든 것을 유지합니다.
• 세션 시간이 일상적으로 10시간을 넘고 아직 FSLogix 26.08로 표준화할 수 없는 경우. 하이브리드 조인 클라이언트는 Entra 전용 클라이언트가 사용할 수 없는 클라우드 트러스트 완화를 사용할 수 있습니다.

Azure Files의 하이브리드 FSLogix는 여전히 완전히 지원되며, GA의 어떤 것도 마이그레이션을 강제하지 않습니다.

지금 해야 할 일

1. ID 유형별로 사용자를 조사합니다. 하이브리드, 클라우드 전용, 게스트입니다. 현재 영구 프로필이 없는 클라우드 전용 사용자와 게스트가 첫 후보입니다.
2. 파일럿 이미지를 KB5079391 이상이 적용된 Windows 11 24H2(게스트도 사용한다면 KB5065789 이상)로 패치하거나 다시 빌드하고 FSLogix 26.08을 설치합니다.
3. 전용 스토리지 계정과 공유를 만들고, Entra Kerberos를 사용하도록 설정하고, 관리자 동의를 부여하고, kdc_enable_cloud_group_sids를 추가하고, 스토리지 앱을 MFA 정책에서 제외합니다.
4. 기본 공유 수준 권한을 Storage File Data SMB Share Contributor로 설정하고, 관리자에게 Elevated Contributor를 부여하고, Manage access로 루트 ACL을 설정합니다.
5. Intune 설정 카탈로그를 통해 CloudKerberosTicketRetrievalEnabled, LoadCredKeyFromProfile, FSLogix 레지스트리 값을 배포합니다.
6. 호스트 풀에서 SSO(enablerdsaadauth:i:1)를 사용하도록 설정하고, Windows Cloud Login을 구성하고, 이전 지침에서 남은 targetisaadjoined:i:1을 제거합니다.
7. 두 개의 조건부 액세스 정책을 만들고, 제외를 확인하고, 사용자별 MFA를 사용하지 않도록 설정합니다.
8. 클라우드 전용 파일럿 사용자로 로그인을 진행하고 frx.exe list-redirects로 컨테이너를 검증한 뒤 게스트로 반복합니다.
9. 그런 다음에야 도메인 컨트롤러 폐기 계획을 다시 검토하고, 온-프레미스 Kerberos가 여전히 필요한 항목에는 하이브리드 공유를 유지합니다.

이 모든 것의 월별 변화는 AVD 새로운 기능 시리즈에서 추적합니다.

도움이 필요하신가요? Big Hat Group은 미국과 캐나다의 조직에 Azure Virtual Desktop 아키텍처 컨설팅을 제공합니다. ID 및 FSLogix 상태 점검부터 완전한 Entra 전용 호스트 풀 구축까지입니다. 디스커버리 콜을 예약하여 환경에 대해 논의하세요.

출처

• Microsoft Entra ID를 사용하여 Azure Files에 FSLogix 프로필 컨테이너 저장
• Azure Files용 Microsoft Entra Kerberos 인증
• Azure Files의 공유 수준 권한 할당
• Azure Files의 디렉터리 및 파일 수준 권한 구성
• SMB 스토리지 권한 구성(FSLogix)
• 프로필 컨테이너 구성(FSLogix)
• FSLogix 구성 설정 참조
• FSLogix 릴리스 정보
• 로깅 및 진단을 통한 FSLogix 문제 해결
• FSLogix 코드와 의미
• Microsoft Entra Kerberos 소개
• Azure Files ID 기반 인증 문제 해결(SMB)
• Azure Virtual Desktop ID 및 인증
• Azure Virtual Desktop의 Microsoft Entra 조인 세션 호스트
• Microsoft Entra ID를 사용하여 Azure Virtual Desktop용 Single Sign-On 구성
• 지원되는 RDP 속성
• 조건부 액세스를 사용하여 Azure Virtual Desktop에 Microsoft Entra 다단계 인증 적용
• Azure Virtual Desktop 라이선싱
• Microsoft Entra 관리 센터에서 B2B 협업 사용자 추가
• Azure Virtual Desktop의 새로운 기능