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
[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
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