42
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:
Hat irgendwer einen Lösungsansatz?
Vielen Dank im Voraus
MfG
WinWord
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:
Hat irgendwer einen Lösungsansatz?
Vielen Dank im Voraus
MfG
WinWord
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: 305183
Url: https://administrator.de/contentid/305183
Ausgedruckt am: 25.11.2024 um 20:11 Uhr
42 Kommentare
Neuester Kommentar
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.
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.
Hallo emeriks,
erstmals vielen Dank für deine Hilfe
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:
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"
Natürlich kann ich nicht jeden PC einzeln auflisten.
MfG
WinWord
erstmals vielen Dank für deine Hilfe
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:
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"
MfG
WinWord
Hi.
AD-Gruppen, egal ob Global oder Lokal werden ignoriert
Was soll das bedeuten? Beschreibe mal genauer. Hier geht es.
Hallo DerWoWusste,
das ist ein interessantes Phänomen:
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
das ist ein interessantes Phänomen:
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
Du hast geschrieben
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?
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?
Und Du hast den Benutzer, nachdem Du ihn in die AD-Gruppe aufgenommen hast, auch neu angemeldet, damit diese Gruppemitgliedschaft überhaupt wirken kann?
Hallo emeriks,
falls ich das Problem zu undeutlich geschildert haben sollte tut es mir Leid.
Nochmal anders/kompakter formuliert:
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).
falls ich das Problem zu undeutlich geschildert haben sollte tut es mir Leid.
Nochmal anders/kompakter formuliert:
- Grundproblem
- Hintergrund
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).
Was heißt "nicht angenommen"? Landen die AD-Gruppen nicht in der ACL oder doch, aber die Berechtigungen wirken nicht?
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
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
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?
Falls nein: Wird die ACL an den betreffenden Ordner vererbt? Wie ist der Ordner freigegeben?
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
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
Die User melden sich also lokal am Embeded WinXP mit ihrem Domänenkonto an und müssen dann auf die betreffenden Ordner zugreifen?
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
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
OK. Und die Anmeldung dieser Benutzer lokal am Embeded WinXP funktioniert auch? (Ich frage nur der Vollständigkeit wegen.)
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
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
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".
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".
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?
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?
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.
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.
Hallo DerWoWusste,
auch das ist mir bewusst.
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:
Auch an das Verweigern wurde bereits gedacht, es sind aber keine Gruppen/Benutzer vorhanden welche gesperrt sind. (=> Alle nur auf erlauben)
MfG
WinWord
auch das ist mir bewusst.
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:
Auch an das Verweigern wurde bereits gedacht, es sind aber keine Gruppen/Benutzer vorhanden welche gesperrt sind. (=> Alle nur auf erlauben)
MfG
WinWord
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.
Wie sind denn die effektiven Berechtigungen - schau dort mal rein.
Hallo DerWoWusste,
ich bin komplett bei deinen Überlegungen- habe lange genug mit Berechtigungen zu tun gehabt.
Hier siehst du die Berechtigungen beim Messgerät:
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
ich bin komplett bei deinen Überlegungen- habe lange genug mit Berechtigungen zu tun gehabt.
Hier siehst du die Berechtigungen beim Messgerät:
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
Noch mal zu dem "kein Zugriff". Haben die Benutzer keinen Zugriff auf D:\ oder auf einen Unterordner von D: ?
Hallo emeriks,
auf den Zugriffsversuch auf D:\ folgt prompt folgende Fehlermeldung:
Es haben nur die (wie bereits erwähnt) Benutzer welche entweder
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
auf den Zugriffsversuch auf D:\ folgt prompt folgende Fehlermeldung:
- 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!)
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
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
Oder eben mit Startup-Scripten arbeiten.
Jou. Icacls kann das.
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:
Leider fehlt auch mir das Wissen eine SID in die Berechtigungen einzutragen 
Wenn dies möglich ist, wäre der Fall so wie wie als gelöst zu betrachten
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:
MfG
WinWord
vielen Dank für diese Info!
Habe promt darauf die SID (= S-1-5-32-545) ausgelesen und eine Übereinstimmung in deinem Link gefunden:
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:
MfG
WinWord
Keine SID eintragen, einfach Users/Benutzer (je nach Sprache Deines Systems, das die Policies schreibt)
Hallo DerWoWusste,
hier ist leider das identische "Namen-Nicht-Gefunden"-Phänomen (egal ob "Users" oder "Benutzer")
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
hier ist leider das identische "Namen-Nicht-Gefunden"-Phänomen (egal ob "Users" oder "Benutzer")
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
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.
Hallo DerWoWusste,
gerade getestet und folgendes herausgefunden:
Wo befindet sich bei dir die Gruppe Users/Benutzer in der Domäne?
Mit freundlichen Grüßen
WinWord
*Edit01:
Rechtscheibfehler (Öokal => Lokal) korrigiert.
gerade getestet und folgendes herausgefunden:
- Users Lokal nicht gefunden
- Users Domäne nicht gefunden
- Benutzer Domäne nicht gefunden
- Benutzer Lokal gefunden<!
Wo befindet sich bei dir die Gruppe Users/Benutzer in der Domäne?
Mit freundlichen Grüßen
WinWord
*Edit01:
Rechtscheibfehler (Öokal => Lokal) korrigiert.
Benutzer (auch hier eine deutsche Domäne) befindet sich im Container "Builtin".
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.
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.
Hallo DerWoWusste,
Hallo emeriks,
@DerWoWusste:
hier die Bestätigung des generellen Vorhandenseins der Gruppe:
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).
Zum Thema PDC-Emulator/FSMO-Rollen:
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.
Hallo emeriks,
@DerWoWusste:
hier die Bestätigung des generellen Vorhandenseins der Gruppe:
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).
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.
Dcdiag am DC machen.
Hallo DerWoWusste,
hier die ausführliche Antwort von dcdiag (ausgeführt am Client):
"
Verzeichnisserverdiagnose
Anfangssetup wird ausgefhrt:
hier die ausführliche Antwort von dcdiag (ausgeführt am Client):
"
Verzeichnisserverdiagnose
Anfangssetup wird ausgefhrt:
- Identifizierte AD-Gesamtstruktur.
- 1.
- 2.
- 3.
- 4.
Erforderliche Anfangstests werden ausgefhrt.
Server wird getestet: Default-First-Site-Name\DC
Starting test: Connectivity
......................... DC hat den Test Connectivity
bestanden.
Prim„rtests werden ausgefhrt.
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 verfgbar."
......................... 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 verfgbar."
......................... 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 fr 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 fr 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 fr 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 verfgbar."
......................... DC hat den Test SystemLog nicht
bestanden.
Starting test: VerifyReferences
......................... DC hat den Test VerifyReferences
bestanden.
Partitionstests werden ausgefhrt auf: ForestDnsZones
Starting test: CheckSDRefDom
......................... ForestDnsZones hat den Test CheckSDRefDom
bestanden.
Starting test: CrossRefValidation
......................... ForestDnsZones hat den Test
CrossRefValidation bestanden.
Partitionstests werden ausgefhrt auf: DomainDnsZones
Starting test: CheckSDRefDom
......................... DomainDnsZones hat den Test CheckSDRefDom
bestanden.
Starting test: CrossRefValidation
......................... DomainDnsZones hat den Test
CrossRefValidation bestanden.
Partitionstests werden ausgefhrt auf: Schema
Starting test: CheckSDRefDom
......................... Schema hat den Test CheckSDRefDom bestanden.
Starting test: CrossRefValidation
......................... Schema hat den Test CrossRefValidation
bestanden.
Partitionstests werden ausgefhrt auf: Configuration
Starting test: CheckSDRefDom
......................... Configuration hat den Test CheckSDRefDom
bestanden.
Starting test: CrossRefValidation
......................... Configuration hat den Test
CrossRefValidation bestanden.
Partitionstests werden ausgefhrt 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 ausgefhrt 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:
Das Ereignisprotokoll File Replication Service auf dem Server
DC.DOMÄNE konnte nicht abgefragt werden.
Fehler: 0x6ba "Der RPC-Server ist nicht verfgbar."
......................... DC hat den Test FrsEvent nicht
bestanden.
Das Ereignisprotokoll Directory Service auf dem Server
DC.DOMÄNE konnte nicht abgefragt werden.
Fehler: 0x6ba "Der RPC-Server ist nicht verfgbar."
......................... DC hat den Test KccEvent nicht
bestanden.
Fehler: NT-AUTORITŽT\DOMŽNENCONTROLLER DER ORGANISATION besitzt keine
Replicating Directory Changes In Filtered Set
Zugriffsrechte fr 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 fr 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 fr den Namenskontext:
DC=DOMÄNE,DC=DOMÄNE,DC=DOMÄNE
......................... DC hat den Test NCSecDesc nicht
bestanden.
Das Ereignisprotokoll System auf dem Server
DC.DOMÄNE konnte nicht abgefragt werden.
Fehler: 0x6ba "Der RPC-Server ist nicht verfgbar."
......................... 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
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.
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.
Hallo DerWoWusste,
zu deinem PS: Entschuldigung - hier nochmals beim DC-Server ausgeführt:
"
Verzeichnisserverdiagnose
Anfangssetup wird ausgefhrt:
Der Homeserver wird gesucht...
Homeserver = DOMÄNE
zu deinem PS: Entschuldigung - hier nochmals beim DC-Server ausgeführt:
"
Verzeichnisserverdiagnose
Anfangssetup wird ausgefhrt:
Der Homeserver wird gesucht...
Homeserver = DOMÄNE
- Identifizierte AD-Gesamtstruktur.
- 1.
- 2.
Erforderliche Anfangstests werden ausgefhrt.
Server wird getestet: Default-First-Site-Name\DOMÄNE
Starting test: Connectivity
......................... DOMÄNE hat den Test Connectivity
bestanden.
Prim„rtests werden ausgefhrt.
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 fr den Namenskontext:
DC=DOMÄNE,DC=DOMÄNE,DC=DOMÄNE
......................... Der Test NCSecDesc fr 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 ausgefhrt auf: ForestDnsZones
Starting test: CheckSDRefDom
......................... ForestDnsZones hat den Test CheckSDRefDom
bestanden.
Starting test: CrossRefValidation
......................... ForestDnsZones hat den Test
CrossRefValidation bestanden.
Partitionstests werden ausgefhrt auf: DomainDnsZones
Starting test: CheckSDRefDom
......................... DomainDnsZones hat den Test CheckSDRefDom
bestanden.
Starting test: CrossRefValidation
......................... DomainDnsZones hat den Test
CrossRefValidation bestanden.
Partitionstests werden ausgefhrt auf: Schema
Starting test: CheckSDRefDom
......................... Schema hat den Test CheckSDRefDom bestanden.
Starting test: CrossRefValidation
......................... Schema hat den Test CrossRefValidation
bestanden.
Partitionstests werden ausgefhrt auf: Configuration
Starting test: CheckSDRefDom
......................... Configuration hat den Test CheckSDRefDom
bestanden.
Starting test: CrossRefValidation
......................... Configuration hat den Test
CrossRefValidation bestanden.
Partitionstests werden ausgefhrt 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 ausgefhrt 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:
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)
Fehler: NT-AUTORITŽT\DOMŽNENCONTROLLER DER ORGANISATION besitzt keine
Replicating Directory Changes In Filtered Set
Zugriffsrechte fr den Namenskontext:
DC=DOMÄNE,DC=DOMÄNE,DC=DOMÄNE
......................... Der Test NCSecDesc fr 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!
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
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.
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).
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
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
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
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.
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
Werde mich erneut melden falls dies die Lösung gewesen ist
*Und es war so - Spiel Satz Sieg! Hier der Beweis:
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.
Mit freundlichen Grüßen
WinWord
*Edit01:
Anbringung der Antwort
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
*Und es war so - Spiel Satz Sieg! Hier der Beweis:
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.
Mit freundlichen Grüßen
WinWord
*Edit01:
Anbringung der Antwort
