[Samba] sssd on a DC

[Jonathan Hunter]

Hi,

I have a query about the use of sssd on a Samba4 DC. Background is as follows:

I have two DCs and would like to synchronise files between the two
machines. This is for sysvol replication - I am using lsyncd (
https://code.google.com/p/lsyncd/ ) to trigger an rsync whenever files
change.

However I have hit a predictable problem, which is that since there is
no synchronised UID mapping between the two servers (they are both DCs
so rid mapping won't work), when I update a group policy using the
Windows tools, and the rsync job runs in response, my client machines
aren't able to successfully apply the policy when they reboot /
gpupdate. Error messages from Windows are along the lines of:

"The processing of Group Policy failed. Windows attempted to read the
file \\domain.tld\sysvol\domain.tld\Policies\{g-u-i-d}\gpt.ini from a
domain controller and was not successful. Group Policy settings may
not be applied until this event is resolved. [...]"

I can run "samba-tool ntacl sysvolreset" on the offending DC and that
fixes things straight away.. but only until a client requests a GPO
from the *other* DC, at which point the file ownerships on /that/ one
are wrong, and I have to repeat the process again.

After some previous advice (thanks Rowland) I think the best solution
for me would be to install and configure sssd on the DCs to
synchronise the UIDs and GIDs, at which point rsync in this way should
work just fine.. However, I don't know enough about keytabs and
suchlike.

I have sssd configured at a basic level, but am getting a strange error.

>From the log files of sssd, things look fine up to this point:

[resolv_getsrv_send] (0x0100): Trying to resolve SRV record of
'_ldap._tcp.domain.tld'

but then the rest only looks like it works 50% of the time, i.e. when
the above line resolves to the *other* DC.

I have been testing sssd on DC1 first of all. When the above DNS query
resolves to DC1, I get:

[be_resolve_server_process] (0x0200): Found address for server
dc1.domain.tld: [1.2.3.4] TTL 900
[ldap_child_get_tgt_sync] (0x0100): Principal name is: [DC1$@DOMAIN.TLD]
[...]
[sasl_bind_send] (0x0100): Executing sasl bind mech: gssapi, user: DC1$
[sasl_bind_send] (0x0020): ldap_sasl_bind failed (-2)[Local error]
[sasl_bind_send] (0x0080): Extended failure message: [SASL(-1):
generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code
may provide more information (Server not found in Kerberos database)]
[fo_set_port_status] (0x0100): Marking port 389 of server
'dc1.domain.tld' as 'not working'

However, it's perfectly happy when the query resolves to DC2:

[be_resolve_server_process] (0x0200): Found address for server
dc2.domain.tld: [1.2.3.5] TTL 900
[ldap_child_get_tgt_sync] (0x0100): Principal name is: [DC1$@DOMAIN.TLD]
[...]
[sasl_bind_send] (0x0100): Executing sasl bind mech: gssapi, user: DC1$
[child_sig_handler] (0x0100): child [8505] finished successfully.
[fo_set_port_status] (0x0100): Marking port 389 of server
'dc2.domain.tld' as 'working'
[set_server_common_status] (0x0100): Marking server 'dc2.domain.tld'
as 'working'

At first I thought it was something to do with the keytab file (which
is a bit of a black box to me and I don't quite understand); I even
extracted the keytab for DC1 and told sssd to use it directly, but I'm
confused as to why DC1 would have a problem authenticating against
itself, whereas DC2 is quite happy for it to do so.

I used:
# samba-tool domain exportkeytab /etc/krb5-dc1.keytab --principal-DC1\$
and added to sssd.conf:
krb5_keytab=/etc/krb5-dc1.keytab

I suspect this is a samba query, not sssd, given the log messages
above. Can anyone help suggest further debug commands / tests I can
run?

Both machines are CentOS 6.6; samba 4.1 compiled from source.

Many thanks

Jonathan

-- 
"If we knew what it was we were doing, it would not be called
research, would it?"
      - Albert Einstein