Jump to content

olc

Expert Member
  • Gesamte Inhalte

    3.978
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von olc

  1. Hi Herb, das Entfernen der Rechte für die gesamte Domäne war nur ein Beispiel, grundsätzlich habe ich verstanden, was Du machen möchtest. ;) Vom Prinzip her sind die erforderlichen Schritte schon geschrieben worden, Du kannst mittels DSACLS etc. sicher solche Massenänderungen vornehmen. Aber es wurde auch schon gesagt, daß a) das nur nach ausführlichen Tests durchgeführt werden sollte, denn mit sehr hoher Wahrscheinlichkeit wird es Folgeprobleme geben, die Konfigurationsanpassungen nach sich ziehen - das sollte also vor dem Produktiveinsatz bekannt und getestet sein b) das Entfernen des Zugriffs auf den UPN sicher nicht die Gesamtsicherheit erhöht - genügend andere Attribute von Benutzern oder Naming Contexts geben die notwendigen Informationen, sich den UPN zusammenzubauen. Insgesamt wäre also (wenn überhaupt) das Entfernen der Leserechte für Authentifizierte Benutzer der "sinnvollere" Weg. Implement ACEs for the Customer Organization Viele Grüße olc
  2. Hi Sven, es sollte im Normalfall so klappen - falls nicht, schreib hier noch einmal eine kurze Notiz mit ein paar Eckdaten der Umgebung. :) Viele Grüße olc
  3. Hi, wenn Du die Scripts nicht sichtbar machen möchtest, warum aktivierst Du dann die Option: Nachdem Du hier "deaktiviert" eingestellt hast, sollten die Scripts nicht mehr angezeigt werden. Hattest Du das auch schon probiert? Neustart / "gpupdate /force" dazwischen auf dem Client ausgeführt und ggf. die AD / FRS SYSVOL Replikation zwischen den DCs beim Testen abgewartet? Viele Grüße olc
  4. Hi, sorry - ich hatte beim ersten Blick auf die Daten von Dir oben den Logon Type übersehen. Der ist "4", das bedeutet es fehlt das Recht zum Batch-Logon: Weise dem Administrator per GPO einmal das Recht "Log on as a batch job" zu, siehe Log on as a batch job: Security Configuration Editor; Security Services . Viele Grüße olc
  5. Hi, das Thema hatten wir eigentlich abgedeckt: Viele Grüße olc
  6. Hi leg, aus der Beschreibung wird man (ich) tatsächlich nicht so recht schlau. Wenn ich es recht verstehe, hast Du nach einigem hin und her ein Zertifikat für den Server erhalten. Wenn Du die beiden Zertifikate (abgelaufenes Zertifikat und neues Zertifikat) vergleichst (etwa über die GUI oder über "certutil -v -dump cert.cer", gibt es neben den zu erwartenden Unterschieden (Seriennummer, Datum etc.) auch einen anderen Zertifikatzweck / unterschiedliches Template? Die Fehlermeldung sieht mir im Moment danach aus, als ob immer noch das alte Zertifikat verwendet werden würde. Viele Grüße olc
  7. Hi Sycron, nein - mach Dir keine Gedanken. Manchmal braucht es halt Zeit, bis man eine Lösung gefunden hat. ;) Übrigens könntest Du die alten CA Einträge entfernen, wenn die CA nicht mehr vorhanden ist (und vor allen Dingen keine validen Zertifikate dieser CA mehr im Umlauf sind), siehe dazu How to decommission a Windows enterprise certification authority and how to remove all related objects from Windows Server 2003 and from Windows Server 2000 ). Mach das aber nur, wenn Du Dir sicher bist, was Du da tust. ;) Danke für die Rückmeldung und Gruß olc
  8. Hi, wenn Ihr Euch die Arbeit machen möchtet könntet Ihr einmal schauen, ob es im "Trusted Publishers" oder "Root CA" / "Intermediate CA" Speicher auf den betroffenen Clients abgelaufene Zertifikate gibt. Potentielle Kandidaten sind die MS Zertifikate - vielleicht gibt es hier ein Problem, daß dort ein benötigtes Zertifikat zur Integritätssicherstellung der Stammanbieter Pakete nicht mehr valide ist. Viele Grüße olc
  9. Hi Frank, poste ("anonymisiert") für alle Fälle bitte noch ein "ipconfig /all" vom Client und den DCs. Viele Grüße olc
  10. Hi, wenn Du einen GPMC RSOP Result Report für den betroffenen Benutzer und den betroffenen Client ausführst, wird dann die Einstellung im Ergebnissatz angezeigt? Falls nicht, wird die Policy unter Umständen nicht korrekt übernommen - in diesem Fall wäre eine etwas genauere Beschreibung Deiner OU / GPO / Objektstruktur notwendig, um das Problem einzugrenzen. Viele Grüße olc
  11. Hi, Also das ist nun wirklich kein Thema... ad lesen ldap - Google Search :wink2: Wie Nils schon sagte, das läßt sich kaum verhindern. Grundsätzlich kann man den "Authentifizierten Benutzern" den Lesezugriff auf das AD entziehen, dazu gibt es auch entsprechende Dokumente auf Technet (beispielsweise Scenario 1: Authenticated User Permissions Are Removed ). Jedoch sollte das Vorhaben (wie ebenfalls erwähnt) sehr gut getestet werden, wenn man Probleme vermeiden möchte. Viele Grüße olc
  12. Hi, die Uhrzeit (und auch das Jahr) der Systemzeit des Clients ist korrekt? Siehe Viele Grüße olc
  13. Hi, poste doch einmal ein "ipconfig /all" vom DC und von einem "Problemclient" (entferne dabei bitte die Angaben zur Firma etc.). Zusätzlich wäre auch die genaue Fehlermeldung interessant, einfach per STRG + C kopieren und hier als Text einfügen. Firewalls auch Client und ggf. Server wurden testweise einmal deaktiviert? Viele Grüße olc
  14. Hi, nur wenn Du die CA als Enterprise CA installierst, werden die Zertifikate, ggf. CRLs etc. auch automatisch im AD veröffentlicht. Ist die CA als Stand-Alone CA installiert, geschieht das nicht automatisch. Ich würde davon ausgehen, daß Du eine Stand-Alone CA betreibst? Du kannst das jedoch manuell mit dem Befehl "certutil -dspublish" nachholen, siehe dazu Checklist: Creating a certification hierarchy with an offline root certification authority . Viele Grüße olc
  15. Hi Thomas, Im Normalfall sollte das mit gleicher Geschwindigkeit passieren. Du solltest ggf. einmal das Logging ativieren und prüfen, ob es Unterschiede zwischen manuellem und automatischem Kopieren gibt. Unter Umständen führst Du den Task mit anderen Benutzerrechten aus als den manuellen Kopiervorgang? Damit kann ROBOCOPY die Dateien vielleicht nicht kopieren und läuft in die Standard-Timeouts. Na ja - bevor Du von "Herstellermurks" sprichtst solltest Du erst einmal prüfen, ob der Fehler nicht eher auf Deiner Seite liegt oder? ;) Viele Grüße olc
  16. Hi, anhand der Fehlermeldung muß man davon ausgehen, daß dem Benutzerkonto "Administrator" ein bestimmtes Anmelderecht fehlt, also etwa NETZWERK o.ä. Habt Ihr etwas in den Security Policies verändert, die auf den SBS wirken? Ggf. könntest Du mittels GPMC RSOP Result Report prüfen, ob hier etwas verbogen ist. Ansonsten wäre interessant zu wissen, welchen Logon Typ die Installationssoftware nutzt, ggf. kannst Du das bei Symantec in der Support Datenbank einmal suchen. Ein "whoami /all", ausgeführt als Administrator auf dem SBS, kann vielleicht auch etwas Licht ins Dunkel bringen (insbesondere die letzten Zeilen der SE privilages). Viele Grüße olc
  17. Hi, sind eventuell andere Konsolen hinzugefügt worden, die nicht mit der DNS Konsole kompatibel sind (.NET Version)? Siehe MMC 3.0 update is available for Windows Server 2003 and for Windows XP Viele Grüße olc
  18. Hi, Du mußt den Schlüssel nicht löschen, ein normales GPUPDATE /FORCE hat den selben Effekt. Die Frage ist eher, warum die Policy Änderung nicht auf dem Server ankommt oder aber warum das Netzwerk nicht als "intern" erkannt wird - dafür kommen viele Gründe in Betracht. Anfangen mit der Ursachenanalyse würde ich, indem ich die Ereignisprotokolle des Servers auf Fehler überprüfe. Viele Grüße olc
  19. Hallo Manuel, willkommen an Board, es gibt einige Möglichkeiten und Tools, die Ereignisprotokolle auszuwerten - jedoch wäre zunächst einmal interessant, warum die Ordner in der Form überhaupt überwacht werden sollen? So ein Vorhaben macht meist nur in Spezialfällen oder sehr sicherheitskritischen Umgebungen Sinn, nicht aber als "Standard". Zudem ist das ganze Vorhaben auch rechtlich nicht unbedenklich, der Betriebsrat und Datenschutzbeauftragte sollte hier informiert sein und ist ggf. mitbestimmungspflichtig. Hier solltest Du den Rechtsanwalt Deiner Firma involvieren, um diese rechtliche Frage zu klären. Also - noch einmal explizit gefragt: Was ist der Hintergrund für diese Anforderung? Viele Grüße olc
  20. Hi Olaf, neben den Hinweisen von Perin vielleicht noch die Empfehlung "Server Performance Advisor". Wenn Du englische Systeme einsetzt, kannst Du damit wirklich übersichtliche Reports generieren - auf deutschen Systemen ist die Einrichtung sehr aufwändig und gelingt meiner Erfahrung nach nicht immer komplett. http://www.microsoft.com/downloads/details.aspx?familyid=61A41D78-E4AA-47B9-901B-CF85DA075A73&displaylang=en Viele Grüße olc
  21. Hallo Petruss, warum verwendest Du nicht die normalen Office ADM / ADMX Dateien als Template und verteilst die Einstellungen per GPO? Diese werden für die gängigen Office Versionen bereitgestellt und liefern Dir normalerweise fast alle konfigurierbaren Optionen. http://www.microsoft.com/downloads/details.aspx?FamilyID=92d8519a-e143-4aee-8f7a-e4bbaeba13e7&displaylang=en Viele Grüße olc
  22. Hi, schau einmal hier hinein: WDS isn't running EventID.Net Comments Queue Viele Grüße olc
  23. Hi, zusätzlich zu Nils' Hinweis solltest Du den Befehl ggf. auch einmal manuell in die CMD eingeben und nicht per Copy&Paste einfügen - denn wenn ich die "-" (Minus) Zeichen in Deinem letzten Beitrag sehe, unterscheiden diese sich in den beiden Zeilen. Das ist oft ein Zeichen dafür, daß die Zeichen beim Copy&Paste im falschen Encoding in die CMD eingetragen wurden und daher der Befehl scheitert. Einfach einmal direkt tippen, vielleicht hilft das schon. Viele Grüße olc
  24. Hi Chris, schau einmal hier hinein, ein ähnliches Thema hatten wir hier vor einigen Tagen schon einmal besprochen: https://www.mcseboard.de/windows-forum-ms-backoffice-31/komplexe-kennwoerter-bringen-mich-ins-grab-151717.html Viele Grüße olc
  25. Hi, der Fehler tritt in Kombination eines Kennwortwechsels mit servergespeicherten Profilen auf. D.h. nach Kennwortänderung wird das zentrale Profil nicht geladen. Mir ist zwar nicht ganz klar, was mit "dokumentieren" gemeint ist - jedoch läßt sich das Problem problemlos nachstellen, indem Du einen Testbenutzer mit einem "roaming profile" mit dem Flag "Benutzer muß Kennwort bei der nächsten Anmeldung ändern" versiehst. Meldet er sich dann nach einem Neustart am Client an, wird er in den Fehler laufen, sollte Windows XP SP3 ohne Hotfix auf dem Client installiert sein. Um den Fehler zu beheben muß der Hotfix installiert werden, genauso wie es auch bei anderen Problemen sonst gehandhabt werden muß. Von daher ist das Vorgehen zur Patch-Installation nicht verschieden zu anderen Testläufen vor dem Rollout. ;) Viele Grüße olc
×
×
  • Neu erstellen...