Die lokale Richtline erlaubt es Ihnen nicht, sich interaktiv anzumelden

Osch!

Cadet 3rd Year
Registriert
Jan. 2009
Beiträge
44
Hi zusammen ich hab mich an Server 2008 und dem AD versucht, soweit so gut hat auch alles geklappt. Ich konnte einen Testpc in die AD einbinden nur wenn ich jetzt versuche mich anzumelden erscheint "Die lokale Richtlinie erlaubt es Ihnen nicht sich interaktiv anzumelden". Was muss ich ändern damit das machbar wird und gibts allgemein dazu ne Internetseite wo sowas in der Art erklärt ist?
Gruß Osch!
 
hi.


hast du schon mit den GPOs gespielt?
Dort evtl. der Gruppe "Jeder" das Recht auf lokale Anmeldung am System explizit verweigert?
Dann nämlich kannst du dich lokal nicht mehr anmelden, da in der Gruppe "Jeder", wie der Name so schön sagt eben jeder Mitglied ist.
DA verweigern über gewähren steht, darf sich dann eben auch der Admin nicht mehr anmelden.

Sollte das der Fall sein, lässt sich das sicher mit ntrights aus dem Windows Ressource Kit beheben.

http://support.microsoft.com/kb/279664/de

MfG
 
Zuletzt bearbeitet:
Ich hab bis jetzt noch nicht daran rumgespielt, da der Server erst gestern aufgesetzt wurde ich probiers damit mal aus vllt gehts ja
 
Und der Server ist auch nicht (evtl kurzfristig) in einer bestehenden Domäne Mitglied gewesen, die entsprechende Richtlinien durchgedrückt hat? normalen Benutzern eine Anmeldung zu verweigern spricht jedenfalls für eine Maßnahme, wie sie eben typischerweise bei Servern Anwendung findet.
 
Schau mal bei den Eigenschaften des Domänen Users.
 

Anhänge

  • user.jpg
    user.jpg
    102,3 KB · Aufrufe: 2.063
Hast du denn schonmaöl nen DC installiert? Irgendwann ist bekanntlich immer das erste mal und daher sag ich einfach mal: wurde ein Server zum DC promoted, kann man sich an dieser Maschine nicht mehr lokal anmelden.
Da dein Post durchaus nicht ausschliesst, daß das der Fall ist, wollt ichs einfach mal gesagt haben. Da läuft man gern erstmal gegen die Wand, wenn man sich zum ersten mal damit befasst.

Ansonsten an allen Ecken die Rechte nochmal durchgehen wo Berechtigungen gestzt oder verweigert werden können (Filesystem und Shares kannst du da nat. ausser Acht lassen - ne zumindest theorethisch denkbare Ausnahme wäre wohl das Sysvol - wobei man da ne doch recht hübsch verkniesknaddelte Struktur hätte, wenns daran scheitert :))
Also in erster Linie den Useraccount, das Computerkonto (und natürlich die Gruppen in denen USer und/oder Computer Mitglied sind) und alle verknüpften GPOs.
Einfach mal alle durchschauen, die irgendwie mit dem User oder der Maschine Verknüpft sind.

Kommst du denn nur mit einem bestimmten User nicht drauf, oder ist das jetzt erstmal der Status Quo: KEINER kommt auf die Kiste drauf? In dem Fall würde ich nochmal auf "Jeder" hin... öh, huch.. sorry, bin erst jetzt bewust geworden, dass es ja gar nicht um den DC an sich geht, sondern um nen Client... merke: Lesen wirkt brotloser Kunst proaktiv entgegen ;)

Also ok, auf den DC kommst du - mit den Usern, mit denen du es können willst. An den Client kann sich jetzt wer und wie nicht anmelden? egal wer es versucht und auch egal gegen wen (lokale oder Domänenanmeldung) oder ein einzelner User auf die ein und/oder andere Art, oder viellecht ne ganze Benutzergruppe?
So wie du schrreibst kann man da erstmal nichts davon direkt ausschliessen, hört sich aber zumindest so an, dass du die anmeldung auch physikalisch am Client versuchst - sprich nicht über RemoteDesktop?
Hier würde ich dann zunächst mal ansetzen. Teste mal verschiedene Konstellationen wer sich wie anmelden kann, dann kann man das Problem schonmal näher einkreisen.
"Geht nicht" ist keine Fehlermeldung ;) Das kann bisher an echt vielen Stellen hängen.

Sollte sich entgegen meiner Annahme eben doch um RDP Sessions handeln werfe ich mal die lokale Benutzergruppe "Remotedesktopbenutzer" in den Raum (Arbeitsplatz rechtsklicken, verwalten - kann man auch remote einsehen. Eifach auf deinem Rechner aufrufen und über rechtsklick auf deinen Host "remotecomputer verwalten" oder so ähnlich wählen.

Sorry, wenn ich dir da evtl Tipps gebe, über die du evtl schmunzeln wirst, aber anhand des Threads lässt sich nur schwer erahnen wie firm du in der Sache bsit.


MfG
 
Zuletzt bearbeitet:
Beim DC reicht die Gruppe der RDP User allerdings nicht. Da muß auch die lokale Sicherheitsrichtlinie angepaßt werden, wenn sich andere User anmelden könne sollen (was natürlich nicht sinvoll ist).
 
Also danke erstmal für die ganzen Antworten.
Ich hab nen DC installiert und nen PC in die Domäne mit eingefügt und nen neuen Benutzer erstellt... jetzt hab ich versucht mich mit diesem über den PC (nicht am Server selbst) in die Domäne anzumelden wo dann kam "Die lokale Richtline erlaubt es Ihnen nicht, sich interaktiv anzumelden". MIt dem Administrator konto kann ich mich darüber auch anmelden...
 
ja ok, das hört sich ja dann schon viel harmloser an :D

Du musst den Rechnern natürlich zunächst einmal mitteilen wer sich den überhaupt an ihnen anmelden darf.
lokal angelegte Benutzer können da so, Benutzer aus der Domäne müssen erst zugewiesen werden.

Dazu nimmst du entweder:
- am Client mittels Adminkonto den/die Domänenbenutzer(gruppe) in die lokale Gruppe "Benutzer" auf - soll zusätzlich auch von Ferne am Client angemeldet werden können nimmst du die entsprechenden Domänen-benutzer(gruppen) in die lokale Gruppe "Remotedesktopbenutzer" auf.

- oder du erstellst für die Organisationseinheit (OU) in deiner AD Struktur, unter der die Clientrechner geführt werden eine neue Richtlinie in der du unter Computerkonfiguration>windowseinstellungen>sicherheitseinstellungen>eingeschränkte Gruppen
wiederum der/die Domänenbenutzer(grujppen) der Gruppe lokaler Benutzer hinzu.
Remoteberechtigung, wieder das selbe in grün, nur unter Sicherheitseinstellugnen abbiegen nach > lokale Richtlinien>zuweisen von Benutzerrechten und dort sollte es dann irgendwo Remotedesktop geben.

Die zweite Variante ist zu bevorzugen. Wenn du weitere Clients einbinden willst, musst du sie nur in die OU verschieben und die Berechtigungen werden angepasst.

Sollte es nicht direkt gehen am Client, als Admin anmelden und einmal unter start>ausführen>cmd
gpupdate /force
ausführen
danach kannst du mit gpresult die angewendeten GPOs einsehen und anhand des Namens der GPO feststellen ob sie angewendet verweigert odcer eben noch gar nicht gezogen wurde.
Es sollte aber eigentlich nach einmal gpupdate ziehen, da du bisher nur einen LogonServer (der DC) hast, sodass der Client beim starten die GPO ziehen sollte.
Wenn doch nicht -> Einmal die einfachste aller "Rchtlinien" für Windows (Clients) anwenden: Reboot tut gut.


Die Angaben fußen auf windwos 2003, aber unter 2008 sollte das nicht allzuunterschiedlich seib.
FBrenner weiß vielleicht mehr

MfG
 
Zuletzt bearbeitet:
@.mojo
Nein, das stimmt so nicht. Bei Domänenrechnern sind automatisch die Domain Admins in der lokalen Gruppe der Administratoren, Domain User in der lokalen Gruppe der Benutzer. Das ist eigentlich bei allen Domänenrechnern seit NT4 so. Standardmäßig muß sich also jeder Domänenbenutzer an einem Domänenrechner an der Domäne anmelden können.

Man hat aber in der Domäne die Möglichkeit, dies pro User auszuschalten, so wie ich es oben geschrieben hatte. Darauf hat Osch! noch nicht geantwortet.
 
Ach..
Ich war immer der Meinung, nur Admins werden direkt aufgenommen...

Ok, bliebe dein Tipp oder anderweitig explizit verweigerte Rechte..
Überprüfen würde ich die lokalen Gruppen hinsichtlich auf Mitgliedschaft der Domänengruppe aber dennoch.

Dann wäre einmal interessant was gpresult unter verwendung von /USER:Domäne\Benutzer ausspuckt.
 
Das muß nicht mal Absicht gewesen sein. Ich hatte bei einem User auch schon mal das Problem, daß in unregelmäßigen Abständen der Haken gesetzt war, daß er sich an nur an bestimmten Rechnern anmelden kann.
 
Mit der in Builtin enthaltenen default Gruppe "Benutzer" kanns ja nicht zu tun haben?

Einen übergeordneten AD-Forest ist beim TE nicht vorhanden? Von dem könnte evtl noch irgendwas durchgedrückt werden.
 
Du meinst übergeordnete Domain :) Im gleichen Forest müssen die Domains sowieso sein. Wenn er - wie er schrieb - *einen* DC aufgesetz hat, kann das nicht sein ;)
 
Ja ich meine den eigenen Forest nicht einen weiteren Forest. GEht das denn überhaupt? ich dachte ein Forest ist ein Forest ist ein Forest..
Daher heißt es ja uznächst einmal AD-Tree welchedann den Forest bilden :). und weiterhin sollte man ja auch immer einen Forest aufbauen, auch wenn man nur eine Domain fahren will. ob das der fall ist bleibt weiterhin unklar. Jedenfalls ist ein Forest soweit mir bekannt nicht zhwingend.
Naja und es ginge schon. Kommt eben auf die Struktur an. Der Forest könnte ja von einer vorgesetzten Instanz geführt werden und die Domains in den jeweiligen Zuständigkeiten, Stichwört Behörden.


Aber beim Stichwort *einen* sollte man dem TE vielleicht noch nahelegen, mindestens noch einen 2. DC recht zeitnah aufzusetzen.
Ich kenn ja seine Struktur und Mittel nicht, aber auch wenns nur ne schimmlige P4 Rostlaube mit 512 mb ram und consumer board ist, wenn der erste sich mal mit nachdruck auf den Buckel legt, dann is essig. Dann steht mal schnell die halbe produktivität und wenn er nen exchange fährt und wirklich keine übergeordnete Struktur hat auch noch die 2. Hälfte. Aus Usersicht wiegt nichts so schwer wie ein streikendes MAilsystem.
Da steht bei uns demnächst noch nen Ex2010 Cluster an :)




Was mir grad noch einfällt: Um einzeluser spezifische Probleme zu evaluieren, sollte der TE mal nen neuen User anlegen. So sollte recht schnell klar werden obs wirklich mit dem USer ein Problem gibt.

Könnte auch ein UID/SID Ding sein.
Mit welchem Konto funktioniert das anmelden? Mit neu erstelltem Admin Konto oder hast du den default Admin genommen?
Nimm auch mal explizit diesen User in die lokale Gruppe "Benutzer" des Clients auf,bzw was ich damit bezwecken will, ist ober der Client den User auch auflösen kann oder ob es evtl einfach wirklich an der ID liegen kann.

Wo ich mir jetzt nicht sicher bin, aber evtl einen versuch wert:
Beim TE ist ja nich alles frisch, der Lack noch nicht ganz Trocken und wohl noch wenig bis nichts konfiguriert in GPOs.
Könnte er sich evtl an einem, zwar dem AD konformen Kennwort, aber eben nicht - warum und wie auch immer, sei einmal dahingestellt - konform mit einer Vorgabe vom Client?
Ich weiß nicht was da geschieht wenn der Fll eintritt, das ein Client mit Vorgabe eine AD joint, die keine hat. Ich würde vermuten, die lokale bleibt erstmal so wie sie ist..


jetzt muss ich hier nochmal nachhaken:
Ich hab nen DC installiert und nen PC in die Domäne mit eingefügt und nen neuen Benutzer erstellt...
je nach Interpretation könnte man es so lesen, dass der Benutzer an dem Client erstellt wurde? Ich denke ja du hast den User in der AD angelegt, aber wenn du eben doch am Client einen User lokal angelegt hast, dann wird eine Domänenanmeldung nicht funktionieren.
Eine Aufnahme eines Rechner in die AD heißt in keinem Fall auch eine Aufnahme der User in eben diese.
Die User sind und bleiben weiterhin nur auf diesem Rechner lokal berechtigt.


Auch mal einen versuch wert evtl diese:
http://www.benutzer.de/Anmeldung_bei_Domäne_nur_mit_Benutzer_at_domänenname.lokal_möglich..html
Hab ich so in der Form auch noch nie gehört.
Wenns denn mal kein klassischer Fall von PEBCAC war.
 
Zuletzt bearbeitet:
Ein Forest wird immer bei Erstellen der ersten Domäne erstellt. Ein Forest kann aus mehreren Trees bestehen. ;)

Ich denke, spekulieren bringt aber nichts, solange der TE sich nicht dazu äußert.
 
Zurück
Oben