samba - Apr 2019 - DsReplicaSync failed - WERR_LOGON_FAILURE // Failed to bind to uuid for ncacn_ip_tcp - NT_STATUS_LOGON_FAILURE

Hello Rowland,

thanks for your help.
Below my comments


Am Sa., 6. Apr. 2019 um 14:32 Uhr schrieb Rowland Penny via samba <
samba at lists.samba.org>:
> On Sat, 6 Apr 2019 10:58:15 +0200
> Martin Krämer via samba <samba at lists.samba.org> wrote:
>
> > Hello everyone,
> >
> > I have setup two Samba AD DC's running Debian 9 with BIND9_DLZ dns
> > backend. Both are running Samba 4.5.16 - I know it is already very
> > old version but this is the default one coming with debian stretch
> > repo. (I will upgrade to Debian buster - and with this to newer Samba
> > version - as soon as it is released stable and I could test the
> > upgrade correctly :) )
>
> See here:
>
> http://apt.van-belle.nl/
>
>
>From stability point of view I always had the best experience by saying
with the debian default repository.
Additionally as you have seen blow I am using ssds (more on this
later) "PACKAGES
ARE NOT COMPATIBLE WITH SSSD"


> >
> > location-000001.domain.de is one of the DCs hosting all FSMO
> > Roles.location-000002.domain.de is the second one.
> > Both are in different subnets but can reach each other.
> > Unfortunately replication only works from location-000001.domain.de to
> > location-000002.domain.de.
> > The other way round I always end up with error:
> > ----------
> > ERROR(<class 'samba.drs_utils.drsException'>):
DsReplicaSync failed -
> > drsException: DsReplicaSync failed (1326,
'WERR_LOGON_FAILURE')
> > ----------
> >
> > Additionally within journalctl I see:
> > ----------Failed to bind to uuid 50abc2a4-574d-40b3-9d66-ee4fd5fba076
> > for
> > ncacn_ip_tcp:192.168.13.251[1024,sign,target_hostname>
location-000001.domain.de
>
,abstract_syntax=50abc2a4-574d-40b3-9d66-ee4fd5fba076/0x00000005,localaddress=192.168.13.251]
> > NT_STATUS_LOGON_FAILURE ----------
>
> Try reading and following this:
>
>
>
https://wiki.samba.org/index.php/Verifying_and_Creating_a_DC_DNS_Record#The_objectGUID_CNAME_Record

I know that article. - But how does it help here?
Both <DC objectGUID>._msdcs.domain.de CNAMES already exist.
An none of the both objectGUIDs I recieve from:  ldbsearch -H
"/var/lib/samba/private/sam.ldb" '(invocationId=*)'
--cross-ncs objectguid
does match to the uuid I recieve the error about.
Should I (additionally to the objectGUIDs recieve from ldbsearch) register
the error uuid "50abc2a4-574d-40b3-9d66-ee4fd5fba076" ?
If yes, should I register a CNAME to location-000001(192.168.13.251) or
location-000002(192.168.30.251) dc?

>
> >
> >        Checking file: /etc/resolv.conf
> >
> > # fai installation resolve.conf
> >
> > #nameserver 127.0.0.1
> > nameserver 192.168.13.251
> > nameserver 192.168.30.251
> > nameserver 8.8.4.4
> > nameserver 192.168.13.254
> > domain domain.de
> > search domain.de
> >
>
> Why all the nameservers ?
> You only need the DC itself
>
Well the first one that is available should be used or?
Others are ignored - due to this there should be no error with them, should
it?
I just added most of the servers for test purposes I did why I tried to
find reason for the error described.
(I removed any other than the both DC IPs)

>
> >
> >        Checking file: /etc/nsswitch.conf
> >
> > # /etc/nsswitch.conf
> > #
> > # Example configuration of GNU Name Service Switch functionality.
> > # If you have the `glibc-doc-reference' and `info' packages
> > installed, try: # `info libc "Name Service Switch"' for
information
> > about this file.
> >
> > passwd:         compat sss
> > group:          compat sss
> > shadow:         compat sss
>
> Why are you using sssd ?
> You do not seem to be using the DC as a fileserver.
>
I came from an openldap installation running on centOS.
This one was already using sssd and all my debian clients (infrastructure
about 50% windows; 50% debian) were set up to use sssd.
What is wrong with it? Until yesterday I never hat problems with it. I can
successfully authenticate most services (sudo; ssh; apache etc.) using
kerberos and sssd.

>
> >
> >        Checking file: /etc/samba/smb.conf
> >
> > ## FAI generated smb.conf
> > ## do not manually edit this file - changes might be overwritten
>
> OH yes, definitely manually edit this by removing the rubbish FAI added
> (what is FAI ?) :
>
>
:) - Think you miss interpreted.
FAI is Fully Automatic Installation tool (http://fai-project.org/ ) which I
use to administer my network configuration.
"manually edit" here means outside of the FAI administration tool
since if
I do this it will be overwritten again by FAI softupdate.
Changes have to be made in the FAI "version" of this file.

> [global]
>         realm = DOMAIN.DE
>         server role = active directory domain controller
>         server services = -dns
>         workgroup = DOMAIN
>         idmap_ldb:use rfc2307 = yes
>         ldap server require strong auth = no
>
> [netlogon]
>         read only = no
>         path = /var/lib/samba/sysvol/domain.de/Scripts
> [sysvol]
>         read only = no
>         path = /var/lib/samba/sysvol
>
> Rowland
>
>
You removed some stuff.
But as soon as I remove it some ldaps connections from other applications
do not further work.


-- 
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>

On Sat, 6 Apr 2019 17:21:26 +0200
Martin Krämer <mk.maddin at gmail.com> wrote:
> Hello Rowland,
> 
> thanks for your help.
> Below my comments
> > See here:
> >
> > http://apt.van-belle.nl/
> >  
> From stability point of view I always had the best experience by
> saying with the debian default repository.
> Additionally as you have seen blow I am using ssds (more on this
> later) "PACKAGES
> ARE NOT COMPATIBLE WITH SSSD"
Well, Louis builds them using exactly the same tools etc that Debian
uses, so they should be just as stable. As for sssd, see below.
> I know that article. - But how does it help here?
> Both <DC objectGUID>._msdcs.domain.de CNAMES already exist.
> An none of the both objectGUIDs I recieve from:  ldbsearch -H
> "/var/lib/samba/private/sam.ldb" '(invocationId=*)'
--cross-ncs
> objectguid does match to the uuid I recieve the error about.
> Should I (additionally to the objectGUIDs recieve from ldbsearch)
> register the error uuid "50abc2a4-574d-40b3-9d66-ee4fd5fba076" ?
> If yes, should I register a CNAME to location-000001(192.168.13.251)
> or location-000002(192.168.30.251) dc?
This is just a starting point and, if you don't have the required
records, you get a similar error. I would next try running
'samba_dnsupdate' and see what happens.

> 
> >  
> > >
> > >        Checking file: /etc/nsswitch.conf
> > >
> > > # /etc/nsswitch.conf
> > > #
> > > # Example configuration of GNU Name Service Switch functionality.
> > > # If you have the `glibc-doc-reference' and `info'
packages
> > > installed, try: # `info libc "Name Service Switch"'
for
> > > information about this file.
> > >
> > > passwd:         compat sss
> > > group:          compat sss
> > > shadow:         compat sss  
> >
> > Why are you using sssd ?
> > You do not seem to be using the DC as a fileserver.
> >  
> 
> I came from an openldap installation running on centOS.
> This one was already using sssd and all my debian clients
> (infrastructure about 50% windows; 50% debian) were set up to use
> sssd. What is wrong with it? 
There is nothing wrong with it, it just isn't supported by Samba (we
don't produce it) and in most cases isn't needed.
>Until yesterday I never hat problems
> with it. I can successfully authenticate most services (sudo; ssh;
> apache etc.) using kerberos and sssd.
They all work with winbind & kerberos, except for possibly sudo and
this mostly works with winbind unless you store the sudo rules in AD
and then you can use sudo-ldap
> >
> > >        Checking file: /etc/samba/smb.conf
> > >
> > > ## FAI generated smb.conf
> > > ## do not manually edit this file - changes might be overwritten
> >
> > OH yes, definitely manually edit this by removing the rubbish FAI
> > added (what is FAI ?) :
> >
> >  
> :) - Think you miss interpreted.
> FAI is Fully Automatic Installation tool (http://fai-project.org/ )
> which I use to administer my network configuration.
> "manually edit" here means outside of the FAI administration tool
> since if I do this it will be overwritten again by FAI softupdate.
> Changes have to be made in the FAI "version" of this file.
OK, I got it wrong, edit FAI instead

These lines are defaults:

	tls cafile = tls/ca.pem
	tls certfile = tls/cert.pem
	tls keyfile = tls/key.pem
	tls enabled = yes
	usershare allow guests = No
	client use spnego = yes

Not having them is the same as having them.

Normally only the secrets.tdb is used to verify kerberos tickets, this
will work 99.999% of the time, using:

 	kerberos method = secrets and keytab


means that the system keytab will be used as well, for most Samba AD
DC's, you do not need the above line.

Normally SMB signing is offered, but not enforced, but when this is set:

	client signing = yes

SMB signing is required. This is normally not required on a DC, but if
your clients need it, then put it back.

Rowland

Am Sa., 6. Apr. 2019 um 18:01 Uhr schrieb Rowland Penny via samba <
samba at lists.samba.org>:
> On Sat, 6 Apr 2019 17:21:26 +0200
> Martin Krämer <mk.maddin at gmail.com> wrote:
>
> > Hello Rowland,
> >
> > thanks for your help.
> > Below my comments
>
> > > See here:
> > >
> > > http://apt.van-belle.nl/
> > >
> > From stability point of view I always had the best experience by
> > saying with the debian default repository.
> > Additionally as you have seen blow I am using ssds (more on this
> > later) "PACKAGES
> > ARE NOT COMPATIBLE WITH SSSD"
>
> Well, Louis builds them using exactly the same tools etc that Debian
> uses, so they should be just as stable. As for sssd, see below.
>
hm... to be truth there were already multiple times I tough of having a
more up-to-date version would be greate...
Maybe I can try with my test servers first (I would start with
http://downloads.van-belle.nl/samba4/Upgrade-info.txt here I think )  - but
first I think have to check how to get rid of sssd ( I do not want to build
on my own)

>
> > I know that article. - But how does it help here?
> > Both <DC objectGUID>._msdcs.domain.de CNAMES already exist.
> > An none of the both objectGUIDs I recieve from:  ldbsearch -H
> > "/var/lib/samba/private/sam.ldb" '(invocationId=*)'
--cross-ncs
> > objectguid does match to the uuid I recieve the error about.
> > Should I (additionally to the objectGUIDs recieve from ldbsearch)
> > register the error uuid
"50abc2a4-574d-40b3-9d66-ee4fd5fba076" ?
> > If yes, should I register a CNAME to location-000001(192.168.13.251)
> > or location-000002(192.168.30.251) dc?
>
> This is just a starting point and, if you don't have the required
> records, you get a similar error. I would next try running
> 'samba_dnsupdate' and see what happens.
>
Thanks for this - I tried "samba_dnsupdate" in following ways.
All of them run through without any error telling me "No DNS updates
needed" at the end

samba_dnsupdate --verbose
samba_dnsupdate --verbose --rpc-server-ip=location-000001.domain.de
samba_dnsupdate --verbose --rpc-server-ip=location-000002.domain.de

afterwards unfortunately there is still no change to the error :/

> >
> > >
> > > >
> > > >        Checking file: /etc/nsswitch.conf
> > > >
> > > > # /etc/nsswitch.conf
> > > > #
> > > > # Example configuration of GNU Name Service Switch
functionality.
> > > > # If you have the `glibc-doc-reference' and `info'
packages
> > > > installed, try: # `info libc "Name Service
Switch"' for
> > > > information about this file.
> > > >
> > > > passwd:         compat sss
> > > > group:          compat sss
> > > > shadow:         compat sss
> > >
> > > Why are you using sssd ?
> > > You do not seem to be using the DC as a fileserver.
> > >
> >
> > I came from an openldap installation running on centOS.
> > This one was already using sssd and all my debian clients
> > (infrastructure about 50% windows; 50% debian) were set up to use
> > sssd. What is wrong with it?
>
> There is nothing wrong with it, it just isn't supported by Samba (we
> don't produce it) and in most cases isn't needed.
>
> >Until yesterday I never hat problems
> > with it. I can successfully authenticate most services (sudo; ssh;
> > apache etc.) using kerberos and sssd.
>
> They all work with winbind & kerberos, except for possibly sudo and
> this mostly works with winbind unless you store the sudo rules in AD
> and then you can use sudo-ldap
>
hm...this is how I currently use sssd & sudo:
https://linux.die.net/man/5/sssd-sudo
I think with sudo-ldap you refere to the following:
https://www.sudo.ws/man/1.8.17/sudoers.ldap.man.html ?
As of today my sudo rules are "linked" to the ou of the device and
based on
the  "ldap_sudo_search_base" config from sudo-sssd devices apply one
the
one matching for them.
(nearly the same way as group policy linking in windows works)
I think in case of switching I need to work with
"SUDOERS_SEARCH_FILTER" or
"SUDOERS_BASE" option... maybe I will check.

Louis once guided me to: https://github.com/thctlo/samba4/tree/master/howtos
Are these how-to compliant to what you mention about samba support &
winbind?

>
> > >
> > > >        Checking file: /etc/samba/smb.conf
> > > >
> > > > ## FAI generated smb.conf
> > > > ## do not manually edit this file - changes might be
overwritten
> > >
> > > OH yes, definitely manually edit this by removing the rubbish FAI
> > > added (what is FAI ?) :
> > >
> > >
> > :) - Think you miss interpreted.
> > FAI is Fully Automatic Installation tool (http://fai-project.org/ )
> > which I use to administer my network configuration.
> > "manually edit" here means outside of the FAI administration
tool
> > since if I do this it will be overwritten again by FAI softupdate.
> > Changes have to be made in the FAI "version" of this file.
>
> OK, I got it wrong, edit FAI instead
>
> These lines are defaults:
>
>         tls cafile = tls/ca.pem
>         tls certfile = tls/cert.pem
>         tls keyfile = tls/key.pem
>         tls enabled = yes
>         usershare allow guests = No
>         client use spnego = yes
>
> Not having them is the same as having them.
>
> Normally only the secrets.tdb is used to verify kerberos tickets, this
> will work 99.999% of the time, using:
>
>         kerberos method = secrets and keytab
>
>
> means that the system keytab will be used as well, for most Samba AD
> DC's, you do not need the above line.
>
> Normally SMB signing is offered, but not enforced, but when this is set:
>
>         client signing = yes
>
> SMB signing is required. This is normally not required on a DC, but if
> your clients need it, then put it back.
>
> Rowland
>
>
okay - could remove all options except the "client signing = yes".
Without this a very old window custom application does not further work. :/
Unfortunately still no change to my error :(

> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>