19.1.1 DSfW Fails to Set Up Signed NTP for Clients to Trust

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:

19.1.2 W32Time Auth Provider for NTP Does Not Work in a Cross-Partition Setup

Apparmor abstraction has static information related to NTP. The static information represents a socket file /var/lib/ntp/var/opt/novell/xad/rpc/xadsd. This information is valid only when the system has a single partition for '/' (root partition) or /var (var partition). However, in a multiple partition setup where /var/opt, /var/opt/novell, or /var/opt/novell/xad directory is on a different partition, the above socket file path is no longer valid. In such a setup depending on a particular partition pattern, the socket file path is going to be different. Along with the static information a new dynamic information has to be set in the Apparmor abstraction for NTP profile.

On an OES2 SP3 server that is running as a DSfW domain controller if the /var/opt, /var/opt/novell, or /var/opt/novell/xad directory is on a different partition, you must change the AppArmor NTP profile from enforce mode to complain mode in order to allow the ntpd daemon to process signed NTP requests coming from the Windows workstations that are joined to the DSfW domain.

Do the following to change the NTP AppArmor profile from enforce to complain mode:

Novell plans to address this issue in a future release.

19.1.3 setspn Tool Fails to Bind to a DSfW Domain Controller (DC) Using NetBIOS Domain Name

If you attempt to bind to a DSfW domain controller using the setspn tool by specifying the NetBIOS domain name, you will receive the following error:

Failed to bind to DC of domain DSFW, error 0x5/5 -> Access is denied.

This is because there is no corresponding servicePrincipalName value on the DC object. The DC object needs to be extended with the new servicePrincipalName value containing NetBIOS domain name. To apply this configuration change, ensure that you move to the latest OES patch level and run the following command on every domain controller.

$ /opt/novell/xad/share/dcinit/UpdateDC.pl poststage

19.1.4 Changing the User Password Requires Reimport of Third-Party Application Certificates

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.

19.1.5 Kinit Not Working for Users

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.

19.1.6 Cleanup Task Fails in Name Mapped Scenarios

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.

19.1.7 MMC Fails to Create Users

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.

19.1.8 Using DSfW Server as a WINS Server Results in an Error

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.

19.1.9 iManager Fails to Create Samba Shares if the Administrator Name is Changed using MMC

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.

19.1.10 If Administrator and Default Group Objects are Accidentally Deleted

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

19.1.11 Tree Admin is Not Automatically Granted Rights for DSfW Administration

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.

19.1.12 DSfW Services Stop Working if the Concurrent LDAP Bind Limit is Set to 1

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.

19.1.13 The Provision Utility Succeeds Only With the --locate-dc Option

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.

19.1.14 Users Are Not Samified When the RID Master Role is Seized

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.

19.1.15 Shared Volumes Are Not Accessible

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.

19.1.16 Users Cannot Join a Workstation to a Domain

For joining domains, ensure that SLES 10 SP4 is installed first, updated with Samba 3.0.36 patch, and then OES2 SP3 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

19.1.17 Joining Multiple Workstations to the Domain at the Same Time Results in an Error

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.

19.1.18 Requirements for Samba/CIFS Access to NSS volumes via DSfW

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.

19.1.19 Identifying novell-named Error

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.

19.1.20 Login Failure

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

19.1.21 Unable to Connect to Legacy Applications

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

19.1.22 User in a Domain Can Access Resources from Another Domain by Using the UID of the Foreign User

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.

19.1.23 Users Cannot Log In if They Are Moved From a Non-Domain Partition to a DSfW Domain Partition

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.

19.1.24 Users Not Associated With a Universal Password Policy Cannot Log In if They Are Moved From a Non-Domain Partition to a DSfW Domain Partition

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.

19.1.25 Child Domains Slow Down When the First Domain Controller is Not Functional

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.

19.1.26 Making the DSfW Server work When The IP address is Changed

After the IP address is changed, execute the following instructions:

After executing these steps, if the IP address change is not effective, delete the /etc/opt/novell/named/{DOMAIN}.db file and restart named.The IP address changes will be effective.

19.1.27 Error Mapping SID to UID

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(smb, winbind, and nmb) to proceed.

19.1.28 After DSfW Installation, the Services are Not Working

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