-
Gesamte Inhalte
3.978 -
Registriert seit
-
Letzter Besuch
Alle erstellten Inhalte von olc
-
Ok, aber "externe" Zertifikate von Verisign o.ä. werden in größerer Anzahl schnell sehr teuer. Aber dafür müßt Ihr Euch dann nicht im die PKI Struktur kümmern. Nils hat Recht - laßt Euch diesbezüglich einmal beraten, bevor da nicht optimale Entscheidungen fallen. :) Viele Grüße olc
-
W2K8 - LDAP Query auf Parameter logonHours
olc antwortete auf ein Thema von MartinAD in: Windows Server Forum
Hi Martin, ein VBScript ist keine Alternative? faq-o-matic.net Anmeldezeiten fr AD-Benutzer per Skript ausgeben Viele Grüße olc -
W2K8 - DFS Replikation funktioniert nicht
olc antwortete auf ein Thema von MartinAD in: Windows Server Forum
Moin Martin, alles klar, schön daß es wieder klappt. Die Geschichte mit dem AV-Ausschluß solltest DU Dir ggf. trotzdem einmal anschauen. :) Viele Grüße olc -
Nee, ich meinte ja explizit "indirekt". Sprich von Dir, nicht von MS. ;) Es gibt halt Gründe dafür, daß auch unter Windows 7 die MaxTokenSize noch auf 12KB steht. Wenn die Gnadenfrist für andere Applikationen / Dienste dann vielleicht irgendwann einmal vorbei ist, kommt vielleicht der Wert auch mal per RTM oder per ADMX. :D Viele Grüße olc
-
...die kommen (indirekt), wenn Du eine schreibst. :D
-
Hi Norbert, nein, in meinem zweiten Beitrag gleich ganz zu Beginn: How to use Group Policy to add the MaxTokenSize registry entry to multiple computers :) [EDIT] Zu spät. :) [/EDIT] Viele Grüße olc
-
Großartig! :jau: Vielen Dank an die Betreiber für dieses tolle Board! :) Auf die nächste Million, viele Grüße olc
-
Hi, stellt Ihr den Kunden denn Zertifikate mit Eurer CA aus? "Issuing" CA ist eine Zertifikat ausstellende CA. Dienstleister zu dem Thema gibt es übrigens durchaus - nur haben die aufgrund der (fast schon) "Alleinstellung" bei gutem fachlichen PKI Know-How eben einen ordentlichen Tagessatz. Der ist bei dem Thema aber auch gut investiert... Viele Grüße olc
-
W2K8 - DFS Replikation funktioniert nicht
olc antwortete auf ein Thema von MartinAD in: Windows Server Forum
Hi, die DFSRS.exe ist der DFSR Dienst - also normal, daß er ein handle auf die Datenbank hat. ;) Jede Wette, daß das bei Dir der Virenscanner oder ein ähnlicher Filtertreiber ist. Schließe also einmal die *\System Volume Information\DFSR\* Daten vom real-time Scan der AV Applikation aus (on-demand kann und sollte im Normalfall bleiben) oder deinstalliere den AV-Scanner testweise einmal. Nimm es mir nicht krumm, aber "Uptime" ist vollkommener Unsinn. Wofür ist die wichtig? Du weißt, daß Du für Security Updates / andere Hotfixes auch die Systeme neu starten mußt? Wenn ich ein Windows System sehe, welches länger als 30 Tage nicht gestartet wurde, dann habe ich aus diesem Grund "Angst" um die Sicherheit des Systems und freue mich nicht über die "Uptime". Viele Grüße olc -
Hi, genau aus diesen "Phantom-Gründen" machen Einstellungen unterhalb der 10 Anmeldeversuche bis zur Sperrung meines Erachtens keinen Sinn. Besser sind sogar 20-50 ungültige Anmeldeversuche - je nachdem, ob ein zeitnahes / real-time Monitoring der Anmeldeversuche erfolgt oder nicht. Danke für Deine Rückmeldung und Gruß olc
-
Hi, klasse - also wie vermutet die MaxTokenSize. Schön, daß es nun klappt und danke für die Rückmeldung. :) Teste trotzdem auch alle Deine Applikationen, ob sie mit dem 64KB großen Puffer zurecht kommen - das muß (leider) nicht der Fall sein. Im oben von mir genannten KB hast Du auch gleich ein ADM für die Verteilung der Einstellung per GPO. Viele Grüße olc
-
Zertifikatsserver und Webregistierung
olc antwortete auf ein Thema von sabine79 in: Windows Server Forum
Hi, an welcher Stelle kommt die doppelte Kennwortabfrage: Beim "new", "submit" und / oder "accept"? Beim "new" und "accept" sollte die Nachfrage auf jeden Fall passieren, wenn ich mich nicht irre. Webenrollment funktioniert AFAIK aufgrund der über den gesamten Vorgang geladenen DLLs anders, daher ist kein direkter mit certreq Vergleich möglich. Viele Grüße olc -
Verlängerung/Erneuerung des Root CA Zertifkats
olc antwortete auf ein Thema von t.friedrich in: Windows Server Forum
Hi t.friedrich, willkommen an Board, :) die ausgestellten Zertifikate werden weder bei einem neuem privaten Schlüssel ungültig noch bei einer Erneuerung des CA Zertifikats mit dem alten privaten Schlüssel. Von daher ist Dein Vorhaben also kein Problem. Siehe dazu auch: Using CA Certificate Renewal: Public Key Bei gleichem privaten Schlüssel gibt es nicht einmal eine neue (Delta) CRL, sondern es wird die alte CRL weiterhin genutzt bzw. neu geschrieben. Das liegt daran, daß die CRLs immer mit dem privaten Schlüssel der CA signiert werden - ändert dieser sich nicht, kann auch die CRL beibehalten werden. Viele Grüße olc -
Hi, als alternative könntet Ihr auch die Zertifikate / Schlüssel der internen Issuing CAs von einer öffentlichen Zertifizierungsstelle beziehen und nicht alle Zertifikate. Damit ist die Root vertrauenswürdig und die anderen Firmen könnten Eure Zertifikate erfolgreich validieren. Gleiches gilt dann für die anderen Firmen. Oder Ihr macht mit den CAs der anderen Unternehmen eine sogenannte Kreuzzertifizierung: Planning and Implementing Cross-Certification and Qualified Subordination Using Windows Server 2003 . Viele Grüße olc
-
Hi Norbert, oh je - stimmt. Ich habe das mit dem lastLogon / der lastLogonTimestamp verwechselt. Danke für den Hinweis. Die anderen Fragen sind trotzdem noch aktuell. ;) Viele Grüße olc
-
Hi, versuch es trotzdem einmal mit dem Hochsetzen auf dem betroffenen Client auf 65535 dezimal - zum Testen. Wie viele Gruppen waren im Export für den betroffenen Benutzer angegeben (Anzahl)? Du hast den TokenSZ Export als ein betroffener Benutzer ausgeführt, korrekt? Übrigens würde Kerberos Event ID 4 eher auf andere Kerberos Probleme hinweisen (etwa mit fehlerhaften SPNs) anstatt der MaxTokenSize. Aber wenn Du das Problem beheben kannst, wenn Du Gruppen entfernst, deutet alles eher auf die MaxTokenSize hin. --> Oder es sind schlichtweg fehlerhafte Gruppenvergaben mit DENY auf die problematischen Ressourcen... Viele Grüße olc
-
Ich auch - Schreibfehler. :)
-
Nein, in einer Single Label Domain sehe ich spontan keine Vorteile von A-G-DL-P gegenüber A-G-G-P, außer vielleicht der "Übersichtlichkeit". Aber die kann man natürlich auch über das Namensschema darstellen. Du vergißt dabei aber eine Ebene: Nicht A-G-P wäre dann sinnvoll, sondern wenn überhaupt dann A-G-G-P. Läßt Du die Ebene weg, ist kein Rollenkonzept mehr drin bei gleichzeitiger Nachverfolgung der vergebenen Rechte auf Resourcenebene. Wenn jedoch in einer Single Domain Umgebung ein Trust dazu kommt - und das ist durchaus gängig für Migrationsszenarien etc. - sieht es schon wieder anders aus. Die Mitgliedschaft in DL bzw. globalen Gruppen läßt sich dann auch Forest-übergreifend regeln. Und damit schließe ich meine Einschätzung: Um flexibel auch bei Forest Trusts oder bei nachträglich eingerichteten Domänen im selben Forest zu sein, würde ich immer A-G-DL-P empfehlen. Sonst kann sich ein Problem mit dem Gruppenbereich später bei einer Erweiterung zeigen. :) Viele Grüße olc
-
DAS war nicht die Frage. :D :p ...und außerdem, A-G-DL-P klingt irgendwie besser als A-G-G-P. :D Ok, zurück zum Thema? :) Viele Grüße olc
-
Der Gruppenbereich spricht gegen Global Groups. ;) Group scope: Active Directory Viele Grüße olc
-
Hi, Das Prinzip ist IMHO schon in Ordnung - solange es bei MS keine Rückverfolgung der Berechtigungen wie bei Novell gibt. Anders kannst Du kaum nachvollziehen, wo eigentlich der Benutzer Berechtigungen besitzt. Außerdem hilft es, Rollenkonzepte umzusetzen. Loginscripte bringen nichts, der Schlüssel liegt im HKEY_LOCAL_MACHINE Zweig, da hat ein Benutzer ohne lokale Admin-Rechte keine Berechtigungen zu schreiben. :) Alternativ würde ein Startup Script möglich sein (das läuft als SYSTEM) oder aber ein Administrative Template nutzen, welches die Einstellung über die Registry CSE verteilt, siehe dazu: How to use Group Policy to add the MaxTokenSize registry entry to multiple computers . Aber mach da ohne weitere Tests kein größeres Rollout - es kann Applikationen geben, die damit nicht zurecht kommen. Also erst ausführlich testen, sollte die MaxTokenSize tatsächlich die Lösung sein. Viele Grüße olc
-
Hi Sandra, willkommen an Board, :) nach Deiner Beobachtung sieht es ja tatsächlich nach der MaxTokenSize aus. Wenn Du im Kontext eines betroffenen Benutzers (er ist also angemeldet) einmal ein "C:\> whoami /groups" ausgibst - wie viele Gruppen werden angezeigt? Alternativ kannst Du auch gleich TokenSZ verwenden. Sind es mehr als ca. 300 expandierte Gruppen im Token bzw. wie groß ist laut TokenSZ das Token (steht ganz unten)? Wo hast Du die MaxTokenSize angehoben? Auf den DCs oder auf dem Client? Die Einstellung ist im Kern ein Kerberos-Client Setting, muß also für Benutzer zum Beispiel an den XP Clients aktiv sein und benötigt meiner Erinnerung nach einen Neustart. @Norbert: Warum DLG? A-G-DL-P. :) Viele Grüße olc
-
Vertrauensstellung: NT4 Dom. zu 2003/2008 Dom.
olc antwortete auf ein Thema von oernst in: Windows Server Forum
Hi, unter Windows Server 2008 kannst Du noch den Secure Channel "Strong Session Key" abschalten - unter Umständen ist der aktiv? Check einmal die Einstellung zum starken Sitzungsschlüssel auf den DCs: Client, service, and program incompatibilities that may occur when you modify security settings and user rights assignments Registry Schlüssel lautet "RequireStrongKey". In 2008 R2 ist die Einstellung nicht mehr nutzbar, der Secure Channel Strong Sesion Key ist hard-coded unter Windows Server 2008 R2 RTM. Zum jetzigen Zeitpunkt gibt es meines Wissens keinen Workaround dafür. Zeit also, die NT Domänen schnellstmöglich abzuschalten - wenn man einmal davon absieht, daß es dafür schon seit Jahren keine Security Fixes mehr gibt. Viele Grüße olc -
Zertifikatsserver und Webregistierung
olc antwortete auf ein Thema von sabine79 in: Windows Server Forum
Hi Sabine, mal abgesehen davon, daß ich die Webregistrierung ab 2008 R2 nicht mehr nutzen würde, sondern die MMC ;) - was genau meinst Du mit "über die Kommandozeile holen"? Kann es sein, daß auf der SmartCard mehrere Zertifikate gespeichert sind? Viele Grüße olc -
Hi, ok, obwohl Du wieder nicht konkret beantwortet hast, was ich gefragt habe, kann man anhand der Events nun zumindest sehen, daß es sich um ein Network Logon über NTLM handelt. Noch einmal die Frage ob Du das Webinterface von OWA nutzt oder Dich etwa per Popup authentifizierst. Ich vermute letzteres. Wie oft treten die Logon Versuche bei einem konkret betroffenen Benutzer auf, zu welcher Tageszeit und wie viele Logon Versuche werden (nach der Sperrung) unternommen? Viele Grüße olc