NilsK

Moin,

da es hier um den Anzeigenamen geht: Der ist nach meiner Erfahrung unkritisch. Der wäre im Zweifel aber auch leicht und ohne größere Abhängigkeiten zu ändern.

In Objektnamen hingegen wäre ich auch konservativ. Ein Kunde hatte mal Schrägstriche in seinen OU-Namen. Das ist echt mal ne bl*de Idee.

Gruß, Nils

Moin,

aber dann bau das doch einfach so, wie es gedacht ist. Das Grunddesign von S2D sieht vor, dass Hypervisor - also Hyper-V - und Storage auf demselben System sind. Hieraus bildet man einen Cluster aus mehreren Systemen (sinnvollerweise mind. drei; für Testzwecke usw. geht es auch schon mit zweien), sodass Ausfallsicherheit für die VMs gegeben ist und der Storage automatisch vom System repliziert wird. Für den Hypervisor handelt es sich logisch um lokalen Speicher, sodass kein iSCSI usw. nötig ist.

Da es die Technik seit Windows Server 2016 gibt, wirst du einiges an Dokumentation dazu finden.

Gruß, Nils

Moin,

ich glaube immer noch, dass du auf dem falschen Dampfer bist. Wenn es dir darum geht, Storage bereitzustellen, der auf anderen Systemen genutzt wird, dann ist Storage Spaces Direct nicht die richtige Technik. In dem Fall brauchst du einfach einen Speicherpool und das iSCSI Target (oder meinethalben auch NFS - aber das wird dann auch schon immer praxisferner). Für den Pool würde man dann in der Praxis auch eher ein konventionelles RAID nehmen.

Gruß, Nils

Moin,

Dann hat du es ja bestätigt: wenn die Anforderungen an Verfügbarkeit des Systems so hoch sind, dann braucht es andere Prozesse. Das ist keine Kritik an dir persönlich, sondern ein ernst gemeinter Hinweis.

Gruß, Nils

Moin,

wenn ein Reboot für dich schon ein "finaler Rettungsschuss" ist, solltest du dringend an deinen Betriebsprozessen arbeiten.

Gruß, Nils

Moin,

Vielleicht warten wir erst mal ab, was denn der TO zu seinen Plänen sagt.

Gruß, Nils

Moin,

Wenn du das regelmäßig machst, wäre es dann keine Option, das Gerät in die Domäne aufzunehmen?

Gruß, Nils

Moin,

was soll das denn werden, wenn es fertig ist? S2D ist primär eine Hyperconverged-Lösung, man würde damit also eher "lokalen" (aber replizierten) Speicherplatz für eine Hyper-V-Umgebung bereitstellen. Es ist vom Design her nicht als SAN-Ersatz gedacht, der beliebigen externen Hosts Storage bereitstellt.

Beschreib doch bitte mal, was du vorhast.

Gruß, Nils

Moin,

Ihr habt gesehen, dass nicht der TO die jüngsten Ergänzungen in diesem Thread gemacht hat? Ich glaube, ttom ist gar nicht derjenige, der die Anforderung hat.

Gruß, Nils

PS. Die Aussagen zum BR durften hier kaum zutreffen, außerdem kann ein Mitarbeiter nicht einfach so fordern, dass Anweisungen schriftlich erfolgen. Mit solchen Aussagen sollten wir zurückhaltend umgehen.

Moin,

manchmal bin ich so froh, dass ich Dienstleister bin und kein Admin.

Gruß, Nils

Moin,

und je nach Use Case wäre ein CRM oder ganz was anderes besser ... just sayin'. 

Gruß, Nils

Moin,

hm, also für mich klingt das insgesamt so, als sollte man noch mal prüfen, ob der ganze Ansatz passt. Ich könnte mir vorstellen, dass 15.000 Kontakte in einer Outlook-Mailbox nicht nur an der Stelle problematisch sind.

Gruß, Nils

Moin,

ich kann dir nicht folgen. Wenn die Leute den Schlüssel haben, können sie die Daten doch auch nach Belieben exportieren. Da ist dann kein Vorteil der Verschlüsselung gegenüber Berechtigungen. (Ich meinte damit auch nicht "Berechtigung erteilen", sondern eher "Berechtigung verweigern" ...)

Wie immer in solchen Fällen müssen auch hier die Anforderungen genau definiert werden. "Verschlüsselung" ist fast nie ein passender Lösungsvorschlag. Es wird mindestens viel komplizierter, vielleicht aber auch ganz ungeeignet. Das erlebt man eigentlich jedes Mal, wenn so ein Thema aufkommt.

Boxcryptor verhindert übrigens auch nicht, dass jemand, der an die Daten rankommt, damit beliebige Dinge anstellen kann.

Gruß, Nils

PS. die "Unternehmen, die hoch kritische Geschäftsgeheimnisse auf den Platten haben", haben auch keine wasserdichten Lösungen. Wie man an den Ukraine Leaks sehen konnte.

Moin,

Planner kannst du auch mit On-Prem-Exchange nutzen. To-Do nicht und auch die Exchange-Integration nicht. Wenn das ausreicht, geht es. Macht aber viel weniger Spaß als die integrierte Variante.

Gruß, Nils

Moin,

was spricht dagegen, einfach die Berechtigungen passend zu setzen?

Gruß, Nils

PS. Bitlocker verschlüsselt ausschließlich ganze Datenträger, um Offline-Angriffen vorzubeugen, und wäre hier schon grundsätzlich nicht geeignet.

Moin,

die Gründe sind in meinem Artikel eigentlich schon recht umfassend aufgezählt. Wenn die dich nicht überzeugen, werde ich vermutlich hier auch nicht mehr viel tun können. So mag sich Norberts Reaktion erklären.

Das GUI ist sehr unübersichtlich - wie du ja selbst gemerkt hast, daher deine Frage hier - und verleitet zu falschen Annahmen. Der Assistent kann nur neu zuweisen und verschweigt die vorhandenen Berechtigungen. AD-Berechtigungen können aber sehr heikel sein - ruck-zuck hat man Dinge kaputt gemacht, die man mit dem GUI nicht mehr vernünftig repariert bekommt. Oder man hat Lücken aufgerissen, von denen nach zehn Minuten niemand mehr was weiß.

Ich gehöre zu den Menschen, die auch bei kurzen Fahrten den Gurt im Auto anlegen. Eine Bagatellgrenze gibt es für AD-Berechtigungen aus meiner Sicht - und aus meiner Erfahrung - nicht. Wenn du weder testen noch dokumentieren willst, musst du das selbst wissen. Ich habe den Anspruch, Leute in diesem Forum darauf hinzuweisen, wenn sie aus meiner Sicht etwas auf ungünstige Weise angehen.

Falls du doch Interesse haben solltest, empfehle ich neben dsacls-Skripten das Analyse-Tool LIZA:

[Liza: Berechtigungen in Active Directory analysieren | faq-o-matic.net]
https://www.faq-o-matic.net/2010/04/06/liza-berechtigungen-in-active-directory-analysieren/

sowie zur umfassenden Analyse und Doku dies hier: 

[Berechtigungen in Active Directory dokumentieren | faq-o-matic.net]
https://www.faq-o-matic.net/2013/05/27/berechtigungen-in-active-directory-dokumentieren/

Gruß, Nils

Moin,

der Unterschied ist: "gewählte Objekte" sind nur die Klassen, die du darüber ausgewählt hast. "Alle Objekte" sind alle Klassen, also Computer, Kontakte, User, crossRef, passwordSettingsObjects oder was immer dir einfällt.

Aber ein ganz dringender Rat: Verwalte die AD-Berechtigungen nicht* über das GUI. Und schon gar nicht über den Delegations-Assistenten. Mach sowas nur per Skript und teste es vorher in einem separierten Testlabor. Es gibt dafür ein Kommandozeilentool, das zwar gewöhnungsbedürftig ist, aber alles Wichtige kann. Eine kurze Einweisung findest du im zweiten Abschnitt in diesem Artikel:

[AD-Adressen im Sekretariat bearbeiten lassen | faq-o-matic.net]
https://www.faq-o-matic.net/2008/06/23/ad-adressen-im-sekretariat-bearbeiten-lassen/

Gruß, Nils

PS. genauer sollte hier stehen: NIE, NIE, NIE

Moin,

um das mit dem Backup einfach mal explizit zu machen: Ihr sichert falsch. Ein geeignetes Sicherungsprogramm kann mit so einer Situation umgehen, wenn es einen Service-Account verwendet, der über das "Backup"-Privileg auf dem jeweiligen Rechner verfügt. Dieses Privileg ist genau dafür da und sorgt dafür, dass der Account sich über (fehlende) Berechtigungen hinwegsetzen kann. Recht einfach lässt sich dieses Privileg zuweisen, indem man den Service-Account in die lokale Gruppe "Sicherungsoperatoren" aufnimmt - wohlgemerkt, lokal auf dem Dateiserver, nicht die Gruppe im AD.

Und zur Folder Redirection: Ja, kann gehen, hat aber seine Caveats, wie man heute so schön sagt:

[Ordnerumleitung – Denial of Service in Wartestellung | faq-o-matic.net]
https://www.faq-o-matic.net/2011/11/14/ordnerumleitung-denial-of-service-in-wartestellung/

Gruß, Nils

Moin,

Der "Jemand" soll aber nur diese Mails nicht weiterleiten können? Oder gar keine? Und neue Mails soll er senden können? Oder wie?

Erschließt sich mir nur schwer, was da das Szenario sein könnte. Wie schon beschrieben, wird man das nur näherungsweise hinbekommen, aber nicht "sicher".

Klingt mir so, als wäre Mail das falsche Medium, um diesen "Jemand" zu informieren.

Gruß, Nils

Moin,

Mails weiterzuleiten, ist zunächst ein Client-Feature. Für "die Mailbox", also den Server, der diese hostet, ist eine Weiterleitung nicht sicher zu unterscheiden von einer "neuen" Mail.

Was ist denn das zu lösende Problem?

Gruß, Nils

Moin,

es geht um das Serverprodukt, das von der NTP-Organisation gepflegt wird. Das Problem besteht also nur, wenn man selbst dieses Serverprodukt einsetzt. Die Nutzung der Dienste von pool.ntp.org stellt kein Sicherheitsproblem für die Nutzer dar - außer dass evtl. eine manipulierte Zeit zurückkommt, falls diese Dienste tatsächlich mit der nicht gepatchten Version laufen sollten.

Wenn du also diese Software nicht selbst einsetzt, besteht kein Handlungsbedarf.

Gruß, Nils

PS. die heise-Meldung ist ziemlich schlecht geschrieben.

Moin,

wenn es ein wenig Geld kosten darf, könnte der User Profile Wizard von ForensiT einen Blick wert sein.

Gruß, Nils

Moin,

Die kurze Antwort ist: das wirst du mit einem Allzweck-System wie Windows nicht hinbekommen. Selbst näherungsweise wird das nichts, wenn du Flexibilität zulassen willst wie "mal eben eine Verknüpfung anlegen".

Die längere Antwort würde umfassen, dass ihr vor allem eure wichtigen Daten und Systeme mit Berechtigungen schützt. Dann ist es egal, welche Werkzeuge jemand hat und man muss auch keine Verrenkungen wegen Cmdlets anstellen. Den Desktop einzuschränken, ist immer nur ein Versteckspiel. Gerade wenn jemand fit ist, wird er Mittel und Wege finden.

Unterschätze auch nicht die Wirkung rechtlicher Vereinbarungen, betrieblicher Regeln usw. Wenn es wirklich ein Praktikant ist, wird er sich daran halten. Wenn es ein Verbrecher ist, werden ihn simple Desktop-Sperren auch nicht aufhalten.

Und um es noch mal zu betonen: eine Einschränkung per GPO lässt sich nicht mit "höheren Rechten" umgehen. Man muss sie explizit aufheben. 

Gruß, Nils

Moin,

Naja, wenn man meint, dass man selber mit seiner Arbeit Geld verdienen will, andere das aber nicht dürfen, dann sind 150 Dollar schon sehr viel.

SCNR,

Nils

Moin,

ich verstehe das Problem nicht - und vermute, dass da einige Irrtümer bezüglich Windows, Benutzerprofilen und GPOs vorliegen.

vor einer Stunde schrieb Nummernschild-B:

Wenn ich mich als Nutzer (Praktikant im konkreten Beispiel) an einem Domänenrechner anmelde, sehe ich dort ordnungsgemäß nur die Oberfläche / die Einstellungen, die per AD/GPO für dieses Benutzerprofil vorgesehen sind.

Ist das eine Zustandsbeschreibung? Oder ein Ziel?

Wenn es eine Zustandsbeschreibung ist, der Zustand aber nicht zu den Anforderungen passt, dann solltest du den Zustand ändern. Sprich: dann sind die Einschränkungen wohl nicht passend.

vor einer Stunde schrieb Nummernschild-B:

Nun soll z.B. eine neue Verkünfung mit einem Netzwerkordner in der rechten oberen Ecke auf dem Desktop platziert werden.

Da stößt mir schon die rechte obere Ecke auf. Was machst du denn, wenn an dem Arbeitsplatz eine andere Auflösung ist? Muss es wirklich die rechte obere Ecke sein? Wenn ja, dann ist möglicherweise der herkömmliche Desktop gar nicht die richtige Oberfläche.

Und wenn du die Anforderung hast, dass ein User eine neue Verknüpfung anlegen können soll, dann solltest du ihm die Möglichkeit dazu nicht nehmen. Sonst beißt sich die Katze in den Schwanz. 

vor einer Stunde schrieb Nummernschild-B:

Ebenso kann ich das Konto nicht zum lokalen Adminstrator machen und mich dann neu anmelden, da die Rechte gemäß Einstellung dafür fehlen.

Das liegt aber dann daran, dass deine Einschränkungen nicht zu den Anforderungen passen. Die gelten dann ja unabhängig davon, was der User darf. Mit Rechten hat das nichts zu tun, und deshalb ...

vor einer Stunde schrieb Nummernschild-B:

Also wäre es gut, ein Benutzerprofil während einer Anmeldesitzung mit höheren Rechten versehen zu können

... würde das hier gar nichts ändern. Wenn du einem Account per GPO die Möglichkeit nimmst, Einstellungen vorzunehmen, dann ändern auch höhere Rechte nichts daran.

Allgemein ist man schon lang davon weg, Usern "per Technik" detaillierte Vorgaben zu machen, wie ihr Desktop auszusehen hat. Es kommt darauf an, 1. ihnen funktional bereitzustellen, was sie für die Arbeit benötigen und 2. ihnen den Zugriff dort zu verweigern, wo sie wirklich nicht randürfen. Den lokalen Desktop einzuschränken, ist dabei fast nie ein geeignetes Werkzeug.

Gruß, Nils