winword
Goto Top

Lokale Laufwerksberechtigung via GPO

Hallo Zusammen!

Wir verwenden spezielle Messgeräte mit einem angepassten (englischen) Windows XP Embedded welche vorpartitioniert sind. Diese befinden sich korrekt eingebunden in unserer Domäne.

Einzelne Benutzer müssen auf dem Laufwerk D Schreibrechte haben, das Problem hierbei ist leider, dass die AD-Benutzer direkt angegeben werden müssen (AD-Gruppen, egal ob Global oder Lokal werden ignoriert). Lokale Gruppen, welche sich auf dem Gerät befinden, werden fehlerfrei berücksichtigt.
Da wir von Berechtigungsvergabe von einzelne Benutzer stark wechselnd zu Gruppen sind, wäre es sehr sinnvoll, wenn denn die Möglichkeit vorhanden ist, via GPO eine lokale Gruppe (im Beispiel wäre die Gruppe "Users" passend) auf den Client zu verwenden und Vollzugriff auf D zu geben.

Hier nochmals zur Vereinfachung in Screenshots dargestellt:
gpo2
gpo

Hat irgendwer einen Lösungsansatz?
Vielen Dank im Voraus face-smile


MfG
WinWord

Content-Key: 305183

Url: https://administrator.de/contentid/305183

Ausgedruckt am: 19.03.2024 um 08:03 Uhr

Mitglied: emeriks
emeriks 23.05.2016 um 11:32:26 Uhr
Goto Top
Hi,
ich wüsste jetzt zwar nicht, warum das mit AD-Gruppen nicht gehen sollte. Aber der Weg über die lokalen Gruppen ist sowieso der bessere. Stichwort A-G-DL-P. "DL" sind hier die lokalen Gruppen.

Setze doch die Rechte für die lokalen Gruppen. Dann mittels GPO "eingeschränkte Gruppen" diese Gruppen mit AD-Gruppen füllen. Die AD-Benutzer im AD in diese Gruppen packen.

E.
Mitglied: WinWord
WinWord 23.05.2016 um 12:46:04 Uhr
Goto Top
Hallo emeriks,

erstmals vielen Dank für deine Hilfe face-smile

Nun zum eigentlichen:
A-G-DL-P ist ja die best-practise-Variante von Microsoft soweit ist mir das bewusst.

Das Problem besteht leider bei dem grundlegenden Problem:
Zitat von @emeriks:

[...] Setze doch die Rechte für die lokalen Gruppen.[...]
Wie kann ich via GPO der lokalen Gruppe Berechtigungen zuweisen bzw. diese auswählen?
Mir werden hier lediglich Domänenbenutzer vorgeschlagen: Domäne\Benutzer
Vorstellung von lokale Berechtigung: "LokalerPC\Gruppe"
lokal
Natürlich kann ich nicht jeden PC einzeln auflisten.


MfG
WinWord
Mitglied: DerWoWusste
DerWoWusste 23.05.2016 um 12:51:41 Uhr
Goto Top
Hi.

AD-Gruppen, egal ob Global oder Lokal werden ignoriert
Was soll das bedeuten? Beschreibe mal genauer. Hier geht es.
Mitglied: WinWord
WinWord 23.05.2016 um 13:00:52 Uhr
Goto Top
Hallo DerWoWusste,

das ist ein interessantes Phänomen:
lokald
Der Benutzer befindet sich in der AD-Gruppe welche Vollzugriff auf D hat.
Diese hat aber leider keinerlei effektive Auswirkung - erst der Wechsel auf eine lokale, am Client vorhandene, Gruppe hat geholfen um Schreibberechtigung zu erhalten.

Zusatzinformation:
Es betrifft nur diese speziellen Geräte (Windows XP Embedded), die Nachfolger (Windows 7 Embedded) funktionieren fehlerfrei mit dieser Einstellung, deshalb müssen wir mit lokalen Gruppen arbeiten.


Mfg
WinWord
Mitglied: emeriks
emeriks 23.05.2016 aktualisiert um 13:02:41 Uhr
Goto Top
Du hast geschrieben
Lokale Gruppen, welche sich auf dem Gerät befinden, werden fehlerfrei berücksichtigt.
Bin davon ausgegangen, dass Du diese Gruppen schon eingetragen hast.

Jetzt kommen mir Zweifel, ob wir Dich richtig verstehen. Auch wegen DWWs Nachfrage.
Werden denn die NTFS-Berechtigungen überhaupt aus der GPO übernommen? Egal für wen?
Mitglied: emeriks
emeriks 23.05.2016 um 13:03:59 Uhr
Goto Top
Und Du hast den Benutzer, nachdem Du ihn in die AD-Gruppe aufgenommen hast, auch neu angemeldet, damit diese Gruppemitgliedschaft überhaupt wirken kann?
Mitglied: WinWord
WinWord 23.05.2016 aktualisiert um 13:16:04 Uhr
Goto Top
Hallo emeriks,

falls ich das Problem zu undeutlich geschildert haben sollte tut es mir Leid.

Nochmal anders/kompakter formuliert:
  • Grundproblem
Das Messgerät hat eine lokale Gruppe welche ich via GPO Schreibberechtigung auf das Laufwerk D geben möchte.
  • Hintergrund
Ziel von uns: Größtenteils noch mit Gruppen zu arbeiten.
Ich kann leider nur AD-User sowie AD-Gruppen via Richtlinie hinzufügen - diese werden auch fehlerfrei ausgerollt, nur vom Messgerät (Grund-Auch-Immer-Einfügen) nicht angenommen - es funktioniert erst wenn der User direkt in den Berechtigungen steht.

Ist das besser verständlicher geschrieben?


Mit freundlichen Grüßen
WinWord

*Edit01:
Die AD-Gruppe besteht schon längers und der Benutzer ist schon darin "verwurzelt" (seit Beginn an dabei).
Mitglied: emeriks
emeriks 23.05.2016 um 13:20:11 Uhr
Goto Top
Was heißt "nicht angenommen"? Landen die AD-Gruppen nicht in der ACL oder doch, aber die Berechtigungen wirken nicht?
Mitglied: WinWord
WinWord 23.05.2016 um 13:32:02 Uhr
Goto Top
Hallo emeriks,

nicht angenommen heißt:
Sie erscheinen korrekt im Security-Register bei den Einstellungen vom D-Laufwerk, ich kann aber als AD-User (obwohl er Mitglied dieser AD-Gruppe ist, siehe Post 23.05.2016 um 13:00 Uhr) keinen Zugriff erlangen/keine Datei schreiben. (Ja, es hört sich genauso verflixt an wie es ist...) Hierbei ist es irrelevant ob die Gruppe manuell hinzufüge oder via GPO ausrollen lassen - der Fehler bleibt derselbe.


MfG
WinWord
Mitglied: emeriks
emeriks 23.05.2016 um 13:53:13 Uhr
Goto Top
Und die User greifen dann über D$ zu? Sollen sie schon ab D:\ lesen/schreiben können?
Falls nein: Wird die ACL an den betreffenden Ordner vererbt? Wie ist der Ordner freigegeben?
Mitglied: WinWord
WinWord 23.05.2016 um 14:59:31 Uhr
Goto Top
Hallo emeriks,

dieser Ordner ist und wird nicht freigegeben.
Er wird z.B. für messgerätspezifische Kalibrierungsdateien welche darin geschrieben werden oder für Firmwareupdates benötigt.
Die Berechtigung muss sogar direkt ab D:\ funktionieren.


MfG
WinWord
Mitglied: emeriks
emeriks 23.05.2016 um 15:02:13 Uhr
Goto Top
Die User melden sich also lokal am Embeded WinXP mit ihrem Domänenkonto an und müssen dann auf die betreffenden Ordner zugreifen?
Mitglied: WinWord
WinWord 23.05.2016 um 15:27:11 Uhr
Goto Top
Hallo emeriks,

generell stimmt deine Aussage so.

Was man aber vielleicht wissen sollte:
*Die bereits genannten Kalibrierungsdaten werden direkt beim Messgerät erzeugt und auf D:\ geschrieben (man kann die nicht einfach von irgendwo her kopieren) - dies passiert über einen (mehr oder minder) Allgemeinbenutzer
*Es sind zwei User im AD vorhanden, welche für die Firmwareupdates/Aktualisierungen zuständig sind (die letzten Endes die Berechtigungen benötigen)


MfG
WinWord
Mitglied: emeriks
emeriks 23.05.2016 um 15:40:09 Uhr
Goto Top
OK. Und die Anmeldung dieser Benutzer lokal am Embeded WinXP funktioniert auch? (Ich frage nur der Vollständigkeit wegen.)
Mitglied: WinWord
WinWord 23.05.2016 um 16:02:01 Uhr
Goto Top
Hallo emeriks,

jeder Benutzer lässt sich problemlos anmelden.
Weil wenn man Berechtigung direkt vergibt (also den Benutzer direkt hinzufügt), funktioniert alles wie gewünscht, das Problem ist erst bei AD-Gruppen.


MfG
WinWord
Mitglied: emeriks
emeriks 23.05.2016 um 16:13:09 Uhr
Goto Top
Also hat das ganze Problem doch überhaupt nichts mit GPO zu tun ....

Könnte es sein, dass das Benutzer sind, welche direkt oder indirekt (verschachtelt) in sehr vielen Gruppen Mitglied sind? Falls ja, könnte es sein, dass die Größe des Sitzungstoken, welches das Embeded WinXP für diese User ausstellt, nicht alle Gruppen-SID aufnehmen kann.

(Das o.g. kann auch auftreten, wenn die Gruppenanzahl nicht ganz so groß ist, die gruppen aber schon mal mit ADMT und Übernahme der sidHistory zwischen Domänen migriert wurden und die sidHistory seit dem noch nicht bereinigt wurde.)

Falls es das sein könnte, dann suche im Web mal nach "MaxTokenSize".
Mitglied: WinWord
WinWord 24.05.2016 aktualisiert um 06:30:50 Uhr
Goto Top
Hallo emeriks,

nein, das Problem liegt nicht an der GPO.

Auch ist die AD-Gruppe nicht verschachtelt, die User stehen direkt drin.
Interessant: Die lokale Gruppe "Users" beinhaltet die AD-Gruppe "Domäne\Domain Users" (ist also verschachtelt) diese Rechte ziehen aber.

Also bleibt leider immer noch der von anfangs an erwähnte Punkt offen (zumindest fällt mir nichts anderes mehr ein):
Kann man via GPO lokale Gruppen auswählen um (lokale) Berechtigungen zu vergeben?
Im Sinne von "%hostname%\Users". (Wäre zumindest sogar denkbar, da die Variable hostname den jeweiligen PC-Namen wiedergibt.)


Mit freundlichen Grüßen
WinWord

*Edit01:
Schieb es den frühen Morgenstunden zu, erst jetzt habe ich korrekt gelesen, was du gemeint hast.
Benutzer A ist in insgesamt 7, Benutzer B ist in insgesamt 9 Gruppen.
Ich denke das sind relativ geringe Anzahlen, mit dem ein Windows (auch ein angepasstes XP Embedded) umgehen können sollte?
Mitglied: DerWoWusste
DerWoWusste 24.05.2016 aktualisiert um 09:42:56 Uhr
Goto Top
Hör mal.

Das Verteilen von ACLs funktioniert, da gibt es überhaupt keinen Zweifel daran. Ich nutze es seit Jahr und Tag, auf allen möglich Betriebssystemen und immer mit Domänengruppen. Nimm Dir bitte mal einen leeren Rechner mit einem Ordner c:\test, pack diesen in eine OU und wende eine GPO darauf an, die eine Domänengruppe berechtigt, dort zu lesen. Du wirst sehen, dass es geht - das hattest Du schon vorher festegestellt, aber mit "Der Benutzer befindet sich in der AD-Gruppe welche Vollzugriff auf D hat.
Diese hat aber leider keinerlei effektive Auswirkung - erst der Wechsel auf eine lokale am Client vorhandene Gruppe hat geholfen um Schreibberechtigung zu erhalten." ausgesagt, dass es dennoch nicht funktioniert. Liegt es vielleicht daran, dass diesem Nutzer als Teil einer anderen Gruppe das Schreiben explizit verweigert wird? Klingt mir doch sehr danach. Schau Dir doch einfach mal die effektiven Berechtigungen für diese Gruppe an.
Mitglied: WinWord
WinWord 24.05.2016 um 12:00:10 Uhr
Goto Top
Hallo DerWoWusste,

auch das ist mir bewusst.
Zitat von @DerWoWusste:

[...]Nimm Dir bitte mal einen leeren Rechner [...]
Hier mag es auch fehlerfrei funktionieren - diese Messgeräte (ja es betrifft alle mit diesem Stand) sind aber ab Werk mit Software/Treiber ausgeliefert, zu denen wir keinen Zugriff haben => Neuinstallation leider unmöglich.
Wir haben eine ähnliche bereits funktionierende Konstellation, nur heißt der Ordner nicht C:\Test sondern wird mit %systemdrive%\ORDNER gearbeitet:
systemdrive

Auch an das Verweigern wurde bereits gedacht, es sind aber keine Gruppen/Benutzer vorhanden welche gesperrt sind. (=> Alle nur auf erlauben)


MfG
WinWord
Mitglied: DerWoWusste
DerWoWusste 24.05.2016 um 12:47:42 Uhr
Goto Top
Es hat nichts damit zu tun, was auf den rechnern drauf ist, da geb ich Dir Brief und Siegel drauf.
Wie sind denn die effektiven Berechtigungen - schau dort mal rein.
Mitglied: WinWord
WinWord 24.05.2016 um 13:03:33 Uhr
Goto Top
Hallo DerWoWusste,

ich bin komplett bei deinen Überlegungen- habe lange genug mit Berechtigungen zu tun gehabt.

Hier siehst du die Berechtigungen beim Messgerät:
berechtigungend

Selbst die erste Gruppe (zu der niemand der Betroffenen gehört) sollte Zugriff haben - wenn auch nur lesend.
Leider muss ich diesen Gedanken schon wieder zerstören => Kein Zugriff (da keine lokale Gruppe bzw. da nicht der User dediziert angegeben).
Der Besitzer ist die Lokale "Administrators"-Gruppe - falls diese Information noch etwas zu tun haben.


MfG
WinWord
Mitglied: emeriks
emeriks 24.05.2016 um 16:59:04 Uhr
Goto Top
Noch mal zu dem "kein Zugriff". Haben die Benutzer keinen Zugriff auf D:\ oder auf einen Unterordner von D: ?
Mitglied: WinWord
WinWord 25.05.2016 um 06:31:31 Uhr
Goto Top
Hallo emeriks,

auf den Zugriffsversuch auf D:\ folgt prompt folgende Fehlermeldung:
d
Es haben nur die (wie bereits erwähnt) Benutzer welche entweder
  • Direkt eingetragen (irrelevant ob lokale oder AD) oder
  • Die sich in der lokalen Gruppe (!) in den Berechtigungen von D befinden (Verschachtelung möglich - d. h. darin kann sich sogar meine betroffene AD-Gruppe befinden!)
Zugriff.

Was mich leider erneut zu der (meiner Meinung nach Lösungs-)Frage bringt:
Ist es möglich in der Richtlinie eine lokale Gruppe auszuwählen?


MfG
WinWord
Mitglied: DerWoWusste
Lösung DerWoWusste 25.05.2016 um 08:26:29 Uhr
Goto Top
Du kannst natürlich lokale Gruppen wählen, jedoch müssen die well-known groups sein, also die eingebauten Administratoren/RemoteDesktopbenutzer/Benutzer... siehe https://support.microsoft.com/en-us/kb/243330
Mitglied: emeriks
emeriks 25.05.2016 um 11:08:31 Uhr
Goto Top
Oder eben mit Startup-Scripten arbeiten.
Mitglied: DerWoWusste
DerWoWusste 25.05.2016 um 11:44:48 Uhr
Goto Top
Jou. Icacls kann das.
Mitglied: WinWord
WinWord 25.05.2016 um 11:48:33 Uhr
Goto Top
Hallo DerWoWusste,

vielen Dank für diese Info!
Habe promt darauf die SID (= S-1-5-32-545) ausgelesen und eine Übereinstimmung in deinem Link gefunden:
psgetsid
Leider fehlt auch mir das Wissen eine SID in die Berechtigungen einzutragen face-sad
namenotfound
Wenn dies möglich ist, wäre der Fall so wie wie als gelöst zu betrachten face-smile

Falls jemandem oben stehender Link nicht weiterhelfen sollte, hier noch ein anderer:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa379649(v=vs.8 ...

Interessanterweise ist die Gruppe Users unter Windows 7 nicht mehr aufzufinden:
psgetsidwin7


MfG
WinWord
Mitglied: DerWoWusste
DerWoWusste 25.05.2016 aktualisiert um 14:48:24 Uhr
Goto Top
Keine SID eintragen, einfach Users/Benutzer (je nach Sprache Deines Systems, das die Policies schreibt) face-smile
Mitglied: WinWord
WinWord 25.05.2016 um 14:36:33 Uhr
Goto Top
Hallo DerWoWusste,

hier ist leider das identische "Namen-Nicht-Gefunden"-Phänomen (egal ob "Users" oder "Benutzer") face-sad

Herausgefunden habe ich noch, dass die Users Gruppe unter Windows 7 auch mit der identischen SID (würde daraus schlussfolgern, dass dies unsere Well-known SID ist) existiert - nur unter den Namen Benutzer (wie du korrekter weise bereits geschrieben hast) - hier habe ich leider etwas zu früh den Strich gezogen.


MfG
WinWord
Mitglied: DerWoWusste
DerWoWusste 25.05.2016 um 14:54:21 Uhr
Goto Top
Hier geht es. Wenn Du diese Gruppen nicht siehst, ist irgendwas im Argen - hast Du den Suchpfad überhaupt auf lokal gestellt, oder auf Domäne? Beides müsste users kennen, wenn man danach suchen lässt.
Mitglied: WinWord
WinWord 25.05.2016, aktualisiert am 27.05.2016 um 07:15:03 Uhr
Goto Top
Hallo DerWoWusste,

gerade getestet und folgendes herausgefunden:
  • Users Lokal nicht gefunden
  • Users Domäne nicht gefunden
  • Benutzer Domäne nicht gefunden
  • Benutzer Lokal gefunden<!
benutzerfound

Wo befindet sich bei dir die Gruppe Users/Benutzer in der Domäne?


Mit freundlichen Grüßen
WinWord

*Edit01:
Rechtscheibfehler (Öokal => Lokal) korrigiert.
Mitglied: DerWoWusste
DerWoWusste 25.05.2016 um 15:17:52 Uhr
Goto Top
Benutzer (auch hier eine deutsche Domäne) befindet sich im Container "Builtin".
Mitglied: emeriks
emeriks 25.05.2016 um 18:30:41 Uhr
Goto Top
wenn du das als domäne\benutzer eingibst, dann kann als suchpfad stehen was will.

irgendwie ist mir so, als wenn das problem ganz woanders ist.
ist die zeit zwischen dem member und dem dc synchron?
ist der pdc-emulator verfügbar?
hat der member den korrekten dns-server eingetragen?
usw.
Mitglied: WinWord
WinWord 27.05.2016 aktualisiert um 07:47:37 Uhr
Goto Top
Hallo DerWoWusste,
Hallo emeriks,

@DerWoWusste:
hier die Bestätigung des generellen Vorhandenseins der Gruppe:
builtinusers

Interessanterweise lässt sich bei der Berechtigungsvergabe keine der Namen welche sich unter Builtin befinden auswählen.

@emeriks:
Hier stellt sich mir die Frage: sind WellKnown-SID = Domänenbenutzer?

Zeit zwischen Member und DC (DC = NTP-Zeitgeber) ist synchron. (Zeitverschiebung ca. 1 Min 12 Sekunden).
datetime
Zum Thema PDC-Emulator/FSMO-Rollen:
fsmo

Auch wurden gerade die DNS-Server-Eintragungen kontrolliert => Alle OK


Mit freundlichen Grüßen
WinWord

*Edit01:
Bild für FSMO-Rollen angepasst.
Zeitverschiebung hinzugefügt.
Mitglied: DerWoWusste
DerWoWusste 27.05.2016 um 09:04:23 Uhr
Goto Top
Dcdiag am DC machen.
Mitglied: WinWord
WinWord 27.05.2016 um 10:19:05 Uhr
Goto Top
Hallo DerWoWusste,

hier die ausführliche Antwort von dcdiag (ausgeführt am Client):
"
Verzeichnisserverdiagnose

Anfangssetup wird ausgefhrt:
        • Identifizierte AD-Gesamtstruktur.
        Sammeln der Ausgangsinformationen abgeschlossen.

        Erforderliche Anfangstests werden ausgefhrt.

        Server wird getestet: Default-First-Site-Name\DC
        Starting test: Connectivity
        ......................... DC hat den Test Connectivity
        bestanden.

        Prim„rtests werden ausgefhrt.

        Server wird getestet: Default-First-Site-Name\DC
        Starting test: Advertising
        ......................... DC hat den Test Advertising bestanden.
        Starting test: FrsEvent
        Das Ereignisprotokoll File Replication Service auf dem Server
        DC.DOMÄNE konnte nicht abgefragt werden.
        Fehler: 0x6ba "Der RPC-Server ist nicht verfgbar."
        ......................... DC hat den Test FrsEvent nicht
        bestanden.
        Starting test: DFSREvent
        ......................... DC hat den Test DFSREvent bestanden.
        Starting test: SysVolCheck
        ......................... DC hat den Test SysVolCheck bestanden.
        Starting test: KccEvent
        Das Ereignisprotokoll Directory Service auf dem Server
        DC.DOMÄNE konnte nicht abgefragt werden.
        Fehler: 0x6ba "Der RPC-Server ist nicht verfgbar."
        ......................... DC hat den Test KccEvent nicht
        bestanden.
        Starting test: KnowsOfRoleHolders
        ......................... DC hat den Test KnowsOfRoleHolders
        bestanden.
        Starting test: MachineAccount
        ......................... DC hat den Test MachineAccount
        bestanden.
        Starting test: NCSecDesc
        Fehler: NT-AUTORITŽT\DOMŽNENCONTROLLER DER ORGANISATION besitzt keine
        Replicating Directory Changes In Filtered Set
        Zugriffsrechte fr den Namenskontext:
        DC=ForestDnsZones,DC=DOMÄNE,DC=DOMÄNE,DC=DOMÄNE
        Fehler: NT-AUTORITŽT\DOMŽNENCONTROLLER DER ORGANISATION besitzt keine
        Replicating Directory Changes In Filtered Set
        Zugriffsrechte fr den Namenskontext:
        DC=DomainDnsZones,DC=DOMÄNE,DC=DOMÄNE,DC=DOMÄNE
        Fehler: NT-AUTORITŽT\DOMŽNENCONTROLLER DER ORGANISATION besitzt keine
        Replicating Directory Changes In Filtered Set
        Zugriffsrechte fr den Namenskontext:
        DC=DOMÄNE,DC=DOMÄNE,DC=DOMÄNE
        ......................... DC hat den Test NCSecDesc nicht
        bestanden.
        Starting test: NetLogons
        ......................... DC hat den Test NetLogons bestanden.
        Starting test: ObjectsReplicated
        ......................... DC hat den Test ObjectsReplicated
        bestanden.
        Starting test: Replications
        ......................... DC hat den Test Replications
        bestanden.
        Starting test: RidManager
        ......................... DC hat den Test RidManager bestanden.
        Starting test: Services
        ......................... DC hat den Test Services bestanden.
        Starting test: SystemLog
        Das Ereignisprotokoll System auf dem Server
        DC.DOMÄNE konnte nicht abgefragt werden.
        Fehler: 0x6ba "Der RPC-Server ist nicht verfgbar."
        ......................... DC hat den Test SystemLog nicht
        bestanden.
        Starting test: VerifyReferences
        ......................... DC hat den Test VerifyReferences
        bestanden.


        Partitionstests werden ausgefhrt auf: ForestDnsZones
        Starting test: CheckSDRefDom
        ......................... ForestDnsZones hat den Test CheckSDRefDom
        bestanden.
        Starting test: CrossRefValidation
        ......................... ForestDnsZones hat den Test
        CrossRefValidation bestanden.

        Partitionstests werden ausgefhrt auf: DomainDnsZones
        Starting test: CheckSDRefDom
        ......................... DomainDnsZones hat den Test CheckSDRefDom
        bestanden.
        Starting test: CrossRefValidation
        ......................... DomainDnsZones hat den Test
        CrossRefValidation bestanden.

        Partitionstests werden ausgefhrt auf: Schema
        Starting test: CheckSDRefDom
        ......................... Schema hat den Test CheckSDRefDom bestanden.
        Starting test: CrossRefValidation
        ......................... Schema hat den Test CrossRefValidation
        bestanden.

        Partitionstests werden ausgefhrt auf: Configuration
        Starting test: CheckSDRefDom
        ......................... Configuration hat den Test CheckSDRefDom
        bestanden.
        Starting test: CrossRefValidation
        ......................... Configuration hat den Test
        CrossRefValidation bestanden.

        Partitionstests werden ausgefhrt auf: DOMÄNE
        Starting test: CheckSDRefDom
        ......................... DOMÄNE hat den Test CheckSDRefDom
        bestanden.
        Starting test: CrossRefValidation
        ......................... DOMÄNE hat den Test CrossRefValidation
        bestanden.

        Unternehmenstests werden ausgefhrt auf: DOMÄNE
        Starting test: LocatorCheck
        ......................... DOMÄNE hat den Test
        LocatorCheck bestanden.
        Starting test: Intersite
        ......................... DOMÄNE hat den Test
        Intersite bestanden.
        "

        Um es mal auf die Fehler zu begrenzen:
        • 1.
        Starting test: FrsEvent
        Das Ereignisprotokoll File Replication Service auf dem Server
        DC.DOMÄNE konnte nicht abgefragt werden.
        Fehler: 0x6ba "Der RPC-Server ist nicht verfgbar."
        ......................... DC hat den Test FrsEvent nicht
        bestanden.
        • 2.
        Starting test: KccEvent
        Das Ereignisprotokoll Directory Service auf dem Server
        DC.DOMÄNE konnte nicht abgefragt werden.
        Fehler: 0x6ba "Der RPC-Server ist nicht verfgbar."
        ......................... DC hat den Test KccEvent nicht
        bestanden.
        • 3.
        Starting test: NCSecDesc
        Fehler: NT-AUTORITŽT\DOMŽNENCONTROLLER DER ORGANISATION besitzt keine
        Replicating Directory Changes In Filtered Set
        Zugriffsrechte fr den Namenskontext:
        DC=ForestDnsZones,DC=DOMÄNE,DC=DOMÄNE,DC=DOMÄNE
        Fehler: NT-AUTORITŽT\DOMŽNENCONTROLLER DER ORGANISATION besitzt keine
        Replicating Directory Changes In Filtered Set
        Zugriffsrechte fr den Namenskontext:
        DC=DomainDnsZones,DC=DOMÄNE,DC=DOMÄNE,DC=DOMÄNE
        Fehler: NT-AUTORITŽT\DOMŽNENCONTROLLER DER ORGANISATION besitzt keine
        Replicating Directory Changes In Filtered Set
        Zugriffsrechte fr den Namenskontext:
        DC=DOMÄNE,DC=DOMÄNE,DC=DOMÄNE
        ......................... DC hat den Test NCSecDesc nicht
        bestanden.
        • 4.
        Starting test: SystemLog
        Das Ereignisprotokoll System auf dem Server
        DC.DOMÄNE konnte nicht abgefragt werden.
        Fehler: 0x6ba "Der RPC-Server ist nicht verfgbar."
        ......................... DC hat den Test SystemLog nicht
        bestanden.

        1. 2. und 4. sind nicht relevante Fehlermeldungen.
        3. könnte im ersten Moment schon interessanter werden, ist aber nach durchlesen von http://ex201.de/faq/index.php?action=artikel&cat=6&id=154&a ... wieder hinfällig(?).


        MfG
        WinWord
Mitglied: DerWoWusste
DerWoWusste 27.05.2016 aktualisiert um 10:30:18 Uhr
Goto Top
Alllsoo.
Bevor dass zu einem Mammutthread mutiert (ist es bereits, ok...), lass uns mal den Ball flach halten. Nimm ein Startskript, welches mit icacls die Berechtigungen setzt und fertig. Wenn Du noch die ganzen Probleme mit nicht vorhandenen Gruppen und "RPC-Server nicht verfügbar" hier angehen willst, sind wir vermutlich noch nächste Woche dabei. Ich gebe ungern auf, aber es kostet auch zum Helfen zuviel Zeit.

PS: "ausgeführt am Client" sehe ich gerade. Das solltest Du doch am DC ausführen.
Mitglied: WinWord
WinWord 27.05.2016 aktualisiert um 11:16:08 Uhr
Goto Top
Hallo DerWoWusste,

zu deinem PS: Entschuldigung - hier nochmals beim DC-Server ausgeführt:
"
Verzeichnisserverdiagnose

Anfangssetup wird ausgefhrt:
Der Homeserver wird gesucht...
Homeserver = DOMÄNE
        • Identifizierte AD-Gesamtstruktur.
        Sammeln der Ausgangsinformationen abgeschlossen.

        Erforderliche Anfangstests werden ausgefhrt.

        Server wird getestet: Default-First-Site-Name\DOMÄNE
        Starting test: Connectivity
        ......................... DOMÄNE hat den Test Connectivity
        bestanden.

        Prim„rtests werden ausgefhrt.

        Server wird getestet: Default-First-Site-Name\DOMÄNE
        Starting test: Advertising
        ......................... DOMÄNE hat den Test Advertising bestanden.
        Starting test: FrsEvent
        ......................... DOMÄNE hat den Test FrsEvent bestanden.
        Starting test: DFSREvent
        ......................... DOMÄNE hat den Test DFSREvent bestanden.
        Starting test: SysVolCheck
        ......................... DOMÄNE hat den Test SysVolCheck bestanden.
        Starting test: KccEvent
        ......................... DOMÄNE hat den Test KccEvent bestanden.
        Starting test: KnowsOfRoleHolders
        ......................... DOMÄNE hat den Test KnowsOfRoleHolders
        bestanden.
        Starting test: MachineAccount
        ......................... DOMÄNE hat den Test MachineAccount
        bestanden.
        Starting test: NCSecDesc
        Fehler: NT-AUTORITŽT\DOMŽNENCONTROLLER DER ORGANISATION besitzt keine
        Replicating Directory Changes In Filtered Set
        Zugriffsrechte fr den Namenskontext:
        DC=DOMÄNE,DC=DOMÄNE,DC=DOMÄNE
        ......................... Der Test NCSecDesc fr DOMÄNE ist
        fehlgeschlagen.
        Starting test: NetLogons
        ......................... DOMÄNE hat den Test NetLogons bestanden.
        Starting test: ObjectsReplicated
        ......................... DOMÄNE hat den Test ObjectsReplicated
        bestanden.
        Starting test: Replications
        ......................... DOMÄNE hat den Test Replications
        bestanden.
        Starting test: RidManager
        ......................... DOMÄNE hat den Test RidManager bestanden.
        Starting test: Services
        ......................... DOMÄNE hat den Test Services bestanden.
        Starting test: SystemLog
        Warnung. Ereignis-ID: 0x0000043D
        Erstellungszeitpunkt: 05/27/2016 09:47:48
        Ereigniszeichenfolge:
        Fehler beim Anwenden der "Microsoft Disk Quota"-Einstellungen. Die "Microsoft Disk Quota"-Einstellungen besitzen m”glicherweise eine eigene Protokolldatei. Klicken Sie auf den Link "Weitere Informationen".
        Warnung. Ereignis-ID: 0x0000043D
        Erstellungszeitpunkt: 05/27/2016 09:58:49
        Ereigniszeichenfolge:
        Fehler beim Anwenden der "Microsoft Disk Quota"-Einstellungen. Die "Microsoft Disk Quota"-Einstellungen besitzen m”glicherweise eine eigene Protokolldatei. Klicken Sie auf den Link "Weitere Informationen".
        Warnung. Ereignis-ID: 0x0000043D
        Erstellungszeitpunkt: 05/27/2016 10:08:50
        Ereigniszeichenfolge:
        Fehler beim Anwenden der "Microsoft Disk Quota"-Einstellungen. Die "Microsoft Disk Quota"-Einstellungen besitzen m”glicherweise eine eigene Protokolldatei. Klicken Sie auf den Link "Weitere Informationen".
        Warnung. Ereignis-ID: 0x0000043D
        Erstellungszeitpunkt: 05/27/2016 10:19:51
        Ereigniszeichenfolge:
        Fehler beim Anwenden der "Microsoft Disk Quota"-Einstellungen. Die "Microsoft Disk Quota"-Einstellungen besitzen m”glicherweise eine eigene Protokolldatei. Klicken Sie auf den Link "Weitere Informationen".
        Warnung. Ereignis-ID: 0x0000043D
        Erstellungszeitpunkt: 05/27/2016 10:29:53
        Ereigniszeichenfolge:
        Fehler beim Anwenden der "Microsoft Disk Quota"-Einstellungen. Die "Microsoft Disk Quota"-Einstellungen besitzen m”glicherweise eine eigene Protokolldatei. Klicken Sie auf den Link "Weitere Informationen".
        Warnung. Ereignis-ID: 0x0000043D
        Erstellungszeitpunkt: 05/27/2016 10:39:54
        Ereigniszeichenfolge:
        Fehler beim Anwenden der "Microsoft Disk Quota"-Einstellungen. Die "Microsoft Disk Quota"-Einstellungen besitzen m”glicherweise eine eigene Protokolldatei. Klicken Sie auf den Link "Weitere Informationen".
        ......................... DOMÄNE hat den Test SystemLog bestanden.
        Starting test: VerifyReferences
        ......................... DOMÄNE hat den Test VerifyReferences
        bestanden.


        Partitionstests werden ausgefhrt auf: ForestDnsZones
        Starting test: CheckSDRefDom
        ......................... ForestDnsZones hat den Test CheckSDRefDom
        bestanden.
        Starting test: CrossRefValidation
        ......................... ForestDnsZones hat den Test
        CrossRefValidation bestanden.

        Partitionstests werden ausgefhrt auf: DomainDnsZones
        Starting test: CheckSDRefDom
        ......................... DomainDnsZones hat den Test CheckSDRefDom
        bestanden.
        Starting test: CrossRefValidation
        ......................... DomainDnsZones hat den Test
        CrossRefValidation bestanden.

        Partitionstests werden ausgefhrt auf: Schema
        Starting test: CheckSDRefDom
        ......................... Schema hat den Test CheckSDRefDom bestanden.
        Starting test: CrossRefValidation
        ......................... Schema hat den Test CrossRefValidation
        bestanden.

        Partitionstests werden ausgefhrt auf: Configuration
        Starting test: CheckSDRefDom
        ......................... Configuration hat den Test CheckSDRefDom
        bestanden.
        Starting test: CrossRefValidation
        ......................... Configuration hat den Test
        CrossRefValidation bestanden.

        Partitionstests werden ausgefhrt auf: DOMÄNE
        Starting test: CheckSDRefDom
        ......................... DOMÄNE hat den Test CheckSDRefDom
        bestanden.
        Starting test: CrossRefValidation
        ......................... DOMÄNE hat den Test CrossRefValidation
        bestanden.

        Unternehmenstests werden ausgefhrt auf: DOMÄNE.DOMÄNE.DOMÄNE
        Starting test: LocatorCheck
        ......................... DOMÄNE.DOMÄNE.DOMÄNE hat den Test
        LocatorCheck bestanden.
        Starting test: Intersite
        ......................... DOMÄNE.DOMÄNE.DOMÄNE hat den Test
        Intersite bestanden.
        "

        Um es erneut auf die Fehler zu begrenzen:
        • 1.
        Starting test: SystemLog
        Warnung. Ereignis-ID: 0x0000043D
        Erstellungszeitpunkt: 05/27/2016 09:47:48
        Ereigniszeichenfolge:
        Fehler beim Anwenden der "Microsoft Disk Quota"-Einstellungen. Die "Microsoft Disk Quota"-Einstellungen besitzen m”glicherweise eine eigene Protokolldatei. Klicken Sie auf den Link "Weitere Informationen".
        Warnung. Ereignis-ID: 0x0000043D
        Erstellungszeitpunkt: 05/27/2016 09:58:49
        Ereigniszeichenfolge:
        Fehler beim Anwenden der "Microsoft Disk Quota"-Einstellungen. Die "Microsoft Disk Quota"-Einstellungen besitzen m”glicherweise eine eigene Protokolldatei. Klicken Sie auf den Link "Weitere Informationen".
        Warnung. Ereignis-ID: 0x0000043D
        Erstellungszeitpunkt: 05/27/2016 10:08:50
        Ereigniszeichenfolge:
        Fehler beim Anwenden der "Microsoft Disk Quota"-Einstellungen. Die "Microsoft Disk Quota"-Einstellungen besitzen m”glicherweise eine eigene Protokolldatei. Klicken Sie auf den Link "Weitere Informationen".
        Warnung. Ereignis-ID: 0x0000043D
        Erstellungszeitpunkt: 05/27/2016 10:19:51
        Ereigniszeichenfolge:
        Fehler beim Anwenden der "Microsoft Disk Quota"-Einstellungen. Die "Microsoft Disk Quota"-Einstellungen besitzen m”glicherweise eine eigene Protokolldatei. Klicken Sie auf den Link "Weitere Informationen".
        Warnung. Ereignis-ID: 0x0000043D
        Erstellungszeitpunkt: 05/27/2016 10:29:53
        Ereigniszeichenfolge:
        Fehler beim Anwenden der "Microsoft Disk Quota"-Einstellungen. Die "Microsoft Disk Quota"-Einstellungen besitzen m”glicherweise eine eigene Protokolldatei. Klicken Sie auf den Link "Weitere Informationen".
        Warnung. Ereignis-ID: 0x0000043D
        Erstellungszeitpunkt: 05/27/2016 10:39:54
        Ereigniszeichenfolge:
        Fehler beim Anwenden der "Microsoft Disk Quota"-Einstellungen. Die "Microsoft Disk Quota"-Einstellungen besitzen m”glicherweise eine eigene Protokolldatei. Klicken Sie auf den Link "Weitere Informationen".
        ......................... DOMÄNE hat den Test SystemLog bestanden.
        (Schlussendlich bestanden)
        • 2.
        Starting test: NCSecDesc
        Fehler: NT-AUTORITŽT\DOMŽNENCONTROLLER DER ORGANISATION besitzt keine
        Replicating Directory Changes In Filtered Set
        Zugriffsrechte fr den Namenskontext:
        DC=DOMÄNE,DC=DOMÄNE,DC=DOMÄNE
        ......................... Der Test NCSecDesc fr DOMÄNE ist
        fehlgeschlagen.
        Hier befindet sich schlussendlich der einzige Fehler.

        Ich muss mich bis jetzt schon x-fach für eure in den Fehler gesteckte Zeit bedanken!
        Es ist ein wahnsinnig gutes und schnell reagierendes Forum welches von Leute wir euch am Leben erhalten wird! face-smile

        Da es allerseits doch eine deutliche Zeitinvestition ist, erkundige ich mich noch weiters um den Fehler, es sieht aber sehr danach aus, als wäre die sinnvollste Lösung immer noch die, die passenden AD-User dediziert hinzuzufügen (was bekanntlicherweise ja funktioniert).


        Mit freundlichen Grüßen
        WinWord

        *Edit01:
        Unnötige Zeile gelöscht
Mitglied: emeriks
emeriks 27.05.2016 um 19:57:48 Uhr
Goto Top
Hier stellt sich mir die Frage: sind WellKnown-SID = Domänenbenutzer?
Was eine Wellknown SID ist, das findest Du bei Googel.
Die "Domänen-Benutzer" haben keine Wellknown SID, aber die "domäne\Benutzer" bzw. "domain\Users".

Ich sehe es wie DWW: Wenn er nicht mal auf der Kommandozeile die NTLM-Namen korrekt auflösen kann, egal mit welchem Tool, dann ist DAS Dein Problem.

Könnte es sein, dass diese ganzen Embedded WinXP Installationen von einem Image stammen, dadurch dieselbe lokale SID haben?

Bzgl: Zeit
Der Bezug zum NTP-Server ist irrelevant. Der Zeitunterschied zwischen Client (Embedded WinXP) und dem/die DC ist der Punkt. Bei den Embedds könnte ich mir vorstellen, dass die von Werk aus in einer anderen Zeitzone sind, als "Berlin" (oder wie auch immer Deine Zeitzone ist). Wenn dann trotzdem Client und Server dieselbe Uhrzeit anzeigen, dann sind sie tatsächlich 1 oder mehrerer Stunden auseinander. Und dann funktioniert die Authentfizierung am Kerberos nicht mehr und einiges anderes, davon abhängiges auch nicht mehr. z.B. Auflösung von Gruppennamen oder SID über die Domäne.
Mitglied: WinWord
WinWord 30.05.2016 um 07:44:34 Uhr
Goto Top
Hallo emeriks,

was eine WellKnown-SID ist habe ich soweit verstanden - es war mehr so gemeint, ob eine WellKnown-SID in die Berechtigungsstufe wie ein AD-Object eingetragen werden kann, diese Frage hat sich erübrigt.

So wie ich es herauslese, befindet sich deiner Meinung nach der Fehler bei de NTLM? Diese Authentifizierungs-Methode ist doch, seit Kerberos, nur noch nur noch als Fall-Back-Methode einzustufen, oder irre ich?

Wie der Hersteller bei seinen Messgeräten genau verfährt ist eine gute Frage, allerdings wäre dies im Bereich des sinnvoll Möglichen hier ein Image zu verwenden und dieses über alle einfach auszurollen (ich denke von dem Fall können wir ausgehen).

  • Zeit
Wir haben vor kurzem (unabhänig von Thread-Problem) herausgefunden, dass einige der Geräte auf eine andere Zeitzone als "Berlin" gestellt sind - hier liegst du richtig, bei dem betreffenden Test-Windows wurde dies aber bereits korrigiert.
Nichtsdestotrotz würde Kerberos Version 5 eine Zeitdifferenz von bis zu 5 Minuten (Quelle: https://support.microsoft.com/de-at/kb/956627, "Der Standardwert für die Einstellung maximale Toleranz für Computer Uhr Synchronisierung ist fünf Minuten.") erlauben - unter diesen Wert befinden wir uns deutlich.


MfG
WinWord
Mitglied: emeriks
emeriks 30.05.2016 um 08:01:10 Uhr
Goto Top
So wie ich es herauslese, befindet sich deiner Meinung nach der Fehler bei de NTLM? Diese Authentifizierungs-Methode ist doch, seit Kerberos, nur noch nur noch als Fall-Back-Methode einzustufen, oder irre ich?
Hier geht es nicht um die Authentifizierung, sondern darum, dass er Namen nicht auflösen kann. Oder nicht?
Nichtsdestotrotz würde Kerberos Version 5 eine Zeitdifferenz von bis zu 5 Minuten (Quelle: https://support.microsoft.com/de-at/kb/956627, "Der Standardwert für die Einstellung maximale Toleranz für Computer Uhr Synchronisierung ist fünf Minuten.") erlauben - unter diesen Wert befinden wir uns deutlich.
Wenn Computer A in Zeitzone 1 ist und Computer B in Zeitzone 2 ist und beide die selbe Uhrzeit anzeigen, dann ist ihre Zeit bezogen auf UTC min. 0,5 h auseinander, i.A. aber 1 oder 2 h. Das hängt von den konkreten Zonen und der Anwendung der Sommerzeit ab.
Mitglied: WinWord
WinWord 30.05.2016 aktualisiert um 10:27:46 Uhr
Goto Top
Hallo emeriks,

es können nur die BuiltIn-User nicht aufgelöst werden, bei allen anderen Objekte ist diese Funktion fehlerfrei.
Wenn man folgenden Eintrag nachliest: https://social.technet.microsoft.com/Forums/de-DE/166879aa-fd6a-4e02-a12 ...
Überlegung: Von Domäne auf Lokalen PC umstellen => Es wird die WellKnown-SID im Hintergrund verwendet => Erledigt
lokalgroups
Werde mich erneut melden falls dies die Lösung gewesen ist face-smile
*Und es war so - Spiel Satz Sieg! Hier der Beweis:
lokalgroupsmessgeraet

Natürlich stimmt deine Aussage, dennoch wurde, wie bereits beschrieben, die Zeitzone auf "Berlin" angepasst => Das Anliegen ist nicht (mehr) relevant.

Möchte mich für die investierte Zeit von euch beiden recht herzlich bedanken. face-smile


Mit freundlichen Grüßen
WinWord

*Edit01:
Anbringung der Antwort