Azure NetApp Files에서 LDAP 사용 이해

아티클
06/13/2024

LDAP(Lightweight Directory Access Protocol)는 IETF(Internet Engineering Task Force)라는 국제 위원회에서 개발한 표준 디렉터리 액세스 프로토콜입니다. LDAP는 다른 유형의 플랫폼에서 네트워크 개체를 찾는 데 사용할 수 있는 범용 네트워크 기반 디렉터리 서비스를 제공하기 위한 것입니다.

LDAP 모델은 LDAP 디렉터리 저장소와 통신하는 방법, 디렉터리에서 개체를 찾는 방법, 저장소의 개체를 설명하는 방법과 디렉터리에 액세스하는 데 사용되는 보안을 정의합니다. LDAP를 사용하면 저장소에 설명된 개체를 사용자 지정하고 확장할 수 있습니다. 따라서 LDAP 저장소를 사용해 다양한 유형의 정보를 저장할 수 있습니다. 대부분의 초기 LDAP 배포는 이메일과 웹 애플리케이션 같은 애플리케이션용 디렉터리 저장소로 LDAP를 사용하고 직원 정보를 저장하는 데 중점을 두었습니다. 많은 회사에서 NIS(네트워크 정보 서비스)를 네트워크 디렉터리 저장소인 LDAP로 바꾸고 있거나 바꿨습니다.

LDAP 서버는 NAS 볼륨에 사용할 UNIX 사용자/그룹 ID를 제공합니다. Azure NetApp Files에서 Active Directory는 현재 사용할 수 있도록 지원되는 유일한 LDAP 서버입니다. 이 지원에는 AD DS(Active Directory Domain Services) 및 Microsoft Entra Domain Services가 모두 포함됩니다.

LDAP 요청은 두 가지 주요 작업으로 세분화할 수 있습니다.

LDAP 바인딩은 LDAP 클라이언트에서 LDAP 서버에 로그인하는 것입니다. 바인딩은 읽기 전용 액세스 권한으로 LDAP 서버를 인증하여 LDAP를 조회하는 데 사용됩니다. Azure NetApp Files는 LDAP 클라이언트 역할을 합니다.
LDAP 조회는 이름, 숫자 ID, 홈 디렉터리 경로, 로그인 셸 경로, 그룹 멤버 자격 등과 같은 사용자 및 그룹 정보에 대한 디렉터리를 쿼리하는 데 사용됩니다.

LDAP는 이중 프로토콜 NAS 액세스에 사용되는 다음과 같은 정보를 저장할 수 있습니다.

사용자 이름
그룹 이름
숫자 UID(사용자 ID) 및 GID(그룹 ID)
홈 디렉터리
로그인 셸
Netgroup, DNS 이름 및 IP 주소
그룹 구성원

현재 Azure NetApp Files는 사용자 및 그룹 정보에만 LDAP를 사용하고 netgroup 또는 호스트 정보에는 사용하지 않습니다.

LDAP는 UNIX 사용자와 그룹을 ID 원본으로 사용할 수 있는 다양한 이점을 제공합니다.

LDAP는 향후에도 사용할 수 있습니다.
더 많은 NFS 클라이언트에서 NFSv4.x 지원을 추가함에 따라 액세스를 정의할 때 최적의 보안 성능과 확실한 액세스를 보장하기 위해서는 클라이언트와 스토리지에서 액세스할 수 있는 사용자/그룹의 최신 목록이 포함된 NFSv4.x ID 도메인이 필요합니다. SMB/NFS 사용자에게 모두 일대일 이름 매핑을 제공하는 ID 관리 서버를 사용하면 현재뿐만 아니라 향후 몇 년간 스토리지 관리자의 업무가 크게 간소화됩니다.
LDAP는 확장성이 있습니다.
LDAP 서버는 수백만 개의 사용자/그룹 개체를 포함할 수 있는 기능을 제공하며, Microsoft Active Directory에서 여러 서버를 사용해 여러 사이트에 복제하면 성능과 복원력을 모두 스케일링할 수 있습니다.
LDAP는 안전합니다.
LDAP는 스토리지 시스템이 LDAP 서버에 연결하여 사용자 정보를 요청하는 방식으로 보안을 제공합니다. LDAP 서버는 다음과 같은 바인딩 수준을 제공합니다.
- 익명(Microsoft Active Directory에서 기본적으로 사용되지 않음, Azure NetApp Files에서 지원되지 않음)
- 간단한 암호(일반 텍스트 암호, Azure NetApp Files에서 지원되지 않음)
- SASL(Simple Authentication and Security Layer) – TLS, SSL, Kerberos 등을 포함해 암호화된 바인딩 메서드 Azure NetApp Files는 LDAP over TLS, LDAP 서명(Kerberos 사용), LDAP over SSL을 지원합니다.
LDAP는 강력합니다.
NIS, NIS+ 및 로컬 파일은 UID, GID, 암호, 홈 디렉터리 등의 기본 정보를 제공합니다. 그러나 LDAP는 이러한 특성 외에 다양한 특성을 제공합니다. LDAP에서 사용하는 추가 특성은 이중 프로토콜 관리 기능을 NIS에 비해 LDAP와 훨씬 더 많이 통합해 줍니다. Azure NetApp Files를 사용해 ID를 관리하기 위한 외부 이름 서비스로 LDAP만 지원됩니다.
Microsoft Active Directory는 LDAP를 기반으로 합니다.
기본적으로 Microsoft Active Directory는 사용자/그룹 항목에 LDAP 백 엔드를 사용합니다. 그러나 이 LDAP 데이터베이스에는 UNIX 스타일 특성이 포함되어 있지 않습니다. 이러한 특성은 UNIX용 ID 관리(Windows 2003R2 이상), UNIX 서비스(Windows 2003 이하) 또는 Centrify 같은 타사 LDAP 도구를 통해 LDAP 스키마를 확장할 때 추가됩니다. Microsoft는 LDAP를 백 엔드로 사용하기 때문에 LDAP는 Azure NetApp Files에서 이중 프로토콜 볼륨을 활용하기로 선택한 환경에 이상적인 솔루션입니다.

참고 항목

Azure NetApp Files는 현재 LDAP 서비스용 기본 Microsoft Active Directory만 지원합니다.

Azure NetApp Files의 LDAP 기본 사항

다음 섹션에서는 Azure NetApp Files와 관련된 LDAP의 기본 사항을 설명합니다.

LDAP 정보는 LDAP 서버의 플랫 파일에 저장되며 LDAP 스키마를 통해 구성됩니다. LDAP 서버의 스키마를 사용하여 요청과 조회를 조정하는 방식으로 LDAP 클라이언트를 구성해야 합니다.
LDAP 클라이언트는 LDAP 바인딩을 통해 쿼리를 시작합니다. 이 바인딩에서는 기본적으로 LDAP 스키마에 대한 읽기 액세스 권한이 있는 계정을 사용하여 LDAP 서버에 로그인합니다. 클라이언트의 LDAP 바인딩 구성은 LDAP 서버에서 정의한 보안 메커니즘을 사용하도록 구성됩니다. 일반 텍스트(단순)로 사용자 이름과 암호를 교환하는 경우도 있습니다. 또 어떤 경우에는 바인딩이 Kerberos 또는 LDAP over TLS 같은 단순 인증 및 보안 계층 메서드(sasl)를 통해 보호됩니다. Azure NetApp Files는 최상의 보안 성능을 제공하기 위해 SASL 인증을 통해 바인딩하는 데 SMB 컴퓨터 계정을 사용합니다.
LDAP에 저장된 사용자 및 그룹 정보는 RFC 2307에 정의된 표준 LDAP 검색 요청을 사용하여 클라이언트에서 쿼리합니다. 또한 RFC 2307bis 같은 최신 메커니즘을 통해 더욱 간소하게 사용자와 그룹을 조화할 수 있습니다. Azure NetApp Files는 Windows Active Directory의 스키마 조회에 RFC 2307bis 형식을 사용합니다.
LDAP 서버는 사용자 및 그룹 정보와 netgroup을 저장할 수 있습니다. 그러나 Azure NetApp Files는 현재 Windows Active Directory의 LDAP에서 netgroup 기능을 사용할 수 없습니다.
Azure NetApp Files의 LDAP는 포트 389에서 작동합니다. 현재 이 포트는 포트 636(SSL을 통해 LDAP) 또는 포트 3268(Active Directory 글로벌 카탈로그 검색)과 같은 사용자 지정 포트를 사용하도록 수정할 수 없습니다.
암호화된 LDAP 통신은 LDAP over TLS(포트 389를 통해 작동) 또는 LDAP 서명을 사용하여 수행할 수 있으며, 둘 다 Active Directory 연결에서 구성할 수 있습니다.
Azure NetApp Files는 완료하는 데 3초 이상 걸리지 않는 LDAP 쿼리를 지원합니다. LDAP 서버에 개체가 많은 경우 이 시간 제한을 초과하여 인증을 요청하지 못할 수 있습니다. 이러한 경우 성능을 향상시키려면 쿼리를 필터링하도록 LDAP 검색 범위를 지정하는 것이 좋습니다.
Azure NetApp Files는 요청 속도를 높이는 데 도움이 되는 기본 LDAP 서버 지정도 지원합니다. Azure NetApp Files 지역에 가장 가까운 LDAP 서버를 사용하려면 이 설정을 사용합니다.

기본 LDAP 서버가 설정되지 않은 경우 LDAP 서비스 레코드용 DNS에서 Active Directory 도메인 이름을 쿼리하여 해당 SRV 레코드 내 지역에서 사용할 수 있는 LDAP 서버 목록을 채웁니다. nslookup 또는 dig 명령을 사용하여 클라이언트에서 DNS의 LDAP 서비스 레코드를 수동으로 쿼리할 수 있습니다.

예시:

C:\>nslookup
Default Server:  localhost
Address:  ::1

> set type=SRV
> _ldap._tcp.contoso.com.

Server:  localhost
Address:  ::1

_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 0
          port           = 389
          svr hostname   = oneway.contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = ONEWAY.Contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = oneway.contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = parisi-2019dc.contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = contoso.com
oneway.contoso.com       internet address = x.x.x.x
ONEWAY.Contoso.com       internet address = x.x.x.x
oneway.contoso.com       internet address = x.x.x.x
parisi-2019dc.contoso.com        internet address = y.y.y.y
contoso.com      internet address = x.x.x.x
contoso.com      internet address = y.y.y.y

LDAP 서버는 사용자가 사용자 지정 이름을 매핑하는 데에도 사용할 수 있습니다. 자세한 내용은 LDAP를 사용한 사용자 지정 이름 매핑을 참조하세요.
LDAP 쿼리 시간 초과

기본적으로 LDAP 쿼리는 적시에 완료할 수 없는 경우 시간이 초과됩니다. 시간 제한으로 인해 LDAP 쿼리에 실패하면 사용자 및/또는 그룹 조회에 실패하고, 볼륨의 권한 설정에 따라 Azure NetApp Files 볼륨에 대한 액세스가 거부될 수 있습니다. Azure NetApp Files LDAP 쿼리 시간 제한 설정을 이해하려면 Active Directory 연결 만들기 및 관리를 참조하세요.

이름 매핑 형식

이름 매핑 규칙은 대칭과 비대칭의 두 가지 주요 형식으로 나눌 수 있습니다.

대칭 이름 매핑은 같은 사용자 이름을 이용하는 UNIX 사용자와 Windows 사용자 간의 암시적 이름 매핑입니다. 예를 들어 CONTOSO\user1 Windows 사용자는 user1 UNIX 사용자에게 매핑됩니다.
비대칭 이름 매핑은 다른 사용자 이름을 이용하는 UNIX 사용자와 Windows 사용자 간의 이름 매핑입니다. 예를 들어 CONTOSO\user1 Windows 사용자는 user2 UNIX 사용자에게 매핑됩니다.

기본적으로 Azure NetApp Files는 대칭 이름 매핑 규칙을 사용합니다. 비대칭 이름 매핑 규칙이 필요한 경우 이를 사용하도록 LDAP 사용자 개체를 구성하는 것이 좋습니다.

LDAP를 이용한 사용자 지정 이름 매핑

LDAP 서버의 LDAP 스키마 특성이 채워진 경우 LDAP는 이름 매핑 리소스일 수 있습니다. 예를 들어 UNIX 사용자를 일대일로 일치하지 않는(즉 비대칭) 해당 Windows 사용자 이름에 매핑하려면 Windows 사용자 이름에 구성된 값과 다른 사용자 개체의 uid 값을 지정하면 됩니다.

다음 예제에서 사용자는 Windows 이름이 asymmetric이고 UNIX ID UNIXuser에 매핑되어야 합니다. Azure NetApp Files에서 이를 달성하려면 Active Directory 사용자 및 컴퓨터 MMC의 인스턴스를 엽니다. 그런 다음 원하는 사용자를 찾아 속성 상자를 엽니다. (이렇게 하려면 특성 편집기를 사용해야 합니다.) 특성 편집기 탭으로 이동하여 UID 필드를 찾은 다음 원하는 UNIX 사용자 이름(UNIXuser)으로 UID 필드를 채우고 추가와 확인을 차례대로 클릭하여 확인합니다.

이 작업이 완료되면 asymmetric Windows 사용자가 Windows SMB 공유에서 작성한 파일을 NFS 쪽 UNIXuser가 소유하게 됩니다.

다음 예제는 Windows SMB 소유자 asymmetric을 보여 줍니다.

다음 예제는 NFS 소유자 UNIXuser(LDAP를 이용해 Windows 사용자 asymmetric에서 매핑됨)를 보여 줍니다.

root@ubuntu:~# su UNIXuser
UNIXuser@ubuntu:/root$ cd /mnt
UNIXuser@ubuntu:/mnt$ ls -la
total 8
drwxrwxrwx  2 root     root   4096 Jul  3 20:09 .
drwxr-xr-x 21 root     root   4096 Jul  3 20:12 ..
-rwxrwxrwx  1 UNIXuser group1   19 Jul  3 20:10 asymmetric-user-file.txt

LDAP를 사용하는 로컬 NFS 사용자 허용

사용자가 NFS를 통해 Azure NetApp Files 볼륨에 액세스하려고 하면 요청이 숫자 ID로 제공됩니다. 기본적으로 Azure NetApp Files는 NFS 사용자에 대한 확장된 그룹 멤버 자격을 지원합니다(표준 16개 그룹 제한을 초과). 따라서 Azure NetApp 파일은 해당 숫자 ID를 가져와서 RPC 패킷에 그룹 멤버 자격을 전달하는 대신 사용자에 대한 그룹 멤버 자격을 확인하기 위해 LDAP에서 조회합니다. 이 동작으로 인해 LDAP에서 사용자에게 해당 숫자 ID를 확인할 수 없는 경우 조회가 실패하고 요청 중인 사용자에게 볼륨 또는 데이터 구조에 액세스할 수 있는 권한이 있더라도 액세스가 거부됩니다. Active Directory 연결에서 LDAP를 사용하여 로컬 NFS 사용자 허용 옵션은 확장된 그룹 기능을 사용하지 않도록 설정하여 NFS 요청에 대해 이러한 LDAP 조회를 사용하지 않도록 설정하기 위한 것입니다. Azure NetApp Files 내에서 “로컬 사용자 만들기/관리”를 제공하지 않습니다.

"LDAP를 사용하여 로컬 NFS 사용자 허용" 옵션을 사용하도록 설정하면 숫자 ID가 Azure NetApp Files에 전달되고 LDAP 조회가 수행되지 않습니다. 이렇게 하면 아래와 같이 다양한 시나리오에 대해 다양한 동작이 생성됩니다.

UNIX 보안 스타일 볼륨이 있는 NFSv3

숫자 ID는 사용자 이름으로 변환할 필요가 없습니다. "LDAP를 사용하여 로컬 NFS 사용자 허용" 옵션은 볼륨에 대한 액세스에 영향을 주지 않지만 사용자/그룹 소유권(이름 변환)이 NFS 클라이언트에 표시되는 방식에 영향을 줄 수 있습니다. 예를 들어 1001의 숫자 ID가 LDAP의 user1이지만 NFS 클라이언트의 로컬 passwd 파일에서 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 동작으로 대체되기 때문에 NFSv4.1 액세스에는 영향을 주지 않습니다. Azure NetApp Files에는 일부 클라이언트에 문제가 될 수 있는 기본 UNIX 사용자 집합이 있으며 도메인 ID 문자열이 일치하지 않는 경우 "아무도" 사용자로 스쿼시할 수 있습니다.

로컬 사용자는 루트(0), pcuser(65534), 아무도(65535)를 포함합니다.
로컬 그룹에는 루트(0), 디먼(1), pcuser(65534), 아무도(65535)가 포함됩니다.

가장 일반적으로 루트는 NFSv4.1 도메인 ID가 잘못 구성된 경우 NFSv4.1 클라이언트 탑재에서 잘못 표시할 수 있습니다. 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(v3 및 v4.1)

UNIX 보안 스타일 볼륨은 UNIX 스타일 권한(모드 비트 및 NFSv4.1 ACL)을 활용합니다. 이러한 유형의 볼륨에 대해 NFS는 위에 나열된 시나리오에 따라 숫자 ID 또는 이름 문자열을 활용하는 UNIX 스타일 인증만 활용합니다. 그러나 NTFS 보안 스타일 볼륨은 NTFS 스타일 권한을 사용합니다. 이러한 권한은 Windows 사용자 및 그룹을 사용하여 할당됩니다. NFS 사용자가 NTFS 스타일 권한이 있는 볼륨에 액세스하려고 하면 적절한 액세스 제어를 보장하기 위해 UNIX에서 Windows로의 이름 매핑이 발생해야 합니다. 이 시나리오에서는 NFS 숫자 ID가 여전히 Azure NetApp Files NFS 볼륨에 전달되지만 초기 인증을 위해 Windows 사용자 이름에 매핑될 수 있도록 숫자 ID를 UNIX 사용자 이름으로 변환해야 합니다. 예를 들어 숫자 ID 1001이 Windows 사용자 "user1"에 대한 액세스를 허용하는 NTFS 보안 스타일 권한으로 NFS 탑재에 액세스하려고 하면 LDAP에서 1001을 "user1" 사용자 이름으로 확인하여 예상된 액세스 권한을 얻어야 합니다. 숫자 ID가 "1001"인 사용자가 LDAP에 없거나 LDAP가 잘못 구성된 경우 UNIX에서 Windows로의 이름 매핑이 시도됩니다 1001@contoso.com. 대부분의 경우 해당 이름을 가진 사용자가 없으므로 인증이 실패하고 액세스가 거부됩니다. 마찬가지로 숫자 ID 1001이 잘못된 사용자 이름(예: user2)으로 확인되면 NFS 요청이 예기치 않은 Windows 사용자에게 매핑되고 사용자에 대한 권한은 "user2" 액세스 제어를 사용합니다.

"LDAP를 사용하여 로컬 NFS 사용자 허용"을 사용하도록 설정하면 숫자 ID의 모든 LDAP 변환을 사용자 이름으로 사용하지 않도록 설정하면 NTFS 보안 스타일 볼륨에 대한 액세스가 효과적으로 중단됩니다. 따라서 NTFS 보안 스타일 볼륨에서 이 옵션을 사용하는 것은 권장되지 않습니다.

LDAP 스키마

LDAP 스키마는 LDAP 서버가 정보를 구성하고 수집하는 방법입니다. LDAP 서버 스키마는 일반적으로 동일한 표준을 따르지만, LDAP 서버 공급자마다 스키마가 표시되는 방식이 다를 수도 있습니다.

Azure NetApp Files가 LDAP를 쿼리할 때 스키마를 사용하면 특정 특성을 이용해 UID와 같은 사용자 정보를 찾을 수 있으므로 이름 조회 속도를 높이는 데 도움이 됩니다. Azure NetApp Files에서 항목을 찾을 수 있으려면 스키마 특성이 LDAP 서버에 있어야 합니다. 그렇지 않으면 LDAP 쿼리가 데이터를 반환하지 않을 수도 있고 인증 요청에 실패할 수도 있습니다.

예를 들어 Azure NetApp Files에서 UID 번호(예: root=0)를 쿼리해야 하는 경우 스키마 특성 RFC 2307 uidNumber Attribute가 사용됩니다. UID 번호 0이 uidNumber 필드의 LDAP에 없으면 조회 요청에 실패합니다.

현재 Azure NetApp Files에서 사용하는 스키마 형식은 RFC 2307bis를 기반으로 하는 스키마 형식이며, 수정할 수 없습니다.

RFC 2307bis는 RFC 2307의 확장이며, posixGroup에 대한 지원을 추가합니다. 이를 통해 LDAP 스키마에서 memberUid 특성을 사용하는 대신 uniqueMember 특성을 사용하여 추가 그룹에서 동적 조회를 사용할 수 있습니다. 이 특성은 사용자 이름만 사용하는 것이 아니라 LDAP 데이터베이스에 있는 다른 개체의 전체 DN(고유 이름)을 포함합니다. 따라서 그룹은 다른 그룹을 멤버로 포함하여 그룹이 중첩될 수 있습니다. RFC 2307bis에 대한 지원은 groupOfUniqueNames 개체 클래스에 대한 지원도 추가합니다.

이 RFC 확장은 Microsoft Active Directory가 일반적인 관리 도구를 통해 사용자와 그룹을 관리하는 방법으로 매우 적합합니다. 이는 표준 Windows 관리 방법을 사용하여 그룹에 Windows 사용자를 추가할 때(해당 그룹에 유효한 숫자 GID가 있는 경우) LDAP 조회가 일반적인 Windows 특성에서 필요한 보조 그룹 정보를 가져와 숫자 GID를 자동으로 찾기 때문입니다.

다음을 통해 공유