23
2003 Domäne - Keine lokalen Rechte für Domänen-Benutzer
Hallo liebe administrator.de-Gemeinde,
Folgendes Szenario:
Windows Server 2003 Domäne mit Windows 2000 Clients (SP4)
Die Domäne wurde komplett neu aufgesetzt und es sind keine Gruppenrichtlinien vorhanden.
Probleme:
- Domänen-Benutzer können von diversen Anwendungen aus nicht drucken, z.B. Adobe Reader (9.4.0 als auch 9.3.4) oder spezielle für unser Aufgabengebiet entwickelte Software
Das Drucken von Office aus funktioniert dahingegen einwandfrei, von daher kann es kein Rechteproblem in Bezug auf die Drucker selbst sein. Zudem tritt das Problem bei allen Druckern auf, nicht nur bei einem. Administratoren können dahingegen einwandfrei drucken, auf jedem Drucker, von überall aus.
- Domänen-Benutzer haben keine Rechte lokale Dateien wie z.B. xcopy oder wscript.exe auszuführen. Das liegt wohl an den Sicherheitseinstellungen der Dateien selbst. Allerdings hatten wir vor 2 Wochen noch eine 2000er Domäne und da hat das einwandfrei funktioniert. In den Sicherheitseinstellungen der lokalen Dateien sind nur Administratoren und SYSTEM mit Vollzugriff eingetragen. An diesen Einstellungen wurde seit der Umstellung auf die neue Domäne nichts geändert.
Ich vermute, dass es sich um ein Problem mit den Sicherheitseinstellungen handelt und ich denke auch, dass die beiden Probleme zusammenhängen.
Eventuell hat jemand von euch eine Idee, wie wir dieses Problem beseitigen könnten.
mfg
Freeze2404
Windows Server 2003 Domäne mit Windows 2000 Clients (SP4)
Die Domäne wurde komplett neu aufgesetzt und es sind keine Gruppenrichtlinien vorhanden.
Probleme:
- Domänen-Benutzer können von diversen Anwendungen aus nicht drucken, z.B. Adobe Reader (9.4.0 als auch 9.3.4) oder spezielle für unser Aufgabengebiet entwickelte Software
Das Drucken von Office aus funktioniert dahingegen einwandfrei, von daher kann es kein Rechteproblem in Bezug auf die Drucker selbst sein. Zudem tritt das Problem bei allen Druckern auf, nicht nur bei einem. Administratoren können dahingegen einwandfrei drucken, auf jedem Drucker, von überall aus.
- Domänen-Benutzer haben keine Rechte lokale Dateien wie z.B. xcopy oder wscript.exe auszuführen. Das liegt wohl an den Sicherheitseinstellungen der Dateien selbst. Allerdings hatten wir vor 2 Wochen noch eine 2000er Domäne und da hat das einwandfrei funktioniert. In den Sicherheitseinstellungen der lokalen Dateien sind nur Administratoren und SYSTEM mit Vollzugriff eingetragen. An diesen Einstellungen wurde seit der Umstellung auf die neue Domäne nichts geändert.
Ich vermute, dass es sich um ein Problem mit den Sicherheitseinstellungen handelt und ich denke auch, dass die beiden Probleme zusammenhängen.
Eventuell hat jemand von euch eine Idee, wie wir dieses Problem beseitigen könnten.
mfg
Freeze2404
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 154321
Url: https://administrator.de/contentid/154321
Printed on: April 26, 2024 at 03:04 o'clock
23 Comments
Latest comment
Hallo Freeze2404,
Bei 2000 weiß ich das nicht mehr so genau was da drinne war aber bei XP ist auf C: standardmäßig die Gruppe "jeder" mit lesen und ausführen drin.
Gruß ganymed
- Domänen-Benutzer haben keine Rechte lokale Dateien wie z.B. xcopy oder wscript.exe auszuführen.
Das sieht mir sehr komisch aus die sollten wenigstens Dateien lesen und ausführen können.Bei 2000 weiß ich das nicht mehr so genau was da drinne war aber bei XP ist auf C: standardmäßig die Gruppe "jeder" mit lesen und ausführen drin.
Gruß ganymed
Hallo,
danke für die Antwort.
Es liegt tatsächlich an den unzureichenden Rechten (bzgl. beider Probleme).
Ich frage mich nur, wie es dann vor der Umstellung auf die 2003er Domäne funktioniert haben kann.
An den Sicherheitseinstellungen der lokalen Dateien hat sich ja nichts geändert.
Gibt es hier irgendeine Gruppenrichtlinie o.ä., über die man das konfigurieren kann?
mfg
Freeze2404
danke für die Antwort.
Es liegt tatsächlich an den unzureichenden Rechten (bzgl. beider Probleme).
Ich frage mich nur, wie es dann vor der Umstellung auf die 2003er Domäne funktioniert haben kann.
An den Sicherheitseinstellungen der lokalen Dateien hat sich ja nichts geändert.
Gibt es hier irgendeine Gruppenrichtlinie o.ä., über die man das konfigurieren kann?
mfg
Freeze2404
Gruppenrichtlinien wirken nur auf Benutzer und Computerobjekte im Active Directory
Bei dir geht es aber um die NTFS Berechtigungen auf dem localen Systemlaufwerk ( meist C: )
Daher würde ich sagen nein. Man möge mich belehren wenn ich falsch liege.
Um dir die Arbeit etwas zu erleichtern schau dir mal den Befehl SECEDIT für die Konsole an.
http://www.gruppenrichtlinien.de/index.html?/sec/secedit_in_der_CMD.htm zeigt wie man damit das System auf die Default NTFS Berechtigungen zurücksetzen kann.
Kannst du ja mal testen und hier das Ergebnis schildern.
Ich selbst habe das noch nie gemacht und auch hier gilt wenn jemand eine bessere Lösung kennt bitte teilt euer Wissen.
Hast du denn schon mal jeder auf einem Rechner zu den Berechtigungen von C: hinzugefügt?
Funktioniert es?
Gruß ganymed
Bei dir geht es aber um die NTFS Berechtigungen auf dem localen Systemlaufwerk ( meist C: )
Daher würde ich sagen nein. Man möge mich belehren wenn ich falsch liege.
Um dir die Arbeit etwas zu erleichtern schau dir mal den Befehl SECEDIT für die Konsole an.
http://www.gruppenrichtlinien.de/index.html?/sec/secedit_in_der_CMD.htm zeigt wie man damit das System auf die Default NTFS Berechtigungen zurücksetzen kann.
Kannst du ja mal testen und hier das Ergebnis schildern.
Ich selbst habe das noch nie gemacht und auch hier gilt wenn jemand eine bessere Lösung kennt bitte teilt euer Wissen.
Hast du denn schon mal jeder auf einem Rechner zu den Berechtigungen von C: hinzugefügt?
Funktioniert es?
Gruß ganymed
Hallo,
wenn ich die Sicherheitseinstellungen manuell setze (also für Authentifizierte Benutzer das Ändern+Lesen erlaube) funktioniert alles einwandfrei.
Nun gibt es ja die Möglichkeit die Einstellungen mittels subinacl zu setzen.
Allerdings setzt subinacl die Sicherheitseinstellungen für jede Datei und jeden Ordner einzeln anstatt die Einstellungen zu vererben (am besten vom Wurzelverzeichnis C: aus).
Nun habe ich es wie von ganymed empfohlen mittels secedit versucht.
Secedit setzt die NTFS Berechtigungen allerdings nicht auf einen Standard zurück, der für Domänen nutzbar ist.
Als berechtigte User werden nämlich nach einem Ausführen des secedits die lokalen Konten "Benutzer" und "Hauptbenutzer" eingetragen.
In einer Domäne kann das allerdings nicht funktionieren.
Hier müsste "Authentifizierte Benutzer" in den Richtlinien stehen.
Wie kann ich dies bewerkstelligen?
mfg
Freeze2404
wenn ich die Sicherheitseinstellungen manuell setze (also für Authentifizierte Benutzer das Ändern+Lesen erlaube) funktioniert alles einwandfrei.
Nun gibt es ja die Möglichkeit die Einstellungen mittels subinacl zu setzen.
Allerdings setzt subinacl die Sicherheitseinstellungen für jede Datei und jeden Ordner einzeln anstatt die Einstellungen zu vererben (am besten vom Wurzelverzeichnis C: aus).
Nun habe ich es wie von ganymed empfohlen mittels secedit versucht.
Secedit setzt die NTFS Berechtigungen allerdings nicht auf einen Standard zurück, der für Domänen nutzbar ist.
Als berechtigte User werden nämlich nach einem Ausführen des secedits die lokalen Konten "Benutzer" und "Hauptbenutzer" eingetragen.
In einer Domäne kann das allerdings nicht funktionieren.
Hier müsste "Authentifizierte Benutzer" in den Richtlinien stehen.
Wie kann ich dies bewerkstelligen?
mfg
Freeze2404
Das funktioniert durchaus.
Denn "Benutzer" und "Hauptbenutzer" und auch "Administratoren" sind keine Konten sondern Gruppen.
Wenn du einen Rechner zu einer Domain hinzufügst passiert im Normalfall folgendes.
Zu deiner lokalen Gruppe "Benutzer" wird die Domain Gruppe "DeineDomain\Domain-Benutzer" hinzugefügt.
Bei der lokalen Gruppe "Hauptbenutzer" nichts.
Bei der lokalen Gruppe "Administratoren" wird die Domain Gruppe "DeineDomain\Domain-Administratoren" hinzugefügt.
Versuche mal Rechner raus aus der Domain in eine Arbeitsgruppe und dann wieder in die Domain aufnehmen.
Das ist zwar umständlich, aber da bei dir einiges schief gegangen ist vieleicht der sicherste Weg.
Ansonsten einfach die entsprechenden Domaingruppen zu den lokalen hinzufügen.
"Authentifizierte Benutzer" ist etwas was du wahrscheinlich nicht brauchen wirst, Denn in deiner Domain sind alle erst mal Domain-Benutzer.
Welche Nutzer allerdings zur Gruppe "Authentifizierte Benutzer" zählen weiß ich auch nicht so genau.
Pauschal würde ich sagen alle die eine Benutzerkennung haben die das System überprüfen kann, egal ob Domain oder nicht ( Google weiß da sicher mehr)
Im übrigen solltest du es vermeiden Benutzer zu Hauptbenutzern zu machen, denn jeder Hauptbenutzer kann sich sehr einfach zum localen Admin machen.
Gruß ganymed
Du Papa! Wie habt ihr eigentlich gegoogelt als es noch kein Internet gab?
Denn "Benutzer" und "Hauptbenutzer" und auch "Administratoren" sind keine Konten sondern Gruppen.
Wenn du einen Rechner zu einer Domain hinzufügst passiert im Normalfall folgendes.
Zu deiner lokalen Gruppe "Benutzer" wird die Domain Gruppe "DeineDomain\Domain-Benutzer" hinzugefügt.
Bei der lokalen Gruppe "Hauptbenutzer" nichts.
Bei der lokalen Gruppe "Administratoren" wird die Domain Gruppe "DeineDomain\Domain-Administratoren" hinzugefügt.
Versuche mal Rechner raus aus der Domain in eine Arbeitsgruppe und dann wieder in die Domain aufnehmen.
Das ist zwar umständlich, aber da bei dir einiges schief gegangen ist vieleicht der sicherste Weg.
Ansonsten einfach die entsprechenden Domaingruppen zu den lokalen hinzufügen.
"Authentifizierte Benutzer" ist etwas was du wahrscheinlich nicht brauchen wirst, Denn in deiner Domain sind alle erst mal Domain-Benutzer.
Welche Nutzer allerdings zur Gruppe "Authentifizierte Benutzer" zählen weiß ich auch nicht so genau.
Pauschal würde ich sagen alle die eine Benutzerkennung haben die das System überprüfen kann, egal ob Domain oder nicht ( Google weiß da sicher mehr)
Im übrigen solltest du es vermeiden Benutzer zu Hauptbenutzern zu machen, denn jeder Hauptbenutzer kann sich sehr einfach zum localen Admin machen.
Gruß ganymed
Du Papa! Wie habt ihr eigentlich gegoogelt als es noch kein Internet gab?
Ah, danke für die Erklärung.
Da liegt wohl das Übel begraben.
Auf den Clients befindet sich in der lokalen Gruppe Benutzer nur "Authentifizierte Benutzer" und "INTERAKTIV".
Jetzt müsste ich also nur einen Weg finden, um per Skript die Gruppe Domänen-Benutzer jeweils in die lokale Gruppe Benutzer hinzuzufügen.
/e:
Kommando zurück!
Auf meinem Test-Rechner ist die Gruppe Domänen-Benutzer bereits in die lokale Gruppe Benutzer eingetragen.
Aber wenn ich mich als normaler Domänen-Benutzer an dem Rechner anmelde, funktioniert garnichts mehr.
Es wird nicht mal die explorer-Shell geladen. Nach dem Laden der benutzerdefinierten Einstellungen bleibt er einfach stehen.
Das ist erst der Fall seitdem ich das secedit drüberlaufen lassen habe und somit alle NTFS Settings zurückgesetzt wurden.
Da liegt wohl das Übel begraben.
Auf den Clients befindet sich in der lokalen Gruppe Benutzer nur "Authentifizierte Benutzer" und "INTERAKTIV".
Jetzt müsste ich also nur einen Weg finden, um per Skript die Gruppe Domänen-Benutzer jeweils in die lokale Gruppe Benutzer hinzuzufügen.
/e:
Kommando zurück!
Auf meinem Test-Rechner ist die Gruppe Domänen-Benutzer bereits in die lokale Gruppe Benutzer eingetragen.
Aber wenn ich mich als normaler Domänen-Benutzer an dem Rechner anmelde, funktioniert garnichts mehr.
Es wird nicht mal die explorer-Shell geladen. Nach dem Laden der benutzerdefinierten Einstellungen bleibt er einfach stehen.
Das ist erst der Fall seitdem ich das secedit drüberlaufen lassen habe und somit alle NTFS Settings zurückgesetzt wurden.
Gut das das nur der Testrechner war.
Für das hinzufügen der Berechtigung hätte ich noch einen Tip gehabt Der Befehl lautet "net localgroup Benutzer MeineDom\Domain-Benutzer /add".
Aber warum jetzt nichts mehr geht, da bin ich überfragt.
Funktioniert denn wenigstens was als Admin?
Lass dir doch mal anzeigen welche GPO's für deinen Benutzer auf dem Testrechner greifen. Evtl. findet sich da ja was.
Gruß ganymed
Du Papa! Wie habt ihr eigentlich gegoogelt als es noch kein Internet gab?
Für das hinzufügen der Berechtigung hätte ich noch einen Tip gehabt Der Befehl lautet "net localgroup Benutzer MeineDom\Domain-Benutzer /add".
Aber warum jetzt nichts mehr geht, da bin ich überfragt.
Funktioniert denn wenigstens was als Admin?
Lass dir doch mal anzeigen welche GPO's für deinen Benutzer auf dem Testrechner greifen. Evtl. findet sich da ja was.
Gruß ganymed
Du Papa! Wie habt ihr eigentlich gegoogelt als es noch kein Internet gab?
Als Admin funktioniert alles einwandfrei.
Der steht ja auch in den NTFS Settings drin.
Mein Testuser ist Mitglied von Domänen-Benutzer, Jeder, Benutzer (lokal), INTERAKTIV (lokal), Authentifizierte Benutzer (lokal) und LOKAL.
Also ist er ja eigentlich in der Gruppe Benutzer drin.
Stellt sich die Frage, warum nach dem secedit nichts mehr geht.
Hab übrigens die defltwk.inf benutzt. Sollte doch die Richtige sein?
Der steht ja auch in den NTFS Settings drin.
Mein Testuser ist Mitglied von Domänen-Benutzer, Jeder, Benutzer (lokal), INTERAKTIV (lokal), Authentifizierte Benutzer (lokal) und LOKAL.
Also ist er ja eigentlich in der Gruppe Benutzer drin.
Stellt sich die Frage, warum nach dem secedit nichts mehr geht.
Hab übrigens die defltwk.inf benutzt. Sollte doch die Richtige sein?
Mein Testuser ist Mitglied von Domänen-Benutzer, Jeder, Benutzer (lokal), INTERAKTIV (lokal), Authentifizierte Benutzer (lokal) und LOKAL.
Ein Benutzer, der lokal angemeldet ist, ist temporär Mitglied in den Gruppen Interaktiv und Lokal.
Lass dir auch mal die efektiven Berechtigungen für deinen Benutzer anzeigen.
Hab übrigens die defltwk.inf benutzt. Sollte doch die Richtige sein?
Gruß ganymed
Wo kannst du das sehen?
In der cmd mit dem Befehl gpresult.
Mein Testuser ist ganz normaler Domänen-Benutzer. Dementsprechend bin ich mit dem auch nicht lokal angemeldet, sondern über die Domäne.
Lass dir auch mal die efektiven Berechtigungen für deinen Benutzer anzeigen.
Wie mache ich das?
So, neuer Sachstand.
Ich hab jetzt zu den Berechtigungen der lokalen Dateien per cacls die Gruppe Authentifizierte Benutzer hinzugefügt.
Jetzt funktioniert zumindest das Drucken aus unserer speziellen Software heraus wieder.
Der Adobe Reader mag aber immernoch nicht.
Dort kommt zuerst "Dokument kann nicht gedruckt werden" und dann "Keine zum Drucken ausgewählten Seiten vorhanden".
Dies hängt aber wohl nicht vom Drucker ab, sondern vom Benutzer.
Ich habe Nutzer, die können auf 2 von 2 Druckern nicht drucken, aufgrund oben genannter Fehlermeldung.
Bei einem anderen Nutzer funktionierts auf einem Drucker problemlos und auf dem anderen nicht.
Die beiden Benutzer sind beide nur in der Gruppe Domänen-Benutzer, sonst garnichts.
Domänen-Admins können auf jedem Drucker von jedem Rechner aus einwandfrei drucken.
Woran mags liegen?
Ich hab jetzt zu den Berechtigungen der lokalen Dateien per cacls die Gruppe Authentifizierte Benutzer hinzugefügt.
Jetzt funktioniert zumindest das Drucken aus unserer speziellen Software heraus wieder.
Der Adobe Reader mag aber immernoch nicht.
Dort kommt zuerst "Dokument kann nicht gedruckt werden" und dann "Keine zum Drucken ausgewählten Seiten vorhanden".
Dies hängt aber wohl nicht vom Drucker ab, sondern vom Benutzer.
Ich habe Nutzer, die können auf 2 von 2 Druckern nicht drucken, aufgrund oben genannter Fehlermeldung.
Bei einem anderen Nutzer funktionierts auf einem Drucker problemlos und auf dem anderen nicht.
Die beiden Benutzer sind beide nur in der Gruppe Domänen-Benutzer, sonst garnichts.
Domänen-Admins können auf jedem Drucker von jedem Rechner aus einwandfrei drucken.
Woran mags liegen?
Wie mache ich das?
Rechtsklick -> Eigenschaften -> Registerkarte Sicherheit -> Erweitert -> Registerkarte Effektive Berechtigungen.
Dort den entsprechenden User auswählen und du siehst was für berechtigungen er hat.
Es kann natürlich noch sein, dass die Berechtigungen nicht komplett auf alle Unterordner durchvererbt werden.
Hast du schon mal nachgeschaut welche Berechtigungen auf dem Drucker eingestellt sind.
Auf einem Drucker hat normalerweise die Gruppe jeder das Recht drucken.
Auf einem Drucker hat normalerweise die Gruppe jeder das Recht drucken.
Die Berechtigungen der Drucker sind richtig eingestellt.
Zumal es ja beim einen User geht und beim anderen nicht, obwohl beide nur Domänen-Benutzer sind und sonst nichts.
Rechtsklick worauf?
Zumal es ja beim einen User geht und beim anderen nicht, obwohl beide nur Domänen-Benutzer sind und sonst nichts.
Rechtsklick -> Eigenschaften -> Registerkarte Sicherheit -> Erweitert -> Registerkarte Effektive Berechtigungen
Rechtsklick worauf?
Rechtsklick worauf?
Auf eine Datei, ein Verzeichnis oder Laufwerk.
Um die NTFS Berechtigungen anzuzeigen.
PS: Der beschriebene Weg ( Rechtsklick->... ) ist von XP müsste bei deinen 2000 Clients aber genauso sein.
Unter 2000 gibt es dort keinen Reiter namens Effektive Berechtigungen, sondern nur Berechtigungen.
Ich weiß auch nicht so ganz worauf du hinaus willst.
Habe dem Authentifizierten Benutzer nun Lese+Schreibrechte auf dem kompletten C-Laufwerk gegeben.
Bei dem einen User funktionierts jetzt problemlos und beim anderen immernoch nicht.
Ich bin weiterhin am eroieren.
Ich weiß auch nicht so ganz worauf du hinaus willst.
Habe dem Authentifizierten Benutzer nun Lese+Schreibrechte auf dem kompletten C-Laufwerk gegeben.
Bei dem einen User funktionierts jetzt problemlos und beim anderen immernoch nicht.
Ich bin weiterhin am eroieren.
Ich weiß auch nicht so ganz worauf du hinaus willst.
http://www.hasslinger.com/microsoft/sites/server/dotnet/grund/effektive ...Damit du mal siehst ob es einen Unterschied in den Berechtigungen gibt und wenn ja welchen.
Also gut da das bei 2000 scheinbar nicht funktioniert ( bei XP habe ich diese Registerkarte ) hilft vieleicht eine andere Herangehensweise.
Per Ausschlussverfahren die Ursache eingrenzen.
Sind deine Drucker lokale. oder Netzwerkdrucker?
Bei lokalem Drucker teste bitte mal folgendes.
Richte einen lokalen Benutzer ein. Nur anlegen nicht noch nachträglich irgendwelchen Gruppen hinzufügen, damit du einen sauberen Standardbenutzer bekommst.
Kannst du mit dem dann Drucken ist das Problem in Richtung Domainbenutzer zu suchen, wenn nicht in Richtung Rechner also deine Vermutung NTFS Berechtigungen.
Es handelt sich um Netzwerkdrucker, die auf einem zentralen Server eingerichtet sind.
Unterschiede in den Berechtigungen gibt es nicht.
Ich habe bei beiden Rechnern manuell die NTFS Settings des kompletten C Laufwerks ersetzt.
Außerdem hängt es definitv vom User ab.
Es geht mit dem einen User auf beiden Rechnern und mit dem anderen auf keinem der Rechner.
Unterschiede in den Berechtigungen gibt es nicht.
Ich habe bei beiden Rechnern manuell die NTFS Settings des kompletten C Laufwerks ersetzt.
Außerdem hängt es definitv vom User ab.
Es geht mit dem einen User auf beiden Rechnern und mit dem anderen auf keinem der Rechner.
Hallo,
habe die letzten Tage keine Mails von Administrator.de bekommen, daher habe ich nicht gemerkt, das wieder eine Antwort da war.
Aber da du das ausschließt ist bei deinem Problem jetzt weiter bei den Benutzern zu suchen.
Folgendes solltes du bei den Benutzern prüfen.
1. Befinden sich beide in der gleiche OU deiner Domain?
2. Gelten die gleichen Gruppenrichtlinien?
3. Laufen bei den Benutzern irgendwelche Startskripte, wenn ja welche und wirken die pro USER evtl. unterschiedlich.
Gruppenmitgliedschaft hast du ja schon geklärt da beide nur Domänen-Benutzer sind kann dort ja nicht das Problem sein.
habe die letzten Tage keine Mails von Administrator.de bekommen, daher habe ich nicht gemerkt, das wieder eine Antwort da war.
Außerdem hängt es definitv vom User ab.
Definitiv kannst du nur sagen, wenn beide Rechner absolut gleich konfiguriert sind.Aber da du das ausschließt ist bei deinem Problem jetzt weiter bei den Benutzern zu suchen.
Folgendes solltes du bei den Benutzern prüfen.
1. Befinden sich beide in der gleiche OU deiner Domain?
2. Gelten die gleichen Gruppenrichtlinien?
3. Laufen bei den Benutzern irgendwelche Startskripte, wenn ja welche und wirken die pro USER evtl. unterschiedlich.
Gruppenmitgliedschaft hast du ja schon geklärt da beide nur Domänen-Benutzer sind kann dort ja nicht das Problem sein.
Definitiv kannst du nur sagen, wenn beide Rechner absolut gleich konfiguriert sind.
Definitiv kann ich sagen, weil es auf dem selben Rechner mit dem einen User geht und mit dem anderen nicht.
1. Befinden sich beide in der gleiche OU deiner Domain?
2. Gelten die gleichen Gruppenrichtlinien?
3. Laufen bei den Benutzern irgendwelche Startskripte, wenn ja welche und wirken die pro USER evtl. unterschiedlich.
Gruppenmitgliedschaft hast du ja schon geklärt da beide nur Domänen-Benutzer sind kann dort ja nicht das Problem sein.
2. Gelten die gleichen Gruppenrichtlinien?
3. Laufen bei den Benutzern irgendwelche Startskripte, wenn ja welche und wirken die pro USER evtl. unterschiedlich.
Gruppenmitgliedschaft hast du ja schon geklärt da beide nur Domänen-Benutzer sind kann dort ja nicht das Problem sein.
Nein, die User befinden sich nicht in derselben OU, aber es sind in den OUs keine weiteren Richtlinien oder Skripte festgelegt.
Der einzige Unterschied, der mir noch einfällt ist, dass ich bei dem einen User, bei dems geht, die Drucker nochmal komplett neu eingerichtet habe nachdem ich die NTFS Settings neu gesetzt habe. Bei dem User, bei dems nicht funktioniert habe ich das noch nicht gemacht.
Das werde ich morgen testen und dann Rückmeldung geben.
So, nun hier zur zusammengefassten Problemlösung:
Es lag tatsächlich an den lokalen NTFS Einstellungen.
Per Startskript und subinacl habe ich nun der Gruppe "Authentifizierte Benutzer" Schreib-, Lese- und Änderungsrechte für alle lokalen Dateien gegeben.
Zudem mussten alle Drucker auf den Clients neu installiert werden (also einfach rauslöschen und neu verbinden).
Nun funktioniert auch das Drucken vom Adobe Reader aus wieder einwandfrei.
mfg
Es lag tatsächlich an den lokalen NTFS Einstellungen.
Per Startskript und subinacl habe ich nun der Gruppe "Authentifizierte Benutzer" Schreib-, Lese- und Änderungsrechte für alle lokalen Dateien gegeben.
Zudem mussten alle Drucker auf den Clients neu installiert werden (also einfach rauslöschen und neu verbinden).
Nun funktioniert auch das Drucken vom Adobe Reader aus wieder einwandfrei.
mfg
Na wenn es jetzt funktioniert ist es ja gut und du kannst das Thema als gelöst makieren.
Allerdings ist es ein ziemliches Sicherheitsrisiko wenn deine Benutzer alle lokalen Dateien ändern dürfen.
Gruß ganymed
Allerdings ist es ein ziemliches Sicherheitsrisiko wenn deine Benutzer alle lokalen Dateien ändern dürfen.
Gruß ganymed
Hm, da hast du wohl Recht.
Aber ich wüsste nicht, wie ich die Berechtigungen vernünftig setzen sollte, so dass es noch funktioniert.
Aber ich wüsste nicht, wie ich die Berechtigungen vernünftig setzen sollte, so dass es noch funktioniert.
