olc

Hi PsyStorm und willkommen an Board, :) wenn Du über ein geroutetes Netzwerk sprichst (wie in Deinem Fall), kannst Du die NetBIOS Namensaufösung der Netzwerkumgebung nicht nutzen. Die Netzwerkumgebung wird über Broadcasts aufgelöst und genau diese Broadcasts werden nicht geroutet. Alternative wäre also nur ein WINS Server oder aber das direkte Verbinden der Netzlaufwerke (setzt voraus, daß Du den Namen kennst). [EDIT] Lukas war schneller. :) [/EDIT] Viele Grüße olc

Hi, ich weiß nicht so recht, warum Du die Beiträge teilen möchtest. Das Thema Sicherheit gehört in den Ursprungsthread hinein; und zwar genau da hinein und nicht in eine Grundsatzdiskussion. Das Problem ist, daß Du bzw. vielleicht auch Deine Vorgesetzten das nicht hören wollen, aber dafür kann ich / können wir nichts. Es ging in Deinem Urspungsthread um eine Steuerungsmaschine, also vermute ich, daß sich Dein Arbeitgeber als "Mittelständler" bezeichnet? Vielleicht sogar eine GmbH? Falls ja, dann kann die Geschäftsführung mit Ihrem Privatvermögen haftbar gemacht werden, wenn grob fahrlässig Dritte gefährdet werden (etwa als Opfer von Viren- / Spam- / Trojaner-Attacken, die aus Deinem Netzwerk kamen). Und mit dem Betreiben von nicht gepatchten Rechnern und dem Herabsetzen von Systemsicherheitseinstellungen hast Du mit Sicherheit kein Argument für sinnvolle technische Lösungen zur Anhebung der Netzwerksicherheit eingebracht. Zusätzlich ist dieser Bereich im Normalfall ganz besonders an einem "sicheren Netzwerk" interessiert. Mittelständler fürchten sich vor Spionage - Unternehmen - Mittelstand - Blickpunkt Mittelstand - Nachrichten + Trends - Handelsblatt.com Aus nachvollziehbaren Gründen werde ich mich aus der weiteren Diskussion hier heraushalten. Wenn Du renitent gegen gut gemeinte und vor allen Dingen produktive Hinweise bist, hilft so ein Thread nicht weiter. Viele Grüße olc

Hi, neben dem o.g. Hinweis auf die RMS sei noch die aktuelle c't genannt. Dort ist ein Artikel zu dem Thema bzw. angrenzenden Aspekten zu finden. c't 3/2010, Seite 138 ff. Viele Grüße olc

Hi, ich weiß, Du wirst es nicht hören wollen, aber ich sage es trotzdem. ;) Was würde es Euer Unternehmen kosten, wenn Ihr aufgrund der manuell heruntergesetzten Sicherheit in der Gesamt-Umgebung Opfer eines Angriffs oder Datendiebstahls werdet? Sicher weit mehr als das Ersetzen der entsprechenden Software. Wir reden hier von einem Betriebssystem, welches knapp über 12 Jahre (!) alt ist (und übrigens schon viele, viele Jahre keinerlei Sicherheitsupdates mehr verfügbar sind)... Viele Grüße olc

Daß es Sicherheitstechnisch der Super-GAU ist, das Domänen-Admin Konto für Dienste zu nutzen, ist Euch bewußt...? Prüfe wie oben angegeben alle Dienste, gplante Tasks und Scripts etc. Dort wird irgendwo das Konto mit alten Anmeldefunktionen noch hinterlegt sein. Viele Grüße olc

Hi, schau Dir einmal die Rights Management Services an: http://www.microsoft.com/windowsserver2003/technologIEs/rightsmgmt/default.mspx Viele Grüße olc

Hi, ja, das Sharing gilt in Arbeitsgruppen nur auf der lokalen Maschine; in Domänenumgebungen geht es dann auch remote. Ggf. kann man in der Umgebung darüber nachdenken, ob generell eine Domäne Sinn macht. Das mußt Du entscheiden. :) Viele Grüße olc

Hi, im Normalfall kannst Du das Target dann noch mittels DFSUTIL entfernen: Dfsutil Examples: Storage Services; Remote File Systems; File and Storage Services Bei dem Thema: In Windows Server 2003 R2 gibt es keine "One-Way Replication". Wenn Du die Verbindungsobjekte manuell deaktiviert hast, dann solltest Du die Replikationsgruppen schleunigst neu aufbauen, das kann bis hin zum Datenverlust führen. Viele Grüße olc

Hi, ohne eine Domänenumgebung klappt das nicht - EFS benötigt auf Remote Shares das Recht "Trusted for Delegation" auf dem Server / Computerobjekt. Handelt es sich um eine Arbeitsgruppe oder um Domänenclients? Viele Grüße olc

Hi, ja, wie gesagt. Die hardware clock auf einigen Maschinen funktioniert in VMs eben nicht einwandfrei. Daher auch mein Einwand, daß etwa der PDC eine gute Wahl ist, wenn man einnen DC physisch laassen möchte. Wenn Du einen ESX hast, dann hast Du wahrscheinlich auch VMWare Support? Ggf. würde ich bei VMWare einen Call aufmachen, so daß sie sich das Problem anschauen können. P.S.: Ich persönlich bin kein Fan von automatisierten Zeitabgleichen (etwa mittels der genannten NTP Dienste) des PDCe der Root Domäne (oder anderer DCs). Ich würde das immer von Hand machen. Aber das nur "nebenbei". :) Viele Grüße olc

Hi, Du könntest es mit einer FOR /F Schleife durchführen, indem Du Dir erst alle IE-Prozesse bzw. deren PIDs ausliest (und z.B. in eine Datei schreibst) und die PIDs dann nacheinander abarbeitest. Aber einmal anders gefragt: Muß es BATCH sein oder ist auch die PowerShell eine Alternative? Viele Grüße olc

Hi, schau doch einmal in die Feature-Liste des jeweiligen HSM Anbieters. ;) Spontan würden mir 3 Dinge einfallen, es gibt aber weit mehr Faktoren, die für eine HSM sprechen: 1. Höhere Sicherheit, da das HSM gesondert gesichert (Zugriff als auch Datensicherung) und betrieben werden kann. So kann man auch die Anwesenheit von mehreren Personen erzwingen, wenn Schlüsselmaterial erstellt werden soll o.ä. 2. Diverse HSM bieten die Möglichkeit, nicht nur eine Maschien zu bedienen, sondern im Netzwerk zu arbeiten. 3. Ein großer Teil der Rechenarbeit verlagert sich vom Server auf die HSM, so daß die Durchsatzrate bei guter Planung gesteigert werden kann. Dies ist meiner Erfahrung nach jedoch eher für größere Umgebungen oder Provider relevant. Wie gesagt, nur ein Auszug. ;) Viele Grüße olc

Hi, die CA Funktionalität hat nichts mit den FSMO Rollen zu tun. ;) Daher wäre die Reihenfolge in Bezug auf FSMO und CA "Deinstallation" egal. Ich persönlich würde wohl so vorgehen, wenn ich einen solchen DC demoten müßte: 1. FSMO Rollen manuell an gewünschten DC übertragen. 2. CA Backup und Deinstallation (man bedenke, daß man nicht "mal eben" eine bestehnde C / PKI außer Betrieb setzen kann / sollte). 3. DCPROMO Demotion. Viele Grüße olc

Hi, ja, eine CA sollte nach Möglichkeit immer "alleinstehend", also auf einer Stand-Alone Maschine oder einem Member-Server installiert werden (je nach Anforderung). Auf der Maschine sollte dann als "öffentlicher" Dienst ausschließlich die PKI Funktionalität genutzt werden und keine weiteren Dienste. Andere Konfigurationen machen sicherheitstechnisch keinen Sinn, insbesondere bei CAs (und mit Einschränkungen bei DCs) nicht. Viele Grüße olc

Hi, ich würde aus Sicherheitsgründen stark davon abraten, CA und DC auf einer OS-Instanz zu installieren. Wenn Du es trotzdem machen möchtest, dann muß zuerst das DCPROMO erfolgen und danach die CA Installation. Eine demotion des DC ist dann jedoch erst nach Deinstallation der CA möglich. Wie gesagt, ich würde davon abraten. Viele Grüße olc

Hi, es ist immer empfehlenswert, nach so langer Zeit einen neuen Thread aufzumachen. Der Hinweis zum Threadalter kommt ja nicht umsonst. ;) Hier geht es weiter: https://www.mcseboard.de/windows-server-forum-78/rolle-dc-ca-maschine-reihenfolge-161234.html Viele Grüße olc

Hi, das magst Du stark bezweifeln, es ändert nichts an meiner Empfehlung einen Anwalt zu konsultieren. Ich bin mir da nämlich sehr sicher - denn Kennwörter haben rein gar nichts mit Firmeneigentum zu tun. Du hast da scheinbar eine falsche Definition von diesem Begriff. Rein Datenschutz-technisch ist das Thema natürlich auch relevant: http://www.datenschutz-bayern.de/technik/orient/pwreg.htm Ok, ich habe gesagt, was ich zu sagen hatte und klinke mich aufgrund der Bedenken in Bezug auf rechtliche Fragen im Forum einmal aus. ;) Viele Grüße olc

Hi, nur noch als Zusatz: Für HOCHsicherheitsumgebungen empfiehlt Microsoft mindestens 10 Anmeldeversuche. Im Normalfall 20 - 50, je nachdem, ob ein Monitoring erfolgt oder nicht. Bei 5 DCs kannst Du wie angesprochen neben dem LogParser problemlos auch die PowerShell, die im Blog genannte Batch-Variante oder den EventCombMT nutzen (sofern dieser bei Dir keine Probleme verursacht, wie von Nils beschrieben). Wie angesprochen solltest Du explizit prüfen, ob die Konten gesperrt oder deaktiviert sind. Viele Grüße olc

Hi Vicky und willkommen an Board, :) grundsätzlich würde ich mir genau überlegen, ob Du diese Einstellung wirklich verändern möchtest. Es kann diverse Wechselwirkungen mit anderen Applikationen geben, die das propagierte Zertifikat benötigen, um die Verbindung zum privaten Schlüssel auf der SmartCard zu "erkennen". Falls Du es doch machen möchtest, schau einmal in der MS KB nach "disable certificate propagation" oder hier: SmartCard Infrastructure : Smart Card related Group Policy Settings in Vista Viele Grüße olc

Hi Leute, wir dürfen hier keine rechtlichen Aspekte besprechen, daher belasse ich es beim Hinweis auf den Rechtsanwalt Deiner Wahl; denn es ist rechtlich nicht einwandfrei. Das Kennwort gehört zu den Daten eines Benutzers, die meines Wissens nicht abgefragt werden dürfen(!). Viele Grüße olc

Hi, Wie viele DCs habt Ihr denn genau? Denn auf den DC würden Kontensperrungen geloggt werden. Bedenke dabei, daß der LogParser etwas Einarbeitungsaufwand benötigt. Zusätzlich bieten natürlich größere Lösungen komfortablere Wege, so etwa SCOM mit den Audit Collection Services. "Automatische Deaktivierung" ist relativ. Ich persönlich sehe sehr oft Scripte, die das übernehmen. Oftmals weiß die eine Hand nicht, was die andere tut... Guter Einwurf, wenn es 5 ungültige Anmeldeversuche bis zur Sperrung sind, können wir eigentlich an dieser Stelle hier aufhören. :D Viele Grüße olc

Jepp, Thomas hat Recht. :) Ich war derjenige, der sich verzählt hat. ;) VIele Grüße olc

Hi gnoovy, am besten Du besorgst Dir ein entsprechendes Buch (z.B. das Windows PKI Buch von Brian Komar) und fängst mit den Grundlagen an. Wir können wir nicht alle Deine Fragen nacheinander beantworten, wenn diese im Kern dort beantwortet werden. ;) Kurz und knapp: zu 1. Standardinstallation heißt nicht, daß man rein gar nicht tun muß. Es funktioniert ja auch so. Aber in jeder MS PKI Literatur wirst Du den Hinweis finden, daß Du Anpasseungen an Deine Umgebun vornehmen mußt. Wie soll es sonst auch funktionieren? Es weiß ja niemand, wie Deine Umgebung aussieht außer Du selbst. zu 2. Ugestellt hast Du es laut Deinen Screenshots schon, nur eben erst nach der Ausstellung des Sub-CA Zertifikats. Daher sind die URLs nicht in diesem Zertifikat vorhanden. Du müßtest also das Sub-CA Zertifikat erneuern, dann wären die zusätzlichen URLs im neuen Zertifikat der Sub-CA vorhanden. zu 3. Erneuern kannst Du das Zertifikat, indem Du den entsprechenden Ablauf auf der Root-CA durchführst. ;) zu 4. Ja, das kannst Du dort machen. Das muß dann jedoch regelmäßig stattfinden. Du kannst es auch mittels des Befehls "certutil -crl" auf der jeweiligen CA initiieren. Zusätzlich solltest Du beachten, daß die offline Root-CA, die sicherlich nicht Domänenmitglied ist, nicht auf den LDAP Pfad schreiben kann. Daher mußt Du die CRL und Delta CRL manuell ins LDAP schreiben. Auch dazu gibt es diverse Anleitungen, Stichowrt wäre "certutil -dspublish". Bitte habe Verständnis, daß nicht alle Deine Grundsatzfragen an dieser Stelle ausführlich zu beantworten sind. Sonst würde ich eher ein Buch schreiben - aber das haben andere schon getan. ;) Viele Grüße olc

Hi Nils, in kleineren Umgebungen funktioniert das Tool zumindest meiner Erfahrung nach recht gut. Aber Du hast in jedem Fall Recht, der LogParser ist da eine ganz andere "Marke". Ich dachte nur, daß das in diesem Fall eher als "overkill" erscheint. ;) Alternativ kann man "quick and dirty" auch das unten genannte Batch-Script nutzen: Aktives Verzeichnis Blog : Grundsätzliche Informationen zum Security Event Logging / Auditing Viele Wege und Rom usw. ;) Viele Grüße olc

Hi, der Export von CA2 war korrekt. Da die URL des Root Zertifikats ausschließlich per LDAP bereitsteht (was nicht optimal ist, aber in der Testumgebung sollte es ausreichend sein), brauchst Du eigentlich nichts "umziehen". Die AD sollte immer verfügbar sein. Lediglich bei Ablauf / Erneuerung des Root Zertifikats mußt Du das angehen: ---------------- Zertifikat abrufen ---------------- Überprüft "Zertifikat (0)" Zeit: 0 [0.0] ldap:///CN=winnet-CA1-CA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=winnet,DC=local?cACertificate?base?objectClass=certificationAuthority Problematischer ist jedoch, daß die Delta CRLs abgelaufen sind: ---------------- Zertifikat abrufen ---------------- Überprüft "Basissperrliste (01)" Zeit: 0 [0.0] ldap:///CN=winnet-CA1-CA,CN=CA1,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=winnet,DC=local?certificateRevocationList?base?objectClass=cRLDistributionPoint [color="Red"] Abgelaufen "Deltasperrliste (01)" Zeit: 0 [0.0.0] ldap:///CN=winnet-CA1-CA,CN=CA1,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=winnet,DC=local?deltaRevocationList?base?objectClass=cRLDistributionPoint[/color] ---------------- Basissperrliste veraltet ---------------- Abgelaufen "Deltasperrliste (02)" Zeit: 0 [0.0] ldap:///CN=winnet-CA1-CA,CN=CA1,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=winnet,DC=local?deltaRevocationList?base?objectClass=cRLDistributionPoint Hier liegt ein Problem, da durch diese abgelaufene Delta CRL die Zertifikatkette als üngültig eingestuft werden wird und die Überprüfung von Zertifikaten damit fehlschlägt. Da mußt Du also ran und dafür sorgen, daß diese Delta CRL regelmäßig veröffentlicht wird (per "certutil -dspublish" etwa). Viele Grüße olc