[Samba] sssd on a DC

[Rowland Penny]

On 09/05/15 18:20, Jonathan Hunter wrote:
> 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
>

I think what you are hitting here is the problem where idmap.ldb is not 
synced between DCs. This means that a windows group can have a different 
IDs between DCs. A cure is to copy idmap.ldb from the first DC to the 
second DC and then run 'samba-tool ntacl sysvolreset' , unfortunately, 
this doesn't seem to work with the latest samba 4.2.x and it also seems 
that this will not be fixed.

If this doesn't work, then I would recommend taking your problem to the 
sssd list, they know more about sssd, after all they write it :-)

Rowland