Azure Files에서 DFS 네임스페이스를 사용하는 방법

적용 대상: ✔️ SMB 파일 공유

분산 파일 시스템 네임스페이스(Distributed File Systems Namespaces), 일반적으로 DFS 네임스페이스 또는 DFS-N이라고 불리며, 운영 환경에서 SMB 파일 공유의 배포 및 유지보수를 단순화하는 Windows Server 서버 역할입니다. DFS 네임스페이스는 스토리지 네임스페이스 가상화를 제공하여, 파일 공유의 UNC 경로와 실제 파일 공유 사이에 간접적인 레이어를 제공할 수 있습니다. DFS 네임스페이스는 해당 파일 공유가 호스트되는 위치에 관계없이 SMB 파일 공유에서 작동합니다. Azure 파일 동기화 유무 여부와 관계없이 온프레미스 Windows 파일 서버에 호스팅된 SMB 공유, Azure 파일 공유, Azure NetApp Files 또는 기타 서드파티 서비스에서 호스팅된 SMB 파일 공유, 심지어 다른 클라우드에 호스팅된 파일 공유와도 사용할 수 있습니다.

DFS 네임스페이스의 핵심은 사용자 친화적인 UNC 경로(예: \\contoso\shares\ProjectX)와 SMB 공유의 기본 UNC 경로(예: \\Server01-Prod\ProjectX\\storageaccount.file.core.windows.net\projectx또는 )를 매핑합니다. 최종 사용자가 파일 공유로 이동할 때 사용자 친화적인 UNC 경로를 입력하지만, SMB 클라이언트는 매핑의 기본 SMB 경로에 접근합니다. 이 개념을 확장하여 기존 파일 서버 이름(예: \\MyServer\ProjectX.)을 인수할 수도 있습니다. 이 기능을 사용하여 다음 시나리오를 달성할 수 있습니다.

논리적 데이터 집합에 대한 마이그레이션 방지 이름을 제공합니다. 예를 들어 \\contoso\shares\Engineering을 \\OldServer\Engineering에 매핑할 수 있습니다. Azure Files로의 마이그레이션을 완료하면 매핑\\storageaccount.file.core.windows.net\engineering을 로 변경할 수 있어서, 최종 사용자가 사용자 친화적인 UNC 경로에 접근할 때 Azure 파일 공유 경로로 원활하게 리디렉션됩니다.
Azure 파일 동기화와 같이 서로 다른 물리적 사이트에 분산된 여러 서버에 배포된 논리 데이터 집합에 대한 공통 명칭을 설정합니다. 이 예시에서 와 \\contoso\shares\FileSyncExample 같은 이름은 , , \\FileSyncServer2\DifferentShareName, 와 \\FileSyncServer3\ExampleShare같은 여러 UNC 경로\\FileSyncServer1\ExampleShare에 매핑됩니다. 사용자가 사용자 친화적인 UNC에 접속하면 가능한 UNC 경로 목록을 받고 Windows Server Active Directory(AD) 사이트 정의를 바탕으로 가장 가까운 경로를 선택합니다.
크기, IO 또는 기타 규모 임계값에 걸쳐 논리적 데이터 집합을 확장합니다. 이 확장 기능은 각 사용자가 공유에서 자신의 폴더를 갖는 사용자 디렉터리와, 임시 데이터를 위한 임의의 공간을 할당하는 스크래치 공유에 유용합니다. DFS 네임스페이스를 사용하면 여러 폴더를 함께 응집력 있는 네임스페이스에 연결합니다. 예를 들어, \\contoso\shares\UserShares\user1는 \\storageaccount.file.core.windows.net\user1에 매핑되고, \\contoso\shares\UserShares\user2는 \\storageaccount.file.core.windows.net\user2에 매핑됩니다.

다음 비디오 개요에서 Azure Files 배포와 함께 DFS 네임스페이스를 사용하는 방법의 예를 볼 수 있습니다.

비고

비디오에서 10:10으로 건너뛰어 DFS 네임스페이스를 설정하는 방법을 확인합니다.

이미 DFS 네임스페이스가 있다면 Azure Files와 파일 동기화에서 사용할 특별한 절차는 필요하지 않습니다. 온프레미스에서 Azure 파일 공유에 접근할 경우, 일반적인 네트워킹 고려사항이 적용됩니다. 자세한 내용은 Azure Files 네트워킹 고려 사항을 참조하세요.

이 글에서는 Azure Files에 특화된 DFS 네임스페이스 배포 부분을 다룹니다. 기본 Windows Server 개념과 전체 네임스페이스 절차 세트에 대해서는 DFS 네임스페이스 개요와 DFS 네임스페이스 배포를 참조하세요.

사전 요구 사항

DFS 네임스페이스를 Azure Files 및 File Sync와 함께 사용하려면 다음 자원이 필요합니다:

Active Directory 도메인입니다. 이 도메인은 온프레미스, Azure 가상 머신(VM) 또는 다른 클라우드에서 어디서든 호스팅할 수 있습니다.
DFS 네임스페이스 서버 역할이 설치된 도메인에 가입된 Windows Server 멤버 서버입니다. DFS 네임스페이스는 지원되는 모든 Windows Server 버전에서 사용할 수 있습니다.

Important

Active Directory 도메인 컨트롤러에 루트 통합 네임스페이스를 호스팅하지 마세요. 기존 파일 서버 이름을 인수하려면 전용 멤버 서버나 Windows Server 장애 지점 클러스터가 필요합니다.
도메인 조인 환경에서 호스팅되는 SMB 파일 공유, 예를 들어 도메인 가입 스토리지 계정의 Azure 파일 공유나 Azure 파일 동기화가 포함된 도메인 가입 Windows 파일 서버의 파일 공유. 자세한 내용은 신원 기반 인증을 참조하세요.
클라이언트에서 SMB 파일 공유까지의 네트워크 연결 가능성. 자세한 내용은 직접 액세스에 대한 네트워킹 고려 사항을 참조하세요.
도메인 관리자 권한 또는 영향을 받는 컴퓨터 계정의 servicePrincipalName 특성에 대한 위임받은 쓰기 권한. 이름 획득 절차는 Active Directory 객체를 수정하며 상승된 세션을 필요로 합니다.

DFS 네임스페이스 서버 역할 설치

이미 DFS 네임스페이스를 사용 중이라면 이 단계를 건너뛰세요.

서버 관리자
PowerShell

서버 관리자를 열고 '역할 및 기능 추가' 관리(Manage>Add Loles and Features)를 선택하세요. 역할 기반 설치나 기능 기반 설치를 선택하세요. 서버 역할 페이지에서 파일 및 스토리지 서비스>파일과 iSCSI 서비스 항목에서 DFS 네임스페이스를 선택하세요. 위저드는 필요한 보조 역할이나 기능을 추가합니다.

DFS 네임스페이스 역할이 선택된 역할 및 기능 추가 마법사의 스크린샷

관리자 권한으로 PowerShell 세션을 시작하여 다음 명령을 실행합니다.

Install-WindowsFeature -Name "FS-DFS-Namespace", "RSAT-DFS-Mgmt-Con"

더 많은 설치 옵션은 DFS 네임스페이스 설치 항목을 참조하세요.

네임스페이스 형식 선택

DFS 네임스페이스는 도메인 기반 과 독립 실행형 두 가지 네임스페이스 유형을 제공합니다. 확장 제한, 가용성 옵션, Active Directory 요구사항 등 전체 비교는 '이름 공간 유형 선택'을 참조하세요.

새로운 네임스페이스 마법사에서 도메인 기반 네임스페이스와 독립형 네임스페이스 중에서 선택하는 스크린샷입니다.

Azure Files의 경우, 선택지는 보통 한 가지 질문으로 귀결됩니다:

기존의 온프레미스 파일 서버 이름을\\MyServer\share보존해야 한다면, 독립 실행형 네임스페이스 를 선택하고 루트 통합을 사용하세요. 이 방법은 파일 공유를 Azure Files로 마이그레이션할 때 권장되는데, 마이그레이션 후에도 문서 단축키, 임베디드 링크, 하드코딩된 UNC 경로가 계속 작동하기 때문입니다. 이 글의 나머지 부분은 이 시나리오에 초점을 맞추고 있습니다.
다른 경우에는도메인 기반 네임스페이스를 선택하세요.

독립형 네임스페이스는 계획해야 할 상충 요소가 있습니다:

네임스페이스 메타데이터는 Active Directory가 아니라 네임스페이스 서버의 레지스트리에 저장됩니다. 서버 백업 전략에 네임스페이스 구성을 포함하세요.
중복성을 위해 독립 실행형 네임스페이스에 여러 개의 네임스페이스 서버를 추가할 수는 없습니다. 높은 가용성을 위해 네임스페이스를 Windows Server 장애 전환 클러스터에 호스팅하세요.
독립형 네임스페이스는 Windows Server 2008 모드에서 도메인 기반 네임스페이스보다 낮은 규모의 타겟을 지원합니다.

사용자가 선택하는 경로는 네임스페이스 유형에 따라 다릅니다:

네임스페이스 구성	사용할 경로
루트 통합 기능이 있는 독립 실행형 네임스페이스	`\\<old-server>\<share>`
독립 실행형 네임스페이스	`\\<DFS-server>\<namespace>\<share>`
도메인 기반 네임스페이스	`\\<domain-name>\<namespace>\<share>`

도메인 기반 네임스페이스를 선택했다면 루트 통합 단계를 건너뛰세요. 네임스페이스와 폴더 대상 절차는 두 유형 모두에서 동일합니다. Create the namespace를 사용하고 Azure 파일 공유DomainV2 유형을 네임스페이스 타입으로 추가하세요.

루트 통합을 사용하여 기존 서버 이름 인수

루트 통합을 통해 단일 DFS 네임스페이스 서버가 여러 파일 서버 이름에 응답하고 요청을 적절한 공유로 라우팅할 수 있습니다. 이 기능은 Azure Files 도입에 특히 유용한데, 이유는 다음과 같습니다:

Azure 파일 공유는 기존 온프레미스 서버 이름을 재사용할 수 없습니다.
Azure 파일 공유는 스토리지 계정 완전 정식 도메인 이름(FQDN)을 사용해 처리합니다. 예를 들어, 스토리지 계정 \\storageaccount.file.core.windows.net\share의 파일 공유 storageaccount에 액세스하려면 share를 사용합니다. 이 경로는 짧은 이름(예: \\MyServer\share.)을 기대하는 최종 사용자에게 혼란을 줄 수 있습니다. Azure Files는 스토리지 계정 이름이 도메인 접두사일 때 커스텀 도메인 이름을 지원하지만, DFS 네임스페이스가 없으면 .와 같은 \\MyServer.contoso.com\share이름을 사용할 수 없습니다.

루트 통합은 독립 실행형 네임스페이스에서만 사용할 수 있습니다. 이미 도메인 기반 네임스페이스가 파일 공유를 위해 있다면, 루트 통합 네임스페이스가 필요하지 않습니다.

루트 통합 네임스페이스를 매우 유용하게 만들려면 장애 조치 클러스터에 호스팅하세요. 기본 클러스터를 구축하려면 '장애 조치 클러스터 만들기'를 참조하세요. 이 방식을 택할 때는 개별 노드가 아니라 클러스터 이름 객체(CNO)에 대해 별칭을 등록하세요.

다음 다이어그램은 고가용성 루트 통합 배포를 보여줍니다. Azure Load Balancer는 루트 통합 네임스페이스를 호스팅하는 DFS 네임스페이스 서버로 구성된 Windows Server 장애 조치 클러스터의 전단에 배치되어, 공유가 Azure Files로 이동한 후에도 클라이언트가 사용 중지된 파일 서버 이름에 계속 연결할 수 있도록 합니다.

온-프레미스 파일 서버가 Azure 파일 공유로 마이그레이션되는 모습을 보여 주는 아키텍처 다이어그램입니다. Azure Load Balancer는 루트 통합 네임스페이스 #fileserver01 및 #fileserver02를 호스팅하는 DFS 네임스페이스 서버로 이루어진 Windows Server 장애 조치 클러스터의 앞단에 배치되며, 이 서버들은 클라이언트를 스토리지 계정 stcontoso01 및 stcontoso02의 파일 공유로 안내합니다. contoso.com용 Active Directory 도메인 컨트롤러가 인증을 제공합니다.

기존 서버 이름을 인수하는 것은 덧붙이는 변경이 아니라 컷오버입니다. 다음 단계를 순서대로 완료하세요:

DFS 네임스페이스 서버에서 루트 통합을 활성화하세요.
#<old-server-name>라는 이름의 네임스페이스를 사용하여 네임스페이스를 만들고 Azure 파일 공유를 추가하세요.
소스 파일 서버에서 서버 이름과 서비스 주체 이름을 전송합니다.
기존 파일 서버 이름에 대해 DNS 항목을 생성하세요.
이름 탈취를 확인하세요.

Important

3단계와 4단계는 소스 파일 서버를 오프라인으로 만들기 때문에, 종료와 DNS 변경 완료 사이의 간격은 사용자에게 장애가 됩니다. 유지 관리 기간 예약

시작하기 전에 소스 서버 이름으로 해상도되는 나머지 모든 것을 인벤토리에 넣어두세요. 인쇄 큐, DFS 복제 멤버, 데이터베이스 별칭, 예약된 작업, 백업 작업, 그리고 이전 이름을 참조하는 하드코딩 스크립트는 이름이 DFS 네임스페이스 서버로 리디렉션될 때 작동을 멈춥니다. 네임스페이스 서버는 SMB 추천만 반환하기 때문입니다. 먼저 그 의존성을 마이그레이션하거나 종료하세요.

루트 통합 활성화

네임스페이스 서버에서 상승된 PowerShell 세션에서 다음 레지스트리 값을 설정한 후 DFS 네임스페이스 서비스를 재시작하세요. 서비스는 이 값들을 시작 시에만 읽습니다; 재시작되기 전까지는 이름이 로 시작하는 #네임스페이스를 만들 수 없습니다.

New-Item `
    -Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs" `
    -Type Registry `
    -ErrorAction SilentlyContinue
New-Item `
    -Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs\Parameters" `
    -Type Registry `
    -ErrorAction SilentlyContinue
New-Item `
    -Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs\Parameters\Replicated" `
    -Type Registry `
    -ErrorAction SilentlyContinue
Set-ItemProperty `
    -Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs\Parameters\Replicated" `
    -Name "ServerConsolidationRetry" `
    -Type DWord `
    -Value 1

Restart-Service -Name "Dfs"

페일오버 클러스터에서는 모든 노드에 레지스트리 값을 설정한 후, 클러스터 네임스페이스 역할을 오버 실패하여 각 노드가 서비스를 재시작하도록 합니다.

네임스페이스를 만들고 Azure 파일 공유를 추가하세요

DFS 네임스페이스의 기본 관리 단위는 네임스페이스이며, 그 루트는 트리의 시작점입니다. \\contoso.com\Public\에서 네임스페이스 루트는 Public입니다. 네임스페이스 내에서 폴더 타겟이 있는 폴더는 콘텐츠를 담고 있는 SMB 파일 공유를 가리키고, 폴더 타겟이 없는 폴더는 구조와 계층 구조를 추가합니다.

일반적인 Windows Server 절차에 대해서는 DFS 네임스페이스 생성, DFS 네임스페이스 내 폴더 생성, 폴더 타겟 추가를 참조하세요. Azure 파일 공유를 목표로 할 때 다음 사항들을 염두에 두세요:

폴더 타겟으로 스토리지 계정 FQDN을 사용하세요. 폴더 대상을 \\<storage-account>.file.core.windows.net\<share>로 지정합니다. Azure Files는 스토리지 계정 이름이 도메인 접두사일 때도 커스텀 도메인 이름을 지원하지만, 폴더 타겟에 도메인을 사용하면 각 추천 뒤에 두 번째 DNS와 Kerberos 의존성이 생깁니다. 이미 커스텀 도메인에 의존하지 않는 이상 FQDN을 사용하세요.
DFS 관리에서 연결 경고가 뜰 것으로 예상됩니다. Azure 파일 공유에 대한 폴더 대상을 추가하면 콘솔에 storageaccount.file.core.windows.net에 연결할 수 없다고 표시될 수 있습니다. 이 경고는 예상된 것입니다. 계속하려면 예를 선택합니다.
루트 통합 네임스페이스는 접두사가 # 필요합니다. 네임스페이스 이름은 교체하는 서버와 일치해야 하며, 그 앞에 #.가 붙어야 합니다. MyServer라는 서버를 인수하려면 #MyServer라는 네임스페이스를 생성하세요. PowerShell 예제는 접두사를 추가해 줍니다. DFS 관리 콘솔에는 지원이 없으니 직접 입력하세요.
폴더 이름은 이전 공유 이름과 일치해야 합니다. 열리는 \\MyServer\Finance 클라이언트는 네임스페이스 내 #MyServer 폴더 Finance 에서 서비스를 받으므로, 폴더 이름은 소스 서버의 공유 이름과 정확히 일치해야 합니다.

DFS 경영진
PowerShell

DFS 관리 콘솔에서 네임스페이스(Namespaces>) 새네임스페이스를 선택하고 새 네임스페이스 마법사를 따라가세요. 그 다음 새 네임스페이스를 선택하고 새 폴더를 선택한 뒤 폴더 이름을 입력한 뒤, Azure 파일 공유의 UNC 경로를 폴더 타겟으로 제공하려면 추가를 선택하세요.

새 폴더 대화상자 스크린샷과 폴더 타겟이 추가된 사진입니다.

DFS 네임스페이스 서버의 상위 PowerShell 세션에서 다음 명령을 실행하세요. 첫 번째 블록의 변수를 환경별로 업데이트하세요.

# Variables
$namespace = "MyServer"                   # Namespace root name. For root consolidation, use the
                                          # name of the file server you're replacing.
$type = "Standalone"                      # "Standalone" for a stand-alone namespace, or "DomainV2"
                                          # for a domain-based namespace (Windows Server 2008 mode).
$takeOverName = $true                     # Set to $false if you aren't using root consolidation.
$shareName = "Finance"                    # Folder name within the namespace. For root consolidation,
                                          # match the share name on the source file server exactly.
$targetUNC = "\\storageaccount.file.core.windows.net\finance"

# Root consolidation namespaces must be prefixed with "#".
if ($takeOverName -and $type -eq "Standalone" -and $namespace -notlike "#*") {
    $namespace = "#$namespace"
}

$dfsnServer = $env:ComputerName
$namespaceServer = if ($type -like "Domain*") {
    Get-CimInstance -ClassName "Win32_ComputerSystem" | `
        Select-Object -ExpandProperty Domain
} else { $dfsnServer }

# Create the SMB share that backs the namespace root. Read-only access matches the DFS Management
# default, because this share serves referrals rather than data.
$smbSharePath = "C:\DFSRoots\$namespace"
if (!(Test-Path -Path $smbSharePath)) {
    New-Item -Path $smbSharePath -ItemType Directory | Out-Null
}
New-SmbShare -Name $namespace -Path $smbSharePath -ReadAccess "Everyone"

# Create the namespace root.
Import-Module -Name DFSN
$namespacePath = "\\$namespaceServer\$namespace"
New-DfsnRoot -Path $namespacePath -TargetPath "\\$dfsnServer\$namespace" -Type $type

# Create the folder and point it at the Azure file share.
New-DfsnFolder -Path "$namespacePath\$shareName" -TargetPath $targetUNC

# Verify the namespace root and folder target.
Get-DfsnRoot -Path $namespacePath
Get-DfsnFolderTarget -Path "$namespacePath\$shareName"

계속하기 전에 네임스페이스가 네임스페이스 서버 자체의 이름을 통해 해결되는지 확인하세요. 예전 서버 이름은 아직 작동하지 않습니다; 다음 두 단계를 지나면 작동하기 시작합니다.

Test-Path -Path "\\CloudDFSN\#MyServer\Finance"

경로가 해결되지 않는다면, 클라이언트가 Azure 파일 공유에 직접 \\<storage-account>.file.core.windows.net\<share>접근할 수 있는지 확인하세요. DFS 네임스페이스는 참조만 반환하므로, 기본 공유와 관련된 네트워킹이나 인증 문제는 여기서 나타납니다. 자세한 내용은 직접 액세스에 대한 네트워킹 고려 사항을 참조하세요.

서버 이름과 서비스 주체 이름을 전송하세요

루트 통합은 DFS 네임스페이스 서버가 이전 파일 서버의 이름으로 응답할 수 있게 하지만, 클라이언트가 그 이름으로 인증하기 전에 두 가지 다른 조건이 반드시 충족되어야 합니다:

네임스페이스 서버의 SMB 서버는 자신의 컴퓨터 이름이 아닌 이름으로 이루어진 연결을 받아들여야 합니다.
Kerberos는 cifs/MyServer을(를) 요청을 처리하는 계정으로 매핑해야 합니다. 해당 서비스 주체명(SPN)이 폐쇄된 파일 서버의 컴퓨터 계정에 아직 등록되어 있다면, 클라이언트는 잘못된 계정으로 티켓을 받게 됩니다. 그러면 "대상 계정 이름이 잘못되었습니다"라는 오류와 함께 연결이 실패하거나, 별다른 알림 없이 NTLM으로 대체됩니다.

명령은 netdom computername 두 가지 요구사항을 모두 처리합니다. 이 시스템은 네임스페이스 서버에 이전 이름을 대체 컴퓨터 이름으로 등록하여 서버 msDS-AdditionalDnsHostName 속성에 이름을 추가하고 일치 HOST/<alias> 하는 SPN을 등록합니다. HOST SPN은 cifs를 포함하는 서비스 클래스 집합을 암묵적으로 포괄하므로, 클라이언트의 cifs/MyServer 요청은 네임스페이스 서버의 계정으로 확인됩니다. 서비스 클래스의 전체 목록은 setspn을 참조하세요.

netdom 대신 수작업으로 만든 setspn 등록을 사용하지 마세요. 네임스페이스 서버 계정에 등록하면 cifs/MyServer Kerberos는 설정되지만 SMB 서버는 그렇지 않고, 디렉터리 서비스는 대상 계정 이름에서 파생되지 않은 SPN은 거부합니다. 자세한 내용은 SMB 파일 서버 공유 접근이 DNS CNAME 별칭을 통한 실패 사례를 참조하세요.

Warning

원본 컴퓨터 계정을 삭제하지 마세요. 비활성화하면 계정과 보안 식별자(SID), 그룹 멤버십이 유지되므로, 계정을 다시 활성화하고 SPN을 복원하면 컷오버를 되돌릴 수 있습니다. 계정을 삭제하면 롤백이 훨씬 어려워집니다.

Important

이 절차에서 디렉터리 변경을 동일한 도메인 컨트롤러, 가능하면 PDC 에뮬레이터에 대해 실행하세요. Active Directory는 일관성이 느슨한 다중 마스터 복제를 사용하기 때문에, 복제본들이 어느 시점에서도 서로 일관성을 유지한다는 보장은 없습니다. 한 도메인 컨트롤러에서 이전 등록을 제거한 후 다른 도메인 컨트롤러에 추가하면, 중복 검사가 삭제된 등록을 보고 기록을 거부할 수 있습니다. PDC 에뮬레이터를 찾으려면 (Get-ADDomain).PDCEmulator를 실행한 다음, 해당 서버의 세션에서 명령을 실행하세요.

소스 파일 서버를 종료하세요. 소스 서버와 DFS 네임스페이스 서버가 모두 같은 이름에 응답할 수는 없습니다. 서버를 도메인에서 제거하는 대신 전원을 끄세요.
소스 컴퓨터 계정을 비활성화하세요. Active Directory 사용자 및 컴퓨터에서 컴퓨터 객체를 우클릭하여 계정 비활성화를 선택하세요. Active Directory 모듈이 설치된 컴퓨터에서 PowerShell에서 같은 작업을 하려면, 다음을 실행하세요:
```
$oldServer = "MyServer"
Disable-ADAccount -Identity ($oldServer + '$')
```
소스 컴퓨터 계정에서 SPN을 제거하세요. 계정을 비활성화한다고 해서 SPN이 사라지는 것은 아닙니다. 이전 계정에 남겨진 등록은 다음 단계를 막아요. 같은 이름이 두 계정에 등록될 수 없기 때문입니다. 중복된 SPN은 .의 KDC_ERR_PRINCIPAL_NOT_UNIQUE원인으로 문서화되어 있습니다. 자세한 내용은 Kerberos에서 KDC_ERR_S_PRINCIPAL_UNKNOWN 또는 KDC_ERR_PRINCIPAL_NOT_UNIQUE 오류가 발생하는 문제를 참조하세요. 등록된 항목을 나열한 다음 cifs 및 HOST 항목을 삭제하세요:
```
setspn -L MyServer
setspn -D HOST/MyServer MyServer
setspn -D HOST/MyServer.contoso.com MyServer
```
명시적인 cifs/ 항목도 같은 방식으로 삭제하세요. 만약 setspn -LTERMSRVMSSQLSvc또는 , 와 같은 다른 서비스 클래스를 표시한다면, 이전 이름은 여전히 SMB가 아닌 다른 서비스를 제공합니다. 계속하기 전에 그 의존성을 먼저 해결하세요.
네임스페이스 서버에 이전 이름을 대체 컴퓨터 이름으로 추가하세요. 네임스페이스 서버의 상위 명령 프롬프트에서 실행하세요 netdom . 단일 DFS 네임스페이스 서버의 경우, 그 서버의 컴퓨터 계정을 타겟팅하세요. 클러스터 독립 실행형 네임스페이스의 경우, 개별 노드 계정이 아닌 클러스터 이름 객체(CNO)를 타겟팅하세요. netdom 원격 서버 관리 도구의 AD DS 도구와 함께 제공됩니다; 명령어가 없으면 설치 RSAT-AD-Tools 하세요.
```
netdom computername CloudDFSN.contoso.com /add:MyServer.contoso.com
```
두 이름 모두 완전 자격 도메인 이름으로 지정하세요. netdom는 대상 계정에 HOST/MyServer.contoso.com 및 HOST/MyServer SPN을 등록하고, 해당 계정의 msDS-AdditionalDnsHostName 특성에 이름을 추가하여 SMB 서버가 이전 이름으로 이루어진 연결을 수락할 수 있게 합니다.

결과를 확인합니다. 스위치는 /verify 각 등록된 이름에 대해 DNS 레코드와 SPN이 존재하는지 확인합니다:
```
netdom computername CloudDFSN.contoso.com /enumerate:AlternateNames
netdom computername CloudDFSN.contoso.com /verify
```
netdom에서 해당 이름이 이미 사용 중이라고 보고하는 경우, 해당 이름은 포리스트 내 다른 위치에 여전히 등록되어 있습니다. 계속하기 전에 상반되는 객체를 찾아보세요:
```
setspn -T contoso -F -Q */MyServer
```
만약 이전 단계에서 수정한 원본 컴퓨터 계정만 반환된 객체라면, 제거 작업이 아직 쿼리 중인 도메인 컨트롤러에 복제되지 않은 것입니다. 복제가 수렴할 때까지 기다리거나, PDC 에뮬레이터에서 명령을 다시 실행하세요.

기존 파일 서버 이름에 대해 DNS 항목을 생성하세요

DFS 네임스페이스가 기존 파일 서버 이름에 응답하려면, 이전 파일 서버 이름을 DFS 네임스페이스 서버를 가리키는 별칭(CNAME) 레코드를 생성합니다. 정확한 절차는 귀하의 조직이 사용하는 DNS 서버에 따라 다릅니다. 다음 단계는 Windows Server에 포함된 DNS 서버를 사용합니다.

DNS 관리자
PowerShell

Windows DNS 서버에서 DNS 관리 콘솔을 열고 도메인의 포워드 룩업 존으로 가세요. 존을 우클릭하고 새 별칭(CNAME)을 선택하세요. 대화 상자에 교체하려는 파일 서버의 짧은 이름을 입력하세요. 그 다음 대상 호스트 텍스트 박스의 완전 적격 도메인 이름(FQDN) 에 DFS-N 서버의 이름을 입력합니다. 확인을 선택하여 CNAME 레코드를 생성합니다.

CNAME DNS 항목의 새 자원 레코드 대화상자 스크린샷입니다.

Windows DNS 서버에서 상위 파워셸 세션에서 다음 명령어를 실행하세요. $dfsnServer에는 교체할 파일 서버의 이름을 입력하고, $oldServer에는 DFS 네임스페이스 서버의 짧은 이름을 입력하세요. 클러스터 네임스페이스의 경우, 노드 이름 대신 클러스터 네트워크 이름을 사용하세요. 이 변수는 $domain 로컬 컴퓨터의 도메인에서 채워집니다.

# Variables
$oldServer = "MyServer"
$dfsnServer = "CloudDFSN"
$domain = Get-CimInstance -ClassName "Win32_ComputerSystem" | `
    Select-Object -ExpandProperty Domain

# Create CNAME record
Import-Module -Name DnsServer
Add-DnsServerResourceRecordCName `
    -Name $oldServer `
    -HostNameAlias "$dfsnServer.$domain" `
    -ZoneName $domain

이름 탈취를 확인하세요

도메인에 가입된 클라이언트에서 테스트하고, 대상 Azure 파일 공유에 대한 권한을 가진 사용자로 로그인했습니다. DFS 네임스페이스 서버 자체에서 테스트하지 마세요. 루프백 연결은 원격 클라이언트가 사용하는 인증 경로와 다르기 때문입니다.

대체 이름 등록이 모든 도메인 컨트롤러에 복제되었는지 확인하세요. 클라이언트의 키 배포 센터가 반드시 변경한 도메인 컨트롤러는 아니며, Active Directory 복제본은 어느 시점에서도 일관성을 보장하지 않습니다:
```
$oldServer = "MyServer"
$dfsnServer = "CloudDFSN"
Get-ADDomainController -Filter * | ForEach-Object {
    $spns = (Get-ADComputer -Identity $dfsnServer -Properties servicePrincipalName `
        -Server $_.HostName).servicePrincipalName
    [pscustomobject]@{
        DomainController = $_.HostName
        HasHostSpn       = [bool]($spns -contains "HOST/$oldServer")
    }
}
```
도메인 컨트롤러 중 하나라도 False를 보고하면 복제가 완료되지 않은 상태입니다. 계속하기 전에 다시 확인해 보세요. 도메인 컨트롤러를 통해 인증하는 클라이언트는 여전히 실패합니다.
이전 서버 이름이 이제 DFS 네임스페이스 서버로 해결되는지 확인하세요:
```
Resolve-DnsName -Name "MyServer" -Type CNAME
```
이전 이름으로 공유를 열고 Azure 파일 공유의 내용이 보이는지 확인하세요:
```
Test-Path -Path "\\MyServer\Finance"
Get-ChildItem -Path "\\MyServer\Finance"
```
세션이 NTLM으로 되돌아가는 대신 Kerberos로 인증되었는지 확인하려면 이전 이름으로 티켓이 발급되었는지 확인하세요:
```
klist
```
서버 필드가 . cifs/MyServer인 티켓을 찾아보세요. Kerberos는 HOST/MyServer 등록이 cifs 서비스 클래스를 포함하므로 네임스페이스 서버 계정에 대해 이 티켓을 발급합니다. 만약 그런 티켓이 없다면, 가장 흔한 원인은 대체 이름 등록이 클라이언트가 사용하는 도메인 컨트롤러에 복제되지 않았거나, 비활성화된 계정에 등록이 남겨졌거나, 포레스트 내 다른 곳에 중복이 존재하는 경우입니다.

DNS 또는 Kerberos 변경이 즉시 적용되지 않으면 클라이언트 측 캐시를 지우고 다시 시도하세요:

ipconfig /flushdns
klist purge

클라이언트 캐시를 지워도 기본 변경 사항이 아직 복제되지 않았다면 도움이 되지 않습니다. 재시도가 여전히 실패하면, 다른 변경을 하기 전에 1단계에서 복제 수렴을 다시 확인하세요.

접근 기반 열거(ABE)

접근 기반 열거는 사용자가 접근할 권한이 없는 파일과 폴더를 숨깁니다. DFS 네임스페이스에서는 네임스페이스에서 ABE 활성화가 해당 네임스페이스 내 DFS-N 폴더에만 적용됩니다. 폴더 대상 내용의 열거를 제어하려면 대상 파일 공유 자체에서 ABE를 활성화하세요. ABE는 모든 네임스페이스 서버가 Windows Server 2008 이상을 실행하도록 요구하며, 도메인 기반 네임스페이스는 Windows Server 2008 모드를 사용해야 합니다. 자세한 내용은 이름 공간에 대한 접근 기반 열거 활성화를 참조하세요.

Azure 파일 공유에서는 ABE를 활성화할 수 없기 때문에, SMB Azure 파일 공유 내에서 파일과 폴더의 가시성을 ABE로 제어하는 것은 지원되지 않는 시나리오입니다. 이 제한은 DFS-N 폴더 대상 앞에서 프록시가 아닌 추천 방식으로 작동하기 때문에 존재합니다. 사용자가 를 입력 \\mydfsnserver\share하면 SMB 클라이언트가 추천 \\mydfsnserver\share => \\server123\share 을 받고 직접 마운트하여 DFS-N 서버가 더 이상 데이터 경로에 있지 않게 됩니다.

ABE는 리디렉션 전에 필터링하려는 계층 구조 수준을 DFS-N 서버가 호스팅하는 경우에만 작동합니다. 다음 두 레이아웃 모두 작동하는데, 이는 사용자별 폴더 이름이 DFS-N 서버의 네임스페이스에 존재하기 때문입니다:

\\DFSServer\users\contosouser1 => \\SA.file.core.windows.net\contosouser1
\\DFSServer\users\contosouser1 => \\SA.file.core.windows.net\users\contosouser1, 여기서 contosouser1 는 share의 users 하위 폴더입니다.

각 사용자가 리디렉션 후 하위 폴더로 설정되면 ABE는 작동하지 않습니다. 사용자 단위 폴더는 DFS-N 서버에서 열거되지 않기 때문입니다:

\\DFSServer\SomePath\users => \\SA.file.core.windows.net\users

참고하십시오

피드백

이 페이지가 도움이 되었나요?

2026-08-28 에 마지막으로 업데이트됨