사용자가 NFS를 통해 Azure NetApp Files 볼륨에 액세스하려고 하면 요청이 숫자 ID로 제공됩니다. 기본적으로 Azure NetApp Files는 NFS 사용자에 대한 확장된 그룹 멤버 자격을 지원합니다(표준 16개 그룹 제한을 확장). 결과적으로 Azure NetApp 파일은 RPC 패킷에서 그룹 멤버 자격을 전달하는 대신 숫자 ID를 가져와 LDAP(Lightweight Directory Access Protocol)에서 조회하여 사용자의 그룹 멤버 자격을 확인하려고 시도합니다. 이러한 동작으로 인해 해당 숫자 ID가 LDAP에서 사용자로 확인되지 않으면 조회가 실패하고 액세스가 거부됩니다. 이러한 거부는 요청하는 사용자에게 볼륨이나 데이터 구조에 대한 액세스 권한이 있는 경우에도 발생합니다.
Active Directory 연결에서 LDAP를 사용하여 로컬 NFS 사용자 허용 옵션은 확장된 그룹 기능을 사용하지 않도록 설정하여 NFS 요청에 대해 이러한 LDAP 조회를 사용하지 않도록 설정하기 위한 것입니다. Azure NetApp Files 내에서 "로컬 사용자 만들기/관리"를 제공하지 않습니다.
"LDAP를 통해 로컬 NFS 사용자 허용" 옵션이 사용하도록 설정된 경우 숫자 ID가 Azure NetApp Files에 전달되고 LDAP 조회가 발생하지 않습니다. 이는 아래에서 설명하는 것처럼 다양한 시나리오에 따라 다양한 동작을 만듭니다.
UNIX 보안 스타일 볼륨을 갖춘 NFSv3
숫자 ID는 사용자 이름으로 변환할 필요가 없습니다. "LDAP를 통해 로컬 NFS 사용자 허용" 옵션은 볼륨 액세스에 영향을 미치지 않습니다. 이는 NFS 클라이언트에서 사용자/그룹 소유권(이름 변환)이 표시되는 방식에 영향을 줄 수 있습니다. 예를 들어, LDAP에서는 숫자 ID가 1001인 user1이 NFS 클라이언트의 로컬 암호 파일에서는 user2인 경우, 숫자 ID가 1001이면 클라이언트는 해당 파일의 소유자로 "user2"를 표시합니다.
UNIX 보안 스타일 볼륨이 있는 NFSv4.1
숫자 ID는 사용자 이름으로 변환할 필요가 없습니다. 기본적으로 NFSv4.1은 인증을 위해 이름 문자열(user@CONTOSO.COM)을 사용합니다. 그러나 Azure NetApp Files는 NFSV4.1에서 숫자 ID 사용을 지원하므로 NFSv4.1 요청은 숫자 ID와 함께 NFS 서버에 도착합니다. Azure NetApp Files 볼륨의 로컬 파일이나 LDAP와 같은 이름 서비스에 숫자 ID를 사용자 이름으로 변환하는 기능이 없는 경우 숫자가 클라이언트에 제공됩니다. 숫자 ID가 사용자 이름으로 변환되는 경우 이름 문자열이 사용됩니다. 이름 문자열이 일치하지 않으면 클라이언트는 해당 이름을 클라이언트의 idmapd.conf 파일에 지정된 익명 사용자에게 압축합니다. "LDAP를 통해 로컬 NFS 사용자 허용" 옵션을 사용하도록 설정해도 NFSv4.1 액세스에는 영향을 미치지 않습니다. Azure NetApp Files가 로컬 NFS 사용자 데이터베이스에서 숫자 ID를 사용자 이름으로 확인할 수 없는 한, 액세스는 표준 NFSv3 동작으로 돌아갑니다. Azure NetApp Files에는 일부 클라이언트에게 문제가 될 수 있는 기본 UNIX 사용자 집합이 있으며, 도메인 ID 문자열이 일치하지 않으면 "nobody" 사용자로 Squash됩니다.
- 로컬 사용자에는 root(0), pcuser(65534), nobody(65535)가 포함됩니다.
- 로컬 그룹에는 root(0), daemon(1), pcuser(65534), nobody(65535)가 포함됩니다.
가장 흔한 문제는 NFSv4.1 도메인 ID가 잘못 구성된 경우 NFSv4.1 클라이언트 탑재에서 root가 잘못 표시되는 것입니다. NFSv4.1 ID 도메인에 대한 자세한 내용은 Azure NetApp Files에 대한 NFSv4.1 ID 도메인 구성을 참조하세요.
NFSv4.1 ACL은 이름 문자열이나 숫자 ID를 사용하여 구성할 수 있습니다. 숫자 ID를 사용하는 경우 이름 번역이 필요하지 않습니다. 이름 문자열을 사용하는 경우 적절한 ACL 확인을 위해 이름 변환이 필요합니다. NFSv4.1 ACL을 사용할 때 "LDAP를 통해 로컬 NFS 사용자 허용"을 사용하도록 설정하면 ACL 구성에 따라 잘못된 NFSv4.1 ACL 동작이 발생할 수 있습니다.
듀얼 프로토콜 구성의 NTFS 보안 스타일 볼륨을 갖춘 NFS(NFSv3 및 NFSv4.1)
UNIX 보안 스타일 볼륨은 UNIX 스타일 권한(모드 비트 및 NFSv4.1 ACL)을 활용합니다. 이러한 형식의 볼륨의 경우 NFS는 위에 나열된 시나리오에 따라 숫자 ID나 이름 문자열을 활용하는 UNIX 스타일 인증만 활용합니다.
하지만 NTFS 보안 스타일 볼륨은 NTFS 스타일 권한을 사용합니다. 이러한 권한은 Windows 사용자 및 그룹을 사용하여 할당됩니다. NFS 사용자가 NTFS 스타일 권한으로 볼륨에 액세스하려고 하면 적절한 액세스 제어를 보장하기 위해 UNIX-Windows 이름 매핑이 이루어져야 합니다. 이 시나리오에서 NFS 숫자 ID는 여전히 Azure NetApp Files NFS 볼륨으로 전달되지만 숫자 ID를 UNIX 사용자 이름으로 변환해야 초기 인증을 위해 Windows 사용자 이름에 매핑할 수 있습니다. 예를 들어, 숫자 ID 1001이 Windows 사용자 "user1"에 대한 액세스를 허용하는 NTFS 보안 스타일 권한으로 NFS 탑재에 액세스하려고 시도하는 경우 예상되는 액세스 권한을 얻으려면 1001이 LDAP에서 "user1" 사용자 이름으로 확인되어야 합니다. LDAP에 "1001"이라는 숫자 ID를 가진 사용자가 없거나 LDAP가 잘못 구성된 경우 UNIX에서 Windows로의 이름 매핑은 1001@contoso.com으로 시도를 완료합니다. 대부분의 경우 해당 이름을 가진 사용자는 존재하지 않습니다. 결과적으로 인증이 실패하고 액세스가 거부됩니다. 마찬가지로 숫자 ID 1001이 잘못된 사용자 이름(예: user2)으로 확인되면 NFS 요청은 잘못된 Windows 사용자에 매핑됩니다(이 시나리오에서 user1은 user2에게 부여된 액세스 권한을 갖음).
"LDAP를 통해 로컬 NFS 사용자 허용"을 사용하도록 설정하면 숫자 ID를 사용자 이름으로 변환하는 모든 LDAP 기능이 사용하지 않도록 설정됩니다. 이 작업을 수행하면 NTFS 보안 스타일 볼륨에 대한 액세스가 효과적으로 차단됩니다. 따라서 NTFS 보안 스타일 볼륨에서 이 옵션을 사용하는 것은 권장되지 않습니다.