Am 09.08.2016 um 22:18 schrieb Achim Gottinger via samba:> > > Am 09.08.2016 um 21:48 schrieb Rainer Meier via samba: >>> I think the 10.0.06 entry was created during domain creation. I'd skim >>> thru dns records from an windows machine if possible and delete all >>> occurences of unwanted ip adresses. I assume the gpo's still can not be >>> loaded during logon on the client? Did you inspect gpresult /h >>> result.html? >> >> I did remove the record for 10.0.0.6 now. Currently I only have >> 10.0.1.6 in the DNS and Samba listening only on 10.0.1.6. Though it >> still fails to sync with exactly the same error. > You may find other left over records in > DnsDomainZones/ForestDnsZones/GC.msdcs. On my test system where i > create eth0:0 interfaces with different ip's on a regular basis i > found alot of leftovers (seems they do not cause problems here). >> >> gpresult /h result.html does not do anything as GPO has never been >> synced. It seems to provide results only if the sync at least >> completed once. >> > You can run tshark on your server and the traffic during the client > tries to update gpo's. May shed a light. > > [Sorry for the double post to your private email] >I ran an tshark log here because i got curious and in case you want to compare.
rme at bluemail.ch
2016-Aug-09 21:50 UTC
[Samba] Samba 4.2.14 Group Policy (GPO) sync error
> You may find other left over records in > DnsDomainZones/ForestDnsZones/GC.msdcs. On my test system where i create > eth0:0 interfaces with different ip's on a regular basis i found alot of > leftovers (seems they do not cause problems here).I couldn't actually spot something strange. I also watched the query log during gpupdate and didn't find anything special there. On a Windows 7 Pro VM I installed (note, it's in the untrusted 10.0.2.0/24 network) I see the following BIND logs on connect: 09-Aug-2016 23:18:24.585 database: info: samba_dlz: committed transaction on zone ad.cyberdyne.local 09-Aug-2016 23:18:24.654 database: info: samba_dlz: starting transaction on zone ad.cyberdyne.local 09-Aug-2016 23:18:24.655 update-security: error: client 10.0.2.95#57343: view internal: update 'ad.cyberdyne.local/IN' denied 09-Aug-2016 23:18:24.655 database: info: samba_dlz: cancelling transaction on zone ad.cyberdyne.local 09-Aug-2016 23:18:24.656 database: info: samba_dlz: starting transaction on zone ad.cyberdyne.local 09-Aug-2016 23:18:24.658 database: info: samba_dlz: allowing update of signer=cyb64w7-test\$\@AD.CYBERDYNE.LOCAL name=CYB64W7-TEST.ad.cyberdyne.local tcpaddr= type=AAAA key=316-ms-7.3-7c5a71.894664bf-5e64-11e6-3d8b-080027eead7d/160/0 09-Aug-2016 23:18:24.660 database: info: samba_dlz: allowing update of signer=cyb64w7-test\$\@AD.CYBERDYNE.LOCAL name=CYB64W7-TEST.ad.cyberdyne.local tcpaddr= type=A key=316-ms-7.3-7c5a71.894664bf-5e64-11e6-3d8b-080027eead7d/160/0 09-Aug-2016 23:18:24.662 database: info: samba_dlz: allowing update of signer=cyb64w7-test\$\@AD.CYBERDYNE.LOCAL name=CYB64W7-TEST.ad.cyberdyne.local tcpaddr= type=A key=316-ms-7.3-7c5a71.894664bf-5e64-11e6-3d8b-080027eead7d/160/0 09-Aug-2016 23:18:24.662 update: info: client 10.0.2.95#63502/key cyb64w7-test\$\@AD.CYBERDYNE.LOCAL: view internal: updating zone 'ad.cyberdyne.local/NONE': deleting rrset at 'CYB64W7-TEST.ad.cyberdyne.local' AAAA 09-Aug-2016 23:18:24.662 update: info: client 10.0.2.95#63502/key cyb64w7-test\$\@AD.CYBERDYNE.LOCAL: view internal: updating zone 'ad.cyberdyne.local/NONE': deleting rrset at 'CYB64W7-TEST.ad.cyberdyne.local' A 09-Aug-2016 23:18:24.664 database: info: samba_dlz: subtracted rdataset CYB64W7-TEST.ad.cyberdyne.local 'CYB64W7-TEST.ad.cyberdyne.local. 1200 IN A 10.0.2.95' 09-Aug-2016 23:18:24.665 update: info: client 10.0.2.95#63502/key cyb64w7-test\$\@AD.CYBERDYNE.LOCAL: view internal: updating zone 'ad.cyberdyne.local/NONE': adding an RR at 'CYB64W7-TEST.ad.cyberdyne.local' A 10.0.2.95 09-Aug-2016 23:18:24.668 database: info: samba_dlz: added rdataset CYB64W7-TEST.ad.cyberdyne.local 'CYB64W7-TEST.ad.cyberdyne.local. 1200 IN A10.0.2.95' 09-Aug-2016 23:18:24.677 database: info: samba_dlz: committed transaction on zone ad.cyberdyne.local Expect the line about update-security (line 3) it looks like the records get updated properly. I am also able to forward- and reverse-lookup the node. I just did a complete Wireshark dump of a gpupdate process on my Windows 10 machine too. You can find it here: <https://dl.dropboxusercontent.com/u/2015365/gpupdate.pcapng> I also did an ipconfig /flushdns just before the capture. Thank you Rainer
Am 09.08.2016 um 23:50 schrieb Rainer Meier via samba:>> You may find other left over records in >> DnsDomainZones/ForestDnsZones/GC.msdcs. On my test system where i create >> eth0:0 interfaces with different ip's on a regular basis i found alot of >> leftovers (seems they do not cause problems here). > > I couldn't actually spot something strange. I also watched the query > log during gpupdate and didn't find anything special there. > > > On a Windows 7 Pro VM I installed (note, it's in the untrusted > 10.0.2.0/24 network) I see the following BIND logs on connect: > > > 09-Aug-2016 23:18:24.585 database: info: samba_dlz: committed > transaction on zone ad.cyberdyne.local > 09-Aug-2016 23:18:24.654 database: info: samba_dlz: starting > transaction on zone ad.cyberdyne.local > 09-Aug-2016 23:18:24.655 update-security: error: client > 10.0.2.95#57343: view internal: update 'ad.cyberdyne.local/IN' denied > 09-Aug-2016 23:18:24.655 database: info: samba_dlz: cancelling > transaction on zone ad.cyberdyne.local > 09-Aug-2016 23:18:24.656 database: info: samba_dlz: starting > transaction on zone ad.cyberdyne.local > 09-Aug-2016 23:18:24.658 database: info: samba_dlz: allowing update of > signer=cyb64w7-test\$\@AD.CYBERDYNE.LOCAL > name=CYB64W7-TEST.ad.cyberdyne.local tcpaddr= type=AAAA > key=316-ms-7.3-7c5a71.894664bf-5e64-11e6-3d8b-080027eead7d/160/0 > 09-Aug-2016 23:18:24.660 database: info: samba_dlz: allowing update of > signer=cyb64w7-test\$\@AD.CYBERDYNE.LOCAL > name=CYB64W7-TEST.ad.cyberdyne.local tcpaddr= type=A > key=316-ms-7.3-7c5a71.894664bf-5e64-11e6-3d8b-080027eead7d/160/0 > 09-Aug-2016 23:18:24.662 database: info: samba_dlz: allowing update of > signer=cyb64w7-test\$\@AD.CYBERDYNE.LOCAL > name=CYB64W7-TEST.ad.cyberdyne.local tcpaddr= type=A > key=316-ms-7.3-7c5a71.894664bf-5e64-11e6-3d8b-080027eead7d/160/0 > 09-Aug-2016 23:18:24.662 update: info: client 10.0.2.95#63502/key > cyb64w7-test\$\@AD.CYBERDYNE.LOCAL: view internal: updating zone > 'ad.cyberdyne.local/NONE': deleting rrset at > 'CYB64W7-TEST.ad.cyberdyne.local' AAAA > 09-Aug-2016 23:18:24.662 update: info: client 10.0.2.95#63502/key > cyb64w7-test\$\@AD.CYBERDYNE.LOCAL: view internal: updating zone > 'ad.cyberdyne.local/NONE': deleting rrset at > 'CYB64W7-TEST.ad.cyberdyne.local' A > 09-Aug-2016 23:18:24.664 database: info: samba_dlz: subtracted > rdataset CYB64W7-TEST.ad.cyberdyne.local > 'CYB64W7-TEST.ad.cyberdyne.local. 1200 IN A 10.0.2.95' > 09-Aug-2016 23:18:24.665 update: info: client 10.0.2.95#63502/key > cyb64w7-test\$\@AD.CYBERDYNE.LOCAL: view internal: updating zone > 'ad.cyberdyne.local/NONE': adding an RR at > 'CYB64W7-TEST.ad.cyberdyne.local' A 10.0.2.95 > 09-Aug-2016 23:18:24.668 database: info: samba_dlz: added rdataset > CYB64W7-TEST.ad.cyberdyne.local 'CYB64W7-TEST.ad.cyberdyne.local. > 1200 IN A10.0.2.95' > 09-Aug-2016 23:18:24.677 database: info: samba_dlz: committed > transaction on zone ad.cyberdyne.local > > > Expect the line about update-security (line 3) it looks like the > records get updated properly. I am also able to forward- and > reverse-lookup the node. > > > I just did a complete Wireshark dump of a gpupdate process on my > Windows 10 machine too. You can find it here: > <https://dl.dropboxusercontent.com/u/2015365/gpupdate.pcapng> > > I also did an ipconfig /flushdns just before the capture. > > Thank you > Rainer >This is odd your dump only lists dns queries for _ldap._tcp.DefaultFirstSite... for example. Also no SASL GSS-API requests etc. I attach the dump to this mail and send the reply to your personal and the list adress. Search for the string "Session Setup Response" it is followed by an "Tree Connect Request Tree" to the IPC$ share. In my case the sysvol share is accessed afterwards. Attached is the gpupdate.exe /force dump (samba2.pcap) and an complete logn process followed by an ping to the server and an gpupdate.exe /force run (samba-logon2.pcap) .