[Samba] DsReplicaSync failed - WERR_LOGON_FAILURE // Failed to bind to uuid for ncacn_ip_tcp - NT_STATUS_LOGON_FAILURE

[Rowland Penny]

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