thr3ads.net - samba - [Samba] Samba 4.2.14 Group Policy (GPO) sync error [Aug 2016]

If this information is useful, please help other people find it:
Share via:

rme at bluemail.ch

2016-Aug-04 13:00 UTC

[Samba] Samba 4.2.14 Group Policy (GPO) sync error

Perhaps I am on the wrong track but I would like to share some 
additional observations...

I quickly enabled DNS query logging:
     # rndc querylog


Then run another gpupdate on the client.

During the Update I see lots of queries:

04-Aug-2016 14:46:58.414 queries: info: client 10.0.1.186#59270 
(_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.ad.cyberdyne.local): 
view internal: query: 
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.ad.cyberdyne.local 
IN SRV + (10.0.1.6)
04-Aug-2016 14:46:59.223 queries: info: client 10.0.1.186#50476 
(_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.ad.cyberdyne.local): 
view internal: query: 
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.ad.cyberdyne.local 
IN SRV + (10.0.1.6)
04-Aug-2016 14:46:59.428 queries: info: client 10.0.1.186#58473 
(_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.ad.cyberdyne.local): 
view internal: query: 
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.ad.cyberdyne.local 
IN SRV + (10.0.1.6)
... [message repeated 16 times in total]

or with IPv6 enabled:
04-Aug-2016 14:57:42.217 queries: info: client 
fdea:5b48:d4c1:1:68f2:fa7c:db26:ce22#53050 
(_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.ad.cyberdyne.local): 
view internal: query: 
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.ad.cyberdyne.local 
IN SRV + (fdea:5b48:d4c1:1:1::6)
04-Aug-2016 14:57:42.401 queries: info: client 
fdea:5b48:d4c1:1:68f2:fa7c:db26:ce22#63158 
(_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.ad.cyberdyne.local): 
view internal: query: 
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.ad.cyberdyne.local 
IN SRV + (fdea:5b48:d4c1:1:1::6)
04-Aug-2016 14:57:42.711 queries: info: client 
fdea:5b48:d4c1:1:68f2:fa7c:db26:ce22#64202 
(_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.ad.cyberdyne.local): 
view internal: query: 
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.ad.cyberdyne.local 
IN SRV + (fdea:5b48:d4c1:1:1::6)
... [message repeated 16 times in total]


I did query this from the client:

C:\Temp>nslookup -type=SRV 
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.ad.cyberdyne.local
Server:  skynet.ad.cyberdyne.local
Address:  fdea:5b48:d4c1:1:1::6

_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.ad.cyberdyne.local 
SRV service location:
           priority       = 0
           weight         = 100
           port           = 389
           svr hostname   = skynet.ad.cyberdyne.local
_msdcs.ad.cyberdyne.local       nameserver = skynet.ad.cyberdyne.local
skynet.ad.cyberdyne.local       internet address = 10.0.0.6
skynet.ad.cyberdyne.local       internet address = 10.0.2.6
skynet.ad.cyberdyne.local       internet address = 10.0.1.6
skynet.ad.cyberdyne.local       AAAA IPv6 address = fdea:5b48:d4c1:1:1::6
skynet.ad.cyberdyne.local       AAAA IPv6 address = 2a02:120b:2c38:2950::1
skynet.ad.cyberdyne.local       AAAA IPv6 address = 2a02:120b:2c38:2951::1


And from the server:

# dig -t SRV 
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.ad.cyberdyne.local

; <<>> DiG 9.10.3-P4 <<>> -t SRV 
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.ad.cyberdyne.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33143
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 7

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.ad.cyberdyne.local. 
        IN SRV

;; ANSWER SECTION:
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.ad.cyberdyne.local. 
900 IN SRV 0 100 389 skynet.ad.cyberdyne.local.

;; AUTHORITY SECTION:
_msdcs.ad.cyberdyne.local. 900  IN      NS      skynet.ad.cyberdyne.local.

;; ADDITIONAL SECTION:
skynet.ad.cyberdyne.local. 900  IN      A       10.0.1.6
skynet.ad.cyberdyne.local. 900  IN      A       10.0.0.6
skynet.ad.cyberdyne.local. 900  IN      A       10.0.2.6
skynet.ad.cyberdyne.local. 900  IN      AAAA    fdea:5b48:d4c1:1:1::6
skynet.ad.cyberdyne.local. 900  IN      AAAA    2a02:120b:2c38:2950::1
skynet.ad.cyberdyne.local. 900  IN      AAAA    2a02:120b:2c38:2951::1

;; Query time: 12 msec
;; SERVER: fdea:5b48:d4c1:1:1::6#53(fdea:5b48:d4c1:1:1::6)
;; WHEN: Thu Aug 04 14:53:22 CEST 2016
;; MSG SIZE  rcvd: 290



In fact to me it looks like all the adresses returned are valid.
I am not sure why gpupdate issues 16 queries on this

best regards,
Rainer

rme at bluemail.ch

2016-Aug-04 15:51 UTC

head link

[Samba] Samba 4.2.14 Group Policy (GPO) sync error

Even some more observations.

I noticed when I join my machine to AD it prompts a second time for the 
credentials. It does not matter what I enter or even cancel the dialog 
it will always display an error:

Changing the Primary Domain DNS name of this computer to "" failed.
The name will remain "ad.cyberdyne.local".

Well, actualy this is what I want anyway. I found this Microsoft article 
about:
<https://support.microsoft.com/en-us/kb/2018583>
But also forcing NetBIOS over TCP did not help. I have the follwowing in 
my dhcpd.conf anyway:
     option netbios-name-servers 10.0.1.6;
     option netbios-node-type 8;


In any case this should not harm as far as I understood.


But I went a bit more into DNS topics and came across a potential issue 
or at least nuisance.
I am currently using BIND and it manages the zone cyberdyne.local. Where 
I also manage a reverse-DNS zone (zone 
"1.0.0.0.1.c.4.d.8.4.b.5.a.e.d.f.ip6.arpa" in). This zone is managing 
PTR entries for my local LAN eqipment with fixed IP addresses.

It looks like when a machine is domain-joined the clients try to update 
those records and I see the following in my BIND logs (starts after 
domain join):

04-Aug-2016 17:09:52.381 update-security: error: client 
fdea:5b48:d4c1:1:2839:ba1e:ac57:aa6#56593: view internal: update 
'1.0.0.0.1.c.4.d.8.4.b.5.a.e.d.f.ip6.arpa/IN' denied
04-Aug-2016 17:09:52.382 update: info: client 
fdea:5b48:d4c1:1:2839:ba1e:ac57:aa6#54604/key 
cyb64w10-monste\$\@AD.CYBERDYNE.LOCAL: view internal: updating zone 
'1.0.0.0.1.c.4.d.8.4.b.5.a.e.d.f.ip6.arpa/IN': update failed: rejected 
by secure update (REFUSED)


I am in question to myself how to resolve this.
One possibility might be to remove the reverse DNS zone and let 
Samba_DLZ manage it. This might work but does not allow me to manage the 
PTR records for my static LAN equipment in BIND.

A second possibility might be to allow secure updates. Though I haven't 
been able to find some working guide how to allow kerberos-authenticated 
secure updates. Somewhere I found to use something like

     update-policy {
          grant AD.CYBERDYNE.LOCAL krb5-self * PTR;
     };

in my zone definition. However it didn't work as expected.
I also found this: 
<http://blog.michael.kuron-germany.de/2011/02/isc-dhcpd-dynamic-dns-updates-against-secure-microsoft-dns/>
However I didn't go through the complete instruction. As of my 
understanding it will forward the verification of the request to an 
external script.
Well, I think it's far too complex and kerberos authentication should be 
possible with BIND directly.


As a last option I temporary inserted this into my BIND zone configuration:
     allow-update { any; };

Of course this is risky as it actually allows any client to manipulate 
the PTR entries and it's not meant to be used in production.
The intention was to verify whether those failed DNS updates might have 
an impact on the GPO update issue.

It turned out they don't. I am now able to forward-and-reverse lookup 
the client address:

C:\Temp>nslookup CYB64W10-HPNB.ad.cyberdyne.local
Server:  skynet.ad.cyberdyne.local
Address:  fdea:5b48:d4c1:1:1::6

Name:    CYB64W10-HPNB.ad.cyberdyne.local
Addresses:  fdea:5b48:d4c1:1:1::102
           fdea:5b48:d4c1:1:ec71:fc72:a95b:3d12
           10.0.1.186


C:\Temp>nslookup fdea:5b48:d4c1:1:1::102
Server:  skynet.ad.cyberdyne.local
Address:  fdea:5b48:d4c1:1:1::6

Name:    CYB64W10-HPNB.ad.cyberdyne.local
Address:  fdea:5b48:d4c1:1:1::102


C:\Temp>nslookup fdea:5b48:d4c1:1:ec71:fc72:a95b:3d12
Server:  skynet.ad.cyberdyne.local
Address:  fdea:5b48:d4c1:1:1::6

Name:    CYB64W10-HPNB.ad.cyberdyne.local
Address:  fdea:5b48:d4c1:1:ec71:fc72:a95b:3d12


C:\Temp>nslookup 10.0.1.186
Server:  skynet.ad.cyberdyne.local
Address:  fdea:5b48:d4c1:1:1::6

Name:    CYB64W10-HPNB.ad.cyberdyne.local
Address:  10.0.1.186


Of coruse all of this did not have any effect on the GPO issue. It still 
fails to sync.





In all cases it looks like Windows clients start two transactions all 
the time. The first one is cancelled while the second one succeeds. This 
might be a samba_dlz issue though:

04-Aug-2016 17:37:15.642 database: info: samba_dlz: starting transaction 
on zone ad.cyberdyne.local
04-Aug-2016 17:37:15.644 update-security: error: client 
fdea:5b48:d4c1:1:bdaa:87cf:35dc:3a27#51511: view internal: update 
'ad.cyberdyne.local/IN' denied
04-Aug-2016 17:37:15.644 database: info: samba_dlz: cancelling 
transaction on zone ad.cyberdyne.local
04-Aug-2016 17:37:15.670 database: info: samba_dlz: starting transaction 
on zone ad.cyberdyne.local
04-Aug-2016 17:37:15.675 database: info: samba_dlz: allowing update of 
signer=cyb64w10-hpnb\$\@AD.CYBERDYNE.LOCAL 
name=CYB64W10-HPNB.ad.cyberdyne.local tcpaddr= type=AAAA 
key=764-ms-7.2-45281.b1a8208e-5a58-11e6-3496-0013e8e7cd41/160/0
04-Aug-2016 17:37:15.678 database: info: samba_dlz: allowing update of 
signer=cyb64w10-hpnb\$\@AD.CYBERDYNE.LOCAL 
name=CYB64W10-HPNB.ad.cyberdyne.local tcpaddr= type=A 
key=764-ms-7.2-45281.b1a8208e-5a58-11e6-3496-0013e8e7cd41/160/0
04-Aug-2016 17:37:15.681 database: info: samba_dlz: allowing update of 
signer=cyb64w10-hpnb\$\@AD.CYBERDYNE.LOCAL 
name=CYB64W10-HPNB.ad.cyberdyne.local tcpaddr= type=AAAA 
key=764-ms-7.2-45281.b1a8208e-5a58-11e6-3496-0013e8e7cd41/160/0
04-Aug-2016 17:37:15.685 database: info: samba_dlz: allowing update of 
signer=cyb64w10-hpnb\$\@AD.CYBERDYNE.LOCAL 
name=CYB64W10-HPNB.ad.cyberdyne.local tcpaddr= type=AAAA 
key=764-ms-7.2-45281.b1a8208e-5a58-11e6-3496-0013e8e7cd41/160/0
04-Aug-2016 17:37:15.688 database: info: samba_dlz: allowing update of 
signer=cyb64w10-hpnb\$\@AD.CYBERDYNE.LOCAL 
name=CYB64W10-HPNB.ad.cyberdyne.local tcpaddr= type=A 
key=764-ms-7.2-45281.b1a8208e-5a58-11e6-3496-0013e8e7cd41/160/0
04-Aug-2016 17:37:15.688 update: info: client 
fdea:5b48:d4c1:1:bdaa:87cf:35dc:3a27#64311/key 
cyb64w10-hpnb\$\@AD.CYBERDYNE.LOCAL: view internal: updating zone 
'ad.cyberdyne.local/NONE': deleting rrset at 
'CYB64W10-HPNB.ad.cyberdyne.local' AAAA
04-Aug-2016 17:37:15.689 update: info: client 
fdea:5b48:d4c1:1:bdaa:87cf:35dc:3a27#64311/key 
cyb64w10-hpnb\$\@AD.CYBERDYNE.LOCAL: view internal: updating zone 
'ad.cyberdyne.local/NONE': deleting rrset at 
'CYB64W10-HPNB.ad.cyberdyne.local' A
04-Aug-2016 17:37:15.699 database: info: samba_dlz: subtracted rdataset 
CYB64W10-HPNB.ad.cyberdyne.local 'CYB64W10-HPNB.ad.cyberdyne.local. 
1200    IN      A       10.0.1.186'
04-Aug-2016 17:37:15.701 update: info: client 
fdea:5b48:d4c1:1:bdaa:87cf:35dc:3a27#64311/key 
cyb64w10-hpnb\$\@AD.CYBERDYNE.LOCAL: view internal: updating zone 
'ad.cyberdyne.local/NONE': adding an RR at 
'CYB64W10-HPNB.ad.cyberdyne.local' AAAA 
2a02:120b:2c38:2951:ec71:fc72:a95b:3d12
04-Aug-2016 17:37:15.704 database: info: samba_dlz: added rdataset 
CYB64W10-HPNB.ad.cyberdyne.local 'CYB64W10-HPNB.ad.cyberdyne.local. 
1200    IN      AAAA    2a02:120b:2c38:2951:ec71:fc72:a95b:3d12'
04-Aug-2016 17:37:15.704 update: info: client 
fdea:5b48:d4c1:1:bdaa:87cf:35dc:3a27#64311/key 
cyb64w10-hpnb\$\@AD.CYBERDYNE.LOCAL: view internal: updating zone 
'ad.cyberdyne.local/NONE': adding an RR at 
'CYB64W10-HPNB.ad.cyberdyne.local' AAAA
fdea:5b48:d4c1:1:ec71:fc72:a95b:3d12
04-Aug-2016 17:37:15.707 database: info: samba_dlz: added rdataset 
CYB64W10-HPNB.ad.cyberdyne.local 'CYB64W10-HPNB.ad.cyberdyne.local. 
1200    IN      AAAA    fdea:5b48:d4c1:1:ec71:fc72:a95b:3d12'
04-Aug-2016 17:37:15.708 update: info: client 
fdea:5b48:d4c1:1:bdaa:87cf:35dc:3a27#64311/key 
cyb64w10-hpnb\$\@AD.CYBERDYNE.LOCAL: view internal: updating zone 
'ad.cyberdyne.local/NONE': adding an RR at 
'CYB64W10-HPNB.ad.cyberdyne.local' A 10.0.1.186
04-Aug-2016 17:37:15.711 database: info: samba_dlz: added rdataset 
CYB64W10-HPNB.ad.cyberdyne.local 'CYB64W10-HPNB.ad.cyberdyne.local. 
1200    IN      A       10.0.1.186'
04-Aug-2016 17:37:15.715 database: info: samba_dlz: subtracted rdataset 
ad.cyberdyne.local 'ad.cyberdyne.local. 3600    IN      SOA 
skynet.ad.cyberdyne.local. hostmaster.ad.cyberdyne.local. 690 900 600 
86400 3600'
04-Aug-2016 17:37:15.717 database: info: samba_dlz: added rdataset 
ad.cyberdyne.local 'ad.cyberdyne.local.      3600    IN      SOA 
skynet.ad.cyberdyne.local. hostmaster.ad.cyberdyne.local. 691 900 600 
86400 3600'
04-Aug-2016 17:37:15.728 database: info: samba_dlz: committed 
transaction on zone ad.cyberdyne.local

Rowland Penny

2016-Aug-04 16:10 UTC

head link

[Samba] Samba 4.2.14 Group Policy (GPO) sync error

On Thu, 4 Aug 2016 17:51:09 +0200
rme at bluemail.ch wrote:
> Even some more observations.
> 
> I noticed when I join my machine to AD it prompts a second time for
> the credentials. It does not matter what I enter or even cancel the
> dialog it will always display an error:
> 
> Changing the Primary Domain DNS name of this computer to ""
failed.
> The name will remain "ad.cyberdyne.local".
> 
> Well, actualy this is what I want anyway. I found this Microsoft
> article about:
> <https://support.microsoft.com/en-us/kb/2018583>
> But also forcing NetBIOS over TCP did not help. I have the follwowing
> in my dhcpd.conf anyway:
>      option netbios-name-servers 10.0.1.6;
>      option netbios-node-type 8;
> 
> 
> In any case this should not harm as far as I understood.
> 
> 
> But I went a bit more into DNS topics and came across a potential
> issue or at least nuisance.
> I am currently using BIND and it manages the zone cyberdyne.local.
> Where I also manage a reverse-DNS zone (zone 
> "1.0.0.0.1.c.4.d.8.4.b.5.a.e.d.f.ip6.arpa" in). This zone is
managing
> PTR entries for my local LAN eqipment with fixed IP addresses.
> 
> It looks like when a machine is domain-joined the clients try to
> update those records and I see the following in my BIND logs (starts
> after domain join):
> 
> 04-Aug-2016 17:09:52.381 update-security: error: client 
> fdea:5b48:d4c1:1:2839:ba1e:ac57:aa6#56593: view internal: update 
> '1.0.0.0.1.c.4.d.8.4.b.5.a.e.d.f.ip6.arpa/IN' denied
> 04-Aug-2016 17:09:52.382 update: info: client 
> fdea:5b48:d4c1:1:2839:ba1e:ac57:aa6#54604/key 
> cyb64w10-monste\$\@AD.CYBERDYNE.LOCAL: view internal: updating zone 
> '1.0.0.0.1.c.4.d.8.4.b.5.a.e.d.f.ip6.arpa/IN': update failed:
> rejected by secure update (REFUSED)
> 
> 
> I am in question to myself how to resolve this.
> One possibility might be to remove the reverse DNS zone and let 
> Samba_DLZ manage it. This might work but does not allow me to manage
> the PTR records for my static LAN equipment in BIND.
> 
> A second possibility might be to allow secure updates. Though I
> haven't been able to find some working guide how to allow
> kerberos-authenticated secure updates. Somewhere I found to use
> something like
> 
>      update-policy {
>           grant AD.CYBERDYNE.LOCAL krb5-self * PTR;
>      };
> 
> in my zone definition. However it didn't work as expected.
> I also found this: 
>
<http://blog.michael.kuron-germany.de/2011/02/isc-dhcpd-dynamic-dns-updates-against-secure-microsoft-dns/>
> However I didn't go through the complete instruction. As of my 
> understanding it will forward the verification of the request to an 
> external script.
> Well, I think it's far too complex and kerberos authentication should
> be possible with BIND directly.
> 
> 
No its not, its fairly easy, once you get your head around it. I have
been using something based on that webpage for nearly 4 years now and
 only had self inflicted problems.

Rowland

Possibly Parallel Threads

Search for more apparently analagous threads

samba - Aug 2016 - Samba 4.2.14 Group Policy (GPO) sync error

[Samba] Samba 4.2.14 Group Policy (GPO) sync error

[Samba] Samba 4.2.14 Group Policy (GPO) sync error

[Samba] Samba 4.2.14 Group Policy (GPO) sync error

Possibly Parallel Threads