Background
The File Share connector provided in Discovery Center uses the standard Windows API for accessing content using SMB protocols. However, there are a range of other repositories that can be accessed using that connector provided appropriate configuration is in place.
For access to content held on Unix servers, customers typically use an SMB connection through the Samba suite of applications emulating a Windows server. However it is also possible to access content exported via the native Unix NFS format as long as the Discovery Center application server is configured specifically to support this.
Assumptions
This document makes the following assumptions:
- The data to be indexed is already shared via NFS
- Unix accounts have been identified with permission to access the data to be indexed.
- Certain properties of NFS export configurations have been made to support the Identity Mapping approach outlined below.
Further, it assumes that the security considerations outlined below are understood and acceptable.
Prerequisite configuration
In order to access NFS exported data, the application server hosting Discovery Center must be configured with additional Windows features to provide NFS connectivity. Add these features via PowerShell as follows:
- Import-Module ServerManager
- Install-WindowsFeature -Name FS-NFS-Service
- Install-WindowsFeature NFS-Client
Alternatively, add the required capability by making the following selections in Windows Server Manager:
In order for NFS data to be accessed the Windows NFS client code must be able to map an Active Directory user to a Unix user and group id, a process referred to as Identity Mapping. Configure this using the following steps:
Identify Accounts
- Identify a Unix account that will be used to access the NFS content to be indexed.
- Create an Active Directory user account that will be mapped to the Unix account.
Enable Active Directory Lookup for Mapping
On the Discovery Center application server, run the PowerShell command:
Set-NfsMappingStore -EnableADLookup $true
Identify Unix IDs for Mapping
The identity mapping mechanism makes use of Active Directory schema updates to add “uidNumber” and “gidNumber” attributes to user and group accounts. This requires Active Directory domains running at a functional level of Windows Server 2003 R2 or higher.
Get the UID and GID values for the selected UNIX account. In a Linux environment, for example, use the following commands:
$ id ANAdmin
uid=1000(ANAdmin) gid=1000(ANAdmin) groups=1000(ANAdmin)
Associate Active Directory Account with Unix Account
Using the 'uid' and 'gid' returned above, set the identity mapping from Active Directory account to Unix account in your Windows environment using the following PowerShell command:
Set-NfsMappedIdentity -UserName <AD ACCOUNT> -UserIdentifier <UID> -GroupIdentifier <GID>
Testing NFS Access
Once the required identity mapping is in place, access to NFS data should be tested. On the Discovery Center application server where NFS access has been enabled, this can be achieved by testing data access using the mount command.
First validate that the NFS server hostname can be resolved correctly from the Discovery Center application server. This can be done using the NSLOOKUP or PING commands. If the hostname cannot be resolved you will need to use an IP address instead. Validate the IP address using the PING command.
Once connectivity to the NFS server has been validated an NFS data export can be mapped to a local Windows drive letter to the NFS data export using this command:
mount -o \\<SERVER>\<SHARENAME> <DRIVELETTER>
For example:
mount -o \\10.46.64.13\share2 Z:
If the mount process fails with error code 85, ensure that the chosen drive letter is free on the application server.
The most common error code is 53, this is a generic error and may be encountered for both connectivity and authentication issues. If the basic connectivity checks above have been carried out check for errors that may have been logged at the NFS server and review the identity mapping settings and permissions on the exported data. It has been found that on NetApp servers specific settings are required to overcome this error message.
Configuring a Discovery Center Index
Once NFS mount have been success, Discovery Center will be able to index that data using the UNC path that was used to mount a drive. That is, \\10.46.64.13\share2 in the example above.
Credentials should be configured within Discovery Center Network Map using the Active Directory account used for Identity Mapping above. All normal indexing operations will then possible.
Note that UNC paths generated for NFS content will only be valid (e.g. to access documents) on systems where NFS access has been configured. This means, for example, that the UNC paths presented in the Discovery Center user interface or in an CSV/XLSX export may not be usable on workstations.
Security Considerations
The default Unix security model is not as full featured as that provided by Windows; as a result it may be difficult to identify an account which has access across the whole of any given NFS export. This means that it may be necessary to add the chosen Unix user to existing groups to enable access.
Important factors that will affect the approach that can be taken, and which will vary according to the nature of the data, are:
- Is data already exported via NFS
- Is the data in use with any other applications or user communities (will changing permissions impact on other uses)
- If data is already exported what permissions approach has been utilised to control access? Is there a consistent security model from the "root" of the share.
- Where NFS is used, what versions of NFS are typically in use? Later versions of NFS provide a richer security model that mirrors Windows style permissions but this is beyond the scope of this document.
Linux Export Configuration
The above examples use a RedHat Enterprise Linux Server 7.5; however the processes should be similar for any Linux environment. In testing it was identified that Linux root_squash and all_squash caused problems with Discovery Center's access to content. Your Unix/Linux administrator should be consulted in order to ensure these (or similar) settings are not enabled or otherwise accounted for when selecting the Unix user to access the content.
System Specific Configuration
Some additional configuration may be required for specific platforms. Where we have become aware of such steps they will be documented here.
NetApp
Some NetApp devices may require these commands to be run to allow the Windows NFS client to interact with them.