Google Cloud NetApp Volumes Active Directory integration

This page describes the Google Cloud NetApp Volumes Active Directory integration.

About the integration

An Active Directory policy tells NetApp Volumes how to connect to Active Directory. Storage pool configurations use Active Directory policies to define the Active Directory settings of volumes you create within them.

Active Directory policies are region-specific and you can configure up to five policies per region.

File sharing protocols—such as SMB (CIFS), NFSv3 with extended groups, and NFSv4—using security principals, rely on external directory services to provide user identity information. NetApp Volumes relies on Active Directory for directory services. Active Directory provides the following services:

  • LDAP servers: look up objects such as users, groups, or machines

  • DNS servers: resolve host names and discovery of Active Directory domain controllers

  • Kerberos servers: perform authentication

For more information, see Best practices for running Active Directory on Google Cloud.

Use cases for Active Directory

NetApp Volumes uses Active Directory for several use cases:

  • SMB domain service: Active Directory is the central domain service for SMB. It uses SMB for authentication and identity lookups for users and groups. NetApp Volumes joins the domain as a member but doesn't support SMB in workgroup mode.

  • NFSv3 extended group support: for NFSv3 with extended group support, Active Directory provides the LDAP server required to look up objects such as users, groups, or machine accounts. Specifically, user ID and group ID lookups require an RFC2307bis-compliant LDAP server. LDAP support is enabled on storage pools during pool creation.

    Extended group support ignores all group IDs sent by the NFS client in an NFS call. Instead, it takes the user ID of the request and looks up all group IDs for the given user ID from the LDAP server to do file permission checks.

    For more information, see Manage LDAP RFC2307bis POSIX attributes.

  • NFSv4.x security principal to user ID and group ID mapping: for NFSv4.x, NetApp Volumes uses Active Directory to map security principals to user IDs and group IDs. NFSv4 uses a principal-based authentication model. In principal-based authentication, security principals identify users which take the form user@dns_domain (see RFC 7530 security considerations) instead of user IDs and group IDs. To map security principals to user IDs and group IDs when you access the volume with an NFSv4.x protocol, NetApp Volumes requires an RFC2307bis-compliant LDAP server. NetApp Volumes only supports Active Directory LDAP servers. LDAP support is enabled on storage pools during pool creation.

    To use security principals, the NFS client and server must connect to the same LDAP source and you must configure the idmapd.conf file at the client. For more information on how to configure the idmapd.conf file, see Ubuntu documentation on how to configure the idmapd.conf file for libnfsidmap.

    The dns_domain uses the Active Directory domain name and the user identifies as the name of the Active Directory user. Use these values when you set your LDAP POSIX attributes.

    To use NFSv4.1 without ID mapping and only use user IDs and group IDs similar to NFSv3, use numeric IDs to ignore security principals. NetApp Volumes supports numeric IDs. Current NFS clients use numeric IDs by default if ID mapping isn't configured.

  • NFSv4.x with Kerberos: if you use Kerberos, it's mandatory to use Active Directory as the LDAP server for security principal lookups. Kerberos principals are used as security identifiers. The Kerberos Key Distribution Center uses Active Directory. To make this work, you must attach an Active Directory policy that contains Kerberos settings to the pool and enable LDAP support on a storage pool when you create the pool.

Required permissions to create Active Directory machine accounts

You can add NetApp Volumes machine objects to a Windows Active Directory with an account which has permissions to join a computer to the domain. This group is usually the Domain Admins group, but Active Directory has the capability to delegate the required permissions to individual users or groups on a full domain or organizational unit level.

You can grant these permissions with the Delegation of Control Wizard in Active Directory by creating a custom task that lets you create and delete computer objects with the following access permissions:

  • Read and write

  • Create and delete all child objects

  • Read and write all properties

  • Change and reset password ("Read and write domain password & lockout policies")

Delegating a user adds a security access control list for the defined user to the organizational unit in Active Directory and minimizes the access to the Active Directory environment. Once a user has been delegated, you can provide the username and password as Active Directory policy credentials.

For added security, during the machine account object query and creation, the username and password that are passed to the Active Directory domain use Kerberos encryption.

Active Directory domain controllers

To connect NetApp Volumes to your domain, the service uses DNS-based discovery to identify a list of available domain controllers to use.

The service runs the following steps to find a domain controller to use:

  1. Active Directory Site discovery: NetApp Volumes uses an LDAP ping to the DNS server IP specified in the Active Directory policy to fetch the Active Directory Site subnet information. It returns a list of CIDRs and the Active Directory Sites which are assigned to those CIDRs.

    Get-ADReplicationSubnet -Filter * | Select-Object Name,Site

  2. Define site names: if the IP address of the volume matches any of the defined subnets, the associated site name is used. Smaller subnets matches take precedence over larger subnets matches. If the IP address of the volume is unknown, manually create a temporary volume with the NFS protocol type to determine /28 CIDR used.

    If no site name is defined in the Active Directory, the site name configured in the Active Directory policy is used. If no site name is configured, the Standard, Premium, and Extreme service levels use the Default-First-Site-Name site. If the Flex service level tries to use the Default-First-Site-Name site, it will fail and the Flex service level instead uses the full domain controller discovery. Note that changes to the Active Directory site parameter are ignored by Flex service level storage pools.

  3. Domain controller discovery: with all necessary information acquired, the service identifies potential domain controllers using the following DNS query:

    nslookup -type=srv _ldap._tcp.<site_name>._sites.dc._msdcs.<domain-name> <dns-server>

    For full domain discovery, the service uses the following DNS query:

    nslookup -type=srv _ldap._tcp.dc._msdcs.<domain-name> <dns-server>

  4. Domain controller list generation: a list of domain controllers is generated. NetApp Volumes constantly monitors all of them for availability. Out of the available domain controllers, it selects one for domain join and lookups. If the selected domain controller goes away, another domain controller from the Available list is used automatically. Note that the domain controller you choose isn't necessarily the specified DNS server.

You need to provide at least one accessible domain controller for the service to use. We recommend several for better domain controller availability. Make sure there is a routed network path between NetApp Volumes and the domain controllers, and that the firewall rules on your domain controllers allow NetApp Volumes to connect.

For more information, see Active Directory design considerations and best practices.

Active Directory domain controller topologies

Once you successfully connect to Active Directory domain controllers, you can use the following file sharing protocols:

  • SMB

  • NFSv3 with extended groups

  • NFSv4 with security principals and Kerberos

The following scenarios describe potential topologies. The scenarios describe only the domain controller used by NetApp Volumes. Other domain controllers for the same domain are described only where required. We recommend that you deploy at least two domain controllers for redundancy and availability.

  • Active Directory domain controller and volumes in one region: this scenario is the simplest deployment strategy where a domain controller is in the same region as the volume.

  • Active Directory domain controller and volumes in separate regions: you can use a domain controller in a different region from a volume. This might negatively affect authentication and file access performance.

  • Active Directory domain controllers in multiple regions using AD sites: if you use volumes in multiple regions, we recommend that you place at least one domain controller in each region. While the service tries to choose the best domain controller to use automatically, we recommend that you manage domain controller selection with Active Directory sites.

  • Active Directory domain controller in an on-premises network: you can use an on-premise domain controller over VPN, but it can negatively affect end user authentication and file access performance. Make sure to not add additional Virtual Private Cloud peering hops in your network path. VPC peering is subject to transitive routing restrictions. Traffic is not routed beyond the VPC peering hop that NetApp Volumes already consumes.

  • Active Directory domain controller in a different VPC network: you can't place the domain controller in a different VPC because Google Cloud VPC peering doesn't allow transitive routing. Alternatively, you can connect the VPCs using VPN or attach NetApp Volumes to a shared VPC network that hosts the Active Directory domain controllers. If you attach NetApp Volumes to a shared VPC network, then, architecturally, this scenario becomes the same as one of the scenarios in the previous sections.

What's next

Create an Active Directory policy.