When does the DiskShare Authentication module need to be installed on every Backup Domain Controller and Primary Domain Controller?

This document will help you understand DiskShare Authentication requirements when mapping Windows Domain user accounts. DiskShare supports Windows NT, 2000, and Windows XP. Note, Windows is referred to throughout this document; however, it is a generic term for the DiskShare supported operating systems mentioned. This document is written from a support analyst’s point of view and deals primarily with the necessary information to comprehend and configure DiskShare for domain user mapping.

Additional Support Documents are located in the DiskShare\Support subdirectory. For detailed information regarding DiskShare configuration and user mapping see the DiskShare HELP, the Frequently Asked Questions (FAQ) document, and the DS_Mapping.doc support document.

DiskShare allows you to map Windows Local and Domain accounts to NFS accounts for the purpose of security and maintaining permissions. This is especially important because Windows and NFS accounts differ in the way they are represented to various operating systems. The Windows operating system represents users and groups in terms of Security IDs (SIDs) where as UNIX and Linux represent users and groups in terms of User IDs (UIDs) and Group IDs (GIDs).

This document will often use the term NFS account when referring to either users or groups as represented by UID and GID. DiskShare is designed to assume that the NFS clients that will be accessing its resources will represent its users and groups with UIDs and GIDs. DiskShare is responsible for translating NFS accounts (UIDs and GIDs) to the corresponding Windows equivalent accounts so as to allow or deny file system access and rights.

In order to perform the translations, DiskShare provides an accounts mapping utility, known as the DiskShare User Manager. However the utility relies on the fact that DiskShare is capable of acquiring Windows account information from either the local system or Windows Domain. To accomplish the task of retrieving the Windows account information, DiskShare provides an Authentication module to assist in the task.

If DiskShare is configured to map Windows Domain accounts, the DiskShare Authentication module must be installed on every Backup Domain Controller (or BDC) and Primary Domain Controller (or PDC).

This is because DiskShare makes a request to the Windows Local Security Authority (LSA) to obtain the credentials of the Windows domain user. The LSA passes the request thru the network to the domain controllers. If the DiskShare Authentication module is not present during the request for a network user, the domain cannot handle the request and the DiskShare authentication process fails.

When you map Windows Domain user accounts, DiskShare must be registered with LSA in order to obtain credentials of the Windows Domain User account.

This is accomplished by installing the DiskShare Authentication module on all the Backup Domain Controllers (BDC’s) and Primary Domain Controllers (PDC’s) that handle the domain of the mapped Users and Groups. Also, if there are Logon Servers that handle these requests for the domain, this machine is also required to install the DiskShare Authentication module.

For example, if I have an office in Houston that has domain controllers that are part of a Corporate Domain that is headquartered in New York, ideally you would only need to install the Authentication module to the domain controllers in Houston. In other words, if DiskShare is installed on the Houston domain controllers, you probably do not need to install the Authentication module to the other domain controllers, but because some Windows systems do not allow you to control where these network requests are sent, plus to insure that your User Mappings will be successful, it is strongly recommended that you install the Authentication module to all BDC’s and PDC’s and any related Logon Servers.

After the Authentication module is installed, the request for credentials should succeed. However there may be times when the request will fail. Often times the failure is due to one of the following conditions:

The account is unknown to the domain.
The account has been disabled.
The account is not valid, due to reasons, such as, password expiration, deleted account, etc.

NOTE

DiskShare has no control over the authentication request once it is given to the LSA.

In some cases, the domain controller that receives the request cannot be user-defined; therefore, the DiskShare Authentication module must be installed on all BDC’s, PDC’s, and related Logon Servers.

To install the DiskShare Authentication module: Take the DiskShare installation media to the BDC’s and the PDC’s that handle the domain and invoke “setup”. Continue installing DiskShare and when prompted for the Installation Option, select Custom/Complete Setup. Select the DiskShare Authentication option only and complete the DiskShare Authentication installation. No reboot is necessary if installing the DiskShare Authentication module only.

The Authentication module, if installed properly, sets the registry value, Auth170, to dssa. You can verify this by reviewing the registry key below.

HKEY_LOCAL_MACHINEonLocalMachine\System\CurrentControlSet\ Control\LSA\MSV1_0

NOTE

If DiskShare mapping (or authentication) fails, NFS access from that UNIX/Linux client is considered ‘anonymous’.

If ‘anonymous’ access occurs, DiskShare will generate an Event ID 16 in the Windows Event Viewer. An Event ID 16 is an alert message. Its sole purpose is to notify the DiskShare administrator that ‘anonymous’ access has occurred.