NilsK

Moin,

die Frage ist doch, warum das überhaupt geschehen soll. Meine Vermutung: Auf dem Server, um den es geht, besteht kein Bedarf mehr an einem "echten" SQL Server und die Lizenz soll frei werden, um sie woanders zu nutzen.

Also, unabhängig davon, ob es einen technischen Weg gibt, der theoretisch ein direktes Downgrade ermöglicht (was ich immer noch bezweifle) - die Versionen unterscheiden sich so stark, dass ich keine Experimente vornehmen würde. Ich würde die Datenbank(en), um die es geht, sichern, dann den SQL Standard deinstallieren und dann den SQL Express installieren. Backup wiederherstellen, fertig. Das dauert vielleicht zwei Stunden. Ein Downgrade-Versuch würde nicht viel schneller gehen, dafür aber ein (aus meiner Sicht erhebliches) Risiko des Scheiterns enthalten, und dann dauert es viel länger.

Gruß, Nils

Moin,

Geht es denn mit dem SID eines Users? Wenn nein, arbeitet die Methode nicht mit SID. Wenn ja, muss es ja doch an der Gruppe liegen.

Was sind denn die Eigenschaften der Gruppe?

Gruß, Nils

Moin,

Hab ich doch schon mehrfach gesagt. Ich würde einfach direkt den Gruppen die Berechtigungen auf die vorhandenen Views geben. In dem kleinen Umfang, den du beschreibst, reicht das doch völlig aus.

Dazu dient das Kommando GRANT, wie auch schon gesagt.

Gruß, Nils

Moin,

Und wenn du das Skript als User aus der Zieldomäne ausführst?

Gruß, Nils

Moin,

Falscher Gruppentyp?

Gruß, Nils

Moin,

ich stolpere darüber, dass du die NetBIOS-Schreibweise für den Namen mit dem DNS-Domänennamen verwendest. Das funktioniert manchmal, aber manchmal auch nicht. Ich nehme mal nicht an, dass der NetBIOS-Name "DomB.local" ist, sondern eher "DOMB", oder?

Ansonsten würde ich persönlich Berechtigungen per Skript nur mit SetACL setzen. Vielleicht wäre man da aber auf dasselbe Problem gestoßen.

Gruß, Nils

Moin,

vor 25 Minuten schrieb Squire:

beim Serverstart ist ja dann weder AD noch DNS etc. da.

das ist für den Betrieb als Host ja auch nicht nötig. Seine VMs startet er dann trotzdem. Nach ein paar Minuten gibt es dann also wieder AD und DNS. Und dafür hat man den Vorteil, dass man den Host über das AD konfigurieren und verwalten kann.

Um aber vielleicht noch mal auf den Ursprung des Threads zurückzukommen: Man darf hier durchaus mal die Größe des Netzwerks in den Blick nehmen. Es sind weniger als 10 User. Zwischendurch wurde hier ein Vorschlag diskutiert, der von mindestens fünf zu verwaltenden Servern ausgeht. Nicht so richtig angemessen ...

Gruß, Nils

Moin,

vermutlich kann man technisch Nano auch für Nicht-Container verwenden, es wird eher eine Supportfrage sein. Microsoft entwickelt das einfach nicht mehr für andere Zwecke weiter.

Gruß, Nils

Moin,

soweit ich weiß, ist für Nano die Software Assurance nötig. Das liegt daran, dass Nano eben keine normale Installation ist, sondern immer auf dem aktuellen Service-Release neu installiert werden soll. Und das braucht SA.

Der Rest ist "normal", d.h. eine Standard-Lizenz gilt für einmal physisch oder zweimal virtuell.

Edit: Was hast du denn vor? Nano ist ja vor allem als OS-Basis für Container gedacht. Für "normale" Server ist das ausgesprochen nutzlos.

Gruß, Nils

Moin,

eine Anleitung kann ich dir nicht geben. Konkrete Umsetzungserfahrung habe ich mit Schemas im SQL Server nicht - weil, wie ich vielleicht schon andeutete, nur selten Bedarf daran besteht. Als nächstes müsstest du jedenfalls deine Views in das Schema verschieben (mit ALTER SCHEMA sollte das gehen) oder diese dort anlegen, falls sie noch gar nicht existieren. Erst danach kannst du Berechtigungen vergeben.

Oder, wie gesagt, du lässt den Umweg mit dem Schema einfach bleiben ...

Gruß, Nils

Moin,

das sind ja nicht nur verschiedene Editionen, sondern verschiedene Produkte. Das wird ohne Neuinstallation ziemlich sicher nicht gehen.

Gruß, Nils

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,

vor 19 Minuten schrieb Pitti259:

Die Übertragung von E-Mails mit personenbezogenen Daten ist nur dann erlaubt, wenn neben der Transportverschlüsselung auch der Empfänger seine Adresse per DNSSEC zertifiziert hat.

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,

vor 1 Minute schrieb CoolAce:

[NilsK] LAPS "installierst" du nicht

...

[CoolAce] Aus dem Text ... habe ich geschlossen das ich es auf dem DC installieren muss

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