24.1 Troubleshooting DSfW

24.1.1 Logging In from a Workstation - Issues

Rejoining an Existing Windows Workstation or Server to a DSfW Domain Fails

If you attempt to rejoin an existing Windows workstation or server to a DSfW domain, an error message, "The trust relationship between this workstation and the primary domain failed" might appear.

To resolve this issue, perform the following steps:

  1. Click Start > Administrative Tools > Active Directory Users and Computers.

  2. In the console tree, open the Domain Services for Windows domain, and click Computers container.

  3. In the right pane, browse to the corresponding Windows workstation object.

  4. Right-click on the object and select Delete.

  5. Click Yes to confirm.

  6. Complete the steps mentioned in Section 13.1, Joining a Windows Workstation to a DSfW Domain to rejoin the Windows workstation to a DSfW Domain.

Workstation Join or Login Fails if the tdb Files are Corrupted

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

NOTE:Samba logs are located at /var/log/messages.

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

Joining a Workstation to a Domain Fails if Password Policy Requirements is not met

This error can occur due to the extra attributes that gets added in the Domain Password Policy after it has been opened using the iManager Passwords Plug-in and saved without making any changes.

To resolve this issue, see TID 7004481.

Joining a Workstation to a Domain Fails if Time is Not Synchronized

While joining a workstation to a domain, you must ensure that the system time is synchronized between the Windows workstation and the DSfW server. Otherwise, you will receive an error indicating incorrect username or password. An error message similar to the following is logged in the /var/opt/novell/xad/log/kdc.log file:

Dec 04 10:50:37 sles10sp3 krb5kdc[5048](info): preauth (timestamp) verify failure: Clock skew too great
Dec 04 10:50:40 sles10sp3 krb5kdc[5048](info): AS_REQ (7 etypes {23 -133 -128 3 1 24 -135}) 192.168.100.129: PREAUTH_FAILED: Administrator@NTS.NOVELL.COM for krbtgt/NTS.NOVELL.COM@NTS.NOVELL.COM, Clock skew too great

Join a Workstation to a Domain Fails if Services are Down

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

Workstation Join Fails due to Missing Serviceprincipalname Attribute Value

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>

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.

Workstation Login Fails With Samba Error

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.

  1. Generate the keytab file for the domain controller.

    /opt/novell/xad/sbin/setpassword -DNOSf -r -k /var/opt/novell/xad/ds/krb5kdc/krb5.keytab -u <DC_HOSTNAME>$

  2. Set the necessary permission on the keytab file.

    chmod 0640 "/var/opt/novell/xad/ds/krb5kdc/krb5.keytab"

  3. Change the group ownership on the keytab file to named.

     chgrp named /var/opt/novell/xad/ds/krb5kdc/krb5.keytab

24.1.2 Windows 7 Workstations Cannot Detect the Domain and Forest Functional Levels from MMC on OES 2018 or Later

DSfW on OES 2018 or later is at Windows 2012 Domain or Forest Functional level. If the workstation joined to the domain is Windows 7 SP1 or earlier, it cannot detect the Domain Functional Level and Forest Functional Level using MMC. To view the Domain and Forest functional levels in MMC, the workstation level should be same or more than the domain level. Windows 10 workstation can be used to view the Domain and Forest functional levels from MMC on OES 2018 or later.

24.1.3 Unable to Add msDs-PrincipalName and Create Password Settings Container During Upgrade

After upgrade to OES 2018 or later, it is advisable to review the /var/opt/novell/xad/log/ndsdcinit.log file.

If the following errors are seen in the ndsdcinit log file, you must execute the commands that are suggested in the log file after each of the errors:

2017-08-28 15:04:48 Executing...(principal) LDAPCONF=/etc/opt/novell/xad/openldap/ldap.conf /usr/bin/ldapmodify -Q -Y EXTERNAL -Z -f /var/opt/novell/xad/ds/domain/principal-domain-acls.ldif
2017-08-28 15:04:48 /opt/novell/xad/lib64/perl/util_update.pm:1099 Failed to add msDS-PrincipalName to the objects: 17: [modifying entry "ou=dsfwfrd,o=novell"] at /opt/novell/xad/lib64/perl/util_update.pm line 1094.

and

2017-08-28 15:05:10 /opt/novell/xad/lib64/perl/util_update.pm:1202 Failed to create Password Settings Container: 65: [ldap_add: Object class violation (65)        additional info: NDS error: no such class (-604)adding new entry "CN=Password Settings Container,CN=System,ou=dsfwfrd,o=novell"] at /opt/novell/xad/lib64/perl/util_update.pm line 1199.

24.1.4 No Immediate Effect of the Applied Fine-Grained Password Policy

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.

24.1.5 MMC Fails to Display the “Properties” Option for Multiple Selected Users

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:

  1. Login as Administrator to the DSfW server from a workstation.

  2. Open the Group Policy Management Console.

  3. Right-click the servername and select "Create a GPO in this domain, and Link it here..." .

  4. Go to Policies > Administrative Templates Policy > System > User Profiles and click the "Set roaming Profile paths for all users logging onto this ...." option.

  5. Select the Enabled check box and in the Options field add \\servername\profiles\%username% , then click OK.

  6. In the Group Policy Management Console, select the new group policy created and click Add to add all users that require \\servername\profiles\%username% in the profile path attribute.

24.1.6 Remote Desktop License Server Cannot Update the License Attributes

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.

  1. In iManager, select Roles and Tasks > Rights > Modify Trustees.

  2. Select the domain root partition.

  3. Click Assigned Rights for Public Trustee.

  4. Add the terminalServer attribute to the Public Trustee.

    1. Click Add Property.

    2. Select the terminalServer attribute from the Property Name list and click OK.

  5. Select the Inherit check box for the terminalServer attribute.

  6. Restart the DSfW services.

24.1.7 Editing GPO for Windows Server 2012 R2 Member Server Might Result in an Error

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.

24.1.8 The wbinfo Operation for winbind Daemon Fails if two IP Interfaces are Present in a Domain Controller

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.

24.1.9 DSfW Provisioning Fails When you Configure an Additional Domain Controller to an Existing Child Domain

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:

  1. Click the DNS Service tab of the DNS/DHCP Java Management Console.

  2. Select the parent domain zone.

  3. Click Create on the toolbar.

  4. In the Create New DNS Record Window, select the resource record, then click OK.

  5. In the Create Resource Record Window, select Others > NS.

  6. Specify the child domain's name in the DNS Server Domain Name field and click Create . A new sub-zone is created under the parent zone.

  7. Select the new sub-zone created for the child domain and click Create on the toolbar.

  8. In the Create New DNS Object Window, select Resource Record, then click OK.

  9. In the Create Resource Record Window, add an A record and specify the IP address, then click Create..

24.1.10 Error During DSfW 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

24.1.11 User Moved out of DSfW Domain is able to Access to DSfW Service

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).

24.1.12 Rename of User Object Using iManager Fails to Update the samAccountName and userPrincipalName

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.

  1. Launch iManager and connect to a DSfW server.

  2. In Roles and Tasks, select Directory Administration > Modify Object.

  3. Specify the user object in the Object name field and click OK.

  4. Click the Other tab.

  5. Select samAccountName from the Valued Attributes list and click Edit.

  6. Specify the appropriate value and click OK.

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

NOTE:Optionally, you can also use MMC Users and Computers snap-in and set appropriate logon name to rectify this issue.

24.1.13 Windows Password Synchronization Fails With DSfW Domain Users for Windows XP Clients

If you have enabled the Windows Password Synchronization feature on a workstation with Client for Open Enterprise Server 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.

24.1.14 On a Non-DSfW Server, eDirectory Restart Results in an Error Message

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.

24.1.15 ADC Install Enters Wrong Context for Server

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.

24.1.16 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:

  1. Apply the November 2012 Scheduled Maintenance patch for OES 11 SP1.

  2. Execute the following on the DSfW server:

    • /usr/bin/perl /opt/novell/xad/sbin/cross_partition_ntp_setup.pl

      This tool populates the new mounted location for /var/opt/ or /var/opt/novell/ in xadsd.service, rpcd.service, /etc/samba/smb.conf, and /etc/profile.d/novell-xad.sh.

    • /opt/novell/xad/bin/xadcntrl reload

    • /usr/sbin/rcntp restart

24.1.17 Unable to Proceed with Installation of an Additional Domain Controller

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:

  1. Verify if the DNS server is running on the remote server

    rcnovell-named status

  2. Run the command /usr/bin/dig <server name>.<domain name> +short

    If this command displays no results, proceed to Step 3.

  3. Run the command /usr/bin/dig -t SRV _ldap._tcp.pdc._msdcs.<domain name> +short

    If this command displays the corresponding SRV record, then this confirms the missing 'A' record in DNS.

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 2023: DNS/DHCP Services for Linux Administration Guide.

24.1.18 Unable to Access Sysvol

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

24.1.19 Reverse Zone Record for Workstations Joined to CDC and ADC is Not Getting Updated

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.

24.1.20 DSfW Provisioning Wizard Might Hang During the Restart DSfW Services Phase

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:

  1. A read-write local replica of Configuration partition should be added to the DSfW server. It is recommended to add a read-write local replica of the Schema partition too. For more information, see Administering Replicas in the NetIQ eDirectory Administration Guide.

  2. Restart eDirectory

    systemctl stop ndsd.service

    systemctl start ndsd.service

  3. Abort the provisioning wizard and relaunch it.

24.1.21 Citrix Xenserver Fails to Join a DSfW Domain

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 .

24.1.22 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.

NOTE:This issue occurs only with Windows 7 or later versions.

24.1.23 Administrative Templates in the Computer Configuration and User Configuration Are Empty

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:

  1. Browse to the SYSVOL folder at \\domain.tld\sysvol\ or \\ipadress\sysvol.

  2. Right-click the domain.tld folder to view the properties, then click the DFS tab. It lists all the referrals.

  3. Select the FRD link, then set it as active.

24.1.24 SLED or SLES Workstation Join to DSfW Triggers Traces in the log.smbd File

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.

24.1.25 Extending the DSfW Object Classes with Mandatory Attributes Leads to Object Creation Failure in MMC

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.

24.1.26 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.

24.1.27 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:

  1. Run the following command to display the REPLICA OPTIONS menu:

    ndsrepair -P -Ad

  2. To repair the time stamps and declare a new epoch, enter

    12

  3. You are prompted to perform a database repair and declare a new epoch, enter

    y

  4. Proceed to provide administrator name and password.

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

24.1.28 MMC Fails to Create Users

If you receive a failure 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.

24.1.29 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.

24.1.30 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.

24.1.31 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

24.1.32 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:

  • Give the user the Supervisor right to the Server object

  • Linux-enable the user with Linux User Management by adding the user to the LUM-enabled Domain admingroup associated with the server.

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

24.1.33 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.

24.1.34 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.

24.1.35 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.

24.1.36 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:

  1. ndsd (eDirectory)

  2. novell-named (DNS)

  3. nscd (Name Server cache daemon)

  4. rpcd (RPC server)

  5. Xad-krb5kdc (Kerberos)

  6. xad-kpasswdd (Kpassword)

  7. xadsd (XAD daemon)

  8. nmbd (NMB server, NETBIOS lookup)

  9. winbindd (winbind)

  10. smbd (Samba)

  11. sshd (SSH)

  12. rsyncd (rsync)

To restart the services use the xadcntrl reload command.

24.1.37 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, OES Remote Manager, the Client for Open Enterprise Server, and the command line.

Administrator Not Able to Create Samba Shares

To create Samba shares, the admingroup that the administrator belongs to should be a member of the Unix Workstation Object of the server to which the Samba share is mounted.

  1. Run namgrouplist -x <o=organization> | grep admingroup to list all the admingroups.

  2. Add the listed admingroups as a member of Unix Workstation Object of the server to which the samba shares are mounted.

Users Not Able to Access NSS volume/Samba Shares

Ensure the Domain Users group is added to the groupMembership attribute of the Unix workstation Object of the server to which the NSS volume/Samba share is mounted.

24.1.38 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:

  1. Run rcnovell-named stop to stop the novell-named.

  2. To disable the dynamic reconfiguration, modify the following entry from the /etc/init.d/novell-named file:

    startproc -p ${NAMED_PID} ${NAMED_BIN} ${NAMED_ARGS} -u named

    to

    startproc -p ${NAMED_PID} ${NAMED_BIN} ${NAMED_ARGS} -u named -r off

  3. Run rcnovell-named start to restart the novell-named.

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

24.1.39 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

24.1.40 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.

24.1.41 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.

24.1.42 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.

24.1.43 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.

24.1.44 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.

24.1.45 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(smbd, winbindd, and nmbd) to proceed.

24.1.46 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

NOTE:You do not need to execute this command every time you install DSfW.

24.1.47 Configuring eDirectory on a Non-Default Port Affects the Installation of DSfW in a Name‑Mapped Scenario

If an existing eDirectory is configured on a non-default port, the DSfW installation in a name‑mapped scenario fails.

24.1.48 Issues in Using iManager and MMC Interchangeably to Add Users in a Mixed OES (non-DSfW) and DSfW Environment

Micro Focus recommends that you use only iManager to add users in a mixed OES (non-DSfW) and DSfW environment. If you use iManager or MMC interchangeably to add users, some of the attributes of DSfW users or groups created using MMC will not match with those created using iManager.