Azure NetApp Files의 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를 자동으로 찾기 때문입니다.
Azure NetApp Files 볼륨이 NFS 사용자 ID에 대해 LDAP 조회를 수행해야 하는 경우 RFC-2307bis를 기반으로 LDAP 스키마에서 정의한 일련의 특성입니다. 다음 표에서는 UNIX 특성을 사용할 때 Microsoft Active Directory에 정의된 기본값인 LDAP 조회에서 사용되는 특성을 보여 줍니다. 적절한 기능을 위해 이러한 특성이 LDAP의 사용자 및 그룹 계정에 제대로 채워져 있는지 확인합니다.
| UNIX 특성 | LDAP 스키마 값 |
|---|---|
| UNIX 사용자 이름 | uid* |
| UNIX 사용자 숫자 ID | uidNumber* |
| UNIX 그룹 이름 | cn* |
| UNIX 그룹 숫자 ID | gidNumber* |
| UNIX 그룹 멤버 자격 | 구성원** |
| UNIX 사용자 개체 클래스 | 사용자** |
| UNIX 홈 디렉터리 | unixHomeDirectory |
| UNIX 표시 이름 | gecos |
| UNIX 사용자 암호 | unixUserPassword |
| UNIX 로그인 셸 | LoginShell |
| 이름 매핑에 사용되는 Windows 계정 | sAMAccountName** |
| UNIX 그룹 개체 클래스 | 그룹** |
| UNIX 멤버 UID | memberUid*** |
| 고유 이름 개체 클래스의 UNIX 그룹 | 그룹** |
* 적절한 LDAP 기능에 필요한 특성
** 기본적으로 Active Directory에 채워집니다.
필요하지 않음
LDAP 특성 인덱싱 이해
Active Directory LDAP는 조회 요청 속도를 향상하는 데 도움이 되는 특성에 대한 인덱싱 방법을 제공합니다. 이는 LDAP 검색이 Azure NetApp Files의 조회에 대한 10초 제한 시간 값을 초과할 수 있는 큰 디렉터리 환경에서 특히 유용합니다. 검색이 제한 시간 값을 초과하면 LDAP 조회가 실패하고 서비스에서 액세스를 요청하는 사용자 또는 그룹 ID를 확인할 수 없으므로 액세스가 제대로 작동하지 않습니다.
기본적으로 Microsoft Active Directory LDAP는 LDAP 조회를 위해 Azure NetApp Files에서 사용하는 다음 UNIX 특성을 인덱싱합니다.
uid 특성은 기본적으로 인덱싱되지 않습니다. 결과적으로 UID에 대한 LDAP 쿼리는 인덱싱된 특성에 대한 쿼리보다 더 많은 시간이 소요됩니다.
예를 들어 사용자 및 그룹이 20,000명 이상인 Active Directory 환경의 쿼리에 대한 다음 테스트에서 인덱싱된 특성 CN을 사용하는 사용자를 검색하는 데 약 0.015초가 걸렸으며 UID 특성이 있는 동일한 사용자(기본적으로 인덱싱되지 않음)에 대한 검색은 0.6초(40배 느려짐)에 가깝습니다.
작은 환경에서는 문제가 발생하지 않습니다. 그러나 더 큰 환경(또는 Active Directory 환경이 온-프레미스에 있거나 네트워크 대기 시간이 높은 환경)에서는 Azure NetApp Files 볼륨에 액세스하는 사용자에게 액세스 문제를 일으킬 만큼 차이가 클 수 있습니다. 따라서 Active Directory에서 인덱싱되도록 LDAP에서 UID 특성을 구성하는 것이 가장 좋습니다.
Active Directory에서 인덱싱할 UID 특성 구성
특성은 특성 개체의 값을 통해 인덱싱되며 스키마 명명 컨텍스트에서 ADSI 편집을 통해 구성할 수 있습니다.searchFlags ADSI 편집에 대한 액세스는 신중하게 접근해야 하며 최소한 스키마 관리자 권한이 필요합니다.
기본적으로 uid 특성 개체는 searchFlags 0x8(PRESERVE_ON_DELETE)로 설정됩니다. 이 기본 설정은 Active Directory의 개체가 삭제되더라도 특성 값이 사용자 특성의 기록 레코드로 디렉터리에 저장되도록 합니다.
이에 비해 LDAP 검색을 위해 Active Directory에서 인덱싱된 특성은 uidNumber와 같은 0x1(또는 해당 값을 포함한 일부 조합)의 값을 갖습니다.
이 때문에 uidNumber에 대한 쿼리는 uid에 대한 쿼리보다 빠르게 반환됩니다. 일관성 및 성능을 위해 기존 값인 0x8(INDEX |)와 함께 0x1 추가하여 uid 값을 9로 조정할 searchFlags 수 있습니다. PRESERVE_ON_DELETE). 이 추가 기능은 디렉터리에 특성 인덱싱을 추가하는 동안 기본 동작을 유지합니다.
인덱싱을 사용하면 uid가 있는 사용자 특성을 검색하는 것이 다른 인덱싱된 특성을 검색하는 것만큼 빠릅니다.