NilsK

Moin, also, zunächst einmal ist das Papier ausdrücklich eine "Orientierunngshilfe" und keine Vorgabe. Ganz vorne steht ausdrücklich, dass man die konkreten Umstände in Betracht ziehen muss. Daraus folgt, dass es gerade nicht auf ganz konkrete Umsetzungen (wie etwa DNSSEC) ankommt. Oder einfacher: Anders als vermutet bzw. hier in dem Thread dargestellt, gibt es eben keine Verpflichtung, DNSSEC einzusetzen. In dem Kapitel, in dem es um DNSSEC geht, sind Voraussetzungen genannt, unter denen die Transportverschlüsselung ausreicht - die Formulierung ist aber (ziemlich sicher absichtlich) so, dass sie eben auch andere Lösungen zulässt. Damit will ich das nicht weg- oder kleinreden. Sollte sich aber im konkreten Fall zeigen, dass DNSSEC nicht geht, dann sind eben auch andere Maßnahmen möglich. Es ist kein Schwarz/Weiß (ist es bei der DSGVO auch nur selten). - Ob mögliche Alternativen praktikabler sind, steht auf einem anderen Blatt. Gruß, Nils

Moin, man wird das nur organisatorisch lösen können, aber eigentlich ist es ja einfach: Es gibt eine "endgültige" Datensicherung der VM. Die liegt im Tresor. Es gibt eine lauffähige Kopie der VM. Dort richtet man für die relevanten Applikationen Benutzer ein, die nur Leserechte haben. Falls es die "originalen" Benutzer sein müssen, ändert man deren Berechtigungen. Nur diese User können sich anmelden. Im wesentlichen war's das. Wenn jemand die VM kaputtgespielt hat, erzeugt man sie aus dem Backup neu. Optional könnte man, wie ich oben skizzierte, mit einem Snapshot-Verfahren arbeiten. Gruß, Nils

Moin, ist das so? Wer sagt das denn? Möglicherweise liegt hier ein Missverständnis vor. DNSSEC beglaubigt nicht die Echtheit eines Mail-Empfängers. Es stellt sicher, dass die per DNS übermittelten Informationen zu einem Host (typischerweise zu einem Server) korrekt sind. Ob dein Mailserver das prüft, müsstest du in der Konfiguration des Mailservers nachsehen. Was ist denn die eigentliche Anforderung, die du lösen musst? Gruß, Nils

Moin, was soll denn eine "Read-only VM" sein? Weder VMware noch irgendein anderer Hypervisor hat so ein Konstrukt. Eine ganze VM kann schlicht nicht read-only sein. Allenfalls deren Datenbestände, aber das regelst du dann innerhalb der VM, etwa mit Zugriffsberechtigungen auf die Daten. Oder du trickst mit Snapshots und setzt damit die VM regelmäßig "hart" auf einen definierten Zustand zurück - das wäre aber nicht "read-only" sondern "head-off regularly". Gruß, Nils

Moin, das versteh ich nicht. Wie willst du denn ein Schema erzeugen und Berechtigungen vergeben, wenn dir die Rechte dazu fehlen? Und falls das jemand anders für dich tun muss, liegt die Aufgabe doch bei ihm. Also grob gesagt: Wenn es denn mit einem Schema laufen soll, dann erzeugst du ein neues Schema in der Datenbank. Innerhalb dieses Schemas legst du dann deine vier Views an. Falls diese bereits existieren, verschiebst du sie in das neue Schema. Und dann erteilst du eben die Berechtigungen. Oder du sparst dir den Umstand und erteilst die Berechtigungen einfach direkt innerhalb des bestehenden Schemas. Dafür ist die Anweisung GRANT zuständig. Wie ich schon sagte, ein (zusätzliches) Schema ist nicht erforderlich, um Berechtigungen zu vergeben. Es macht die Dinge auch nicht einfacher - jedenfalls nicht, solange wir nicht über ganz andere Größenordnungen sprechen. Gruß, Nils

Moin, ist das eine Schulaufgabe? Gruß, Nils

Moin, das könnte man, aber wenn in deinem Szenario nur die genannten Anforderungen bestehen, wäre die Definition eines Schemas wahrscheinlich zu hoch gegriffen. Bei dir gibt es ja nur wenige einfache Berechtigungen. Da würde man innerhalb des Standardschemas "dbo" bleiben (was auch den Vorteil hat, dass man die Objekte der Datenbank, z.B. die Views, mit einfacherer Syntax ansprechen kann). Ein Schema ist vor allem in komplexeren Situationen interessant, wenn man auch noch Feinheiten wie den Owner-Zugriff steuern möchte oder wenn man auf hoher Ebene sehr unterschiedliche Berechtigungsrollen umsetzen muss. Also, streng genommen ist die Antwort: Ja, man kann die Anforderung mit einem Schema lösen. Aber, wie gesagt, wenn die Anforderung schon vollständig beschrieben ist, dann ist ein Schema unnötig aufwändig. Gruß, Nils

Moin, ja, grundsätzlich ist das so. Der DC verwaltet alle Anmeldekonten und ist daher sicherheitstechnisch sensibel. Außerdem besteht natürlich eine recht hohe Abhängigkeit von dem DC, denn wenn dieser nicht funktioniert, werden einige Applikationen im Netz, die die Benutzeranmeldung brauchen, nicht oder nicht richtig funktionieren. Daher will man Konfigurationen vermeiden, die die Funktion des DCs einschränken könnten. In der Konsequenz führt das zu der Aussage, dass auf einem DC keine anderen Funktionen, Dienste, Applikationen usw. laufen sollten. In einem sehr kleinen Netzwerk kann man natürlich abwägen und von dem einen oder anderen Prinzip abweichen, das für große Netzwerke gilt. Das sollte aber durchaus mit Bedacht und Sachkenntnis geschehen, denn in kleineren Unternehmen findet man umgekehrt leider zu häufig Systeme, die nach dem Motto "alles drauf, passt scho" betrieben werden. Auf solche Systeme kann man sich nicht nur intern schnell nicht mehr verlassen, sondern sie stellen leider auch extern zu oft ein Sicherheitsproblem dar. Vielleicht hast du vor ein paar Monaten die Aufregung um Patientendaten auf Arztrechnern mitbekommen, die schutzlos für jedermann im Internet zugänglich waren. Die Ursache waren genau solche Kleinst-Netzwerke, bei denen allzu wenig Sorgfalt auf sichere Konfiguration und Betrieb gelegt wird. Daher generell: Ja, die Aussage, die du gelesen hast, stimmt. Gruß, Nils

Moin, geht's um Office 365? Dafür hab ich dies hier gefunden: https://www.ivasoft.com/setsensitivity.shtml Gruß, Nils

Moin, ja, so sollte es passen. Viel Erfolg. Gruß, Nils

Moin, nimm es mir nicht übel - aber das erstaunt mich etwas. Aber sei's drum. Vermutlich stolperst du über die "Installation" der Management-Tools. Die nimmt man auf einem Admin-PC vor. Nicht auf einem DC. (Den Artikel bei faq-o-matic.net habe ich jetzt noch mal angepasst, um das deutlicher zu machen.) Von diesem Admin-PC aus machst du dann auch einmalig das Schema-Update, indem du dich dort einmalig mit einem Account anmeldest, der Schema-Admin ist. Auf keinem der DCs läuft bei LAPS ein zusätzliches Stück Software. Nur auf den Clients, deren Kennwörtern per LAPS verwaltet wird, ist das der Fall, und da ist es eine GPO-Erweiterung. Auch auf dem Admin-PC läuft nicht dauerhaft irgendwas, sondern dort startest du nur bei Bedarf eins der Tools, um zu administrieren. Das ist alles. Ganz ehrlich: Um LAPS sinnvoll zu betreiben, brauchst du mehr Sorgfalt bei der Vorbereitung und im Betrieb, als du bisher anscheinend aufgebracht hast. Gruß, Nils

Moin, hm, was soll ich darauf antworten? Ja, du hast etwas übersehen - weil du möglicherweise nicht verstanden hast, was ich dir schrieb. Du installierst bei LAPS nichts auf dem DC. Und wenn dir die Sicherheit der Umgebung irgendwie wichtig ist, administrierst du auch nichts auf dem DC. Was würdest du denn überhaupt "installieren" wollen? Gruß, Nils

Moin, LAPS "installierst" du nicht, du richtest es ein. Es handelt sich ja nicht um eine laufende Serversoftware, sondern eher um eine Infrastruktur. Die eigentliche Arbeit machen die Clients, auf denen du eine Erweiterung für die Gruppenrichtlinien installierst. Dann brauchst du im Wesentlichen nur noch "einen" Adminrechner, der gerade kein DC sein sollte (auf einem DC administriert man ja nicht), sondern auch ein Client sein kann. Und du brauchst zwei AD-Schema-Erweiterungen, die du aber nur einmalig von einem Adminrechner aus einrichtest. Vielleicht liest du dir das Konzept noch mal richtig durch? Hier ist ein hübscher Einstieg dafür: [LAPS – lokales Admin-Passwort endlich sicher | faq-o-matic.net] https://www.faq-o-matic.net/2015/07/01/laps-lokales-admin-passwort-endlich-sicher/ Gruß, Nils PS. die Vorbehalte, die ich in dem von dir genannten Thread gegenüber LAPS geäußert habe, habe ich immer noch. LAPS ist okay, wenn man weiß, was man tut und wenn man es richtig - also sorgfältig - umsetzt. Wenn nicht, dann nicht.

Moin, Und, was belegt das? Nur weil in einem Dialogfenster eine seltsame Option angezeigt wird, ist die Technik, auf die da scheinbar verwiesen wird, ja nicht sinnvoll. Ich kann es gerade nicht testen, aber sicher kann man doch dort einfach den Namen eines Servers angeben. Und selbst wenn man es nicht könnte, wäre das kein Grund dafür, die Netzwerkumgebung zu verwenden. Und auch kein Beleg, dass diese irgendwie zuverlässig sei. Gruß, Nils

Moin, Raid macht man ja auch nicht wegen Geschwindigkeit. Ausfallsicherheit ist das Thema. Und da sind Storage Pools nur begrenzt als Lösung bekannt. Auch wenn der Hersteller da anderes behauptet. Für mich klingt das ganze Konzept noch nicht ausreichend durchdacht. Wie testperson schon sagt, der Bedarf an schnellem Storage erschließt sich nicht ganz. Aber das kann man im Rahmen eines Forums auch nur begrenzt leisten. Gruß, Nils

Moin, Dass ein RAID Controller eine typische Fehlerquelle sei, wäre mir in 25 Jahren noch nicht untergekommen. Ich würde Storage Pools auch nicht mehr zutrauen als einem guten Hardware Raid. Storage Pools sind auch kein Raid. Behalte bei dem Thema auch im Kopf, dass du bei direkt eingebauten Platten immer eine hohe Abhängigkeit vom konkreten Server hast. Mag zum Szenario passen, mag aber auch sein, dass das ein Irrweg ist. Das Host OS auf eine schnelle SSD zu legen, ist jedenfalls unnötig. Generell: ich habe bei Thomas Joos schon zu oft schwerwiegende Fehler festgestellt, sodass ich davon abrate, sich auf seine Aussagen zu verlassen. Gruß, Nils

Moin, Prima, ich hatte das ja auch schon vorgeschlagen. Bitte sprich hier nicht von Replikation - das ist beim SQL Server ganz was anderes, das man heute kaum noch braucht. Log Shipping arbeitet vereinfacht gesagt mir Backup-Techniken, prinzipiell kannst du also auch ein Recovery auf einem anderen Server machen. Es scheint mir, als solltest du doch mal mit jemandem in Ruhe sprechen, der dir die Möglichkeiten erläutert und auch ein sinnvolles Recovery-Konzept mit dir entwickelt. Zum Einstieg: https://www.faq-o-matic.net/2011/01/03/sql-server-wie-datenablage-backup-und-recovery-funktionieren/ Gruß, Nils

Moin, Wie gesagt - eine Frage der Anforderungen. Denkbar ist vieles, aber ob das insgesamt ein stimmiges Konzept ergibt, steht auf einem anderen Blatt. Die halbautomatische Lösung, die ich ansprach, ist auch nicht kompliziert. Die Frage ist ja eher, wie der Wiederanlauf aussehen soll, wie die Clients von der Umschaltung erfahren, vor welchen Ausfällen das Konstrukt schützen soll ... eben viele Möglichkeiten. Gruß, Nils

Moin, Da gibt es verschiedene Möglichkeiten. Du könntest das halbautomatisch mit Voll- und Log-Backups machen, die du bei Bedarf auf B wiederherstellst. Das geht auch automatisiert per Log shipping. Und weiter nach "oben" mit always-on. Alles eine Frage der Anforderungen. Und der Möglichkeiten, die das Budget bietet. Gruß, Nils

Moin, lol ... ja, ich habe eine Idee, was du meinst. Gruß, Nils

Moin Jan, das sollte dir doch der Disti sagen können, oder? Gruß, Nils

Moin, durchaus. Der verdreckt ja auch. Und manchmal wird er beschmiert. Gruß, Nils

Moin, in den meisten Szenarien ist es völlig egal, welche Zone verwendet wird, um einen DNS-Namen aufzulösen. Beide von dir vorgeschlagenen Wege würden für das genannte Szenario also funktionieren. (Sogar parallel - technisch spricht auch nichts dagegen, dass derselbe Client in mehr als einer DNS-Zone eingetragen ist.) Such dir also aus, was anhand möglicher sonstiger Umstände am besten passt. Gruß, Nils

Moin, ein Angreifer müsste das vorbereiten. Er bräuchte dazu einen DNS-Server mit einer präparierten Domain, soweit ich das verstehe, und einen Client, der den Windows-DNS-Server anspricht (dieser dient ja nur als Werkzeug für den eigentlichen Angriff). In einem "normalen" internen Firmen-Netzwerk eher unwahrscheinlich, dass das gelingt - wer so einen Angriff plant, sucht sich leichtere Wege. In einer Umgebung, die mit "unbekannten" Clients zu tun hat, kann das Problem aber durchaus bestehen. Unis etwa nutzen oft (auch) Windows-DNS und haben praktisch keine Kontrolle über die "internen" Clients. In dem Fall würde ich die RRL-Empfehlung auf jeden Fall umsetzen. Gruß, Nils

Moin, die Antwort ist simpel: Das kommt darauf an, was du erreichen möchtest. Um was für "Geräte" handelt es sich denn? Dass sie die Daten aus dem DNS-Server übernehmen, ist ausgesprochen unwahrscheinlich. Das tun eigentlich nur Windows-Rechner, die Mitglied einer Domäne sind. Gruß, Nils