W2K3 Anwendungsterminal Berechtigungsproblem

[Thanks-and-Goodbye]

Moin!

Ich bastel gerade an einer Testumgebung.

W2K3 DC mit aktiviertem Anwendungsterminal, Client-PC ist XP Pro SP1.

Entgegen der Datev-Kochanleitung, die einen Fileserver als DC vorsieht und den WTS als Memberserver ist bei mir der WTS gleichzeitig DC. Mangels Testgeräten kann ich aber nur einen Server und einen Client laufen lassen.

Das heisst, dass ich über die lokale Gruppe der "Remotedesktopbenutzer" nicht mehr verfüge (wo ich eigentlich den User als Terminaluser freischalte), da alles über das Snapin AD-Computer- und Benutzer geregelt wird. Allerdings muss ich irgendwie meinem normalen User doch beibiegen, dass er sich am Terminal anmelden darf.

Ich habe jetzt eine eigene OU für meine Standarduser, habe für diese Standarduser eine Domänenrichtline nach Datev-Anforderung erstellt und auch zusätzlcih die interaktive Anmeldung freigeschaltet, auch unter den administrativen Vorlagen unter Terminaldienste ist für diese OU die Anmeldung am Terminal freigeschaltet. Die Richtlinien wurden mit "gpudate" auch auf dem Server aktiviert.

Trotzdem bekomme ich, wenn ich mich mit dem Testuser im Terminalclient anmelden will, den Fehler, dass eine interaktive Anmeldung nicht möglich ist. Lokal am PC ist diese Anmeldung kein Problem.

Wo liegt jetzt die Lösung versteckt? Was habe ich übersehen? Wo ist bei mir der Knoten im Gedankengang?

[Thanks-and-Goodbye]

Also, habe hier noch etwas rumgegoogelt und das hier gefunden:

http://support.microsoft.com/default.aspx?scid=kb;en-us;q247989

Funktioniert allerdings nicht.

[hades]

Du benoetigst beim Win2k3 das Recht Logon through Terminal Services, logon locally ist bei Win2k3 nur fuer die Konsolenanmeldung.

http://support.microsoft.com/default.aspx?scid=kb;en-us;837954

[Thanks-and-Goodbye]

Inzwischen beides gesetzt. Reicht leider nicht aus. Anmeldung mit normalem Useraccount wird mir im Terminal verweigert.

[hades]

Darf der User sich am WTS anmelden?

AD Users and Computers -> Eigenschaften des Benutzers -> Reiter Terminal Services Profile -> Allow logon to Terminal Server

[pepper]

Trotzdem bekomme ich, wenn ich mich mit dem Testuser im Terminalclient anmelden will, den Fehler, dass eine interaktive Anmeldung nicht möglich ist. Lokal am PC ist diese Anmeldung kein Problem.

Wo liegt jetzt die Lösung versteckt? Was habe ich übersehen? Wo ist bei mir der Knoten im Gedankengang?

Servus!

Der Fehler in Sachen "interaktive Anmeldung" deutet normalerweise darauf hin, dass die lokale Richtlinie des DC (nicht die Default DC Policy) das Anmelden "normaler User" nicht gestattet.

Kommst Du denn per Remotedesktopverbindung drauf? Ist ja eigentlich das selbe...

Gruß,

pepper

[Thanks-and-Goodbye]

Also ich komme als Admin problemlos drauf auf den Server. Benutzt wird der Remotedesktopclient des W2K3-Servers (aus c:\windows\system32\clients\tsclient).

Füge ich den Testuser in die Gruppe der Admins, kann er sich anmelden. Auch der eigentliche Administrator kann sich problemlos anmelden.

Wegen der Richtline muss ich mal nachschauen.

@ hades: ja, der entsprechende Haken ist gesetzt. Gesperrt wird das wohl von irgendeiner Richtline. Nur wo die versteckt ist, muss ich mal rausbekommen.

[hades]

... dass die lokale Richtlinie des DC (nicht die Default DC Policy) das Anmelden "normaler User" nicht gestattet.

Ergaenzend dazu die Reihenfolge der Gruppenrichtlinien:

lokale Gruppenrichtlinien -> Gruppenrichtlinien des Standortes (wenn vorhanden) -> Domaenen-Gruppenrichtlinien -> Gruppenrichtlinien der OU

Wenn die betreffende Richtlinie in spaeter aktiv werdenden Gruppenrichtlinien nicht definiert ist, dann wird diese von der vorhergehenden Gruppenrichtlinie uebernommen.

D.h. es gibt hier drei Orte zum Nachschauen:

- Lokale Gruppenrichtlinie des Domaincontrollers

- Default Domain Policy

- Default DC Policy

[pepper]

Ergaenzend dazu die Reihenfolge der Gruppenrichtlinien:

lokale Gruppenrichtlinien -> Gruppenrichtlinien des Standortes (wenn vorhanden) -> Domaenen-Gruppenrichtlinien -> Gruppenrichtlinien der OU

Wenn die betreffende Richtlinie in spaeter aktiv werdenden Gruppenrichtlinien nicht definiert ist, dann wird diese von der vorhergehenden Gruppenrichtlinie uebernommen.

D.h. es gibt hier drei Orte zum Nachschauen:

- Lokale Gruppenrichtlinie des Domaincontrollers

- Default Domain Policy

- Default DC Policy

Ergänzend zur Ergänzung ein Tipp:

bei Microsoft gibt es das etwas komfortablere Gruppenrichtlinienverwaltungstool GPMC; ist in jedem Fall übersichtlicher als gpedit.msc. Dort ist die Hierarchie der von hades angesprochenen Wirkungsreihenfolge der Gruppenrichtlinien besser nachzuvollziehen, da sie dort tatsächlich untereinander stehen.

Als Anmerkung nochmal: was domänenseitig "runterkommt" (ob von OU, Domain oder Site) hat Vorrang vor der lokalen Richtlinie; die wirken zwar kumulativ, aber nur, solange sich die Einstellungen "nicht beißen".

Gruß,

pepper

[hades]

Ich hatte heute dasselbe Problem.

Es ist die Default Domain DC Policy, dort muessen die beiden o.g. Rechte gesetzt sein.