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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 282404
Url: https://administrator.de/contentid/282404
Ausgedruckt am: 22.11.2024 um 03:11 Uhr
3 Kommentare
Neuester Kommentar
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
