This page provides an overview about how to use Active Directory as LDAP server for NFS.
As described in Use cases for using Active Directory, NetApp Volumes can use Active Directory for NFS extended groups support, NFSv4 security identifiers, and Kerberos principals. Active Directory is the only LDAP server that the service supports. To enable these features, NetApp Volumes fetches the following information from the LDAP server:
- Mapping of UNIX username to UID
- Mapping of UNIX group name to GID
- All GIDs associated with a UID (up to 1,024)
NetApp Volumes uses the RFC2307bis schema to fetch this information. Active Directory already provides this schema, but you must populate the required attributes for your users and groups.
| UNIX attribute | LDAP attribute name |
|---|---|
| User name | uid |
| User UID | uidNumber |
| Group name | cn |
| Group GID | gidNumber |
For multi-protocol access, the Windows username must match the UNIX username to match UNIX UIDs to Windows SIDs.
NetApp Volumes caches the results of LDAP queries. The following table describes the time to live (TTL) settings for the LDAP cache. If the cache holds invalid data due to misconfigurations that you intend to fix, you must wait until the cache refreshes before your changes in Active Directory are detected. Otherwise, the NFS server continues to use the old data to verify access, which can result in permission denied notifications on the client. After the TTL period, entries age out so that stale entries don't linger. Missing lookup requests are retained for a one minute TTL to help avoid performance issues.
| Cache | Default timeout |
|---|---|
| Group membership list | 24-hour time to live |
| UNIX groups (GID) | 24-hour time to live, 2-hours negative time to live |
| UNIX users (UID) | 24-hour time to live, 2-hours negative time to live |
What's next
Manage customer-managed encryption key policies.