Samba has been the link in heterogeneous networks with Windows and Unix for many years. Once you have mastered the installation, though, everyday operation can present some potential pitfalls, to which you can only really respond correctly if you have prepared for the system errors. After discussing how to use a Samba file server securely in heterogeneous environments in a previous article [1], I will now look at problems that can occur during daily operations.

Replication Errors

At some point, you might notice that users you create on domain controller A are not listed on domain controller B. However, a user that you create on domain controller B is displayed on domain controller A. You then try to perform the replication manually and get the error message in Listing 1.

root@addc-01:/tmp# samba-tool drs replicate addc-02 addc-01 dc=example,dc=net
ERROR(<class samba.drs_utils.drsException'>): DsReplicaSync failed - drsException: DsReplicaSync failed (58, 'WERR_BAD_NET_RESP')
   File "/usr/lib/python2.7/dist-packages/ samba/netcmd/drs.py", line 389, in run drs_utils.sendDsReplicaSync(server_bind, server_bind_handle, source_dsa_guid, NC, req_options)
   File "/usr/lib/python2.7/dist-packages/samba/drs_utils.py", line 87, in sendDsReplicaSync
      raise drsException("DsReplicaSync failed %s" % estr)

No matter from which of the two domain controllers (DCs) you try to replicate, the same error message is always thrown. However, if you reverse the directions, the replication suddenly works. It looks as if the database can no longer grow, because users are no longer fully displayed. You can see that both DCs are responding and communicating correctly during replication because the samba-tool drs showrepl command does not output an error.

In this case, you need to check whether you have enough free space on the hard drive. If a DC runs out of space, the database cannot grow; therefore, no new objects can be created. Make sure you have enough free disk space, restart the Samba service, and test replication again. Replication should now work fully once again, and all of your users should be present on all of your DCs.

To get a better grip on the problem, it might be useful to create a separate partition for the directory where your databases are located. You should also always monitor your system's "fill level," preferably with one of the many free monitoring tools.

Authorization Problems with ACLs

After creating a new group policy object (GPO), you need to test the permissions for the entries in the SYSVOL share, for which you might then see the output in Listing 2. However, this is not an error, because you need to authenticate to query the permissions of the GPOs. Without authentication, you won't see a correct result. A new attempt with authentication gives you the output from Listing 3.

root@addc-01:~# samba-tool gpo aclcheck
ERROR(runtime): uncaught exception - (3221225506, '{Access Denied} A process has requested access to an object but has not been granted those access rights.')
   File "/usr/lib/python2.7/dist-packages/samba/netcmd/__init__.py", line 176, in _run return self.run(*args, **kwargs)
   File "/usr/lib/python2.7/dist-packages/samba/netcmd/gpo.py", line 1148, in run fs_sd = conn.get_acl(sharepath, security.SECINFO_OWNER | security.SECINFO_GROUP | security.SECINFO_DACL, security.SEC_FLAG_MAXIMUM_ALLOWED)

root@addc-01:~# samba-tool gpo aclcheck -U administrator
Password for [EXAMPLE\administrator]:
ERROR: Invalid GPO ACL O:DAG:DAD:PAI(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;;EA)(A;OICIIO; 0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;ED)(A;OICI;0x001200a9;;;S-1-5-21-1129951053-411964844-750776748-1105)(A;OICI;0x001200a9;;;DC) on path (example.net\Policies\{B30A27B8-8221-42B7-BA9F-BC6D2E9D7227}), should be O:DAG:DAD:PAR(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO; 0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;ED)(A;OICI;0x001200a9;;;S-1-5-21-1129951053-411964844-750776748-1105)(A;OICI;0x001200a9;;;DC)

A test with the command

samba-tool ntacl sysvolcheck

leads to the same error message, which refers to an error in the authorization of the GPO listed here. Also, identifying the GPO by its ID and not its name does not make things any easier. The underlying problem is described here in detail. A specific ACL, O:DAG:DAD:PAR, is expected, but the setting is O:DAG:DAD:PAI. The only apparent difference is that PAI is set, but PAR is expected.

To understand what this means, you need to break down the message a bit further: O:DA indicates that this is about the rights for the owner: the Domain Admins group, here. In this case, the owning group is specified as G:DA – again, the Domain Admins. The permissions (DACLs, or discretionary access control lists) then follow: D:PAI, in this case. The translation is: protect against inheriting (P) and automatically propagate the ACL to the child object (AI). The AR permission, which essentially means the same as AI, is expected, but the check here determines whether the filesystem also supports automatic propagation of ACLs, which all current filesystems do under Linux.

The warning is not a problem. The bug exists up to version 4.8. Although the message is ugly, you do not need to worry. If you want to fix the warning, and thus the permissions, you can do so with the

samba-tool ntacl sysvolreset

command, but whenever you edit a GPO, the warning will simply reappear.

Time Differences on the DCs

If you determine that users are not replicated to one of the DCs when they are created, you need to test replication on the DC that did not receive the new objects:

# samba-tool drs replicate addc-02 addc-01 dc=example,dc=net
Replicate from addc-01 to addc-02 was successful.

You might then notice that the replication seems to work, but the object is still not listed. In the next step, you need to test replication on the DC on which you created the object that failed to replicate. If you see the error message from Listing 4, you have already taken one big step toward fixing the problem.

root@addc-01:~# samba-tool drs replicate addc-02 addc-01 dc=example,dc=net
Failed to bind - LDAP client internal error: NT_STATUS_TIME_DIFFERENCE_AT_DC
Failed to connect to 'ldap://addc-02' with backend 'ldap': LDAP client internal error: NT_STATUS_TIME_DIFFERENCE_AT_DC
ERROR(ldb): LDAP connection to addc-02 failed -LDAP client internal error: NT_STATUS_TIME_DIFFERENCE_AT_DC

As you can see from the message, the time on the DC that did not receive the object no longer seems to be correct. Check the time, reset the time, and find out why the DC no longer displays the correct time. The reasons could be:

1. The time server running on your network no longer works or is not accessible.
2. You are synchronizing the time directly with a time server on the Internet, but your firewall has been reconfigured and the port for the NTP service has been blocked.
3. Check whether systemd-timesyncd.service is running on the server. If this is not the case, restart the service and check whether the service failed because of an error on your DC.

After correcting the error, replication should work as usual again.

Synchronous time is so important because all Active Directory services are secured by Kerberos. When two Kerberos-protected systems communicate, the time difference must not exceed five minutes; otherwise, communication will fail.

Only the local time is required when creating a new object. The time between the DCs only becomes relevant during replication. Replication will not work here, but why was the replication on the problematic DC successful? Easy: It has no changes, so it doesn't want to transfer anything; therefore, it doesn't get to the point where time plays a role.