Authentication
Configuring authentication is one of the most important tasks after successfully installing and configuring the IBM Scale Out Network Attached Storage (SONAS) system. Setting up authentication correctly is essential, because it is the entry point to data that is stored on the SONAS system for users. Authentication and authorization ensure data security.
This chapter includes the following information:
2.1 Introduction to authentication preferred practices
It is important to plan for the type of authentication to be configured in the SONAS. Planning for authentication is based on any or all of the following considerations:
•Whether replication is configured on the SONAS system
•What type of clients access SONAS data (Microsoft Windows clients, UNIX clients, or a combination of clients)
•What authentication method was used before adding the SONAS
•Whether multiple domains are available
•How the existing data is being migrated to SONAS
•Whether the authentication servers have been upgraded recently
•Whether an external authentication server is required
|
Important: Do not change authentication after SONAS is configured, because reconfiguration might lead to data access loss. Migration of authentication is unsupported. When it is configured, the only way to change authentication is by cleaning up all previously configured authentication and starting again.
|
The following sections describe the various preferred practices to be implemented for authentication to work well.
For a detailed overview of SONAS authentication, see IBM SONAS Implementation Guide, SG24-7962 and the Managing authentication and ID mapping SONAS product documentation in the IBM Knowledge Center:
2.2 Authentication configuration with asynchronous replication
This section explains how to configure and correct authentication with asynchronous replication.
2.2.1 Authentication requirements for replication
For proper management of files that are copied by using asynchronous replication, ensure that correct user access control information is captured with the file data. File permissions must also be copied, as-is, from source to destination.
For this copying, consistent authentication mappings between the source and target SONAS are required. The users and groups, and therefore UID and GID information, on both source and target must be identical to have the access permissions replicated correctly.
To ensure consistent user and group mappings, authentication configuration must be identical on both the source and target SONAS clusters.
2.2.2 Setting up authentication for asynchronous replication
To configure authentication to have consistent mappings or identical authentication configuration between source and target, make the user and group information, such as UID and GID, available external to SONAS and accessible by both the source and destination.
For asynchronous replication, authentication management must be done by an AD with SFU extension or by an LDAP server. Before SONAS version 1.5.1, AD without the SFU extension was not supported.
SONAS version 1.5.1 supports deterministic auto ID mapping. With deterministic auto ID mapping, the SONAS cluster is configured with AD authentication or Samba Primary Domain Controller (PDC) authentication. This ID mapping method uses a reserved ID range to allocate IDs.
For SONAS 1.5.1, asynchronous replication is also supported by the deterministic auto ID mapping mechanism. For more information about how to use deterministic auto ID mapping, see the Authentication chapter in IBM SONAS Implementation Guide, SG24-7962.
Authentication mechanisms (such as standard AD) that do not hold the Windows security identifier (SID) to UID/GID mapping external to the SONAS, require the mapping to be done internally to the SONAS. Before SONAS 1.5.1, there was no mechanism supported by SONAS that enabled a coordinated agreement between multiple SONAS systems to ensure that the user mapping was consistent between the discrete systems. However, with deterministic auto ID mapping with AD support in SONAS 1.5.1, the preceding restriction is no longer valid.
To summarize, the authentication service that is configured should be an LDAP, AD with SFU environment that is resolvable across their sites, or is mirrored and consistent across their sites such that the SONAS at each site is able to authenticate from each location. For SONAS 1.5.1 and later, async replication also works with clusters that are configured with AD if the ID map configuration on source and target clusters is in sync. For more information, see the Authentication chapter in IBM SONAS Implementation Guide, SG24-7962.
Another important requirement is that the time on the SONAS systems must be synchronized, preferably with a common Network Time Protocol (NTP) server.
2.2.3 Consequences of incorrect authentication setup
During replication, when data is copied, asynchronous replication looks up the user and group names in the access control lists (ACLs) of the file on the target site. It then applies the respective UID and GID on the target site.
If it does not find the user and group name on the target, the UID and GID information from the source is copied. This scenario can typically occur when the authentication that is configured on the source and target are not identical. This scenario might lead to incorrect ACLs being applied with a different UID and GID set for the replicated files. As a result, data on the target might be inaccessible.
2.2.4 Correcting an incorrect configuration
It is important that, at the time of setting up the replication site or target site, even before setting up asynchronous replication between the two sites, that the authentication that is configured on the target is identical to that of source. Alternatively, it can use the deterministic auto ID mapping that is supported in SONAS 1.5.1 and later and its associated tools to maintain same ID map configuration between the source and target sites.
For more information, see the Authentication chapter in IBM SONAS Implementation Guide, SG24-7962.
However, if the authentication that is configured on the target is not identical to that of the source, the only way to correct it is to clean up and reconfigure authentication on the target. If there is already data on the target cluster, it might be inaccessible after reconfiguration of authentication.
2.2.5 Preferred practices for an asynchronous replication configuration
Asynchronous replication is a preferred practice to ensure that data is always available, especially when the primary site is down. Just as you prepare for setting up an alternative SONAS cluster, you must also plan to set up a secondary or alternative authentication server to service the site.
This means that you must have a secondary authentication server at the same location as the secondary SONAS site. The server is part of the same domain.
You can use this configuration to ensure that the following conditions are true:
•There is a minimum latency for data access on the secondary site.
•If both the primary site and the authentication server go down, the secondary site faces no issues to authenticate clients because it has its own secondary authentication server.
•The time synchronization across both sites is sufficient to enable successful authentication with SONAS systems.
2.3 Preferred practices for migration of data by using the Robocopy tool
The Robocopy tool is a Microsoft software tool that is provided with the Microsoft Resource Kit for Windows 2003 or as a standard tool in Windows 2008. You can use the Robocopy tool to migrate groups of Common Internet File System (CIFS) shares from any Source Filer to the IBM SONAS. In general, install the Robocopy tool on a dedicated Windows server that is attached to the network, and then copy a group of shares at a time. Figure 2-1 on page 29 is an overview of how the Robocopy tool works.
The Robocopy tool has the capability to continue to compare the source and the target files, and recopy any files that have been changed since the last copy. It also provides granularity to copy data and metadata.
After all the files are copied onto IBM SONAS, you can change the mapped shares in clients to point to the SONAS shares, and reboot and reconnect these clients.
Figure 2-1 How the Robocopy tool works
2.3.1 Authentication requirements for replication
For proper management of files that are copied by using asynchronous replication, along with the file data, user access control information must also be correctly copied. It is essential that file permissions are also copied without alteration from source to destination.
For this copying, consistent authentication mappings between the source and target SONAS are required. The users and groups and therefore, UID and GID information on both source and target must be identical to have the access permissions replicated correctly.
To ensure consistent user and group mappings, it is mandatory that the authentication configuration is identical on both the source and target SONAS clusters.
2.3.2 Setting up SONAS for migration by using the Robocopy tool
Complete the following steps to set up SONAS for migration by using the Robocopy tool:
1. Sign in to the SONAS Management node as the root user and run the following command:
net conf setparm global "admin users" "[DOMAIN]\administrator"
|
Important: The admin users parameter must to be set with the user name that is used to run the Robocopy tool.
After all CIFS migrations are finished, remove the settings with the following command:
net conf delparm global "admin users" "[DOMAIN]\administrator"
|
2. It is important to check whether the existing NAS environment uses Active Directory. If it is used, check if any AD Domain migration was done in the past. If migration was done, it results in the introduction of a new parameter, SIDHistory, with every user and group
in AD.
in AD.
3. Ensure that you understand security identifier (SID) history.
SID history means that the object is assigned a new SID when it is migrated into the new AD domain, but it also retains a record of its old SID so that it can access resources on its old domain.
Implementing SID histories works as a temporary solution, because the SID histories are the mechanisms that enable migrated users to continue to be able to access resources from the member servers in the old domain. Because of the way that SID histories work, if you were to migrate the member servers and then take the old AD domain offline, all of the SID histories that are related to the old AD domain would stop working and users would no longer be able to access resources on the member servers.
To make the SIDs continue to work even after the old AD domain is removed, re-create the ACLs of all of the member servers as a part of the migration.
|
Important: SONAS does not support SIDHistory (this means the SID that belongs to the old domain). Therefore, before running the Robocopy tool, replace all the ACLs with historic SIDs with new SIDs for every file and directory on the existing NAS.
After this is done, the Robocopy tool can be used to copy security information from heritage NAS to SONAS.
|
2.3.3 Prerequisites for starting migration with the Robocopy tool
This section provides a scenario with the Source NAS filer A and the Target SONAS cluster B.
Complete the following steps to migrate data from A to B:
1. Identify Common Internet File System (CIFS) shares on A whose data and metadata needs to be migrated.
2. At the target (SONAS), export the respective file sets as CIFS shares (this step is required for the Robocopy tool).
3. Log in to the SONAS Management node as the root user and run the following command:
net conf setparm global "admin users" "[DOMAIN]\administrator"
|
Requirement: The admin users parameter must be set with the user name that is used to run the Robocopy tool. After all CIFS migrations are finished, run the following command to remove the settings:
net conf delparm global "admin users" "[DOMAIN]\administrator"
|
4. Map the source and the target on the migration server. Map the CIFS shares from A and B on the Windows server:
net use x: \A est
net use z: \Bfset1
5. Migrate CIFS DATA and ACLs:
a. Run the Robocopy tool to copy only metadata (ACL information):
robocopy \A est \Bfset1 /S /E /IS /COPY:ATSO /log:c:
obocopylog.txt /V
This command includes the following information:
• /E = Copy all subdirectories including empty ones
• Copy file information (/COPY:ATSO):
A = Attributes
T = Timestamps
S = Security = New Technology File System (NTFS) ACLs
O = Owner info
T = Timestamps
S = Security = New Technology File System (NTFS) ACLs
O = Owner info
b. Run the Robocopy tool to copy data and metadata (ACL information):
robocopy \A est \Bfset1 /S /E /IS /COPY:DATSO /log:c:
obocopylog.txt /V
This command includes the following information:
• /E = Copy all subdirectories including empty ones
• Copy file information (/COPY:DATSO)
D = Data
A = Attributes
T = Timestamps
S = Security = NTFS ACLs
O = Owner info
A = Attributes
T = Timestamps
S = Security = NTFS ACLs
O = Owner info
c. After the completion, the log file can be used to review errors.
|
Important: Make sure that the administrator or the user with which the Robocopy tool is run has read access on all files and folders from the source files that need to be migrated. If this user does not have explicit access, the user must be given backup rights and Robocopy must be run with the /B flag.
|
|
Attention: Migration of additional information, such as audit information, might fail if the SONAS does not permit storing this information.
|
2.3.4 Common issues for Robocopy configuration
This section describes common issues that are encountered with the Robocopy setup.
Issue: Data is copied but security information (ACLs) is not copied
To debug this issue, check if the files and folders have ACLs with old SIDs.
If the heritage NAS contains files and folders that have ACLs with old SIDs (historic SIDs), these ACLs are not copied.
Complete the following steps to correct this issue:
1. Remove the SID history on the heritage NAS and re-ACL all shares and re-run the Robocopy tool.
2. Check for old SIDs in the ACLs and correct them as described in step 3 on page 30.
Issue: Permission denied error
To debug this issue, check if the user has the required permissions to run the Robocopy tool.
This error typically occurs when the user with which Robocopy runs does not have permission to either read and write file data or read and write file metadata.
To correct this issue, provide the user who will run Robocopy with the correct privileges. Read point 2 from 2.3.3, “Prerequisites for starting migration with the Robocopy tool” on page 30.
Robocopy must be run with backup user privileges, and the admin users parameter from the Samba registry on SONAS must be set to the user who runs Robocopy.
Issue: ACLs are not copied for well-known and built-in groups
SONAS does not support ACLs with SIDs from well-known and built-in groups. Therefore the Robocopy tool shows errors while trying to copy ACLs for well-known and built-in groups, if any. The Windows local administrators group is an example of a built-in group.
Issue: Copy fails for files and folders with a group set as owner
SONAS does not support a group as a file owner. The Robocopy tool gives an error for the copy of owner information for such files and directories.
2.4 Preferred practices for plain Active Directory
As described in the Authentication chapter of IBM SONAS Implementation Guide, SG24-7962, plain Active Directory supports only Windows client access to SONAS. Avoid using this method for mixed environments where the clients accessing SONAS are Windows in addition to UNIX.
After plain AD is configured, the only way to change to another authentication method is to clean up authentication and reconfigure the new method. With this process, there might be loss of access to existing data.
2.4.1 ID mapping and range size
When you configure plain AD, planning the correct ID Mapping range and range size is important. As described in the IBM SONAS Implementation Guide, SG24-7962 Redbooks publication, the ID mapping that is generated, meaning the UID and GID for every Windows user and group, are created as follows:
ID = RANGE_LOWER_VALUE + RANGE_SIZE * DOMAIN_NUMBER + RID
This statement uses the following values:
•RANGE_LOWER_VALUE, RANGE_SIZE = These are specified on SONAS while running the cfgad command.
•RID = This is fetched from the authentication source.
•DOMAIN_NUMBER = This is assigned to each domain that SONAS recognizes.
The lower ID of the range must be at least 1000, and the range size must be at least 2000.
The range size (number of IDs per domain) defines the available number of UIDs and GIDs per domain. When a user or group is defined in Active Directory, it is identified by an SID that includes a component that is called a relative identifier (RID).
Whenever a user or group from an Active Directory domain accesses Storwize V7000 Unified, a range is allocated per Active Directory domain. A UID or GID is then allocated depending upon this range and the RID of the user and group.
For SONAS 1.5.1 and later, there are changes to the way that automatic internal ID maps
are generated that supports multiple ranges to be allocated to domains and also provides support to maintain a consistent ID map across different clusters. For more information, see the Authentication chapter in the IBM SONAS Implementation Guide, SG24-7962 IBM Redbooks publication.
are generated that supports multiple ranges to be allocated to domains and also provides support to maintain a consistent ID map across different clusters. For more information, see the Authentication chapter in the IBM SONAS Implementation Guide, SG24-7962 IBM Redbooks publication.
For SONAS 1.5.1 and later, the ID mapping that is generated, meaning the UID and GID for every Windows user and group, is created as follows:
ID = RANGE_LOWER_VALUE + (RANGE_SIZE * DOMAIN_NUMBER) + RID - (MULTIPLIER*RANGE_SIZE)
This statement uses the following values:
•RANGE_LOWER_VALUE, RANGE_SIZE = These are specified on SONAS while running the cfgad command. See the man page of cfgad in the SONAS 1.5.1.0 IBM Knowledge Center for more details.
•RID = This is fetched from the authentication source.
•DOMAIN_NUMBER = This is assigned to each domain that SONAS recognizes, and starts
with 0.
with 0.
•MULTIPLIER = This is generated internally by SONAS.
The default value for RANGE is 10000000 - 299999999 and the default value for RANGE_SIZE is 1000000. Therefore, with default values, 290 domains each of size 1000000 can be mapped. The lowerID of the range must be at least 1000 and the range size must be at least 2000.
2.4.2 Configuring plain AD
When you configure authentication for the first time, you must do it correctly before you create data on SONAS.
There is no way to correct misconfiguration, except by cleaning up the authentication that is configured. However, it is not advisable to clean up and reconfigure AD.
The domain number that is generated might not be the same every time if there are multiple domains. Because the domain number is used to calculate the UID and GID, if a new value is generated, the assigned UID and GID for a user might change and they might lose access to existing data.
Choose the range lower value wisely
It is not possible to modify the lower range value after authentication is configured unless you clean up and rerun the configuration. Choose this value carefully.
Make sure that it does not clash with any existing range. If you are attempting to rerun configuration with existing data, if there is a single domain, the domain number is the same. If you choose an incorrect lower range, this selection might create different UID and GID values for users and groups. Users might lose access to existing data.
Choose the range size correctly to accommodate future growth
For SONAS versions earlier than 1.5.1, consider future expansion where the number of users and groups increases when you choose the range size. The RID value depends on the number of users and groups. If the RID of any user is greater than the range size, that user cannot access SONAS exports. So, choose the range size to enable the highest possible RID of users and groups.
The preceding restriction is removed in SONAS version 1.5.1, because multiple ranges can be allocated to domains as a result of the changes to the autorid ID generation algorithm.
Choose the number of domains to be supported
The number of domains that are supported can be calculated with the following formula:
Number of Domains = (Integer) <HigherID of the range> - <LowerID of the range>/<rangesize>
It is important to choose the lower range, higher range, and range size effectively to be able to support the future number of domains.
Multiple IBM SONAS systems that are configured against the same AD server
If there is more than one IBM SONAS system to be configured against the same AD authentication server, ensure that each IBM SONAS system has a unique netBIOS name. The netBIOS name of the SONAS system and AD server domain name must not conflict.
Migrating files
When you are migrating files from other NAS servers to SONAS, make sure that the users and groups to whom the files belong and have access to are also available on the SONAS domain controller. If the users and groups are missing, access is denied.
If users and groups who are part of another domain need access to these files, make sure that the domain is in two-way trust with the domain controller with which you configure SONAS.
If files have ACLs for users and groups who are in a domain that has been removed or upgraded, these ACLs are not copied. SONAS does not resolve those users and therefore, even if it reads the ACLs at source, at the time of applying ACLs, it skips those ACLs. This behavior is expected.
|
Important: The cfgad command restarts the file services:
•File Transfer Protocol (FTP)
•Secure Copy Protocol (SCP)
•Hypertext Transfer Protocol (HTTP)
•Network File System (NFS)
•Common Internet File System (CIFS)
This restart is disruptive for connected clients. The connected clients lose their connection and the file operations are interrupted. File services resume a few seconds after the command finishes successfully.
When Active Directory authentication is configured against the SONAS system, rerunning the cfgad command overwrites the earlier configuration with the new one.
|
2.4.3 Common issues for plain AD configurations
This section lists issues that are commonly encountered in the plain AD configuration, and explains how to correct them.
Issue: NFS users on UNIX clients are unable to access data because plain AD does not support UNIX clients
After configuring plain AD, NFS users on UNIX clients try to access data. They are denied access to data that they are able to access from a Windows client.
How to debug this issue
Complete the following steps to debug this issue:
1. Check for the UID or GID for the AD user or group that has access to the file by using the chkauth command on SONAS.
2. Check the UID or GID for the UNIX user that is denied access.
Typically, the UID and GID are not the same. In this case, access is denied and this is expected behavior.
The UID and GID for users on the UNIX clients is typically a smaller value like less than 1024 as compared to the UID or GID that is automatically created by SONAS.
Conclusion
If you have UNIX users who want to access data, plain AD is not the correct authentication for SONAS. Implement AD + SFU or AD + NIS or LDAP. With SONAS 1.5.1, there is support for using the local authentication server, which can help support NFS users on a UNIX client.
How to correct this issue
The only way to correct this issue is to clean up authentication by running the cleanupauth command. Use the --idmapDelete option to delete the ID mapping that was created.
Rerun the configuration command after you select the correct method for your environment.
|
Attention: Cleaning up authentication and rerunning the authentication command might lead to data being inaccessible.
|
Preferred practice to be followed
Have all the information about which clients need access to data. Based on the client data access, decide on the best solution for your environment, which is typically AD + SFU or AD + NIS or LDAP.
Configure authentication based on the study. Do not copy, migrate, or create data until you are certain that the authentication that is configured is the correct one for your setup.
Issue: Users from another domain cannot access data
Even after plain AD is configured successfully, Windows users from another trusted domain are unable to access data.
How to debug this issue
If data is inaccessible, the first thing you need to check is if the user that is trying to access it has sufficient access through the file ACLs. If not, update the ACLs and try again. Make sure that users from the other domain are added in the format <DOMAIN_NAME>\<username> so that it is resolved successfully.
If ACLs are sufficient, and data is still inaccessible, check if the UID and GID for that user is resolvable. Use the following command to check whether the user or group has a UID or GID assigned:
$chkauth -i -u "<DOMAIN\username>"
As seen in Example 2-1, if the command does not show a UID or GID for that user or group, you need to check whether the SONAS cluster can resolve any of the users on the other domain controller. Check for the direction of trust.
Example 2-1 Failed to get IDMapping for user
$ chkauth -i -u "SONASuser1"
EFSSG0002C Command exception found: FAILED TO FETCH USER INFO
The ideal case is that there is two-way trust between both domains. If there is not a two-way trust, the direction of trust must be correct.
In a one-way trust between Domain A and Domain B, users in Domain A (trusted domain) can access resources in Domain B (trusting domain). However, users in Domain B cannot access resources in Domain A. For example, if the SONAS system is joined to Domain X, and user accounts exist in Domain Y, Domain Y must be trusted by Domain X for the users of Domain Y to gain access to SONAS shares.
Conclusion
When multiple domains exist, make sure that the trusts are configured such that the users can access resources in the SONAS domain.
How to correct this issue
The only way to fix this issue is to fix the trust direction.
Preferred practice to be followed
Have all the other domains in two-way trust with the domain to which SONAS is configured.
Issue: All AD users are denied access to SONAS even though authentication is configured correctly because of a permissions issue on AD
AD is successfully configured with the correct parameters for ID mapping. However, SONAS access fails for all users.
How to debug this issue
Check whether SONAS is inaccessible to a particular user or all users.
If it is unavailable for a particular user, check if the password is correct and retry. If the password is correct, check for ACLs and provide sufficient ACLs if they are not set yet.
If it is for all users, check if the UID and GID are assigned to every user and group. Run the following command to check for UID and GID:
$chkauth -i -u "<DOMAIN\username>"
As shown in Example 2-2 on page 37, if the command does not show a UID or GID for that user or group, you need to check whether the SONAS cluster can resolve any of the users on the other domain controller.
Example 2-2 Failed to get IDMapping for user
$ chkauth -i -u "SONASuser1"
EFSSG0002C Command exception found: FAILED TO FETCH USER INFO
If there are multiple domain controllers in setup, check for the direction of trust. See “Issue: Users from another domain cannot access data” on page 35 for more information about trusts.
If you do not have multiple domain controllers in your setup, or if the trust directions are set up correctly, you need to check whether SONAS has sufficient permissions to access user and group attributes on the AD server.
Conclusion
SONAS uses a Samba component that is known as Winbind to map Windows user information into a UNIX format. When systems are joined to a Windows domain, a machine account that is similar to a user account is created. Winbind internally uses the machine account for user and group attribute lookup. If the machine account has insufficient privileges to read these attributes, SONAS cannot read user and group information and therefore is unable to create the UID and GID mapping that is essential to access the SONAS system.
How to correct this issue
To rectify this issue, you need to delegate control for the SONAS computer account to Read all user information.
A Windows administrator must delegate control to read user attributes to the machine account as follows:
1. In the Active Directory console tree, right-click the domain, select Delegate Control, click Next, click Add, and select the object type Computers.
2. In the object name field, enter the IBM SONAS system’s machine account (the account that is created with the netBIOS name under the Computers container, which is the cluster name that is used with the cfgcluster command).
3. Click Next, and select Delegate the following common tasks. From the displayed list, select Read all user information.
4. Click Next, and then click Finish.
If you have multiple IBM SONAS systems, you can create a group in Active Directory, add each IBM SONAS system machine account to that group, and delegate control to that group.
Preferred practice to be followed
Check and confirm that the SONAS computer account can read all user information. Provide explicit permissions to read the user attributes by delegating control for the SONAS computer account to read all user information if not already set.
Issue: AD is successfully configured, but some users cannot access data because the RID value is out of the Range set
Plain AD was configured successfully, but some windows users are unable to access data.
|
Remember: With SONAS version 1.5.1 and later this issue no longer exists, because the new autorid algorithm supports multiple ranges for domains.
|
How to debug this issue
If data is inaccessible, check if the user who is trying to access it has sufficient access using file ACLs. If not, update the ACLs and try again. For users from another domain, ensure that the trusts are configured correctly. See “Issue: Users from another domain cannot access data” on page 35 for more information about trusts.
If the ACLs are sufficient, and data is still inaccessible, check if the UID and GID for that user is resolvable. Use the following command to check if the user or group has a UID or GID assigned:
$chkauth -i -u "<DOMAIN\username>"
As seen in Example 2-3, if the UID and GID are assigned, check for the RID of the user or group. The RID might be greater than the range size. If the RID for that user is indeed greater than the range size, those users and groups are denied any access by default.
Example 2-3 Failed to get IDMapping for user
$ chkauth -i -u "SONASuser2"
Command_Output_Data UID GID Home_Directory Template_Shell
FETCH USER INFO SUCCEED 10061795 10000513 /var/opt/IBM/sofs/scproot /usr/bin/rssh
In Example 2-4, the lsauth command displays the range as 5000. The maximum value of the ID that is allowed is 10005000. The UID for the user is seen as 10061795, which is greater and therefore is out of range. Because it is out of range, access is denied.
Example 2-4 lsauth displaying range for ID mapping
$ lsauth
AUTH_TYPE = ad
idMapConfig = 10000000-299999999,5000
domain = SONAS
idMappingMethod = auto
clusterName = bhandar
userName = administrator
adHost = SONAS-PUNE.SONAS.COM
passwordServer = *
realm = SONAS.COM
EFSSG1000I The command completed successfully.
Conclusion
RID for all users and groups must always be less than the rangesize specified in the cfgad command. It is important to consider expansion in the future, and anticipate that the number of users and groups will grow, and therefore RID will grow.
How to correct this issue
The only way to correct this issue is to provide a range size that is high enough to anticipate future expansion of the number of users and groups. However, this configuration cannot be done on the current configuration.
|
Attention: Cleaning up authentication and rerunning the authentication command might lead to data being inaccessible. Use this as a last resort.
|
Run the cleanupauth command to clean up authorizations that were configured previously. Rerun the command with the --idMapDelete option so that all UIDs and GIDs that were previously created are deleted.
Select a new range size that is feasible and rerun the cfgad command.
Preferred practice to be followed
Have all ID mapping-related parameters that need to be passed to the cfgad command revisited and recalculated to make sure that it is the minimum possible value to work as expected considering future expansion of users and groups.
Issue: Move to AD + SFU from plain AD
After they use SONAS with plain AD to store and access data, the administrator wants to migrate from plain AD to AD + SFU.
Conclusion
SONAS does not support migration of the authentication method. The only way to change configuration from one type of authentication to another is to clean up authentication by using the cleanupauth command and rerun the required authentication command. You might also need to run the cleanupauth command again with the --idMapDelete option before reconfiguring authentication.
|
Attention: Cleaning up authentication and rerunning the authentication command might lead to data being inaccessible. Use this command as a last resort.
|
Preferred practice to be followed
Take time to understand the possible clients that might be access data. Think of the future and anticipate the requirement before you select an authentication type. Do not change authentication because access to data might be lost in the process.
Issue: Even after successful migration of data, some ACLs are not copied onto the files because older domain SID or SID history values are not copied
SONAS was successfully configured with AD. Migration of data by using the Robocopy tool was done to copy all data from other NAS servers onto SONAS. When users try to access data, it is observed that some ACLs are copied and some are not. Some users are denied access when they try to access files.
How to debug this issue
Start with a quick check and make sure that on the source, the user or group does have ACLs on that file or folder. If ACLs are available on the source, check if the user or group has a UID or GID created. Run the following command to check for UID and GID:
$chkauth -i -u "<DOMAIN\username>"
As seen in Example 2-5, if the UID or GID is available, check if the SID for the ACLs set on the source is the same as that on the target SONAS.
Example 2-5 UID GID mapping correct for user
$ chkauth -i -u "SONAS2user2"
Command_Output_Data UID GID Home_Directory Template_Shell
FETCH USER INFO SUCCEED 10061795 10000513 /var/opt/IBM/sofs/scproot /usr/bin/rssh
Determine whether the domain controller was recently moved. Check the SID for the user on SONAS. If the SID History value is being referred to on the source, that can be the root cause.
Example 2-6 shows one method of obtaining the SID of a local user. The wmic command can also be used to query domain users.
Example 2-6
>wmic useraccount where name="marshall" get name,sid
Name SID
marshall S-1-5-21-955979511-3378639333-3486311995-1000
Conclusion
Typically, upon moving from one domain controller to another, the users and groups are assigned a new SID. This new SID is mapped to a UID on SONAS. However, the older SID which is in SID history is not read by SONAS. Therefore, this SID is not mapped to a UID or GID. Due to this, ACLs for the old SIDs are not copied on SONAS by using the Robocopy utility.
If files were created before data is moved, they have the older SID in the ACLs. It can happen that inheritance has been set and, therefore, many child folders might have this ACL set. Upon upgrade, the SID history is used.
When the file ACLs are being read, the SID that is sent by the source is a value that SONAS does not recognize. Because it is unknown to SONAS, a corresponding UID or GID is not created. Without a UID or GID, SONAS is not able to write the ACLs for the files on the file system.
Therefore, these files are skipped. And due to this skipping, those users will not be able to access the file system because their ACLs are not copied.
How to correct this issue
There are two ways to correct this issue:
•Re-create new folders with new inheriting ACLs on SONAS, and then copy the data without copying the ACLs. This option has the drawback that it destroys manually created ACLs where a user has been added to the access list.
•Replace all old SIDs of the SID history with the current SIDs on the source before copying. Basically, the algorithm iterates over all users. Then, for each user, query the old and new SID and then recursively replace the old SID with the new one on the file system.
The Microsoft SubInACL tool enables recursive manipulation of ACLs. In the worst case, it must be called once for each user.
Preferred practice to be followed
Check for the SID for the ACLs on the files before you consider migration. If there has been a change in the domain and files have an older SID assigned, it might be a good idea to first replace the old SID with the new SID and then copy the data onto SONAS.
2.5 Preferred practices for AD and Services for UNIX
You can configure AD + SFU to support both Windows clients and UNIX clients to access SONAS.
Before you configure authentication on SONAS, study what is the best configuration for your environment because SONAS does not support migrating authentication from one type to another. The only way to change it is to clean up and reconfigure.
Here, SFU works as an external ID mapping server. The authentication only happens using Active Directory. External ID mapping enables the ID mapping to remain external to the SONAS system. This enables multiple SONAS systems to access the same UID and GID information for users and groups. So, for asynchronous replication, both the source and the target are able to see the same user and group information, and therefore apply ACLs correctly.
2.5.1 Range and Schema Mode parameters in SFU
This list describes the range and schema mode parameters:
•Range. The range for the range parameter must be in the format LowerID - UpperID; for example, 20000 - 30000. The allowed range is from 1 - 4294967295.
Make the lower range greater that 1024 to avoid conflict with the management command-line interface (CLI) users. When you run the command with a lower range that is less than 1024, a warning is generated, which also asks for confirmation. You can use the --force option to override it.
|
Important: The specified range must not intersect with the range that is specified with the --idMapConfig option of Active Directory server authentication configuration. The default range for the Active Directory server authentication is 10000000 - 299999999.
|
Users and groups that have a UID or GID that does not fit in the range are denied access.
•SchemaMode. This parameter value can be either sfu or rfc2307, depending on the operating system of the domain controllers. If the operating system of the domain to be joined is Microsoft Windows 2008 or Windows 2003 with R2 packages, use rfc2307. For Windows 2000 and Windows 2003 with SP1, use sfu.
2.5.2 Configuring AD + SFU correctly before data is created on SONAS
When configuring authentication for the first time, it is essential you do it immediately before creating or migrating data on SONAS. There is no way to fix any misconfiguration, except by cleaning up the authentication configuration. However, it is not advisable to clean up and reconfigure AD.
The domain number that is generated might not be the same every time if there are multiple domains. Because this number is used to calculate UIDs and GIDs, if a new value is generated, the assigned UID and GID for a user might change, and they might lose access to existing data.
Also, check for the schema mode and make sure that you choose the correct value. SONAS does not verify if you have chosen the correct schema mode.
Choose the User and Group Range value wisely
It is not possible to modify the range for the user and group for SFU after authentication is configured unless you clean up and rerun the configuration. Therefore, you need to choose this value with great care.
The value should be such that the UNIX user ID (UID) and group ID (GID) which will be mapped in SFU for the respective Windows user and group are in that range.
Make sure that it does not clash with the existing range that is provided for AD in the --idMapConfig command because this range will be used for the Windows user whose UID and GID will be automatically created. This value should not clash with the existing SFU UID and GID.
Check that every user has the UID and GID for its primary Windows group
After AD + SFU is configured with the correct parameters, set up the users and groups. Make sure that all the users have the UID set. Also, the Primary Windows Group for each user must have a valid GID using the Active Directory administration tools.
If other groups that the user is a member of do not have a GID, the group does not have access to data. However, if the user’s Primary Group does not have a valid GID, that user is denied access to data.
Migrating files
Make sure that when you are migrating files from other NAS servers to SONAS, the users and groups to whom the files belong and have access to, are also available on the SONAS domain controller.
If the users and groups are missing, access is denied. These users must also have the UNIX attributes updated in the SFU so that the UID or GID is not auto created, and it is set correctly when files are copied onto SONAS. This way the Windows users and UNIX users can access the data.
If users and groups who are part of another domain need access to these files, make sure that the domain is in two-way trust with the domain to which you have joined SONAS.
If files have ACLs for users and groups who are in a domain that has been removed or upgraded, these ACLs are not copied. SONAS does not resolve those users and groups, even if it reads the ACLs at source. At the time of applying ACLs on SONAS, it skips those ACLs. This behavior is expected.
2.5.3 Common issues for AD + SFU configurations
This section lists common issues that you might encounter in an AD + SFU configuration, and describes how to correct them.
Issue: AD + SFU successfully configured, but some users cannot access data - UID or GID not set correctly
Even after AD + SFU is configured successfully, some Windows users are unable to access data.
How to debug this issue
If data is inaccessible, the first thing you need to check is whether the user trying to access the data is successfully resolved by the system. For users from another domain, make sure that they are also resolved by having the trusts that are configured correctly. For more information about trusts, see “Issue: Users from another domain cannot access data” on page 35.
If, after sufficient ACLs, data is inaccessible, verify that the UID for that user is set. Use the following command to check if the user or group has a UID or GID assigned:
$chkauth -i -u "<DOMAIN\username>"
Example 2-7 shows that the chkauth command does not show the UID or GID for user1. If the chkauth command does not show UID or GID, even though the SONAS cluster can resolve the users on the domain controller, the UID or Primary group might not have a valid GID set in SFU for that user.
Example 2-7 Failed to get ID mapping for user
$ chkauth -i -u "SONASuser1"
EFSSG0002C Command exception found: FAILED TO FETCH USER INFO
In Example 2-7, you can see that the user information cannot be fetched, which means that it is not yet present on the SONAS system.
Conclusion
Access for those users and groups is denied if UID or GID are not set correctly.
How to correct this issue
Complete the following steps to correct this issue:
1. Open the User or Group details on the domain controller by right-clicking Properties on that user or group. Open the UNIX Attributes tab and update the UID or GID for every user
or group.
or group.
2. As shown in Figure 2-2, the UID for the user is missing. Complete this value with the valid UID and save. The user now has a valid UID set and the user should be resolved.
Figure 2-2 UID to be completed for the user in the UNIX Attributes tab in the properties for the user
|
Note: Make sure that the Primary Group that is set for the user in the Member Of tab also has a valid GID for the user to be resolved successfully.
|
Preferred practice to be followed
It is mandatory that you set up SFU correctly before you store data. Assign a UID and GID to users and groups. The preferred practice is to verify that the setup is correct before you store data or access the cluster.
Issue: UID successfully configured, yet some users cannot access data: User’s Primary Windows Group does not have a valid GID
Even after AD + SFU is configured successfully, some Windows users are unable to access data.
How to debug this issue
Complete these steps to debug user access:
1. If data is inaccessible, and the UID is set correctly, the first thing you might want to check is if the user that is trying to access data has sufficient ACLs. If not, provide the ACLs and try again. Make sure that users from another domain are also resolved by configuring the trusts correctly. For more information about trusts, see “Issue: Users from another domain cannot access data” on page 35.
2. If ACLs are sufficient, and data is still inaccessible, check if the UID for that user is set. Use the following command to check whether the user or group has a UID or GID assigned:
$chkauth -i -u "<DOMAIN\username>"
3. If the output from the chkauth command does show the UID, check whether the user’s Primary Windows Group has a valid GID.
Example 2-8 shows that the user’s UID is correctly mapped. However, access is still denied for the user. This means that the user is not set up correctly.
Example 2-8 Failed to get IDMapping for user
$ chkauth -i -u "SONASuser1"
EFSSG0002C Command exception found: FAILED TO FETCH USER INFO
4. Next, check whether the Primary Group that is assigned to the user has a valid GID set. If this setting is missing, the user is denied access even if the UID has been set.
5. Check which Primary Windows Group is set by accessing the user on the AD server. Right-click Properties and select Member Of, as shown in Figure 2-3.
Figure 2-3 Check for Primary Group
6. Now, check for the Group properties for this group. Right-click group, select Properties, and then UNIX Attributes. See Figure 2-4.
Figure 2-4 Primary Group has a missing GID
Here, the GID is missing. This missing value is the cause for access denied.
Groups that do not have a valid GID are denied access. If a Primary group has a missing GID, access is denied for the respective user.
Conclusion
Access for those users Primary Windows group set for user does not have a valid GID.
How to fix this issue
Complete the following steps to fix this issue:
1. Open the user or group details on the domain controller.
2. Right-click Properties on that user or group.
3. Open the Member Of tab and check which is the Primary Group set for that user.
4. Now, click the corresponding group and check the GID by right-clicking Properties on that user or group.
5. Open the UNIX Attributes tab. If the GID is missing, enter a valid GID for the name. See Figure 2-5. Make sure that the GID is in the range that is specified when you configure authentication on SONAS.
Figure 2-5 Primary Group now has a valid GID
Preferred practice to be followed
It is mandatory that the user’s UID and Primary Group (GID) are correctly set. The preferred practice is to verify that these steps are followed before you try to store data or access data.
Issue: UID and GID details are correctly set in SFU, but some users cannot access data because the UID is out of SFU Range
Even after AD + SFU is configured successfully, where the UIDs for all users and the Primary GID are set and the GID has been set for all groups, some Windows users are unable to access data.
How to debug this issue
Complete the following steps to debug user access:
1. If data is inaccessible, the first thing that you need to check is if the user who is trying to access the data has sufficient ACLs. If not, provide the ACLs and try again. Make sure that users from another domain are also resolved by having the trusts configured correctly. See “Issue: Users from another domain cannot access data” on page 35 for more information that is related to trusts.
2. If ACLs are sufficient, and the data is still inaccessible, check if the UID and GID for that user is set. Use the following command to check if the user or group has a UID or GID assigned:
$chkauth -i -u "<DOMAIN\username>"
3. As seen in Example 2-9 on page 49, if the chkauth command does show the UID or GID, check for the range set for each user and group. The UID and GID set for users and groups must be within the User range and Group range.
You can also check this value on the AD side on the UNIX Attributes tab in the properties for that user. See Example 2-9.
Example 2-9 UID out of range for user
$ chkauth -i -u "SONASuser2"
Command_Output_Data UID GID Home_Directory Template_Shell
FETCH USER INFO SUCCEED 5403 6789 /var/opt/IBM/sofs/scproot /usr/bin/rssh
4. You can check for the user range and group range using the lsauth CLI command.
In Example 2-10, the range that is specified is 6000 - 7000. Therefore, every user must have a UID in this range.
Example 2-10 The lsauth command displays the range for the UID and GID
$lsauth -c st001.virtual1.com
AUTH_TYPE = ad
idMapConfig = 10000000-299999999,1000000
SFU_virtual1 = ad,6000-7000,rfc2307
domain = virtual1
idMappingMethod = sfu
clusterName = st001
userName = administrator
adHost = ad1.virtual1.com
passwordServer = *
realm = virtual1.com
EFSSG1000I The command completed successfully.
The user tab shows the UID as 5403 in Figure 2-6. This value does not fit in the range and therefore access is denied. Any user whose UID does not fall in this range is denied access.
Figure 2-6 The UNIX Attributes to be set in SFU are out of range
Conclusion
Access is denied for those users whose UID does not fall in the range that was specified when configuring SFU.
How to correct this issue
The only way to correct the issue is to reconfigure SFU. For this step, you need to run the cfgsfu command again with the correct parameters.
Do not reconfigure SFU because, during this process, other clients might lose access to data because the cluster is in an inconsistent state while authentication is being configured.
Preferred practice to be followed
Set up SFU correctly before you store data. The range must be correctly planned and set to accommodate all users.
Issue: Users are denied access to SONAS even though authentication is configured correctly because of a permissions issue on AD server
AD + SFU is successfully configured with the correct parameters for ID mapping. However, access to SONAS fails for all users.
How to debug this issue
Complete the following steps to debug user access:
1. Check if SONAS is inaccessible to particular user or all users.
2. If for a particular user, check is password is correct and retry. Check if user has sufficient ACLs. Provide with ACLs if not available.
3. If it is for all users, check if the UID and GID are assigned to every user and group. Run the following chkauth command to check for UID and GID:
$chkauth -i -u "<DOMAIN\username>"
4. As shown in Example 2-11, if the command does not show the UID or GID for that user or group, you need to check if the SONAS cluster can resolve any of the users on the other domain controller.
Example 2-11 Failed to get IDMapping for user
$ chkauth -i -u "SONASuser1"
EFSSG0002C Command exception found: FAILED TO FETCH USER INFO
5. If there are multiple domain controllers in the configuration, check for the direction of trust. See “Issue: Users from another domain cannot access data” on page 35 for more information that is related to trusts.
6. If you do not have multiple domain controllers in your setup or if the configured trust directions are also correct, you need to check whether the SONAS has sufficient permissions to access user and group attributes on the AD server.
Conclusion
Winbind internally uses the machine account for user or group attribute lookup. If machine account has insufficient privileges to read these attributes, SONAS will not be able to read user and group information, and therefore is unable to create UID and GID that is essential to access the SONAS system. This requires explicit read permissions for the SONAS system machine account to read the user attributes.
How to correct this issue
To rectify this issue, delegate control for the SONAS computer account[object type] to Read all user information.
To do this, on the OU containing the users and groups, delegate control for the computer account to read user attributes. Complete the following steps:
1. In the Active Directory console tree, right-click the domain, select Delegate Control, click Next, click Add, and select the object type Computers.
2. In the object name field, enter the IBM SONAS system’s machine account (the account that is created with the netBIOS name under the Computers container), which is the cluster name that is used with cfgcluster command.
3. Click Next, and select Delegate the following common tasks.
4. From the displayed list, select Read all user information.
5. Click Next.
6. Click Finish.
If you have multiple IBM V7000 Unified systems, you can create a group in Active Directory, add each IBM V7000 Unified system machine account to that group, and delegate control to that group.
Preferred practice to be followed
Check and confirm that SONAS machine account can read all user information. Provide explicit permissions to read the user attributes by delegating control for the SONAS computer account to read all user information if it is not already set.
Issue: The UID is correctly set in SFU, but users cannot access data because the SFU Schema mode is incorrectly set
AD + SFU are up correctly, but access is still denied for some users.
How to debug this issue
Complete the following steps to debug user access:
1. If data is inaccessible, the first thing you need to check is if the user who is trying to access data is successfully resolved by the system. Make sure that users other domains are also resolved by having the trusts configured correctly. See “Issue: Users from another domain cannot access data” on page 35 for more information about trusts.
2. Use the following command to check whether the user or group has a UID or GID assigned:
$chkauth -i -u "<DOMAIN\username>"
The output in Example 2-12 shows that the UID and GID have been set correctly.
Example 2-12 Successfully displaying ID mapping for a user
$ chkauth -i -u "SONASuser2"
Command_Output_Data UID GID Home_Directory Template_Shell
FETCH USER INFO SUCCEED 5403 6789 /var/opt/IBM/sofs/scproot /usr/bin/rssh
3. In this case, check that the UID and GID are within the range that is provided when configuring authentication with the cfgsfu command. See “Issue: UID and GID details are correctly set in SFU, but some users cannot access data because the UID is out of SFU Range” on page 48 for more information.
4. If the values are also within range, check if the required permissions are also set correctly. See “Issue: Users are denied access to SONAS even though authentication is configured correctly because of a permissions issue on AD server” on page 51 for more information.
5. If all of the previous settings are correct, verify that the schemas are correct. Check if the schema provided in the cfgsfu command is the correct one.
The schemaMode can be either sfu or rfc2307, depending on the operating system of the domain controllers. If the operating system of the domain to be joined is Microsoft Windows 2008 or Windows 2003 with R2 packages, use rfc2307. For Windows 2000 and Windows 2003 with SP1, use sfu.
Conclusion
If the schema chosen during cfgsfu is incorrect, due to the difference in schema variables, authentication does not work as expected. Verify that you chose the correct command parameters before proceeding with the configuration.
How to correct this issue
To rectify the issue, the only method is to reconfigure authentication with the correct values. Run the cfgsfu CLI command again with the correct schema mode value.
Preferred practice to be followed
Ensure that you choose the correct values at the time of configuring authentication.
Issue: The UID is set correctly in SFU, but the ID mapping that is displayed shows a different UID, and access is denied because the IDMap cache must be cleared when modifying the SFU UID
AD + SFU is set up correctly, but access is still denied for some users. When the UID is checked, different values are shown.
How to debug this issue
Complete the following steps to debug user access:
1. If you see that the UIDs are shown as different values than what is set in AD under UNIX Attributes, determine where this value is coming from.
2. Check whether the UID for that user or group has been changed recently. If so, that change might be the root cause.
SONAS usually caches the UID for one week. If any change has been made to the UID set previously, the cached UID is used first until cache is flushed.
Conclusion
UIDs for all users are cached on SONAS. This cache is locally per interface node. For every positive login, the UID is cached for 1 week. For every negative login, the UID is stored for
2 minutes.
2 minutes.
How to correct this issue
To rectify the issue, remove the entry for the user from the cache by manually running the rmidmapcacheentry command. For more help on this command, see the following information in the SONAS area of the IBM Knowledge Center:
Preferred practice to be followed
Do not change UID and GID values. If it must be done, the administrator should run the rmidmapcacheentry command to clear the cache entry.
Issue: SFU is correctly configured but some users cannot access data because the UIDs for some users are auto generated
AD + SFU is set up correctly, but access is denied for some users. When the UID is checked, different values are shown.
How to debug this issue
Complete the following steps to debug user access:
1. If you see that the UIDs are seen as different values than what is set in AD under UNIX Attributes, you need to check from where this value is coming.
2. Check whether the UID for that user or group was changed recently. If so, that might be the root cause.
SONAS usually caches the UID for one week. If any change has been made to the UID set previously, the cached UID is picked up first until the cache is flushed.
3. If the UID has not been changed recently, check whether cfgsfu was run immediately after cfgad was run. In some cases, cfgsfu is run after data has been copied and accessed. What happens then is that the UID and GID are automatically generated when plain AD is configured. This UID and GID are stored in cache. When, after days or weeks, cfgsfu is configured, even though a valid UID or GID is set for the users, SONAS first picks up the values from autorid.tdb because the value exists there.
Conclusion
UID and GID existing in cache or autorid.tdb is root cause. SONAS picks up the older values and therefore access is denied for SFU users.
How to correct this issue
To correct the issue, complete the following steps:
1. Remove the entry for the user from the cache by manually running the rmidmapcacheentry command.
2. Also, run cleanupauth --idMapDelete to clean up the existing authentication. The --idMapDelete option deletes the autorid.tdb database.
3. Now run the cfgsfu command to reconfigure SFU.
|
Important: Running cleanupauth cleans up the configuration. Run this command with caution. If users from other domains are accessing SONAS, they might lose access.
|
Preferred practice to be followed
Run cfgsfu immediately after you run the cfgad command. Run it before any user tries to access exports or data. Upon first login, the UID GID is automatically created if a plain AD setup exists.
2.6 Preferred practices for Lightweight Directory Access Protocol
As described in the Authentication chapter of IBM SONAS Implementation Guide, SG24-7962, LDAP on SONAS supports access for both Windows and UNIX clients. Therefore, for mixed environments with both Windows and UNIX clients, this method
works well.
works well.
Before you configure authentication, make sure that you study what method is the best for your environment, because SONAS does not support authentication migration from one type to another. The only way to change the authentication is to clean it up and reconfigure.
Here, LDAP works as an authentication server in addition to working as an external ID mapping server. External ID mapping enables the ID mapping to remain out of the SONAS system. This method allows multiple SONAS systems to access the same UID and GID information of users and groups. So, for asynchronous replication, both the source and target are able to see the same user and group information, and therefore apply ACLs correctly.
2.6.1 Tasks before you get started
Before SONAS can be configured with an external LDAP server, you must verify the validity of the LDAP server. For this purpose, the following tasks must be done:
1. Validate that Management node can create SSH connections to the Interface nodes.
2. Check whether at least one of the LDAP servers is pingable. Verify that the LDAP server is up and responds by sending an LDAP query with the filter objectClass=*.
3. Verify that LDAP server is configured with at least a few users by sending an LDAP query with the filter ou=People.
4. Before you configure SONAS with LDAP, the LDAP user information must be updated with unique Samba attributes in addition to the attributes that are stored for a normal LDAP user. Ensure that these required Samba attributes are present in the LDAP user entries.
5. The validation is run on each of the Interface nodes. If SSL/TLS is being configured, the certificate is also checked at this stage itself. Also, if Kerberos is enabled, the keytab file is checked for entries of the following types:
– cifs/<cluster-name>.<domain>
– cifs/<hostname>
|
Important: The verification procedure does not change any configuration for an existing authentication (if any).
For LDAP-KRB-CIFS configuration, plain LDAP users are still accepted. If the requirement is to allow access only for Kerberos users, set some invalid passwords in the LDAP database for the users.
|
2.6.2 Prerequisites for configuring the IBM SONAS system with LDAP
Before you configure SONAS, the LDAP schema must be extended to enable storing of additional attributes, such as SID, Windows password hash, and so on, to the LDAP
user object.
user object.
The prerequisites are discussed in the Authentication chapter of IBM SONAS Implementation Guide, SG24-7962.
2.6.3 Preferred practices for configuring LDAP
This section describes the preferred practices to follow when you configure LDAP.
Configuring LDAP correctly before data is created on SONAS
When you configure authentication for the first time, it is essential you do it correctly before creating or migrating data on SONAS.
There is no way to correct any misconfiguration, except by cleaning up the authentication configuration.
User and group ID values must be greater than 1024
This is both a limitation and a preferred practice. Ensure that the UID for users and the GID for groups are greater than 1024. If the UID or GID is lower, access is denied.
Verify that all users and groups have valid UID and GID
Before migrating or copying data, make sure all the users and groups that will be accessing data have valid UID and GID. Do not change these values in the future, especially if data exists on SONAS.
Users with the same user name from different organizational units in the LDAP server
Users with the same user name from different organizational units within the same LDAP server trust are denied access to CIFS shares without regard to the LDAP User Suffix and LDAP Group suffix values configured on the system.
Limitation with the chkauth command and LDAP configuration
For LDAP-based authentication, the chkauth command validates access by using the userPassword attribute of the user in the LDAP directory server. If the userPassword attribute is inconsistent with the sambaNTPassword, CIFS access might be denied even if chkauth authentication is successful.
|
Attention: The cfgldap command restarts the file services (FTP, SCP, HTTP, NFS, CIFS), which is disruptive for connected clients. The connected clients lose their connection and the file operations are interrupted. File services will resume few seconds after the command finishes successfully.
When LDAP authentication is configured against the SONAS system, rerunning the cfgldap command overwrites the earlier configuration with the new one.
|
2.6.4 Common issues for LDAP setup
This section lists common issues that occur during LDAP setup.
Issue: LDAP is successfully configured, but some users cannot access data because the UID or GID is less than 1024
LDAP is set up correctly, but access is denied for some users.
How to debug this issue
Complete the following steps to debug user access:
1. If access is denied, check whether the ACLs are sufficient for user access. If the ACLs are set correctly, check for the UID or GID for the user or group that requires access.
2. Run the chkauth command to check for the UID or GID.
$chkauth -i -u "<DOMAIN\username>"
In Example 2-13, it can be seen that UID is less than 1024. This is the cause of the issue.
Example 2-13 Failed to get IDMapping for user
$ chkauth -i -u "SONASuser1"
EFSSG0002C Command exception found: FAILED TO FETCH USER INFO
Conclusion
The UID for all users or GID for all groups should be greater than 1024. If it is less than 1024, SONAS denies access for the user or group.
How to correct this issue
To correct the issue, you need to update the UID for the users whose UID is lower than 1024.
|
Attention: Users lose access to data that has ACLs with the older UID or GID.
|
Preferred practice to be followed
It is essential that the UID and GID for users and groups is greater than 1024 when using LDAP authentication. Access is denied if any UID or GID is lower than 1024.
Issue: LDAP is successfully configured, but some users cannot access data because the user name is less than three characters
LDAP is set up correctly, but access is denied for some users.
How to debug this issue
Complete the following steps to debug access:
1. If access is denied, check whether the ACLs are sufficient for the user to access. If ACLs are set correctly, check for the UID or GID for the user or group that requires access.
2. Run the chkauth commands to check for the UID or GID:
$chkauth -i -u "<DOMAIN\username>"
In Example 2-14, it can be seen that UID is correctly set. However, it can be seen that the name of the user who is trying to access is fewer than three characters.
Example 2-14 Failed to get IDMapping for user
$ chkauth -i -u "SONASab"
Command_Output_Data UID GID Home_Directory Template_Shell
FETCH USER INFO SUCCEED 10061795 10000513 /var/opt/IBM/sofs/scproot /usr/bin/rssh
This is the root cause. This example is shown in Red Hat Enterprise Linux (RHEL). This is a known issue in RHEL 6.0 releases and has been fixed in RHEL 6.2 and later release. SONAS 1.4 uses RHEL 6.1. This is not an issue for SONAS 1.5.1 and later.
Conclusion
LDAP user and group names must have more than three characters to work correctly.
How to correct this issue
There is a workaround for this issue on older SONAS releases. This section provides tasks for applying manual configurations and for removing them.
Do the following steps to apply manual configurations. These steps require root login to one of the nodes:
1. Copy the stock /etc/nslcd.conf file that is generated to a temporary directory:
cp /etc/nslcd.conf /tmp/tmp_nslcd.conf
2. Add the following lines to the end of the temporary file:
# Workaround to allow 2 characters user names
validnames /^[a-z0-9._@$()][a-z0-9._@$() ~-]*[a-z0-9._@$()~-]$/i
3. Update the registry with this new file:
fileContent="$(cat /tmp/tmp_nslcd.conf; printf x)"
# printf jig takes care of new line character at EOF
net registry setvalue HKLM/SOFTWARE/IBM/SOFS/AUTH NSLCD_CONF sz "${fileContent%x}"
4. Reload cnscmc on all nodes:
onnode all cnscmc reload auth
onnode all service nslcd stop
5. Remove the temporary file:
rm -f /tmp/tmp_nslcd.conf
Complete the following steps to remove the manual configurations:
1. Copy the stock /etc/nslcd.conf file that is generated to a temporary directory:
cp /etc/nslcd.conf /tmp/tmp_nslcd.conf
2. Remove the following lines from the end of the temporary file:
# Workaround to allow 2 characters user names
validnames /^[a-z0-9._@$()][a-z0-9._@$() ~-]*[a-z0-9._@$()~-]$/i
3. Update the registry with this new file:
fileContent="$(cat /tmp/tmp_nslcd.conf; printf x)"
net registry setvalue HKLM/SOFTWARE/IBM/SOFS/AUTH NSLCD_CONF sz "${fileContent%x}"
4. Reload cnscmc on all nodes:
onnode all cnscmc reload auth
onnode all service nslcd stop
5. Remove the temporary file:
rm -f /tmp/tmp_nslcd.conf
|
Important: If breakage is observed, you might need to remove the manual configurations.
Upgrade considerations: The upgrades for these manual configurations do not require any changes before or after upgrade. However, if the manual changes are lost after upgrade, repeat the steps for manual configuration.
Important: Users do not lose access to data because ACLs are stored for UID and GID, which remain intact.
|
Preferred practice to be followed
It is essential that user and group names are more than three characters long. Access is denied if any user or group has a name with fewer characters than that.
2.7 Preferred practices for Network Information Service
NIS is used in UNIX-based environments for centralized user and other services management. NIS is used for keeping user, domain, and netgroup information. Customers with UNIX-based environments use NIS for user management and host name management so all systems have the same user information. In SONAS, NIS is used for netgroup support and ID mapping.
This section explains some of the important points for configuring SONAS with NIS.
2.7.1 Prerequisites for configuring the SONAS system with AD and NIS
The following prerequisites apply to configuring SONAS with Active Directory and NIS:
•No data files have been stored on the SONAS system.
•AD authentication is configured on the SONAS system by using the cfgad SONAS CLI command.
•NIS is used for all User ID Mapping.
•All NIS user and group names must be in lowercase, with white space replaced by the underscore character (_). For example, an Active Directory user name CAPITAL Name should have a corresponding name on NIS as capital_name.
2.7.2 Limitations of configuring the SONAS system with AD and NIS
The following limitations apply to configuring SONAS with Active Directory and NIS:
•The low value of idmapUserRange and idmapGroupRange cannot be less than 1024.
•UNIX-style names do not allow spaces in the name. For mapping Active Directory users or group to NIS users, consider the following conversion on the NIS server:
– Convert all uppercase characters to lowercase.
– Replace all blank spaces with underscores.
For example, an Active Directory user or group name CAPITAL Name should have a corresponding name on NIS as capital_name.
|
Important: If the preceding naming convention is not used for users, NIS mapping does not happen, and ID mapping for such users follows the user map rules that are defined in the cfgnis --userMap option for that AD domain.
|
2.7.3 Revisiting key parameters for configuring NIS
This section reviews key parameters for configuring NIS.
•--extend { extend }
In extended mode, NIS can also be used as an ID mapping mechanism. ID mapping functionality can be activated using the --useAsIdmap option.
•--idmapUserRange { idmapUserRange }
This parameter sets the user ID range. The UIDs of the users from the Active Directory domain that have a user map rule set to AUTO are assigned from this range. Samba will also use this range to map some of the well-known SIDs to UIDs. This option is mandatory when used with the --extend and --useAsIdmap options.
Use the format <lowerID of the range> - <higherID of the range>. LowerID cannot be less than 1024:
--idmapUserRange 100000-200000
•--idmapGroupRange { idmapGroupRange }
This parameter sets the group ID range. The GIDs of all the Active Directory groups that have no NIS mapping are assigned from this range. Samba also uses this range to map some of the well-known SIDs to GIDs. This option is mandatory when used with the --extend and --useAsIdmap options.
Use the format <lowerID of the range> - <higherID of the range>. LowerID cannot be less than 1024:
--idmapGroupRange 100000-200000
|
Note: Absence of the --extend option indicates that NIS is to be configured in basic mode. Basic configuration supports NIS authentication for the NFS netgroup. It does not include any other protocol configuration, and does not support the ID mapping mechanism.
There should be a single mapping entry for a specified server. Having multiple entries for the same NIS server triggers an error.
LowerID cannot be less than 1024.
|
2.7.4 Preferred practices when you configure NIS
This section provides several preferred practices for configuring NIS.
Configuring NIS correctly before data is created on SONAS
When you configure authentication for the first time, it is essential that you do it immediately before creating or migrating data on SONAS.
There is no way to correct any misconfiguration, except by cleaning up the authentication that is configured.
User and group range values must be greater than 1024
This is both a preferred practice and a limitation. Users and groups range values must be greater than 1024.
User and group names must be in lowercase
This is both a preferred practice and a limitation. Users and groups must have names in lowercase letter.
Replace space or blank space in user and group names with an underscore (_)
This is both a preferred practice and a limitation. If there is a space or a blank space in a user or group name, it must be replaced with an underscore (_).
Establishing correct user mapping for Active Directory users who do not already have a user ID mapping in NIS
Use one of the following three options for the --userMap option in the cfgnis command to select the correct mapping for users who do not already have a user ID mapping in NIS:
•AD_domain1:DENY_ACCESS
If a user from this domain does not have a mapping entry in NIS, the user is denied access. The Active Directory domain that has no user rule defined defaults to DENY_ACCESS.
•AD_domain1:AUTO
If a user from this domain does not have a mapping entry in the NIS, a new ID is generated for the user. This ID is generated from the --idmapUserRange option and is auto-incremented. The administrator must ensure that existing NIS IDs do not fall in this ID range. This mapping is maintained in the system. NIS is not aware of this ID mapping.
•AD_domain1:DEFAULT:ad_domain\guest_user
If a user cannot be mapped in NIS, the user is mapped to a single guest user in Active Directory or Samba Primary Directory Controller (PDC), who must have a mapping entry in NIS.
This requires that the guest user as specified in the --map instruction is mapped in NIS.
There can be only one rule out of the three listed options for the cfgnis command per
Active Directory domain. Making multiple rules for the same Active Directory domain causes an error.
Active Directory domain. Making multiple rules for the same Active Directory domain causes an error.
This is an optional parameter and the default setting is to deny all the users who do not have a NIS mapping.
This option can be used only when both the --extend and --useAsIdmap options are specified.
|
Important: The cfgnis command restarts the file services (FTP, SCP, HTTP, NFS, and CIFS), which is disruptive for connected clients. The connected clients lose their connection and the file operations are interrupted. File services will resume few seconds after the command finishes successfully.
When NIS service is configured against the SONAS system, rerunning the cfgnis command overwrites the earlier configuration with the new one.
|
Preferred practice to be followed
The preferred practice is to decide what options to use before installation. Use the default setting and repair failed user attempts with the specified NIS ID mapping.
Issue: AD+NIS successfully configured, yet some users are denied access - AD user does not have a mapping entry in NIS
Even after AD+NIS is successfully configured, some AD users are denied access to the IBM SONAS share.
How to debug this issue
Complete the following steps to debug user access:
1. If after sufficient ACLs are applied, data is inaccessible, check whether the UID for that user is set. Use the following command to check whether the user or group has a UID or GID assigned:
#chkauth -i -u "<DOMAIN\username>"
2. Run the chkauth command. Example 2-15 shows that the chkauth command does not show the UID or GID for autouser3. If the chkauth command does not show a UID or GID (even though SONAS cluster can resolve the users on the domain controller), even though the user is present in the AD server, a corresponding user might not be present in the
NIS server.
NIS server.
Example 2-15 Failed to get IDMapping for user
# chkauth -i -u "SONAS\autouser3"
EFSSG0002C Command exception found: FAILED TO FETCH USER INFO
Conclusion
Access is denied for users present only in the AD server but not present in NIS server.
How to correct this issue
There are multiple ways to resolve this issue:
•Define a corresponding user in the NIS server. See your NIS server documentation for creating new users.
•As per requirements, select the wanted option for the --userMap option while configuring authentication by using the cfgnis command. The default action for such users is to deny access. You can select the AD_domain:AUTO option in --userMap to let SONAS automatically generate a UID. Alternatively, use the AD_domain:DEFAULT option in --userMap to map such users to a predefined guest user in AD server. For the exact syntax and examples for --userMap, see the man page for the cfgnis command.
Preferred practice to follow
The preferred practice is to select options in advance. Configure the correct options for users who are present in AD without a corresponding user in NIS server while configuring authentication and before storing any data or accessing the cluster.
Issue: AD+NIS successfully configured, yet some users are denied access and the AD user has a mapping entry in NIS
Even after AD+NIS is successfully configured some windows users are denied access to the IBM SONAS share even though there is a corresponding user present in the NIS server.
How to debug this issue
Complete the following steps to debug user access:
1. If after sufficient ACLs, data is inaccessible, check if the UID for that user is set. Use the following command to check whether the user or group has a UID or GID assigned:
#chkauth -i -u "<DOMAIN\username>"
2. Example 2-16 shows that the chkauth command does not show the UID or GID for AUTO user4. If the chkauth command does not show UID or GID even though the SONAS cluster can resolve the users on the domain controller, the user might be present in the AD server without a corresponding user present in the NIS server.
Example 2-16 Failed to get ID mapping for user
chkauth -i -u "SONAS\AUTO user4"
EFSSG0002C Command exception found: FAILED TO FETCH USER INFO
Conclusion
UNIX-style names do not allow spaces in the name. For mapping Active Directory users or groups to NIS users, consider the following conversion on the NIS server:
•Convert all uppercase alphabets to lowercase.
•Replace all blank spaces with underscores.
How to correct this issue
Complete the following steps to correct this issue:
1. Define the corresponding user in NIS server as for the UNIX-style names.
2. After the corresponding user is defined in the NIS server as for the UNIX-style names (in this case it should be auto_user4) you can use the chkauth command as shown in Example 2-17 to verify it.
Example 2-17 Successfully displays ID mapping for a user
# chkauth -i -u "SONAS\AUTO user4"
Command_Output_Data UID GID Home_Directory Template_Shell
FETCH USER INFO SUCCEEDED 21015 2100 /var/opt/IBM/sofs/scproot /usr/bin/rssh
EFSSG1000I The command completed successfully.
If the default setting, which is to deny access, was used in the --userMap parameter of the cfgnis command, access is denied for such users. However, if the --userMap option chosen was either AD_domain:AUTO or AD_domain:DEFAULT, such unmapped users are either provided auto incremented UIDs by SONAS or are mapped to predefined guest users that are defined in AD. But then in such cases, even though the user might be able to access the shares, it might not have access to the data as expected.
Preferred practice to be followed
The preferred practice is to define all the users in NIS server as for the UNIX style names for all the AD users with uppercase letters, space in their names, or both. This renaming must be done before storing any data or accessing the cluster.
2.8 Preferred practices for local authentication
For version 1.5.1 and later, SONAS supports configuring authentication by using a local authentication server that is hosted internally by SONAS itself. For a detailed description of local authentication, see the Authentication chapter in IBM SONAS Implementation Guide, SG24-7962.
Local authentication supports both Windows and UNIX clients with some limitations that are described later in this section. Therefore, for mixed environments with both Windows and UNIX clients, this method can be considered.
Local authentication eliminates the requirement for an external authentication server and provides the capability to do user authentication and ID mapping from within the SONAS system. This method reserves an ID range and allocates UIDs and GIDs on a first-come first-served incremental basis as the default setting.
2.8.1 Limitations for configuring SONAS with local authentication
The following limitations apply to configuring SONAS with local authentication:
•There is no support for migration of existing authentication server user and group data to local authentication server.
•There is no support for migration of user and group data from local authentication server to external authentication server.
•NAS user and group names are case-sensitive.
•NAS user and group names cannot collide with the CLI and system users.
•No support for secure NFS and CIFS. SONAS local authentication does not support Kerberized access.
•The local authentication server that is hosted inside SONAS cannot be used as an external directory server.
•NFS netgroups are not supported.
•There are no local data access user password policies (except minimum length password).
•Stand-alone windows clients (not part of any domain) lack ACL update capabilities.
•User names and IDs that are used with local authentication must be the same as those that are used on NFSv4 clients.
•A maximum of 1000 users and 100 groups are supported. A user can belong to only 16 groups. A group can consist of 1000 users.
•Asynchronous replication is not supported.
2.8.2 Preferred practices for configuring SONAS with local authentication
This section describes preferred practices for configuring SONAS with local authentication.
Consistent user and group identity across multiple SONAS systems
It is preferred to make user and group names consistent across multiple SONAS systems in a customer environment. SONAS administrators must ensure this consistency of user and group identities across multiple systems. This configuration simplifies migrating authentication to an external LDAP server.
Unique user and groups IDs across systems
Do not reuse UIDs and GIDs across different SONAS systems. When they manage multiple SONAS systems, administrators should designate a primary SONAS system that will have all the users and groups. Create all new users and groups first on the primary SONAS system and then on the other SONAS system by reusing the same UID and GID as on the primary system. This method ensures that UIDs and GIDs are consistent across SONAS systems even if not all users connect to each SONAS system.
Always specify the UID and GID to create local users and groups
Always use a UID and GID you create users and groups with the CLI commands, rather than letting SONAS auto generate the UID and GID. This method provides increased control and administrative awareness to ensure that no security authorization issues are introduced over many years of use of the system. This method also helps in maintaining consistent user and group names and corresponding UIDs and GIDs across multiple SONAS systems.
Setting up Linux and UNIX systems for NFS access
To avoid UID or GID conflicts, ensure that user and group identities on the host system are consistent with those on IBM SONAS systems. UID/GID can be displayed on the host by using the UNIX id command.
Issue: Local authentication successfully configured but some NFS users are unable to access data.
Even after local authentication was successfully configured, some NFS users are not able to access data.
An NFS export that is mounted on a Linux host by the user autouser1 is not able create files and gets a permission denied error message, as shown in Example 2-18.
Example 2-18 Permission denied message
[autouser1@gssvm01 testex]$ touch testfile
touch: cannot touch `testfile': Permission denied
How to debug this issue
Complete the following steps to debug user access:
1. If data is inaccessible, the first thing you need to check is whether the user that is trying to access the data is successfully resolved by the system and has sufficient ACLs.
2. If ACLs are sufficient, and data is still not accessible, check if the UID and GID for that user is set. Use the following command to check if the user or group has a UID or GID assigned as expected:
#chkauth -i -u autouser1
As shown in Example 2-19, the UID and GID of the user autouser1 are set as expected by the SONAS administrator.
Example 2-19 The UID and GID are set correctly
[st001.virtual1.com]$ chkauth -i -u autouser1
Command_Output_Data UID GID Home_Directory Template_Shell
FETCH USER INFO SUCCEEDED 2000 2000 /var/opt/IBM/sofs/scproot /usr/bin/rssh
EFSSG1000I The command completed successfully.
3. Now on the NFS host, check whether the UID and GID of autouser1 set to what they are on the SONAS cluster by running the id command, as shown in Example 2-20.
Example 2-20 Verifying the UID and GUID of the autouser1 user
[autouser1@gssvm01 testex]$ id autouser1
uid=2001(autouser1) gid=2001(testgrp) groups=2001(testgrp)
As shown in Example 2-20, the UID of user autouser1 on the Linux host does not match that on the SONAS cluster.
Conclusion
Access is denied to user autouser1 because the UID does not match to that of the UID on the SONAS cluster.
How to correct this issue
Re-create the local data access user or group on the SONAS cluster to match that of the users and groups on the NFS clients.
Preferred practice to follow
Ensure that UIDs and GIDs for the NFS client the UIDs and GIDs for the local data access users and groups on the SONAS cluster.
2.9 Common authentication issues
This section lists general authentication issues that can occur in SONAS.
2.9.1 Issue: No services are running after successful configuration of SONAS
In this case, SONAS is installed and configured successfully. However, none of the services, such as CIFS, NFS, or FTP, are running. Clients are not able to access data.
How to debug this issue
Complete the following steps to debug user access:
1. If none of the services are running, check whether authentication has been configured. Run the lsauth CLI command to check, as shown in Example 2-21.
Example 2-21 Checking whether authentication has been configured
$lsauth -c st001.virtual1.com
EFSSG0571I Cluster st001.virtual1.com is not configured with any type of authentication server(ldap/ldap_krb/nt4/ad).
The result of running the lsauth command, as shown in Example 2-21 on page 66, shows that no authentication is configured.
2. In SONAS, the authentication commands start the services. Because no authentication is configured, none of the services started.
Conclusion
For services to be started and configured on SONAS, authentication must be configured after successfully installing and configuring SONAS. SONAS is ready to use only after that.
2.10 Troubleshooting authentication issues
This section shows some methods to debug issues. If your issue is not similar to any of
the issues discussed in this chapter, use one of these commands to check what might be going wrong.
the issues discussed in this chapter, use one of these commands to check what might be going wrong.
2.10.1 CLI commands to check
You can run the following commands to check whether output is as expected or something
is wrong.
is wrong.
List the authentication configured
Check the authentication that is configured by using the lsauth command. This command provides information about the configuration. You can check for the different parameters if they are set correctly, depending on the authentication that is configured. Example 2-22 shows an example for AD authentication. You can check parameters similarly for all other authentication methods.
Example 2-22 Checking the authentication that is configured on the cluster
# lsauth
AUTH_TYPE = ad
idMapConfig = 10000000-299999999,1000000
domain = SONAS
idMappingMethod = auto
clusterName = bhandar
userName = Administrator
adHost = SONAS-PUNE.SONAS.COM
passwordServer = *
realm = SONAS.COM
EFSSG1000I The command completed successfully.
Check the ID Mapping for users and groups
Run the chkauth command to check the user details such as the UID and GID for a user or group, as shown in Example 2-23.
Example 2-23 Check user information by using the chkauth command
# chkauth -c st002.vsofs1.com -i -u VSOFS1\testsfuuser2 -p Dcw2k3dom01
Command_Output_Data UID GID Home_Directory Template_Shell
FETCH USER INFO SUCCEED 250 10000011 /var/opt/IBM/sofs/scproot /usr/bin/rssh
Check for node synchronization
Run the chkauth command to check whether the nodes are in synchronization, as shown in Example 2-24.
Example 2-24 Check node synchronization by using the chkauth command
# chkauth
ALL NODES IN CLUSTER ARE IN SYNC WITH EACH OTHER
EFSSG1000I The command completed successfully.
Check whether the user can authenticate successfully
Run the chkauth command to check whether the user is able to authenticate with the authentication server, as shown in Example 2-25.
Example 2-25 Check if user can authenticate with server using ckhauth
# chkauth -c st002.vsofs1.com -a -u VSOFS1\testsfuuser2 -p Dcw2k3dom01
Command_Output_Data UID GID Home_Directory Template_Shell
AUTHENTICATE USER SUCCEED
Check whether the authentication server is reachableRun the chkauth command to check whether the authentication server is reachable, as shown in Example 2-26.
Example 2-26 Check whether authenticate server is reachable by using the ckhauth command
# chkauth -c st002.vsofs1.com -p
Command_Output_Data UID GID Home_Directory Template_Shell
PING AUTHENTICATION SERVER SUCCEED
2.10.2 Logs to check
The logs contain useful information to help resolve errors and determine what has happened in the SONAS.
System logs
Check the system logs to see whether there are any errors. The lslog CLI command displays the system log.
Audit logs
To check what commands recently ran and the command parameters, you can run the lsaudit CLI command. This shows all of the commands that were run. You might want to see the sequence of commands run, see if any of them were incorrect, and so on.
2.10.3 More logs to collect and check
If the logs in 2.10.2, “Logs to check” do not help, you can contact IBM Support. It is advisable to collect the following logs, which can help for further analysis or debugging:
•Samba Debug 10 Logs
|
Important: Read the man pages for the starttrace and stoptrace commands before you use them.
|
Run the following commands to collect the Samba Logs:
starttrace —cifs —client <client ip address>
Recreate issue on a Windows Client.
stoptrace #traceid
•UID and GID information for the user
Along with the preceding logs, also collect UID and GID information for the users you see problems for. You can run the chkauth command to get the information:
# chkauth -i -u <Username>
•Run the cndump command.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.