3
Samba4 AD + Win10 Member: kein Zugriff auf sysvol
Hallo Experten,
ich betreibe eine kleine Windows-Domäne mit einem Qnap-NAS als Domain Controller (Samba4) und bisher ausschließlich Win7 Clients. Das funktioniert inzwischen ohne Probleme.
Nun habe ich zu Evaluierungszwecken einen meiner Rechner auf Win10-Pro angehoben. Der (Wieder-)Beitritt zur Domäne funktioniert noch, aber es werden keine Gruppenrichtlinien auf dem Win10-Client angewendet.
Ursache ist fehlende Zugriffsberechtigung auf dem sysvol-Share für den Win10-Client. Leider kann ich den Grund dafür nicht finden, denn der manuelle Test (als Domainadmin) ergibt:
\\domainname\sysvol Zugriff wird verweigert
aber:
\\dc.domainname\sysvol Zugriff funktioniert
und:
\\domainname\anderer_share Zugriff funktioniert auch
D.h. es gibt kein prizipielles Problem mit den Berechtigungen, sondern nur dann, wenn der Zugriff auf sysvol über \\domainname\... erfolgt. Bei der expliziten Angabe des Domain Controller kann zugegriffen werden.
Frage: Worin liegt eigentlich der konkrete Unterschied zw. \\domainname und \\dc.domainname und inwieweit kann das zum beschriebenen Zugriffsproblem bei Lesen der GPOs führen? Für mich riechts ja nach 'nem Bug, aber ich möchte auch ein Versagen meinerseits nicht ausschließen.
Die eigentlichen Berechtigungen auf dem sysvol-Share (sowohl die Share Permissions als auch die NTFS Permissions) sind meiner Meinung nach OK, denn a.) haben die Win7-Clients kein Problem und b.) ändert auch der temporäre Vollzugriff für jeden nichts an dem Problem unter Win10.
Hat irgendwer 'ne Idee?
Gruß+Dank, Foxdevilswild
ich betreibe eine kleine Windows-Domäne mit einem Qnap-NAS als Domain Controller (Samba4) und bisher ausschließlich Win7 Clients. Das funktioniert inzwischen ohne Probleme.
Nun habe ich zu Evaluierungszwecken einen meiner Rechner auf Win10-Pro angehoben. Der (Wieder-)Beitritt zur Domäne funktioniert noch, aber es werden keine Gruppenrichtlinien auf dem Win10-Client angewendet.
Ursache ist fehlende Zugriffsberechtigung auf dem sysvol-Share für den Win10-Client. Leider kann ich den Grund dafür nicht finden, denn der manuelle Test (als Domainadmin) ergibt:
\\domainname\sysvol Zugriff wird verweigert
aber:
\\dc.domainname\sysvol Zugriff funktioniert
und:
\\domainname\anderer_share Zugriff funktioniert auch
D.h. es gibt kein prizipielles Problem mit den Berechtigungen, sondern nur dann, wenn der Zugriff auf sysvol über \\domainname\... erfolgt. Bei der expliziten Angabe des Domain Controller kann zugegriffen werden.
Frage: Worin liegt eigentlich der konkrete Unterschied zw. \\domainname und \\dc.domainname und inwieweit kann das zum beschriebenen Zugriffsproblem bei Lesen der GPOs führen? Für mich riechts ja nach 'nem Bug, aber ich möchte auch ein Versagen meinerseits nicht ausschließen.
Die eigentlichen Berechtigungen auf dem sysvol-Share (sowohl die Share Permissions als auch die NTFS Permissions) sind meiner Meinung nach OK, denn a.) haben die Win7-Clients kein Problem und b.) ändert auch der temporäre Vollzugriff für jeden nichts an dem Problem unter Win10.
Hat irgendwer 'ne Idee?
Gruß+Dank, Foxdevilswild
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 282404
Url: https://administrator.de/contentid/282404
Printed on: April 27, 2024 at 16:04 o'clock
3 Comments
Latest comment
Hm, naja, eine Hilfe war die Community ja leider nicht. Aber egal. Vor einiger Zeit habe ich die Lösung dann selbst gefunden, und zwar
https://social.technet.microsoft.com/Forums/en-US/6a20e3f6-728a-4aa9-831 ...
Man setze die folgenden RegKeys:
%COMSPEC% /C reg add HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths /v "\\*\SYSVOL" /d "RequireMutualAuthentication=0" /t REG_SZ
%COMSPEC% /C reg add HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths /v "\\*\NETLOGON" /d "RequireMutualAuthentication=0" /t REG_SZ
Soweit ich das verstanden habe, wird damit das von Microsoft eingeführte Security-Feature abgeschaltet. Es möge also jeder selbst Entscheiden, ob das im konkreten Umfeld eine geeignete Lösung ist. In meinem Fall war es das
https://social.technet.microsoft.com/Forums/en-US/6a20e3f6-728a-4aa9-831 ...
Man setze die folgenden RegKeys:
%COMSPEC% /C reg add HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths /v "\\*\SYSVOL" /d "RequireMutualAuthentication=0" /t REG_SZ
%COMSPEC% /C reg add HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths /v "\\*\NETLOGON" /d "RequireMutualAuthentication=0" /t REG_SZ
Soweit ich das verstanden habe, wird damit das von Microsoft eingeführte Security-Feature abgeschaltet. Es möge also jeder selbst Entscheiden, ob das im konkreten Umfeld eine geeignete Lösung ist. In meinem Fall war es das
Hallo Fox,
auch wenn dieser Beitrag nun bereits eine Zeit her ist ... DANKE für die Lösung. Ich suche seit Wochen danach wo ich meinen Fehler gemacht habe, dies war der erste Schritt meine Netlogons und Sysvol sind nun wenigstens Sichbar. Dafür gehört MS meiner Meinung nach mal wieder geschlagen.
Danke und auf die nächsten Beiträge,
Grüsse, Kakaomonster
auch wenn dieser Beitrag nun bereits eine Zeit her ist ... DANKE für die Lösung. Ich suche seit Wochen danach wo ich meinen Fehler gemacht habe, dies war der erste Schritt meine Netlogons und Sysvol sind nun wenigstens Sichbar. Dafür gehört MS meiner Meinung nach mal wieder geschlagen.
Danke und auf die nächsten Beiträge,
Grüsse, Kakaomonster
Hallo Fox,
deine Lösung hat mir nach stundenlanger Suche sehr geholfen.
Der Zugriff auf die scripte in netlogon und sysvol funktioniert
einwandfrei.
Gruß KaSchu
deine Lösung hat mir nach stundenlanger Suche sehr geholfen.
Der Zugriff auf die scripte in netlogon und sysvol funktioniert
einwandfrei.
Gruß KaSchu