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
On 09/05/15 19: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.Copy the idmap database (in idmap.ldb) from DC1 to DC2 and run sysvolreset on DC2. HTH B
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
Hello Jonathan and Rowlaand, Am 09.05.2015 um 17:46 schrieb 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 >Copy idmap.ldb still works with 4.2.x. If one uses winbindd the cache file /var/cache/samba/gencache.tdb (location of that file may differ depending on the build options) must be removed after copying idmap.ldb. achim~
OK, I've got a little further and I think I have tracked this down to
a reverse DNS issue - which was non-obvious to me, so here is a
write-up for the benefit of the archives.
The part that was failing was this:
[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)]
It turns out that the reverse DNS entry for DC1 led to
DC1.my-pre-AD-dns-domain.tld, rather than DC1.domain.tld. This had
been working perfectly for everything else - but evidently kerberos is
a little pickier. I now have sssd working, I think:
[fo_set_port_status] (0x0100): Marking port 389 of server
'dc1.domain.tld' as 'working'
[set_server_common_status] (0x0100): Marking server 'dc1.domain.tld'
as 'working'
I used the following commands to test the GSSAPI element (easier than
reloading sssd and wading through logs):
Failure scenario (wrong reverse DNS):
# kinit myusername
Password for myusername at DOMAIN.TLD:
# ldapsearch -LLL -s base -b '' '(objectClass=*)' +
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
additional info: SASL(-1): generic failure: GSSAPI Error:
Unspecified GSS failure. Minor code may provide more information
(Server not found in Kerberos database)
Success scenario (fixed reverse DNS):
# kinit myusername
Password for myusername at DOMAIN.TLD:
# ldapsearch -LLL -s base -b '' '(objectClass=*)' +
SASL/GSSAPI authentication started
SASL username: myusername at DOMAIN.TLD
SASL SSF: 56
SASL data security layer installed.
dn:
--
"If we knew what it was we were doing, it would not be called
research, would it?"
- Albert Einstein
On 10 May 2015 at 16:11, Jonathan Hunter <jmhunter1 at gmail.com> wrote:> OK, I've got a little further and I think I have tracked this down to > a reverse DNS issue - which was non-obvious to me, so here is a > write-up for the benefit of the archives.Just to close this off - I have now got sssd configured and working on my Samba4 DCs (well, if I'm being picky, I have it on two out of three so far - the third is still to come, as I'll need to chown/chgrp thousands of files when I do that one) On these two separate machines (which were not ones I copied across idmap.ldb on (not that I'm using winbind now)), with a random test user (created some months ago, and which I have not used or tried to enumerate before), I get the following (sanitised) with sssd configured on each machine: [root at dc1 private]# id testuser uid=1528401182(testuser) gid=1528400513(domain users) groups=1528400513(domain users),1528402109(abc-test-ssh),1528402118(abc-test2-ssh),1528402646(users) and [root at dc2 ~]# id testuser uid=1528401182(testuser) gid=1528400513(domain users) groups=1528400513(domain users),1528402109(abc-test-ssh),1528402118(abc-test2-ssh) I have to say, I'm not sure where the 'users' group has gone to on dc2 (or possibly where it comes from on dc1; these two machines are different builds actually) but I'm happy enough that the UIDs and GIDs are now identical across these two machines. In case anyone needs it, my sssd.conf is very simple. I'm using the standard sssd that comes with CentOS 6.6 (which is 1.11.6). Conf file is: [sssd] config_file_version = 2 domains = domain.tld services = nss, pam [domain/domain.tld] id_provider = ad auth_provider = ad access_provider = ad chpass_provider = ad ldap_id_mapping = True ldap_schema = ad default_shell = /bin/bash fallback_homedir = /home/%d/%u -- "If we knew what it was we were doing, it would not be called research, would it?" - Albert Einstein