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

Sat Apr 6 15:21:26 UTC 2019

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
>