olc

Hi,

nein - Du wendest die AGDLP Regel trotzdem an. ;)

Die AGDLP Regel sagt, daß Du die Sicherheitsfilterung über Gruppen erledigst.

Das bedeutet: Du verlinkst zwar die GPO oberhalb der Benutzer, aber Du gibst Ihnen nicht das Recht die GPO zu übernehmen.

• Entferne dazu die Authentifizierten Benutzer aus der Liste der berechtigten Benutzer und Gruppen auf diese OU.
  
• Bei einem kurzen Test wirst Du nun feststellen, daß die GPO nicht mehr greift.
  
• Nun fügst Du die entsprechende domänenlokale Gruppe als berechtigt, diese GPO zu übernehmen, hinzu.
  
• Die Benutzer sind weiterhin Mitglied der globalen Gruppe, die globale Gruppe ist Mitglied der domänenlokalen Gruppe.
  
• Obwohl die Gruppe nicht in der selben OU liegt, sondern nur die Benutzer unterhalb der GPO liegen, wird die Richtlinie nun wieder greifen.
  

Du filterst also mit Sicherheitsberechtigungen, wer die GPO überhaupt übernehmen darf. Und genau das ist in diesem Fall über AGDLP erfolgt.

Viele Grüße

olc

Hi,

doch - Du kannst es so schon machen. Wie gesagt, AGDLP ist an sich kein Problem, solange es sich um eine ein-Domänen Struktur handelt. Von daher ist Dein Beispiel schon korrekt, Du könntest es nur mit der Zusatzinformation spicken, daß es in bestimmten Konstellationen Probleme geben kann.

Für Dich heißt das nun, daß Du die Sicherheitsfilterung mittels AGDLP auf der GPO so läßt, wie Du es eingerichtet hast. Du verlinkst jedoch die GPO nicht auf die OU "Menüexplorerweg", sondern verlinkst die GPO auf die OUs "Anwalt" und "Sekretaerin".

Im Grunde ist dann die Aufteilung der Gruppen in OUs nicht mehr notwendig, Du könntest die Gruppen also in eine generische OU verschieben, so etwa eine neue OU namens "Gruppen".

Wie angesprochen: Du mußt einfach nur den Geltungsbereich der Gruppenrichtlinien verändern, also die GPO oberhalb der Benutzer verlinken. Dann ist alles in Ordnung und sollte funktionieren.

Viele Grüße

olc

Hi,

ok, dann funktioniert es jetzt?

Wenn es noch weitere Fragen gibt, dann melde Dich einfach.

P.S.: Ich drücke Dir die Daumen, daß Du das alles (Schule und Leben ;) ) hinbekommst.

P.P.S.: Bitte schreibe unbedingt etwas strukturierter, mit ein wenig mehr Grammatik und weniger Ausrufezeichen. Das erleichtert das Verständnis für Deine Fragen ungemein und nützt auch Dir, da dann auch mehr Menschen gewillt sind, Deine Fragen überhaupt bis zu Ende zu lesen... ;)

Viele Grüße

olc

Hi,

in welcher OU liegen denn die Benutzer?

Du kannst Gruppenrichtlinien nicht direkt auf Gruppen anwenden (auch wenn es "Gruppen"-Richlinie heißt), sondern nur die Anwendung damit filtern. Du kannst Gruppenrichtlinien nur auf Computer- oder Benutzerobjekte anwenden.

Das bedeutet in Deinem Szenario, daß die Benutzer ebenfalls unterhalb der OU "Menüexplorerweg" liegen sollten (oder in weiter darunter liegenden OUs). Dann greift erst die Policy.

BTW:

Nach Möglichkeit würde ich Umlaute wie "ü" nicht in OU-Namen oder ähnlichen Bezeichnern verwenden, das macht bei Scripts ö.ä. unter Umständen nur einmal Probleme.

Außerdem gilt das AGDLP Prinzip nicht für AD-Objekte (wie es Gruppenrichtlinien sind), sondern eher für andere Ressourcen wie Drucker, Freigaben, NTFS ACLs etc. In Multi-Domänenumgebungen sind universelle Gruppen anstatt domänenlokale Gruppen zumindest für AD-Objekte die bessere Wahl. Damit kannst Du bei Deinem Lehrer vielleicht extra Punkten. ;)

Siehe dazu auch: Aktives Verzeichnis Blog : Benutzeranmeldung an einem Client einer anderen Domäne und GPO Filterung auf domänenlokale Gruppen

Viele Grüße

olc

Hi und willkommen an Bord,

ich muß zugeben, so ganz habe ich das Szenario nicht verstanden.

So wie ich es sehe, hast Du also mehrere OUs, auf eine davon möchtest Du eine GPO hängen, die dann Einstellungen vornimmt (die Erlaubnis, LAN-Verbindungen umzubenennen). Bis hierhin korrekt?

Du hast als dann als Sicherheitsfilterung die berechtigten Benutzer in eine globale Gruppe gelegt, diese als Mitglied einer domänenlokalen Gruppe definiert und der domänenlokalen Gruppe die Berechtigung gegeben, die GPO anzuwenden. Auch korrekt?

Falls ja, zwei Fragen für den Anfang:

1. Hast Du einmal testweise versucht, einem Benutzer direkt das Recht zu geben, die GPO zu übernehmen?
   
2. Wie lautet der "Pfad" zur verwendeten Gruppenrichtlinie? Ist es eine Computereinstellung oder ist es eine Benutzereinstellung? Vielleicht hast Du es schlichtweg auf der falschen OU verlinkt?
   

Deine Skizze oben ist nicht angekommen - am besten irgendwo extern hochladen und verlinken.

Laß den Kopf nicht hängen, das bekommst Du schon rechtzeitig hin. :)

Viele Grüße

olc

Hi,

na dann Glückwunsch zur bestandenen Prüfung. :)

Viele Grüße

olc

Hi,

was ist denn vor dem Fehler auf dem System passiert?

Ggf. USN Rollback oder etwa manuell die Replikation eingestellt?

Wurde z.B. ein Image zurück gesichert?

Damit würde ich erst einmal beginnen, aber ich vermute, daß der Hintergrund für den Fehler ein anderer ist:

Starting test: Replications

[Replications Check,SRV-FILE] Inbound replication is disabled.

To correct, run "repadmin /options SRV-FILE -DISABLE_INBOUND_REPL"

[Replications Check,SRV-FILE] Outbound replication is disabled.

To correct, run "repadmin /options SRV-FILE -DISABLE_OUTBOUND_REPL"

Viele Grüße

olc

Hi,

kannst Du einen Screenshot machen, diesen extern hochladen und hier verlinken?

Viele Grüße

olc

Hi,

bist Du Enterprise Admin oder hast Du das entsprechende CA Recht delegiert bekommen?

Sieht für mich erst einmal so aus, da Du die Zertifikat-Vorlage ja anpassen konntest. Aber sicher ist sicher.

Viele Grüße

olc

Cool... :cool:

Hi,

soweit bieten so einige Firmen solche Lösungen, so auch Astaro: Astaro Mail Gateway / Unsere Produkte / Astaro - Astaro .

Viele Grüße

olc

Hi Tony,

ja, mach das mal. Bei Fragen - fragen. ;)

Viele Grüße

olc

Hi,

also alles, was Du zuletzt geschrieben hast, habe ich leider nicht wirklich verstanden. :D

Aber es sieht für mich so aus, als ob der Hotfix dann doch die Lösung war, korrekt?

Falls ja - perfekt. :)

Viele Grüße

olc

Hi,

dann versuch einmal nicht den Global Catalog zu befragen, sondern die NCs komplett:

ldifde -s [b][color="Red"]DC_DER_JEWEILIGEN_DOMÄNE_ALS_FQDN[/color][/b] -f check_SPN.txt -t [b][color="Red"]389[/color][/b] -d "" -l servicePrincipalName -r "(servicePrincipalName=HOST/mycomputer*)" -p subtree

Als DC trägst Du zuerst einen DC ein, auf dem das Event geloggt wird. Wirst Du da nicht fündig (was ich nicht glaube), dann versuche es schrittweise mit jeweils einem DC einer anderen Domäne.

AD-Replikation läuft korrekt in der Umgebung (verifiziert)?

Viele Grüße

olc

Hi,

Du schreibst, daß Du die beiden letzten Punkte "nicht machen" kannst.

Nun kann ich auch die Punkte 14-15 nicht machen :

 

Klicken Sie in der Konsole Zertifizierungsstelle mit der rechten Maustaste auf Zertifikatvorlagen, klicken Sie auf Neu und dann auf Auszustellende Zertifikatvorlage.

 

Wählen Sie im Dialogfeld Zertifikatvorlagen aktivieren die neu erstellte Vorlage mit der Bezeichnung ConfigMgr-Standortserver-Signaturzertifikat aus, und klicken Sie dann auf OK.Hinweis

Was genau heißt "kann ich nicht machen"? Wenn Du einen Rechtsklick auf die Zertifikatvorlagen machst, klickst Du auf "Neu". Ist das noch möglich? Falls ja, was passiert dann?

Viele Grüße

olc

Hi,

schau mal hier, das könnte die Lösung sein: You may experience a 20-second delay when you try to access a redirected folder by logging on to a Windows Server 2003 Service Pack 1-based computer or to a Windows XP Service Pack 2-based computer .

Falls nicht versuch einmal die IE Branding Policy testweise zu deaktivieren. Verschwindet dann die Verzögerung?

Viele Grüße

olc

Hi,

auf ein XP System kopieren und ausführen der Datei geht nicht?

Ich denke schon oder?

Viele Grüße

olc

Klasse, vielen Dank für Deine Rückmeldung. :)

Viele Grüße

olc

Hi,

die hochgeladene Datei ist nur die allgemeine Konfigurationsdatei, nicht die Konfiguration für den konkreten Tunnel. Vielleicht kannst Du die andere Datei (wie gesagt, bitte keine Pre-Shared Keys o.ä. mit angeben) noch einmal irgendwo hosten, damit wir hinein schauen können.

Aber ich denke wie djmaker auch, daß Du das Logging einmal einschalten solltest. Ich stimme ebenfalls zu, daß auf der Gegenseite auch etwas zu sehen sein sollte, ggf. muß hier auch das Logging hochgedreht werden.

Viele Grüße

olc

Hi,

die beiden Ausschnitte - gehören die zusammen oder passiert zwischen den beiden Ausschnitten eventuell noch mehr?

Die Zeile

USERENV(1664.564) 12:31:18:566 GetUserDNSDomainName:  Domain name is NT Authority.  No DNS domain name available.

ist insofern interessant, daß scheinbar irgend ein Dienst oder Prozess anstatt nach der Domäne nach einem Konto, nämlich NT Authority sucht (es fehlt der Benutzerteil, also etwa \Network, \System etc.). Hier würde ich also ansetzen.

Siehst Du eventuell welcher Dienst oder was für eine Policy / ein Script vorher geladen wird?

Viele Grüße

olc

Hi,

welche Domäne hast Du mittels LDIFDE exportiert? Wahrscheinlich nur die eigene oder?

Schau einmal in der gesamten Struktur, ob da ein "Scherzbold" ggf. in seiner Domäne den SPN falsch registriert hat.

Viele Grüße

olc

Hi,

mittels DNSCMD solltest Du die Zonen auslesen können und dann ggf. die Ausgabe als Schleife zum Beispiel über "ping" oder ähnliches verifizieren (vorausgesetzt die Hosts sind online).

Was mir nicht ganz klar ist: Du schreibst, daß Einträge nicht vorhanden sind - in dem Fall bringt Dir doch das Auslesen der Zonen nichts oder?

Viele Grüße

olc

Hi,

wenn Du die Profile nur am Terminalserver verwenden möchtest, dann muß meines Wissens kein .V2 mit angegeben werden. Dies ist nur notwendig, wenn das Profil von einem XP System kommt und auf einem Vista / 2008 "Client" umgewandelt wurde. Aber prüfe das noch einmal gegen, ich bin mir hier nicht 100% sicher. Müßte ich selbst erst einmal testen - das kannst Du also auch machen. ;)

Umbenennen mußt Du nicht die LOG-Dateien, sondern wie auch früher nur die NTUSER.DAT. Ich würde dies jedoch zumindest auf Terminalservern nicht manuell durchführen, denn dafür gibt es eine entsprechende Group Policy: Profiles

Außerdem gibt es nun auch die Möglichkeit, das Verzeichnis selbst Mandatory zu machen, siehe dazu http://download.microsoft.com/download/3/b/a/3ba6d659-6e39-4cd7-b3a2-9c96482f5353Managing%20Roaming%20User%20Data%20Deployment%20Guide.doc

Viele Grüße

olc

Hi,

Dein Nickname ist passend, denn wahrscheinlich liegt Dein Problem in der Registrierung. ;)

Schau einmal in den folgenden Artikel: An error message informs you that you cannot move or rename the Documents and Settings folder - Du mußt die "ProfileList" säubern, sonst kann sich der Benutzer weiterhin nur mit einem temporären Profil anmelden. Der Artikel bezieht sich auf ein anderes Problem, mir geht es nur um den Pfad zum Registry Key "ProfileList". Dort entfernst Du den Schlüssel mit der SID des betroffenen Benutzers komplett.

Paß in jedem Fall auf, daß Du die korrekte SID erwischt. Sonst bekommst Du mit anderen Profilen Probleme. Im Zweifel hilft ein Backup vor dem Löschvorgang. :)

Viele Grüße

olc

Hi,

der Fehler existiert erst seit der Installation vom Service Pack 3 für Windows XP. Das war die Ausgangslage für diesen Thread.

Es gab meines Wissens vor ewigen Zeiten mal ein ähnliches Problem (finde den KB nur gerade leider nicht) - also wenn es bei Dir nicht erst seit der Installation von XP SP3 aufgetreten ist, dann liegt das Problem woanders. ;)

Viele Grüße

olc