Forgot one extra. On the win 10, check this reg key. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Hostname It states you hostname here, but if its not in caps change it to HOSTNAME In that register key. (HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters) You should see also you dnsdomain at Domain and NV Domain. NV Hostname should be in CAPS also. The domains not. Greetz, Louis> -----Oorspronkelijk bericht----- > Van: samba [mailto:samba-bounces at lists.samba.org] Namens L.P.H. van Belle > Verzonden: donderdag 4 augustus 2016 8:25 > Aan: samba at lists.samba.org > Onderwerp: Re: [Samba] Samba 4.2.14 Group Policy (GPO) sync error > > Hai, > > No, your output is not good. > > >C:\Temp>netdom verify cyb64w10-monster > >The format of the specified computer name is invalid. > > Thats not good. > > > C:\Temp>nslookup cyb64w10-monster > > Server: UnKnown > > Address: fdea:5b48:d4c1:1:1::6 > > Also not good. > > > If you resolving is setup correct both should work. > netdom verify cyb64w10-monster > and > netdom verify cyb64w10-monster.ad.cyberdyne.local > > Both work for me and my windows 10 gets this policies. > > open dos box and type ipconfig /all > > check you primary dns suffix AND dns search. > Normaly these are the same, can you check this? > > My guess, your missing the dns-search > > Are you using ipv6 in your lan? If not, try disable it. > And try again. > If your using ipv6, then disable it, try it and enable it back. > > > And post the resolv.conf and hosts files > > > > Greetz, > > Louis > > > > > -----Oorspronkelijk bericht----- > > Van: samba [mailto:samba-bounces at lists.samba.org] Namens rme at bluemail.ch > > Verzonden: woensdag 3 augustus 2016 17:51 > > Aan: samba at lists.samba.org > > Onderwerp: Re: [Samba] Samba 4.2.14 Group Policy (GPO) sync error > > > > > Can you run on a failing computer : > > > - netdom verify yourpcname > > > > It seems to work only with FQDN: > > > > > > C:\Temp>netdom verify cyb64w10-monster > > The format of the specified computer name is invalid. > > > > The command failed to complete successfully. > > > > > > C:\Temp>netdom verify cyb64w10-monster.ad.cyberdyne.local > > The secure channel from CYB64W10-MONSTER.AD.CYBERDYNE.LOCAL to the > domain > > CYBERDYNE has been verified. The connection > > is with the machine \\SKYNET.AD.CYBERDYNE.LOCAL. > > > > The command completed successfully. > > > > > > > - nslookup yourpcname > > > > Seems to work fine: > > > > C:\Temp>nslookup cyb64w10-monster > > Server: UnKnown > > Address: fdea:5b48:d4c1:1:1::6 > > > > Name: cyb64w10-monster.ad.cyberdyne.local > > Addresses: fdea:5b48:d4c1:1:1::100 > > 2a02:120b:2c38:2951:8d95:bd76:deaa:73db > > fdea:5b48:d4c1:1:8d95:bd76:deaa:73db > > 10.0.1.119 > > > > > All ok? > > > > To me this looks alright. Isn't it? > > > > > > > And is time in sync? > > > > Yes, 100% in sync, synchronized via NTP server. > > I am using two external time servers and the following config in my > > /etc/ntp.conf: > > restrict default nomodify nopeer noquery limited kod mssntp > > restrict 127.0.0.1 > > restrict [::1] > > > > As of my understanding with Samba time server enabled this should allow > > clients > > to synchronize the clock. Actually manual verification and manual clock > > sync > > seems to work: > > > > C:\Temp>w32tm /resync > > Sending resync command to local computer > > The command completed successfully. > > > > > > > Did you install winbind after the update and also and did you change > > you > > > server services line? > > > > Well, I have installed Samba on Gentoo via official repositories. > Winbind > > was > > enabled from the beginning when upgrading from Samba 3.1 to 4.0. The > group > > policy synchronization worked perfectly fine until 4.2.11 update on > 4.2.9 > > it was > > working flawlessly. > > > > My service line looks as follows: > > server services = -dns > > > > Full line (samba-tool testparm -vv | grep "server service"): > > server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, > > winbindd, > > ntp_signd, kcc, dnsupdate > > > > > > > > > And best is really to setup TLS/SSL > > > > Copy that. > > > > > > > > <https://wiki.samba.org/index.php/Configuring_LDAP_over_SSL_(LDAPS)_on_a_S > > amba_AD_DC> > > > ( missing on that site : add TLS_REQCERT allow to ldap.conf ) > > > > Actually from the page I understood if I don't change anything the TLS > > certificates are generated but they are only valid 700 days. Though my > > ones were > > generated in November 2015 (perhaps on first Samba 4 startup) I just > > cleaned > > them and let Samba rebuild them on restart. I might go for my own CA and > > signed > > certs valid for longer period later if this turns out to be the culprit. > > > > > > So now I changed /etc/ldap/ldap.conf and inserted > > TLS_REQCERT allow > > > > > > Then I verified the configuration: > > > > First verify without TLS, this should fail. > > > > # ldapsearch -xLL -H ldap://localhost -D > > "cn=Administrator,cn=Users,dc=ad,dc=cyberdyne,dc=local" -W -b > > "dc=ad,dc=cyberdyne,dc=local" > > Enter LDAP Password: > > ldap_bind: Strong(er) authentication required (8) > > additional info: BindSimple: Transport encryption required. > > > > > > Then try with TLS, this should succeed. > > > > # ldapsearch -ZZ -xLL -H ldap://localhost -D > > "cn=Administrator,cn=Users,dc=ad,dc=cyberdyne,dc=local" -W -b > > "dc=ad,dc=cyberdyne,dc=local" | head -5 > > Enter LDAP Password: > > version: 1 > > > > dn: CN=Domain Controllers,CN=Users,DC=ad,DC=cyberdyne,DC=local > > objectClass: top > > objectClass: group > > ... > > > > > > Then try with SSL too. > > > > # ldapsearch -xLL -H ldaps://localhost -D > > "cn=Administrator,cn=Users,dc=ad,dc=cyberdyne,dc=local" -W -b > > "dc=ad,dc=cyberdyne,dc=local" | head -5 > > Enter LDAP Password: > > version: 1 > > > > dn: CN=Domain Controllers,CN=Users,DC=ad,DC=cyberdyne,DC=local > > objectClass: top > > objectClass: group > > ... > > > > > > > > > Now, for the other problem, after above is done/checked. > > > > I think TLS works as expected. > > > > > > > You can clear you GPO history on the pc. > > > Its recreated when you reboot/login again, so now worries.. > > > > > @echo off > > > DEL /S /F /Q “%ALLUSERSPROFILE%\Application Data\Microsoft\Group > > > Policy\History\*.*” > > > REG DELETE HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies /f > > > REG DELETE HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies /f > > > DEL /F /Q C:\WINDOWS\security\Database\secedit.sdb > > > klist purge > > > gpupdate /force > > > exit > > > > > now reboot your pc, and check again. > > > > > > I did run those although the Group Policy History and secedit.sdb did > not > > exist > > as GPO has never been synced on this machine (fresh Win 10 Pro 1607 > > installation). Though the klist purge and gpupdate run. Unfortunately > > gpupdate > > immediately showed the same errors again while Samba printing the same > > errors in > > its log: > > > > [2016/08/03 17:48:48.064741, 1] > > ../auth/kerberos/gssapi_helper.c:291(gssapi_unseal_packet) > > gss_unwrap_iov failed: Miscellaneous failure (see text): unknown > mech- > > code 0 > > for mech 1 2 840 113554 1 2 2 > > [2016/08/03 17:48:48.064868, 0] > > ../source4/auth/gensec/gensec_gssapi.c:1051(gensec_gssapi_unseal_packet) > > gssapi_unseal_packet(hdr_signing=1,sig_size=45,data=144,pdu=176) > > failed: > > NT_STATUS_ACCESS_DENIED > > > > > > Many thanks for your patience trying to debug this issue. I am a bit out > > of > > ideas now how to trace this down. All file server services of Samba seem > > to work > > fine. > > > > Thanks again > > Rainer > > > > -- > > To unsubscribe from this list go to the following URL and read the > > instructions: https://lists.samba.org/mailman/options/samba > > > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba
rme at bluemail.ch
2016-Aug-04 08:45 UTC
[Samba] Samba 4.2.14 Group Policy (GPO) sync error
Hello,
> On the win 10, check this reg key.
> HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Hostname
> It states you hostname here, but if its not in caps change it to HOSTNAME
Actually the name was in lowercase letters. I changed it to capital letters.
Though without any effect. I actually also thought Windows does not care about
case sensitivity and for hostnames by default it shouldn't matter.
> In that register key.
(HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters)
> You should see also you dnsdomain at Domain and NV Domain.
> NV Hostname should be in CAPS also.
> The domains not.
Also this was in lowercase which I changed with no effect.
But I noticed another thing:
In HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters there
are a few important parameters:
Dhcpv6DNSServers:
Here I see correctly my server fdea:5b48:d4c1:1:1::6 listed.
Dhcpv6DomainSearchList:
Here it looks only my suffix cyberdyne.local is listed and not
ad.cyberdyne.local. I have updated my DHCPv6 to include the search suffix as
well:
option dhcp6.domain-search "ad.cyberdyne.local",
"cyberdyne.local";
Strangely the value of the Dhcpv6DomainSearchList in the registry did not
update. Neither does the value in ipconifig /all
Connection-specific DNS Suffix Search List :
cyberdyne.local
Actually I tried on one of the machines to disable IPv6 entirely (on client side
only). Even this did not do any change to the result.
So for the moment I am operating one client for testing without IPv6 and one
with IPv6 enabled. But none of them seem to synchronize GPO.
Just for completeness here's the complete output from a test client with
IPv6
disabled entirely (on client side):
C:\Temp>ipconfig /all
Windows IP Configuration
Host Name . . . . . . . . . . . . : CYB64W10-HPNB
Primary Dns Suffix . . . . . . . : ad.cyberdyne.local
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : ad.cyberdyne.local
Ethernet adapter Ethernet:
Connection-specific DNS Suffix . : cyberdyne.local
Description . . . . . . . . . . . : Intel(R) 82566MM Gigabit Network
Connection
Physical Address. . . . . . . . . : 00-1A-4B-79-B0-18
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 10.0.1.186(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : Thursday, August 4, 2016 10:39:04 AM
Lease Expires . . . . . . . . . . : Saturday, August 6, 2016 10:39:03 AM
Default Gateway . . . . . . . . . : 10.0.1.6
DHCP Server . . . . . . . . . . . : 10.0.1.6
DNS Servers . . . . . . . . . . . : 10.0.1.6
10.0.2.6
Primary WINS Server . . . . . . . : 10.0.1.6
NetBIOS over Tcpip. . . . . . . . : Enabled
C:\Temp>nslookup cyb64w10-hpnb
Server: skynet.cyberdyne.local
Address: 10.0.1.6
Name: cyb64w10-hpnb.ad.cyberdyne.local
Address: 10.0.1.186
C:\Temp>netdom verify cyb64w10-hpnb
The secure channel from CYB64W10-HPNB to the domain CYBERDYNE has been verified.
The connection
is with the machine \\SKYNET.AD.CYBERDYNE.LOCAL.
The command completed successfully.
C:\Temp>netdom verify cyb64w10-hpnb.ad.cyberdyne.local
The secure channel from CYB64W10-HPNB.AD.CYBERDYNE.LOCAL to the domain CYBERDYNE
has been verified. The connection
is with the machine \\SKYNET.AD.CYBERDYNE.LOCAL.
The command completed successfully.
C:\Temp>gpupdate /force
Updating policy...
Computer policy could not be updated successfully. The following errors were
encountered:
The processing of Group Policy failed. Windows could not resolve the computer
name. This could be caused by one of more of the following:
a) Name Resolution failure on the current domain controller.
b) Active Directory Replication Latency (an account created on another domain
controller has not replicated to the current domain controller).
User Policy could not be updated successfully. The following errors were
encountered:
The processing of Group Policy failed. Windows could not resolve the user name.
This could be caused by one of more of the following:
a) Name Resolution failure on the current domain controller.
b) Active Directory Replication Latency (an account created on another domain
controller has not replicated to the current domain controller).
To diagnose the failure, review the event log or run GPRESULT /H GPReport.html
from the command line to access information about Group Policy results.
On Server side I still get the same logs:
[2016/08/04 10:44:54.784497, 3]
../lib/ldb-samba/ldb_wrap.c:321(ldb_wrap_connect)
ldb_wrap open of secrets.ldb
[2016/08/04 10:44:54.785818, 5]
../auth/gensec/gensec_start.c:672(gensec_start_mech)
Starting GENSEC mechanism spnego
[2016/08/04 10:44:54.786480, 5]
../auth/gensec/gensec_start.c:672(gensec_start_mech)
Starting GENSEC submechanism gssapi_krb5
[2016/08/04 10:44:54.789262, 5]
../source4/auth/gensec/gensec_gssapi.c:499(gensec_gssapi_update)
gensec_gssapi: NO credentials were delegated
[2016/08/04 10:44:54.789373, 5]
../source4/auth/gensec/gensec_gssapi.c:514(gensec_gssapi_update)
GSSAPI Connection will be cryptographically sealed
[2016/08/04 10:44:54.806151, 1]
../auth/kerberos/gssapi_helper.c:291(gssapi_unseal_packet)
gss_unwrap_iov failed: Miscellaneous failure (see text): unknown mech-code 0
for mech 1 2 840 113554 1 2 2
[2016/08/04 10:44:54.806331, 0]
../source4/auth/gensec/gensec_gssapi.c:1051(gensec_gssapi_unseal_packet)
gssapi_unseal_packet(hdr_signing=1,sig_size=45,data=208,pdu=240) failed:
NT_STATUS_ACCESS_DENIED
best regards,
Rainer
>I actually also thought Windows does not care > about > case sensitivity and for hostnames by default it shouldn't matter.Thats correct but if windows is buggy.. Source : https://support.microsoft.com/nl-nl/kb/2891966 It was worth a try.. https://support.microsoft.com/en-us/kb/2954031 for the status rapport error, one you can check also. I see still something incorrect here.> C:\Temp>nslookup cyb64w10-hpnb > Server: skynet.cyberdyne.local > Address: 10.0.1.6> C:\Temp>nslookup cyb64w10-hpnb > Server: skynet.cyberdyne.local > Address: 10.0.1.6 > > Name: cyb64w10-hpnb.ad.cyberdyne.local > Address: 10.0.1.186SKYNET.AD.CYBERDYNE.LOCAL is the correct AD DC location. Above still shows : skynet.cyberdyne.local Review the settings again, if needed test with a dedicated IP. Preffered ipv4 in the test. Now im really out to office, im getting late.. so no reply for me untill at least 16:00 or tomorrow. Greetz, Louis> -----Oorspronkelijk bericht----- > Van: samba [mailto:samba-bounces at lists.samba.org] Namens rme at bluemail.ch > Verzonden: donderdag 4 augustus 2016 10:45 > Aan: samba at lists.samba.org > Onderwerp: Re: [Samba] Samba 4.2.14 Group Policy (GPO) sync error > > Hello, > > > On the win 10, check this reg key. > > HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Hostname > > > It states you hostname here, but if its not in caps change it to > HOSTNAME > > Actually the name was in lowercase letters. I changed it to capital > letters. > Though without any effect. I actually also thought Windows does not care > about > case sensitivity and for hostnames by default it shouldn't matter. > > > > In that register key. > (HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters) > > You should see also you dnsdomain at Domain and NV Domain. > > NV Hostname should be in CAPS also. > > The domains not. > > Also this was in lowercase which I changed with no effect. > > But I noticed another thing: > In HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters > there > are a few important parameters: > Dhcpv6DNSServers: > Here I see correctly my server fdea:5b48:d4c1:1:1::6 listed. > > Dhcpv6DomainSearchList: > Here it looks only my suffix cyberdyne.local is listed and not > ad.cyberdyne.local. I have updated my DHCPv6 to include the search suffix > as well: > option dhcp6.domain-search "ad.cyberdyne.local", "cyberdyne.local"; > > > Strangely the value of the Dhcpv6DomainSearchList in the registry did not > update. Neither does the value in ipconifig /all > > Connection-specific DNS Suffix Search List : > cyberdyne.local > > Actually I tried on one of the machines to disable IPv6 entirely (on > client side > only). Even this did not do any change to the result. > > > So for the moment I am operating one client for testing without IPv6 and > one > with IPv6 enabled. But none of them seem to synchronize GPO. > > > > > Just for completeness here's the complete output from a test client with > IPv6 > disabled entirely (on client side): > > C:\Temp>ipconfig /all > > Windows IP Configuration > > Host Name . . . . . . . . . . . . : CYB64W10-HPNB > Primary Dns Suffix . . . . . . . : ad.cyberdyne.local > Node Type . . . . . . . . . . . . : Hybrid > IP Routing Enabled. . . . . . . . : No > WINS Proxy Enabled. . . . . . . . : No > DNS Suffix Search List. . . . . . : ad.cyberdyne.local > > Ethernet adapter Ethernet: > > Connection-specific DNS Suffix . : cyberdyne.local > Description . . . . . . . . . . . : Intel(R) 82566MM Gigabit Network > Connection > Physical Address. . . . . . . . . : 00-1A-4B-79-B0-18 > DHCP Enabled. . . . . . . . . . . : Yes > Autoconfiguration Enabled . . . . : Yes > IPv4 Address. . . . . . . . . . . : 10.0.1.186(Preferred) > Subnet Mask . . . . . . . . . . . : 255.255.255.0 > Lease Obtained. . . . . . . . . . : Thursday, August 4, 2016 10:39:04 > AM > Lease Expires . . . . . . . . . . : Saturday, August 6, 2016 10:39:03 > AM > Default Gateway . . . . . . . . . : 10.0.1.6 > DHCP Server . . . . . . . . . . . : 10.0.1.6 > DNS Servers . . . . . . . . . . . : 10.0.1.6 > 10.0.2.6 > Primary WINS Server . . . . . . . : 10.0.1.6 > NetBIOS over Tcpip. . . . . . . . : Enabled > > C:\Temp>nslookup cyb64w10-hpnb > Server: skynet.cyberdyne.local > Address: 10.0.1.6 > > Name: cyb64w10-hpnb.ad.cyberdyne.local > Address: 10.0.1.186 > > C:\Temp>netdom verify cyb64w10-hpnb > The secure channel from CYB64W10-HPNB to the domain CYBERDYNE has been > verified. > The connection > is with the machine \\SKYNET.AD.CYBERDYNE.LOCAL. > > The command completed successfully. > > C:\Temp>netdom verify cyb64w10-hpnb.ad.cyberdyne.local > The secure channel from CYB64W10-HPNB.AD.CYBERDYNE.LOCAL to the domain > CYBERDYNE > has been verified. The connection > is with the machine \\SKYNET.AD.CYBERDYNE.LOCAL. > > The command completed successfully. > > C:\Temp>gpupdate /force > Updating policy... > > Computer policy could not be updated successfully. The following errors > were > encountered: > > The processing of Group Policy failed. Windows could not resolve the > computer > name. This could be caused by one of more of the following: > a) Name Resolution failure on the current domain controller. > b) Active Directory Replication Latency (an account created on another > domain > controller has not replicated to the current domain controller). > User Policy could not be updated successfully. The following errors were > encountered: > > The processing of Group Policy failed. Windows could not resolve the user > name. > This could be caused by one of more of the following: > a) Name Resolution failure on the current domain controller. > b) Active Directory Replication Latency (an account created on another > domain > controller has not replicated to the current domain controller). > > To diagnose the failure, review the event log or run GPRESULT /H > GPReport.html > from the command line to access information about Group Policy results. > > > > On Server side I still get the same logs: > > [2016/08/04 10:44:54.784497, 3] ../lib/ldb- > samba/ldb_wrap.c:321(ldb_wrap_connect) > ldb_wrap open of secrets.ldb > [2016/08/04 10:44:54.785818, 5] > ../auth/gensec/gensec_start.c:672(gensec_start_mech) > Starting GENSEC mechanism spnego > [2016/08/04 10:44:54.786480, 5] > ../auth/gensec/gensec_start.c:672(gensec_start_mech) > Starting GENSEC submechanism gssapi_krb5 > [2016/08/04 10:44:54.789262, 5] > ../source4/auth/gensec/gensec_gssapi.c:499(gensec_gssapi_update) > gensec_gssapi: NO credentials were delegated > [2016/08/04 10:44:54.789373, 5] > ../source4/auth/gensec/gensec_gssapi.c:514(gensec_gssapi_update) > GSSAPI Connection will be cryptographically sealed > [2016/08/04 10:44:54.806151, 1] > ../auth/kerberos/gssapi_helper.c:291(gssapi_unseal_packet) > gss_unwrap_iov failed: Miscellaneous failure (see text): unknown mech- > code 0 > for mech 1 2 840 113554 1 2 2 > [2016/08/04 10:44:54.806331, 0] > ../source4/auth/gensec/gensec_gssapi.c:1051(gensec_gssapi_unseal_packet) > gssapi_unseal_packet(hdr_signing=1,sig_size=45,data=208,pdu=240) > failed: > NT_STATUS_ACCESS_DENIED > > > > > best regards, > Rainer > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba
rme at bluemail.ch
2016-Aug-04 09:26 UTC
[Samba] Samba 4.2.14 Group Policy (GPO) sync error
Hello > https://support.microsoft.com/en-us/kb/2954031 > for the status rapport error, one you can check also. Looks like nothing to apply on a fresh Windows 10 1607 installation with all updates applied. > I see still something incorrect here. > > C:\Temp>nslookup cyb64w10-hpnb > > Server: skynet.cyberdyne.local > > Address: 10.0.1.6 > SKYNET.AD.CYBERDYNE.LOCAL is the correct AD DC location. > Above still shows : skynet.cyberdyne.local Well, good question. Actually the AD DNS domain for me is supplementary. The cyberdyne.local domain is where I keep all my hosts managed. But if this is important for Widnows I can change the PTR entries of those IPs to point to the AD domain. Here we go... C:\Temp>nslookup 10.0.1.6 Server: skynet.ad.cyberdyne.local Address: fdea:5b48:d4c1:1:1::6 Name: skynet.cyberdyne.local Address: 10.0.1.6 C:\Temp>nslookup 10.0.2.6 Server: skynet.ad.cyberdyne.local Address: fdea:5b48:d4c1:1:1::6 Name: skynet.ad.cyberdyne.local Address: 10.0.2.6 C:\Temp>nslookup fdea:5b48:d4c1:1:1::6 Server: skynet.ad.cyberdyne.local Address: fdea:5b48:d4c1:1:1::6 Name: skynet.ad.cyberdyne.local Address: fdea:5b48:d4c1:1:1::6 The result though is still the same. Best regards, Rainer