Logon an einem DC verhindern

[mgerste 10]

Hallo!

 

Ich habe im Board einen Artikel gefunden in dem beschrieben war, wie man die Anmeldung der Clients auf einem bestimmten DC mittels Registryeintrag verhindern kann. Ich habe 2 DC's und ich möchte, dass sich alle Clients in Zukunft nur mehr an einem DC anmelden können. Leider finde ich den Artikel im Board nicht mehr.

[Daim 12]

Moin,

 

wo bleibt da die Ausfallsicherheit bzw. was passiert wenn der vorgegebene DC vorübergehend nicht erreichbar ist wegen wasweissichwas ?

 

Du kannst es technisch auch über das DNS lösen, gebe dem Server eine höhere Pirorität (niedrigere Zahl entspricht höherer Priorität) und somit hättest Du es auch erreicht.

 

Was ist der Sinn des ganzen ?

[mgerste 10]

Hallo!

 

Der Sinn dahinter ist, dass der "alte" Server nur noch eine kurze Zeit läuft und ich sicher sein will, dass beim entfernen aus der Domäne kein User mehr an diesem DC angemeldet ist.

[Velius 10]

Hi

 

Man ist nicht "permanent" an einem DC angemeldet. Sollte der Logonserver nicht mehr da sein, dann schnappt sich der Client eben den nächst besten (bei bedarf)....

 

Also, einfach demoten! ;)

 

 

Gruss

Velius

[Schluml 10]

Würde den DC einfach herab stufen, du hast nichts zu verlieren, die Benutzerprofile liegen ja auf den anderen DC auch und werden auch da gepseichert wenn der erstere nicht mehr da ist

 

edit: ach, zu spät ;)

[lefg 276]

Ich habe im Board einen Artikel gefunden in dem beschrieben war, wie man die Anmeldung der Clients auf einem bestimmten DC mittels Registryeintrag verhindern kann. Ich habe 2 DC's und ich möchte, dass sich alle Clients in Zukunft nur mehr an einem DC anmelden können.

Ein Client, ein User meldet sich nicht an einem DC, auch nicht an einem Server an.

 

Die Anmeldung erfolgt an der Domäne. Für diesen Vorgang wird ein erreichbarer und williger DC benutzt; welcher, ist für den Anmeldevorgang und auch danach ohne wesntliche Bedeutung.

 

Es gibt wahrscheinlich bei deinem Vorhaben wichtigere Dinge: Der globale Katalog, die FSMO-Rollen, die Namensauflösung.

 

Gruß

 

Edgar

[Daim 12]

Korrekt - damit sich die User an dem anderen DC anmelden muss dieser zwingend auch GC sein (abgesehen das man auch die FSMO Rollen verschieben muss).

 

Was Du aber in jedemfall sichern solltest, ist das EFS-Zertifikat:

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

[grizzly999 11]

Korrekt - damit sich die User an dem anderen DC anmelden muss dieser zwingend auch GC sein.

Seit wann das?

 

Und die eventuell vorhandenen FSMO-Rollen werden automatisch beim demoten verschoben.

 

 

grizzly999

[solinske 10]

auf dem alten server einfach net pause server und das mit dem loginhat sich erledigt ! wenn du das ganze wieder in gang bringen willst dann einfach net continue server und die mühle rennt wieder.

[Daim 12]

@grizzly

 

Seit wann das?

 

Befindet sich die Domäne mindestens in der Domänenfunktionsebene 2000 Pur, lässt sich ohne einen GC keine Authentifizierung an der Domäne vornehmen - ausser die Domänen-Admins, diese können sich weiter anmelden.

 

 

Ich habe jetzt leider so auf die schnelle keinen 2003er Artikel gefunden, aber dieser beschreibt es auch:

Bei einer Benutzeranmeldung am Netzwerk stellt der globale Katalog Informationen zu universellen Gruppenmitgliedschaften für das Konto bereit, das eine Anmeldeanforderung an den Domänencontroller sendet. Befindet sich in der Domäne nur ein Domänencontroller, hat der Server gleichzeitig die Funktion des Domänencontrollers und des globalen Katalogs. Verfügt das Netzwerk über mehrere Domänencontroller, wird der globale Katalog auf demjenigen Domänencontroller angelegt, der als globaler Katalog konfiguriert wurde. Ist während des Anmeldevorgangs am Netzwerk kein globaler Katalog verfügbar, kann sich der Benutzer nur am lokalen Computer anmelden.

 

http://www.microsoft.com/windows2000/de/server/help/default.asp?url=/windows2000/de/server/help/sag_adintro_20.htm

 

 

Edit:// Es sei denn man setzt den Schlüssel "IgnoreGCFailures"

http://support.microsoft.com/kb/241789/en-us

 

Dieser ist auch nicht schlecht:

http://support.microsoft.com/kb/216970/en-us

If a GC server cannot be located by the domain controller during this process: • If the account that is used is the built-in Administrator account (RID 0x1F4 or decimal 500), Windows 2000 allows the logon to take place without the domain controller contacting a GC.

• If cached credentials exist for the user on the local computer, the user is logged on with those credentials. Access to network resources must be validated on an individual basis. If the client uses Kerberos to use a server's resources, the KDC must be contacted to get a ticket for the server, or if NTLM is used, pass-through authentication is required.

• If cached credentials do not exist, the user is denied logon.

[IThome 10]

Hm, ich kann mich hier sehr wohl auch ohne GC mit einem Domänenbenutzer anmelden (Single-Server Domäne im Domänenbetriebsmodus Windows 2003, User, der sich vorher noch nie angemeldet hat, kein GC vorhanden (überprüft mit REPLMON und DCDIAG), IgnoreGCFailures nicht konfiguriert)

[grizzly999 11]

@grizzly

Befindet sich die Domäne mindestens in der Domänenfunktionsebene 2000 Pur, lässt sich ohne einen GC keine Authentifizierung an der Domäne vornehmen - ausser die Domänen-Admins, diese können sich weiter anmelden. + weitere Links

Das liest sich schon ein wenig anders, als

"damit sich die User an dem anderen DC anmelden muss dieser zwingend auch GC sein "

 

Zudem gilt das richtigerweise nur bei 2000 Pur Modus oder höher UND in einem Mehrdomänen-Forest. In einem Single Domain Modell ist das hinfällig, da eh jeder DC die kompletten Informationen hat.

 

 

grizzly999

 

/edit: Oh, hatte IThome ja auch schon geschrieben, und ich nicht ganz durchgelesen :)

[Daim 12]

Zudem gilt das richtigerweise nur bei 2000 Pur Modus oder höher UND in einem Mehrdomänen-Forest. In einem Single Domain Modell ist das hinfällig, da eh jeder DC die kompletten Informationen hat.

 

Das stimmt, den Hinweis auf Single Domain und Domänen-Modi hätte ich erwähnen müssen.

[Gadget 37]

Hi,

 

déjà-vu oder ned:

http://www.mcseboard.de/showthread.php?t=65706 ;)

 

EDIT: Nachdem ich mir diese Ressourcen:

TechNet Support WebCast: Overview of universal group caching in Microsoft Windows Server 2003

http://support.microsoft.com/?scid=kb%3Ben-us%3B893435&x=15&y=10

 

Global Catalog Server Requirement for User and Computer Logon

http://support.microsoft.com/default.aspx?scid=kb;en-us;216970[(url]

 

Windows Server Hacks: Configuring Universal Group Caching

http://www.windowsdevcenter.com/pub/a/windows/2004/05/18/ug_caching.html

 

reingezogen hab bin ich mal zu folgendem schluss gekommen (hab ich in nem englischen Forum geschrieben, bei Bedarf kann ichs noch übersetzen) :p :

 

A) Multidomain environment:

1. W2k Mixed Mode:

No GC is needed for userlogon

 

2. W2k Native Mode:

GC is needed for userlogon regardless the user belongs to a universal group or a group who is nested in a universal one. This behavior could be changed but that´s not recommended. When no GC is online, cached credentials will be used to log on, when credential-caching is disabled logon fails.

 

3. W2k Native Mode with one or more W2k3 DC`s in the ad:

On the 2k3 DC universal group caching could be enabled but that´s not recommended, else as number two.

 

4. W2k3 Native Mode:

Universal group caching could be activated. When it is... no global catalog is needed for Users who are in the cache. (By default universal group caching is not activated so logon will fail when no GC is there and cached-credentials are deactivated)

 

B) Single-Domain-environment:

2k & 2k3: No GC is required for logon because all dc´s have the same information.

But a GC should althoug be in the domain because many applications are using gc for ad-lookup.

 

LG Gadget

[Velius 10]

Ich sag mal nichts mehr dazu... :rolleyes: :D :D

 

Soll sich jeder sein eiegens Bild machen- ;)