22.1 Troubleshooting DSfW

22.1.1 Group Policy Update Failure on Windows 10

When a Windows 10 workstation is joined to the domain, the group policies fails to update.To resolve this issue, install the October 2016 hot patch and perform the following manual steps:

Ensure that no principals are obtained in keytab using the command #klist -k | grep -i "cifs/`hostname --fqdn`/`hostname -d`".

Add the required principals to keytab in all Domain Controllers of the domain using the command #setpassword -NDSOf -r -u <server name(output of command 'hostname')>$ -E.

"<domain fqdn(output of command 'hostname --fqdn')>/<domainname(output of the command 'hostname -d')>,
<domain fqdn with hostname in all CAPS>/<domainname>,<domain fqdn with domainname in all CAPS>/<domainname in all CAPS)>,<domain fqdn with hostname and domainname in all CAPS>/<domainname in all CAPS)>,
<domain fqdn with hostname and domainname in all small>/<domainname in all small)>" -k /var/opt/novell/xad/ds/krb5kdc/krb5.keytab.

The input for the parameter of -E option "<domain fqdn with hostname and domainname in all small>/<domainname in all small)>" is required only if the hostname is in mixed case.

Reload all the DSFW services on all Domain Controllers using the command #xadcntrl reload.
Verify that the required principals are added to keytab using the command #klist -k | grep -i "cifs/`hostname --fqdn`/`hostname -d`".
Create a soft link in the primary domain controller using the command #ln -s <domain name>/Policies /var/opt/novell/xad/sysvol/sysvol/Policies in /var/opt/novell/xad/sysvol/sysvol/.
Run the command #sysvolsync in the primary domain controller.
Restart the workstations joined to the domain.

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

Login as Administrator to the DSfW server from a workstation.
Open the Group Policy Management Console.
Right-click the servername and select "Create a GPO in this domain, and Link it here..." .
Go to Policies > Administrative Templates Policy > System > User Profiles and click the "Set roaming Profile paths for all users logging onto this ...." option.
Select the Enabled check box and in the Options field add \\servername\profiles\%username% , then click OK.
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.

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

In iManager, select Roles and Tasks > Rights > Modify Trustees.
Select the domain root partition.
Click Assigned Rights for Public Trustee.
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.
Select the Inherit check box for the terminalServer attribute.
Restart the DSfW services.

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

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

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

Click the DNS Service tab of the DNS/DHCP Java Management Console.
Select the parent domain zone.
Click Create on the toolbar.
In the Create New DNS Record Window, select the resource record, then click OK.
In the Create Resource Record Window, select Others > NS.
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.
Select the new sub-zone created for the child domain and click Create on the toolbar.
In the Create New DNS Object Window, select Resource Record, then click OK.
In the Create Resource Record Window, add an A record and specify the IP address, then click Create..

22.1.7 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

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

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

Launch iManager and connect to a DSfW server.
In Roles and Tasks, select Directory Administration > Modify Object.
Specify the user object in the Object name field and click OK.
Click the Other tab.
Select samAccountName from the Valued Attributes list and click Edit.
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.

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

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

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>$

Set the necessary permission on the keytab file.

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

Change the group ownership on the keytab file to named.

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

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

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

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

Apply the November 2012 Scheduled Maintenance patch for OES 11 SP1.
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 /etc/init.d/xadsd, /etc/init.d/rpcd, /etc/samba/smb.conf, and /etc/profile.d/novell-xad.sh.
- /opt/novell/xad/bin/xadcntrl reload
- /usr/sbin/rcntp restart

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

Verify if the DNS server is running on the remote server

rcnovell-named status
Run the command /usr/bin/dig <server name>.<domain name> +short

If this command displays no results, proceed to Step 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 11 SP3: Novell DNS/DHCP Services for Linux Administration Guide.

22.1.16 Unable to Access Sysvol

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

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

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

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 Novell eDirectory 8.8 SP8 Administration Guide.
Restart eDirectory

/etc/init.d/ndsd restart
Abort the provisioning wizard and relaunch it.

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

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

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

Browse to the SYSVOL folder at \\domain.tld\sysvol\ or \\ipadress\sysvol.
Right-click the domain.tld folder to view the properties, then click the DFS tab. It lists all the referrals.
Select the FRD link, then set it as active.

22.1.22 Workstation Join or Login Fails

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.

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

22.1.24 Workstation Join Fails Because of the 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>

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

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

22.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:

Run the following command to display the REPLICA OPTIONS menu:
```
ndsrepair -P -Ad
```
To repair the time stamps and declare a new epoch, enter
```
12
```
You are prompted to perform a database repair and declare a new epoch, enter
```
y
```
Proceed to provide administrator name and password.

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

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

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

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

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

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

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

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

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

22.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:

ndsd (eDirectory)
novell-named (DNS)
nscd (Name Server cache daemon)
rpcd (RPC server)
Xad-krb5kdc (Kerberos)
xad-kpasswdd (Kpassword)
xadsd (XAD daemon)
nmbd (NMB server, NETBIOS lookup)
winbindd (winbind)
smbd (Samba)
sshd (SSH)
rsyncd (rsync)

To restart the services use the xadcntrl reload command.

22.1.37 Users Cannot Join a Workstation to a Domain

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

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

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

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.

Run namgrouplist -x <o=organization> | grep admingroup to list all the admingroups.
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.

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

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

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

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

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

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

22.1.41 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

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

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

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

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

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

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

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