[Samba] samba-tool drs showrepl shows WERR_BAD_NETPATH

Thu Aug 25 10:15:09 UTC 2016

2016-08-24 12:30 GMT+02:00 Heinz Allerberger via samba <
samba at lists.samba.org>:

> Am 23.08.2016 um 15:36 wrote Heinz Allerberger via samba:
>
>> Hello there,
>>
>> I have a problem with replication between two domain controllers, dc1 and
>> dc2.
>> Distribution: Debian 8.5
>> Samba-Distribution: sernet-samba 4.3.11-14
>>
>> The replication on dc2 working fine without any failures.
>> But the synchronization on dc1 gives the failure "WERR_BAD_NETPATH".
>>
>> Because the message "BAD_NETPATH" I checked the DNS-resolution:
>> ==========================================
>> root at dc1:~#host dc1
>> dc1.mydomain.uni-frankfurt.de has address 192.168.151.230
>>
>> root at dc1:~# host dc2
>> dc2.mydomain.uni-frankfurt.de has address 192.168.151.231
>>
>> host -t SRV _kerberos._tcp.mydomain.uni-frankfurt.de
>> _kerberos._tcp.mydomain.uni-frankfurt.de has SRV record 0 100 88
>> dc1.mydomain.uni-frankfurt.de.
>> _kerberos._tcp.mydomain.uni-frankfurt.de has SRV record 0 100 88
>> dc2.mydomain.uni-frankfurt.de.
>>
>> root at dc1:~# host -t SRV _ldap._tcp.mydomain.uni-frankfurt.de
>> _ldap._tcp.mydomain.uni-frankfurt.de has SRV record 0 100 389
>> dc1.mydomain.uni-frankfurt.de.
>> _ldap._tcp.mydomain.uni-frankfurt.de has SRV record 0 100 389
>> dc2.mydomain.uni-frankfurt.de.
>>
>>
>> OUTBOUND-replication on dc1 show me any failures:
>> ================================
>> root at dc1:~# samba-tool drs showrepl
>> Default-First-Site-Name\DC1
>> DSA Options: 0x00000001
>> DSA object GUID: 1ae9c878-4d33-417a-9995-061189db4f8d
>> DSA invocationId: dff09274-9c24-49c6-beb5-647561d5d893
>>
>> ==== INBOUND NEIGHBORS ====
>>
>> DC=ForestDnsZones,DC=mydomain,DC=uni-frankfurt,DC=de
>>         Default-First-Site-Name\dc2 via RPC
>>                 DSA object GUID: e4da82c7-5d42-4011-8733-00a9dffb6633
>>                 Last attempt @ Mon Aug 22 16:19:25 2016 CEST was
>> successful
>>                 0 consecutive failure(s).
>>                 Last success @ Mon Aug 22 16:19:25 2016 CEST
>> ....
>>
>> ==== OUTBOUND NEIGHBORS ====
>>
>> DC=ForestDnsZones,DC=mydomain,DC=uni-frankfurt,DC=de
>>         Default-First-Site-Name\dc2 via RPC
>>                 DSA object GUID: e4da82c7-5d42-4011-8733-00a9dffb6633
>>                 Last attempt @ Mon Aug 22 16:20:14 2016 CEST failed,
>> result 53 (WERR_BAD_NETPATH)
>>                 37 consecutive failure(s).
>>                 Last success @ NTTIME(0)
>>
>> DC=DomainDnsZones,DC=mydomain,DC=uni-frankfurt,DC=de
>>         Default-First-Site-Name\dc2 via RPC
>>                 DSA object GUID: e4da82c7-5d42-4011-8733-00a9dffb6633
>>                 Last attempt @ Mon Aug 22 16:20:14 2016 CEST failed,
>> result 53 (WERR_BAD_NETPATH)
>>                 37 consecutive failure(s).
>>                 Last success @ NTTIME(0)
>>
>> DC=mydomain,DC=uni-frankfurt,DC=de
>>         Default-First-Site-Name\dc2 via RPC
>>                 DSA object GUID: e4da82c7-5d42-4011-8733-00a9dffb6633
>>                 Last attempt @ Mon Aug 22 16:20:14 2016 CEST failed,
>> result 53 (WERR_BAD_NETPATH)
>>                 37 consecutive failure(s).
>>                 Last success @ NTTIME(0)
>>
>> CN=Schema,CN=Configuration,DC=mydomain,DC=uni-frankfurt,DC=de
>>         Default-First-Site-Name\dc2 via RPC
>>                 DSA object GUID: e4da82c7-5d42-4011-8733-00a9dffb6633
>>                 Last attempt @ Mon Aug 22 16:20:14 2016 CEST failed,
>> result 53 (WERR_BAD_NETPATH)
>>                 37 consecutive failure(s).
>>                 Last success @ NTTIME(0)
>>
>> CN=Configuration,DC=mydomain,DC=uni-frankfurt,DC=de
>>         Default-First-Site-Name\dc2 via RPC
>>                 DSA object GUID: e4da82c7-5d42-4011-8733-00a9dffb6633
>>                 Last attempt @ Mon Aug 22 16:20:14 2016 CEST failed,
>> result 53 (WERR_BAD_NETPATH)
>>                 37 consecutive failure(s).
>>                 Last success @ NTTIME(0)
>>
>> ==== KCC CONNECTION OBJECTS ====
>>
>> Connection --
>>         Connection name: 1367f590-6672-4807-bc27-2ac167d40a88
>>         Enabled        : TRUE
>>         Server DNS name : dc2.mydomain.uni-frankfurt.de
>>         Server DN name  : CN=NTDS Settings,CN=dc2,CN=Servers,CN=
>> Default-First-Site-Name,CN=Sites,CN=Configuration,DC=mydomai
>> n,DC=uni-frankfurt,DC=de
>>                 TransportType: RPC
>>                 options: 0x00000001
>> Warning: No NC replicated for Connection!
>>
>> Best regards
>> Heinz
>>
>>
> Solved!
> For all who have a similar problem with replication:
> ================================
> I had a look to the /var/log/samba/log.samba on both servers, dc1 and dc2
> and I found out,
> that the DNS update failed on server dc2 sins a time where the dc1 really
> was not alive.
> This would be normal.
>
> The failure is that DNS update has not working forward again, when the dc1
> was back into the network
> and was alive again.
> This my be a debility in Samba and the developer could have a look about
> this...
>
> I could fixed it, with a reboot from dc2. Now it is working!
>

Samba ships a tool named "samba_dnsupdate" which is responsible to push
that kind of DNS updates to create needed (by local DC) DNS entries.
This script is run at samba start up, at samba installation too and can be
launched manually.

According to what you wrote I expect there was some issue when joining that
second DC which made DNS entries to not being created but I can completely
wrong as others reasons can father such issue (renaming that second DC for
example).

Anyway as you mentioned a simple restart of Samba could solve that issue.

More: if your DCs are using themselves as DNS resolver and they are using
Bind+DLZ as DNS back end, these DNS entries will be created even there is
only one DC up. This because resolver is localhost so samba_dnsupdate will
send DNS request locally to know which DC is SOA (SOA is "where to write
updates") and as Bind+DLZ knows it is multi-master, every Bind+DLZ will
reply to such request "I am SOA". In other words samba_dnsupdate will use
local DNS service to update local LDAP DB, no need of a second DC to be up.

I'm not really sure that modifying Samba's code to make Samba DC to launch
that samba_dnsupdate tool periodically is really needed as changes on DNS
related to DC should not happen too often and because checking DNS entries
related to a newly added DC should really be part of the tests done by
admins after installing a new DC as AD is relying on DNS so much...
Then once they spot some issue, if they are lucky they would resolve that
issue in only one command which should not be too much, in my own opinion ;)

>
> dc2 in /var/log/samba/log.samba:
> =====================
> .....dns update failed
> [2016/08/19 14:47:31.646907,  0] ../source4/dsdb/dns/dns_update
> .c:294(dnsupdate_nameupdate_done)
>   ../source4/dsdb/dns/dns_update.c:294: Failed DNS update -
> NT_STATUS_IO_TIMEOUT
> [2016/08/19 14:48:59.829660,  0] ../source4/smbd/server.c:121(sig_term)
>   Exiting pid 24381 on SIGTERM
> [2016/08/19 14:50:59.870435,  0] ../source4/smbd/server.c:121(sig_term)
>   Exiting pid 24417 on SIGTERM
> [2016/08/19 14:52:59.898571,  0] ../source4/smbd/server.c:121(sig_term)
>   Exiting pid 24434 on SIGTERM
> [2016/08/19 14:56:16.929109,  0] ../source4/rpc_server/common/f
> orward.c:51(dcesrv_irpc_forward_callback)
>   IRPC callback failed for DsReplicaSync - NT_STATUS_OBJECT_NAME_NOT_FOUND
> [2016/08/19 14:56:16.947998,  0] ../source4/rpc_server/common/f
> orward.c:51(dcesrv_irpc_forward_callback)
>   IRPC callback failed for DsReplicaSync - NT_STATUS_OBJECT_NAME_NOT_FOUND
>
> ....... the server dc1 was back since 4 minutes
> [2016/08/19 15:00:22.673835,  0] ../source4/rpc_server/common/f
> orward.c:51(dcesrv_irpc_forward_callback)
>   IRPC callback failed for DsReplicaSync - NT_STATUS_OBJECT_NAME_NOT_FOUND
> [2016/08/19 15:00:22.687150,  0] ../source4/rpc_server/common/f
> orward.c:51(dcesrv_irpc_forward_callback)
>   IRPC callback failed for DsReplicaSync - NT_STATUS_OBJECT_NAME_NOT_FOUND
>
> .......but dns update failed and failed and runs in a loop until yesterday
> [2016/08/23 16:58:45.284777,  0] ../source4/rpc_server/common/f
> orward.c:51(dcesrv_irpc_forward_callback)
>   IRPC callback failed for DsReplicaSync - NT_STATUS_OBJECT_NAME_NOT_FOUND
> [2016/08/23 16:58:45.292703,  0] ../source4/rpc_server/common/f
> orward.c:51(dcesrv_irpc_forward_callback)
>
> .......reboot
> [2016/08/23 16:58:49.791606,  0] ../source4/smbd/server.c:116(sig_term)
>   SIGTERM: killing children
> [2016/08/23 16:59:00.794333,  0] ../source4/smbd/server.c:372(b
> inary_smbd_main)
>   samba version 4.3.11-SerNet-Debian-14.jessie started.
>   Copyright Andrew Tridgell and the Samba Team 1992-2015
> [2016/08/23 16:59:01.538600,  0] ../source4/smbd/server.c:490(b
> inary_smbd_main)
>   samba: using 'standard' process model
> [2016/08/23 16:59:01.563627,  0] ../lib/util/become_daemon.c:12
> 4(daemon_ready)
>   STATUS=daemon 'samba' finished starting up and ready to serve connections
> ....NOW IT RUNS AND NO FAILURE SINCE THE REBOOT
>
>
> Here you can see when the dc1 was down...
> dc1 /var/log/samba/log.samba:
> ====================
> ...it shutded down
> [2016/08/19 14:41:44.792623,  0] ../source4/smbd/server.c:121(sig_term)
>   Exiting pid 817 on SIGTERM
>
> it started up
> [2016/08/19 14:56:09.521374,  0] ../source4/smbd/server.c:372(b
> inary_smbd_main)
>   samba version 4.3.11-SerNet-Debian-14.jessie started.
>   Copyright Andrew Tridgell and the Samba Team 1992-2015
> [2016/08/19 14:56:10.425955,  0] ../source4/smbd/server.c:490(b
> inary_smbd_main)
>   samba: using 'standard' process model
> [2016/08/19 14:56:10.746602,  0] ../lib/util/become_daemon.c:12
> 4(daemon_ready)
>   STATUS=daemon 'samba' finished starting up and ready to serve connections
>
> I hope I can help other Samba-Users with this information.
>
> Heinz
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>