Protected User Gruppe Zugriff auf \\domain.local erlauben nur wie?

[goat82 2]

Hallo Zusammen,

 

ich habe einige priviligitierten Konten u.a. Domainadminaccounts in der Protected Usergruppe.

Funktioniert alles ganz gut, nur wie kann ich den Zugriff auf \\domain.local freigeben ?

Probem ist auch das wir viel DFS-N im Pfad \\domain.local\xxx\xxx haben und abrufen bzw. testen müssen und die Domainadmins natürlich auch auf sysvol+Policys drauf sollen.

(Geht natürlich auch über C:\Windows\sysvol) und auch DFS-N geht mit jedem anderen User außerhalb der Protected Usergruppe aber der Mensch ist ein Gewohnheitstier)

 

PS: Der Zugriff in der Protectedgroup über \\x.x.x.x funktioniert nur nicht über den DNS Namen.

 

Daher freue ich mich über eine Hilfe wie man \\domain.local innerhalb der Protectedgroup aktivieren kann, falls es geht.

 

Lg Goat

 

bearbeitet 19. Dezember 2024 von goat82
Ergänzung

[testperson 1.729]

Hi,

 

der Zugriff über die IP dürfte ab DFL/FFL 2012 R2 gar nicht mehr funktionieren (außer evtl. vom Host selber auf die eigene IP), da du in den Protected Users kein NTLM mehr machen darfst. Kannst du auf "\\domain.local\netlogon" direkt zugreifen?

 

Gruß

Jan

[goat82 2]

ja \\domain.local\netlogon und \\domain.local\sysvol geht,  \\localhost\  und \\locale DC ip\ geht ebenfalls.

\\donain.local\ geht aber nicht.

 

Immerhin gibts so einen Workarround, wenn auch die DFS-N Problematik noch besteht.

Immerhin geht DFS-N wenn man \\DC\Namespace\ eingibt noch.

 

bearbeitet 19. Dezember 2024 von goat82

[cj_berlin 1.356]

Moin,

 

"geht nicht" ist keine Fehlermeldung von Windows. Welche bekommst Du denn?

[Angua 1]

Moin zusammen,

 

wir haben gerade das gleiche Thema und ich möchte hier mal unsere Erkenntnisse teilen und hoffe auf hilfreiche Hinweise, ob und wie das zu lösen ist.

 

Wenn man versucht, per \\domain.local zuzugreifen, kommt eine Fehlermeldung "Auf \\domain.local kann nicht zugegriffen werden. Sie haben eventuell keine Berechtigung, diese Netzwerkressource zu verwenden. ... Dieser Benutzer kann sich aufgrund von Kontobeschränkungen nicht anmelden. ..."

 

Wenn man es z.B. auf \\domain.local\netlogon versucht, klappt es.

 

Wenn man es mit \\domain (ohne .local) versucht, klappt es auch.

 

Es sieht so aus, als ob bei "\\domain.local" NTLM verwendet wird (konnten wir in den Logs nachvollziehen) und bei "\\domain" Kerberos. Das hätten wir eigentlich anders herum erwartet.

 

Kann das jemand nachvollziehen und hat ggf. eine Lösung, die auch mit "\\domain.local" funktioniert?

 

Gruß, Frank

[cj_berlin 1.356]

vor einer Stunde schrieb Angua:

Das hätten wir eigentlich anders herum erwartet.

Es ist nicht so, dass single label-names automatisch zum NTLM-Fallback führen, denn SPNs können durchaus Hostnamen beinhalten und seit Server 2016 sogar IPs (außer bei Domain Controllern). Schau Dir das Attribut servicePrincipalName bei einem DC an, da findest Du einiges.

In der Umgebung, wo ich gerade herumspiele, fällt der Client sowohl für \\DOMAIN als auch für \\domain.fqdn auf NTLM zurück. 

 

Es gibt einen Trick (keine Empfehlung!), der funktioniert aber nur, wenn Du weißt, auf welchem DC Du mit dieser Anfrage landen wirst (also entweder gibt es nur einen, oder es gibt in der Site, wo diese Funktionalität benötigt wird, nur einen  ). In diesem Fall kannst Du den Domänennamen zu dem Attribut 'msDS-AdditionalDnsHostName' des betroffenen DC hinzufügen. Das wird dazu führen, dass er den SPN 'HOST/domain.fqdn' für sich einträgt. Wie bei Highlander, kann es auch hier nur einen geben...

Es ist sicherlich ein Bug, denn per Spezifikation muss auch der SPN 'HOST/DCNAME/domain.fqdn' angefragt werden, und das passiert auch, wenn Du auf einen Namespace zugreifst.

 

[toao 4]

1 hour ago, cj_berlin said:

Es ist nicht so, dass single label-names automatisch zum NTLM-Fallback führen, denn SPNs können durchaus Hostnamen beinhalten und seit Server 2016 sogar IPs (außer bei Domain Controllern). Schau Dir das Attribut servicePrincipalName bei einem DC an, da findest Du einiges.

In der Umgebung, wo ich gerade herumspiele, fällt der Client sowohl für \\DOMAIN als auch für \\domain.fqdn auf NTLM zurück. 

 

Es gibt einen Trick (keine Empfehlung!), der funktioniert aber nur, wenn Du weißt, auf welchem DC Du mit dieser Anfrage landen wirst (also entweder gibt es nur einen, oder es gibt in der Site, wo diese Funktionalität benötigt wird, nur einen  ). In diesem Fall kannst Du den Domänennamen zu dem Attribut 'msDS-AdditionalDnsHostName' des betroffenen DC hinzufügen. Das wird dazu führen, dass er den SPN 'HOST/domain.fqdn' für sich einträgt. Wie bei Highlander, kann es auch hier nur einen geben...

Es ist sicherlich ein Bug, denn per Spezifikation muss auch der SPN 'HOST/DCNAME/domain.fqdn' angefragt werden, und das passiert auch, wenn Du auf einen Namespace zugreifst.

 

Hatte auch gerade herumgespielt, ein paar weitere Infos:

Bei der Eingabe von "\\fqdn\netlogon" über SMB werden im TGS-REQ folgende 3 SnameStrings angefragt:
cifs
DCHOSTNAME.FQDN

FQDN

TGS-REP is successful und der SMB Tree Connect sieht am Ende so aus \\DCHOSTNAME.FQDN\netlogon.


Bei der Eingabe von "\\fqdn über SMB werden lediglich im TGS-REQ 2 SnameStrings angefragt:

cifs

FQDN

 

Die Anfrage wird mit einem ERR_S_Principal_Unknown quittiert. Ich hab's auf die schnelle mit dem hinzufügen des SPN Eintrags cifs/fqdn gelöst, aber wie oben schon von cj_berlin erwähnt, war dies nur auf einem Domain Controller möglich, da SPN = unique.

Gruß,
toao

 

bearbeitet 9. Januar von toao

[cj_berlin 1.356]

Moin,

 

und da wir innerhalb weniger Wochen diese Anfrage zweimal hier sehen, die Frage an @goat82 und @Angua: Was ist der Use Case?

 

Ich kann mich nicht erinnern, innerhalb der letzten 20 Jahre auf \\domain.fqdn ohne Folder oder Namespace dahinter zugegriffen zu haben, und ich mach ja schon ab und zu mit AD rum...

Es wäre also spannend zu wissen, welche Situation euch oder eure User dazu veranlasst  

 

Danke im vorab!

[Angua 1]

Am 10.1.2025 um 08:05 schrieb cj_berlin:

und da wir innerhalb weniger Wochen diese Anfrage zweimal hier sehen, die Frage an @goat82 und @Angua: Was ist der Use Case?

 

 

Moin und erstmal danke für die Antworten, jetzt können wir das besser einschätzen

 

Zum Use-Case: Das ist bei uns eher ein "Bequemlichkeits"-Thema in Bezug auf DFS. Die Kollegen greifen, insbesondere im Support, auf \\domain.fqdn zu, um die Liste aller DFS-Freigaben zu bekommen, um darin manuell auf die Freigaben zuzugreifen. Kann man sicher auch anders lösen, aber das Mappen der Freigaben ist nicht sinnvoll, da es bei unserer verteilten Struktur um die hundert Freigaben sind, auf die man im Supportfall zugreifen können muss.

 

Wir diskutieren gerade, ob die User, die in den "Protected Users" sind, überhaupt solche Zugriffe brauchen. Da müssen wir unser Tiering-Konzept wohl nochmal anpassen.

 

Gruß, Frank

[cj_berlin 1.356]

Moin,

 

danke für die Rückmeldung. Unter \\domain.fqdn sieht man ja, außer SYSVOL und NETLOGON, nicht Freigaben, sondern erst mal Namespaces. Habt ihr tatsächlich um die Hundert Namespaces, und unterscheiden sie sich auch wirklich voneinander (Namespace Server und Version)? Wieviele Ordner hat denn jedes Namespace?

 

Vielleicht wäre ein Zusammenfassen von 100 Namespaces zu deutlich weniger, vielleicht sogar nur einem, eine Option? Dann könnte man auf \\domain.fqdn\ingloriousfolders gehen und den vollständigen Überblick (minus NETLOGON und SYSVOL, aber die kennt man ja) bekommen?

bearbeitet 14. Januar von cj_berlin

[Angua 1]

Moin,

 

ja, sich meinte Namespaces, sorry. Wir haben sehr viele Standorte und mehrere Gesellschaften im Konzern, das ergibt in der Matrix die über hundert Namespaces. Ist "organisch gewachsen" . So einfach lässt sich das leider nicht auflösen. Ich muss da jetzt erstmal so mit umgehen. Ist ein Projekt für "später" (also vermutlich, wenn ich in Rente bin ) Aber ich schlage das den zuständigen Kollegen mal vor.

[daabm 1.375]

Der Sinn von Namespaces war eigentlich, genau eben NICHT Hunderte von Freigaben zu haben