NilsK

Moin, ob eine solche Einschränkung akzeptiert wird, hängt immer sehr vom Auditor ab. Es gibt Kunden, die mit sowas durchkommen und damit Lizenzkosten sparen. Andere müssen nachzahlen. Die betreffende VM nur aus der HA zu nehmen, reicht i.d.R. nicht aus. Man muss diese Konfiguration auch über die Laufzeit des Systems belegen können. Daraus sollte auch hervorgehen, auf welchem Host die VM wann lief. Mindestens ein solches zusätzliches Logging ist erforderlich, ohne wird es i.d.R. nicht akzeptiert. Vielleicht können andere noch weitere Erfahrungen beisteuern. Gruß, Nils

Moin, nein. Deine Vorbehalte sind nachvollziehbar, aber für die meisten Szenarien gar nicht zutreffend - unter anderem für das hier diskutierte. Wenn man lastLogonTimestamp für das nutzt, wofür es entworfen wurde, ist es die beste Variante. Gruß, Nils

Moin, sehe ich das richtig, dass ihr die Netze rein logisch trennen wollt, ohne VLANs usw.? Wenn ja: Warum? Gruß, Nils

Moin, wenn der Rechner offline ist, könntest du versuchen, dem Phänomen mit dem Process Monitor auf die Spur zu kommen. Vielleicht ist es nur eine Applikation, die fehlerhaft läuft. Gruß, Nils

Moin, genau aus dem Grund gilt die Empfehlung, dass man (mindestens) einen DC pro Domäne unabhängig von der Virtualisierung hält. Aber ihr habt doch hoffentlich nicht nur einen DC, oder? [Darf man einen Domänencontroller virtualisieren? | faq-o-matic.net] https://www.faq-o-matic.net/2011/02/28/darf-man-einen-domnencontroller-virtualisieren/ Sofern der Cluster und die VMs laufen, ist mit keinen Einschränkungen zu rechnen, wenn der DC kurz nicht erreichbar ist. Sollte tatsächlich kein DC/DNS erreichbar sein, wird es natürlich mit der Namensauflösung schwierig, wenn die Adressen nicht mehr im Client-Cache liegen. Die AD-Anmeldung selbst ist aber längere Zeit gültig. Der Cluster sollte auf jeden Fall AD-integriert sein. Rein DNS-integrierte Cluster haben zahlreiche Nachteile. Gruß, Nils

Moin, ganz ehrlich: Du brauchst mehr Grundlagen. Du gehst teilweise von völlig falschen Vorstellungen aus. Das ist OK, wenn man sich einarbeitet, aber überhaupt nicht OK, wenn man eine Umgebung designt, wie du sie beschreibst. Bei dem Projektumfang ist es grob fahrlässig, sich keine externe Unterstützung ins Haus zu holen, wenn man selbst das nötige Wissen nicht hat. Wir reden hier nicht von Zehntausenden, sondern von einigen Tagen Beratung und Design. Daran sollte so ein Projekt nicht scheitern. Da sich diese Fragen in einem Forum nicht sinnvoll behandeln lassen, klinke ich mich hier aus. Gruß, Nils

Moin, was ist denn das Ziel dahinter? Gruß, Nils

Moin, genau dafür ist lastLogonTimestamp da. Du brauchst ja gar nicht das genaue Datum, sondern eben gerade nur ein ungefähres. Es interessiert dich ja nicht, ob der User heute um 10:20 oder um 8:46 sich angemeldet hat, sondern ob das schon mehr als x Tage her ist. https://blogs.technet.microsoft.com/heyscriptingguy/2010/01/27/dandelions-vcr-clocks-and-last-logon-times-these-are-a-few-of-our-least-favorite-things/ Noch einfacher wäre übrigens OldCmp von Joe Richards: http://www.joeware.net/freetools/tools/oldcmp/index.htm @testperson: 104 Tage sind nicht nötig, wenn man 90 Tage meint. Die 14 Tage muss man nicht draufschlagen - alles, was älter als 14 Tage ist, ist akkurat. Gruß, Nils

Moin, naja, ein bisschen mehr muss man schon tun, um eine PKI abzusichern. Die besteht ja nicht nur aus der Root-CA. Und auch für die Root braucht es noch ein paar Dinge - gesicherter Zugriff, Update-Verfahren usw. Computer außerhalb der Domäne - klar, wenn man das manuell macht, kann man Zertifikate anfordern und einbinden. (Wozu sollen die denn eigentlich dienen?) Danach geschieht da aber auch nichts von selbst. Das ginge nur mit Domänenmitgliedern. Und die CRL muss eine Root-CA selbstverständlich veröffentlichen und aktualisieren können. Das gehört zum Betriebskonzept der PKI und muss schon im Design berücksichtigt werden. Üblich ist ein Webserver, der intern wie extern erreichbar ist. Ohne CRL-Check werden Zertifikate nicht akzeptiert. Das Buch von Brian Komar (es gibt nur eins, was da in Frage kommt) ist das einzige wirklich empfehlenswerte, das ich kenne. Auch wenn es nicht schön ist, kommt man bei solchen Spezialthemen leider ohne Englisch nicht weit. Gruß, Nils

Moin, sagen wir es so: Genau dafür sind kommerzielle Zertifikate da. Hab ich ja oben beschrieben. Völlig übliches Vorgehen. Tja, wie soll ich das beantworten? Hast du dir vorher keine Gedanken darüber gemacht? Zertifikate erneuern sich nicht von selbst, das muss schon jemand tun. Es kann schon Sinn ergeben, eine CA zu migrieren und so weiterzuführen, aber gerade in kleineren Umgebungen ist das keineswegs immer erforderlich. Das ist eine Frage von Anforderungen und Design - vielleicht erwähnte ich das schon, im Zusammenhang mit PKI sollte man sich ausreichend Zeit für Planung und Konzept nehmen, sonst wird das nix. Das lässt sich so nicht beantworten. Wenn man es richtig macht: Keine. Wenn man es nicht richtig macht: Viele. Gruß, Nils

Moin, nein, das ist ziemlich falsch. ;) Gekaufte Zertifikate haben mit einer internen PKI nichts zu tun. Ebenso haben die Root-Zertifikate, die Windows kennt, nichts damit zu tun. Letztere sind dazu da, dass man überhaupt SSL-Seiten im Web aufrufen kann. Dazu muss der Computer den dort genutzten Zertifikaten vertrauen, und das tut er deshalb, weil er die zugehörigen Root-Zertifikate "eingebaut" hat. Ein kommerzielles Zertifikat, das man kauft, ist in aller Regel für die SSL-Absicherung eigener Webseiten da. Dazu könnte man auch Zertifikate aus der eigenen PKI nehmen, aber da hätte man das Problem, dass Externe das zugehörige Root-Zertifikat nicht haben. [Was sind Zertifikate eigentlich und wie funktionieren sie | faq-o-matic.net] http://www.faq-o-matic.net/2012/02/20/was-sind-zertifikate-eigentlich-und-wie-funktionieren-sie/ Wenn du eine interne PKI aufbaust, dann nutzt du diese i.d.R. nur für interne Zwecke. In kleinen Umgebungen haben selbstsignierte Zertifikate kaum Nachteile gegenüber denen aus einer eigenen PKI, daher kann man hier durchaus abwägen. Die eigene PKI hat ja auch ihr Root-Zertifikat, für dessen interne Verteilung man sorgen muss. Gruß, Nils

Moin, na, du bist aber ungeduldig. Es gehört nicht grad zum guten Ton, schon nach wenigen Stunden zu maulen. Du weißt schon, dass das hier ein ehrenamtliches Board ist? Deine Anforderungsliste ist teilweise unrealistisch, in anderen Teilen handelt es sich um Selbstverständlichkeiten. Handelt es sich um einen Testaufbau, oder soll das was Produktives werden? selbstverständlich irgendwie. Nur beißt sich das mit dem zweiten Punkt: CRL-Funktionen sind unabdingbar. Was du wahrscheinlich meinst, ist ein Speicherort für die CRL, der nicht auf demselben Server liegt. Das berücksichtigt man bereits beim Design. Anscheinend hast du erst angefangen und machst dir währenddessen Gedanken - das wird bei einer PKI-Struktur nicht funktionieren. Geht so nicht, jedenfalls nicht ohne Weiteres. Anhand wessen sollte die CA entscheiden, ob sie dem Computer ein Zertifikat geben darf? Beides völlig unabdingbar. Ohne einen Plan dafür fängt man sowas nicht an. Informationen dazu gibt es genug, auch kostenlos im Web. Ansonsten empfehle ich das Buch von Brian Komar, gibt es nur noch gebraucht oder als E-Book, ist aber immer noch die beste Quelle zu dem Thema. Gruß, Nils

Moin, was haben die kommerziellen Zertifikate mit deiner CA zu tun? :confused: Gute Anleitungen zum Design und Aufbau einer PKI-Struktur gibt es viele. Vor allem muss das Design zu den Anforderungen passen. Gruß, Nils

Moin, OK, prima, danke für die Rückmeldung. An diesem Thread lässt sich übrigens sehr schön erkennen, warum es sinnvoll ist, auch die Hintergründe einer Frage anzugeben. Hätten wir gewusst, was du eigentlich willst, wäre mit Sicherheit ein Lösungsvorschlag in dieser Richtung bei der ersten oder zweiten Antwort gekommen. Stattdessen haben wir gestochert und uns mit der Detailfrage beschäftigt, die am Ende gar nicht gelöst werden musste. Aber gut, dass es jetzt klappt. Gruß, Nils

Moin, spricht etwas dagegen, die CA einfach platt zu machen und geordnet neu zu installieren? Sie funktioniert ja offenkundig ohnehin nicht. Alte Zertifikate könnte man, soweit vorhanden, dann einfach "rausaltern" lassen. Wenn es nur um einen einzigen Server geht, ist vielleicht eine Windows-PKI auch oversized. Da könnte man z.B. auch mit OpenSSL arbeiten. Gruß, Nils

Moin, es hat schon seinen Sinn, dass das Board beim Aufruf alter Threads warnt. Bitte eröffne einen neuen Thread und beschreibe dein Problem genau. Meistens ist es nämlich doch "ein wenig" anders, und dann sparen wir uns das Herumraten. Gruß, Nils

Moin, sFile.DateCreated sFile.DateLastAccessed sFile.DateLastModified Sinnvoller wäre allerdings das Präfix o, weil du ja keine Strings, sondern Objekte am Wickel hast. Gruß, Nils

Moin, naja, was soll man von außen dazu sagen ... selbstverständlich hast du Recht, dass das, was du zitiert hast, aus technischer Sicht so nicht geht. Du benennst aber auch schon selbst die politischen Aspekte, und mit denen musst du selbst umgehen. Finde einen Weg, deine Bedenken mitzuteilen und dabei selbst nicht Verantwortung für das zu übernehmen, was du für schlechtes Design hältst. Das wirst du aber selbst schon wissen. Alles Weitere ist für ein Forum ungeeignet. Gruß, Nils

Moin, keine weitere konkrete Idee. Für möglich halte ich, dass Office 2013 die Lizenz prüft, sofern die in der ttf-Datei hinterlegt ist, und dabei feststellt, dass ein Einsatz auf einem Server nicht gedeckt ist. Ist aber nur Spekulation. Ich selbst würde da jetzt keine weitere Energie drauf verwenden, sondern für den Einsatzzweck einen alternativen Font suchen. Da gibt es sicher auch was Günstiges oder Kostenloses. Gruß, Nils

Moin, reicht es evtl. aus, das Dienstkonto in die lokale Gruppe "Ereignisprotokollleser" aufzunehmen? Gruß, Nils

Moin, was für ein Typ ist das? Vielleicht fehlt Office 2013 die Bibliothek, um diesen Typ anzuzeigen. Die Fundstellen im Web lassen vermuten, dass der Font schon ziemlich alt ist. Gruß, Nils

Moin, wenn es vorrangig auf die Feststellung ankommt, von wo die Verbindungen stammen, kann sp_who auch ein Ansatz sein. Das könnte man z.B. über einen Tag periodisch ausführen und die Ergebnisse in eine Datei schreiben. Wenn eine Datenbank lange nicht verwendet wurde, sollte man das am Änderungsdatum der Protokolldatei erkennen können. Gruß, Nils

Moin, naja, komisch erläutert, aber nicht ganz falsch. Der "erste" Dom-Admin ist (ursprünglich) der lokale Administrator des ersten Domänencontrollers. Der hat den RID 500 (der SID endet also auf 500) und man kann ihn, wenn ich nicht ganz falsch liege, gar nicht löschen. (Wäre leicht in einem Lab zu testen.) Ebenso ist er vor Account-Sperrung geschützt, wobei das aber seit Windows 2003 konfigurierbar ist. Und schließlich ist er der vordefinierte Recovery Agent für EFS: [Was muss ich tun, um den ersten DC zu deinstallieren? | faq-o-matic.net] http://www.faq-o-matic.net/2003/08/18/was-muss-ich-tun-um-den-ersten-dc-zu-deinstallieren/ Das mit der Mailbox ist aber nicht richtig. Richtig ist eher, dass "der" Administrator keine Mailbox haben sollte. Wenn er eine hat, dann ist die manuell erzeugt, und natürlich kann man sie dann auch wieder löschen. Gruß, Nils

Moin, he, Leute - Piranha hat ein Produkt als Lösungsmöglichkeit erwähnt, nicht um Bewertung gebeten. ;) Gruß, Nils

Moin, für den Zweck (Einzelfall, so wie ich es verstehe) dürfte Disk2VHD geeignet sein. Gruß, Nils