24.1 Troubleshooting DSfW

On the servers configured with Fine-grained password policy, you might receive the following error after running it for several hours:

ldap_bind: Other (e.g., implementation specific) error (80)
additional info: NDS error: insufficient buffer (-649)

To resolve this issue, restart the ndsd service.

The fine-grained password policy might not be effective immediately.

To resolve this issue, change the sync time to a lower value in crontab for fgsync.sh. Alternatively, you can manually run the binary /opt/novell/xad/sbin/fgpsync.sh on the DSfW server.

When a Windows 10 workstation is joined to the domain, the group policies fail to update. Also, the GPO edits fail with the following error:

Failed to open the Group Policy Object. You might not have the appropriate rights.
Details: The user name or password is incorrect

To resolve this issue, install the October 2016 hot patch and perform the following manual steps:

For a workstation joined to a DSfW domain, on the MMC console, if you select multiple users and right-click, the Properties option is not displayed. This is because the nTSecurityDescriptor attribute is not fully supported by DSfW. Therefore, you cannot change settings for multiple users using the Properties option.

You can change the settings for multiple users by adding a GPO in the DSfW domain and applying the same settings on GPO. For example, if you need to add \\servername\profiles\%username% to the profile path attribute of multiple users at the same time, follow the steps given below:

Remote Desktop license server cannot update the license attributes because the terminalServer attribute has insufficient rights. You must provide sufficient rights to terminalServer attribute to resolve this issue. To provide sufficient rights to the terminalServer attribute, follow the steps given below.

After joining a Windows server 2012 R2 to a DSfW domain, editing the GPO might result in the following error:

You can ignore this error since the editing of GPO works fine.

If WINS is enabled, winbind will try to resolve a domain controller name with WINS, which might return the secondary IP address in some cases, resulting in a winbind request failure with a timeout error. This is because the domain controller is configured using the primary IP and it will not be able to resolve the domain controller name with a secondary IP. To resolve this, remove the secondary IP address entry from the /etc/hosts file.

DSfW provisioning fails during the Configure DNS task when the child domain controller is OES 11 SP1 or previous version or the child domain controller is upgraded to OES 11 SP2 or later. When you add a domain controller to an existing child domain, follow the steps below before provisioning:

You might receive the following error during DSfW provisioning if the LDAP certificates are not created correctly:

Can't contact LDAP server (-1)

Verify if the LDAP server is running by executing the following command:

$rcndsd status

If this error is displayed and the LDAP daemon is running on the DSfW server that is contacted over secure port 636, you must execute the following command to rectify this issue:

ndsconfig upgrade

Assume that the container ou=India is mapped to a DSfW domain. A user which is part of this domain will be able to access all DSfW services such as domain login.

Figure 24-1 Access to DSfW Service

If you move the user to a partition above the mapped container (for example o=asia), the user will not be able to access DSfW services. However, if you move this user outside this domain boundary to another eDirectory partition which is below the mapped container( for example ou=Bangalore), and if this partition has a local replica on the DSfW server, the user will still continue to access the DSfW service. To resolve this issue, you must remove the local replica of the partition (ou=Bangalore).

If you rename a user object using iManager, the respective samAccountName and userPrincipalName will not be updated. You must manually update the respective samAccountName and userPrincipalName in iManager.

Repeat Step 5 and Step 6 to change the value of userPrincipalName.

If you have enabled the Windows Password Synchronization feature on a workstation with Novell client installed and then attempt to login to eDirectory and the DSfW domain with a different password for the same user, password synchronization fails with the following error message:

Failed to change windows password to match Novell. Your windows password was not changed. 

This issue is observed only on windows workstations with Windows XP installed.

When you attempt to login to workstation it fails with the following samba error message in the /var/log/samba/log.smbd file:

Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!

This might be because the keytab file is corrupted and it is unable to verify the service ticket. To rectify this issue, you must regenerate the keytab file and set the necessary permissions for the keytab file.

On a non- DSfW Server, if you restart eDirectory, the following error message is received:

Method load failed: libxadnds.so.2: cannot open shared object file: No such file or directory

This is because 3 NMAS methods (IPCExternal, Kerberos, and Negotiate) fail to load on the server. These NMAS methods that are specific to DSfW are part of the novell-xad-nmas-methods rpm and depend on the libraries from the novell-xad-framework rpm. Since the novell-xad-framework rpm is part of the DSfW pattern and is installed only on a DSfW server, you receive this error message on a non-DSfW server.

If you receive this error message, you can ignore this message as these DSfW NMAS methods do not function in a non-DSfW server and do not impact any eDirectory functionality.

During the Additional domain controller install, the server is installed in the cn=users container and the field is grayed out. Any attempt to modify the context in nds.conf fails.

To resolve this problem, you must recreate the Certificate Authority. For information, see TID 7012509.

During DSfW services startup, you might receive the following error:

/var/lib/ntp//var/opt/novell/xad/rpc/xadsd' to `/var/opt/novell/xad/rpc/xadsd':Invalid cross-device link

This is because /var/opt/ and /var/opt/novell/ are in different partitions, so DSfW fails to set up signed NTP for clients to trust.

To set up the signed NTP for clients in a cross-partition environment:

During installation of an ADC, if the Existing Domain Administrator Name field is empty and grayed out, you will be unable to proceed with the installation. This issue may be due to the missing 'A' record in DNS. To confirm if this issue is due to the missing 'A' record, do the following:

To proceed with the installation, you must add the missing A record using Java Console. For information on how to add the record, see Creating Resource Records in the OES 2015 SP1: DNS/DHCP Services for Linux Administration Guide.

If you are unable to access sysvol refer Section 5.15, Ensuring Filesystem ACL Support and TID 7009748.

When workstations are joined to the DSfW domain, the A record is created in the forward zone and PTR record is created in the reverse zone. However, when the workstation is joined to the DSfW domain using CDC or ADC DNS server IP, the PTR record does not get created in the reverse zone. This is because the reverse zone DNS master is always the  FRD DNS server.

To create a PTR record in the reverse zone, specify the FRD DNS server IP in the Alternate DNS server field of the TCP/IP Properties dialog box on the workstation that is being joined to the domain.

The DSfW provisioning Wizard might hang during the Restart DSfW Services phase while executing CLDAP Netlogon query. This is an intermittent issue.

If the Provisioning Wizard hangs, do the following:

Citrix Xenserver 5.6 fails to join a DSfW domain. This is because when Xenserver attempts to join a DSfW domain, it attempts to read certain password policy related attributes in eDirectory which fails. To enable the attributes to be readable, you need to run a script.

For more information, refer to the TID .

If a third-party application requires importing a certificate for authentication and a DSfW user changes the workstation login password after importing the certificate, then the user needs to reimport the certificate after the password change. This issue occurs only if the user password is changed at the workstation and does not occur if the password is changed using iManager.

While you are editing a group policy object, if the administrative templates in the computer configuration and user configuration screens are empty, it is because the DFS link is pointing to ADC instead of FRD as a PDC emulator. If this happens, you must ensure that the DFS link points to FRD as a PDC emulator by executing the following procedure:

If the tdb files at /var/lib/samba are corrupted, then the workstation join or login fails. The tdb files are used by Samba services (smbd, winbindd, and nmbd). The workstation join or login failure is indicated by the following message in the Samba logs:

rec_free_read bad magic

To resolve this issue, you must first delete all the tdb files at /var/lib/samba, then restart the Samba services.

When the SLED and SLES workstations are joined to DSfW as member servers, backtraces are observed in the /var/log/samba/log.smbd file. This is because after joining, the workstations send periodic requests to the Samba server. The Samba server acts as a proxy and forwards these requests to the RPCD server. However, the connection between the Samba server and the RPCD server times out after 5 minutes. Therefore, periodic requests to the Samba server fail after the connection times out, and the traces are logged in the log.smbd file.

If the DSfW domain has multiple domain controllers and certain values of the attribute servicePrincipalName are missing from the domain controller object, then the workstation join to the domain might fail. In this case, the following message is logged in the /var/opt/novell/xad/log/kdc.log file:

<servicePrincipalName>, Server not found in Kerberos database.

To update the servicePrincipalName attribute with the missing values, you must create an LDIF file with the list of service principals. The list of service principals can be obtained from the /var/opt/novell/xad/ds/domain/domain-bl.ldif file. You must then upload the LDIF file by using the following command:

LDAPCONF=/etc/opt/novell/xad/openldap/ldap.conf ldapmodify -Y EXTERNAL -f <path-to-your-ldif-file> 

When you extend the schema of the object classes OrganizationalPerson, OrganizationUnit, and group with mandatory attributes, using MMC to create objects for these classes fails with the following error:

-609 MISSING MANDATORY 

The error message can be observed by using the ndstrace utility with the LDAP tag enabled.

Kinit will not work for users if they were part of a non-dsfw partition that later got merged with the domain partition. This is because after merging the partition, users are not samified automatically. You must use domaincntrl --samify option to do this manually. However, if universal password is not enabled for a user, supplementalcredentials and unicodepwd attributes are not generated. If universal password is enabled, these attributes get populated as part of the samification.

In name mapped installation scenarios, the cleanup task in the provisioning process fails to set the ldapserver attribute. This fails the provisioning process. This issue may occur when the netware server is holding the master replica and the time between the netware server and the domain controller is not in sync. To resolve the time synchronization issue, do the following:

After resolving the time synchronization issue, you must again run the cleanup task in the provisioning wizard.

If you receive the following message while creating users, it indicates a failure while setting Universal Password.

You must ensure that the user is associated to a password policy that has the Universal Password Policy turned on. The password policy can be directly associated to the user, the immediate container, or the partition.

On using DSfW as a WINS server, you may receive an error indicating that NetBIOS name is not registered. This is because the value of the parameter dns proxy in the smb.conf file is set to yes by default. You must ensure that the value of dns proxy is set to No.

If you change the administrator name using MMC after the installation and configuration of DSfW, iManager fails to create Samba Shares. This is because renaming the administrator name using MMC does not update the uniqueID attribute. You must explicitly modify the uniqueID attribute to reflect the changed administrator name using iManager.

In Open Enterprise Server, DSfW provisions the administrator to delete the default groups. If the administrator and default groups are accidentally deleted, they can be re-created; however, ensure that objects are created with appropriate SIDs.

You can use the following LDIF files to search the deleted objects:

/var/opt/novell/xad/ds/domain/domain.ldif

/var/opt/novell/xad/ds/domain/domain-bl.ldif

/var/opt/novell/xad/ds/domain/nds-domain.ldif

The above LDIF files host the information for the following objects:

cn=Domain Admins,cn=users,<domain>

cn=Domain Controllers,cn=users,<domain>

cn=Domain Computers,cn=users,<domain>

cn=Domain Users,cn=users,<domain>

cn=Domain Guests,cn=users,<domain>

cn=Domain Group Policy Creator Owners,cn=users,<domain>

You can use the following LDIF files to search for the Enterprise Admins group object to restore.

/var/opt/novell/xad/ds/domain/forest.ldif

/var/opt/novell/xad/ds/domain/forest-bl.ldif

/var/opt/novell/xad/ds/domain/nds-admin-acls.ldif

The above LDIF files host the information for the following objects:

cn=Enterprise Admins,cn=users,<domain>

The LDIF files generated from this information should be used with ldapmodify command.

Example command:

/usr/bin/ldapmodify -H "ldapi://%2fvar%2fopt%2fnovell%2 fxad%2frun%2fldapi" -x -D "cn=Administrator,cn=users, dc=example,dc=com" -f /restore.ldif

When you install DSfW in a child domain or grandchild domain, the tree admin identity is not automatically added as an administrator of services on the server unless the tree admin is the identity used during the install. If a different identity is used for installation, the tree admin cannot manage the DSfW services on that server.

The administrator credentials that you entered during the DSfW install are automatically configured to allow that user to manage DSfW and related services on the server. After the install, you can add another administrator by configuring the following for the user:

This applies to any administrator that you want to manage DSfW on that server.

This is an invalid scenario.

If you set the bind limit to 1, services such as kinit, rpcclient, SASL-BIND, and Samba, stop and you cannot join a workstation. For the services to function as expected, change the LDAP bind limit to 0, which is the default.

By default, the Provision utility runs with the --locate-dc option only. For other options, it fails with the following message:

Failed to establish LDAP connection with <domain name> : Unknown authentication method.

To execute other options, export SASL_PATH=/opt/novell/xad/lib/sasl2 and kinit with a valid domain username before using Provision utility. All the options will work.

When the current RID master is down, the users already added to the servers other than DSfW after the RID pools are exhausted are not samified.

To resolve this issue, run /opt/novell/xad/share/dcinit/provision/provision_samify.pl on the DSfW server.

Workstations might not be able to access shared volumes from a DSfW server after the server is rebooted.

There are a number of components that must be restarted in a specific order, and this doesn’t always happen when the server restarts.

The correct order to restart services are:

To restart the services use the xadcntrl reload command.

For joining domains, ensure that SLES11 SP4 is installed first, updated with Samba 3.0.36 patch, and then OES is installed. Joining a workstation to a domain might fail sometimes if the services are down. Execute the following command to verify that DSfW services are running:

xadcntrl status

If you attempt to join multiple workstations to the domain at the same time it will result in an error. To resolve this issue, add the following line in the /etc/init.d/smb file:

export KRB5RCACHETYPE="none"

After making the changes, restart the Samba service.

DSfW configures Samba for Samba/CIFS users. Administrators must export NSS volumes over Samba so that domain users (eDirectory users in the DSfW domain partition) can access NSS volume over Samba/CIFS.Samba/CIFS users must be Linux-enabled with Linux User Management in order to access an NSS volumes via this Samba connection. To Linux-enable eDirectory users, use iManager to create a LUM group, then add the users to that group.NSS uses the NetWare Trustee Model for file access. Users must be made file system trustees and granted trustee rights to data on the NSS volume that you want them to be able to access. Rights management can be done in multiple management tools, including iManager, Novell Remote Manager, the Novell Client, and the command line.

You can perform a nslookup operation to novell-named for an existing zone/domain in the tree. If nslookup hangs, do the following steps to troubleshoot it:

If the novell-named continues hanging, you should restart it to ensure its works properly.

One of the common reasons for this error is that the users are not samified. To verify if the users are samified, execute the following command:

ldapsearch -D <admin DN> -w <passwd> -b <user dn> -x samaccountname -LLL

This command returns the dn and samaccountName attribute. If the samaccountName attribute is missing, it indicates that the users are not samified.

To samify the users, run the following script:

/opt/novell/xad/share/dcinit/provision/provision_samify.pl

To connect to legacy applications, you must either extend the object class or connect to a non-DSfW server.

A foreign user is a user who is part of another domain. If this is the case, the administrator must ensure the UID allocation does not overlap between the domains.

If a user with a Universal password policy is moved from non-domain partition to a DSfW partition, the user will not be able to login into the DSfW domain.

To resolve this issue, delete the old password policy using iManager. After this step is done, the user will be able to login to the workstation.

If a user that is not associated with a Universal password policy is moved from non-domain partition to a DSfW partition, the user will not be able to login into the DSfW domain.

To resolve this issue, attempt logging in using ndsLogin utility.

This issue is seen where there is a parent domain and one or more child domains in the DSfW forest.

If all of the domain controllers in a domain go down, requests to domains that are up and running might take a long time to respond.

To prevent this issue from occurring, make sure that at least one domain controller in a domain is up.

For more details on this issue, see TID 7003552.

This error will be recorded in the /var/log/samba/log.winbindd or any of the samba log files available at /var/log/samba/ folder.

If you see a rec_free_read bad magic entry in the log files, it indicates that the tdb files are corrupted. Delete the tdb files in /var/lib/samba/ folder and restart the samba services(smbd, winbindd, and nmbd) to proceed.

DSfW consists of several services that need to be restarted in sequence. Execute the following command to restart all DSfW services after installation.

xadcntrl reload