NilsK

Moin, das ist ziemlich typisch für Umgebungen, wo der Admin die Bedeutung der Gruppen missverstanden hat. Es gibt tausende Umgebungen, in denen User sich per RDP an den DCs anmelden dürfen, aber nicht an den Terminalservern. Wenn du also schon dabei bist - werte auch noch mal die Gruppen unter "Builtin" aus. [AD-Standardgruppen auswerten | faq-o-matic.net] https://www.faq-o-matic.net/2014/09/01/ad-standardgruppen-auswerten/ [Windows-Gruppen richtig nutzen | faq-o-matic.net] https://www.faq-o-matic.net/2011/03/07/windows-gruppen-richtig-nutzen/ Hier sind die Standardeinstellungen aus der Default Domain Controllers Policy: Hm, das sollte eigentlich eine Tabelle sein. Naja, lass ich jetzt so. Hier noch ein Screenshot der lokalen Default-Einstellung, da die DDCP gar nicht alles enthält: Gruß, Nils

Moin, ich verstehe, was du meinst. Und genau daher der Hinweis: Teams ist kein IT-Thema. Es ist ein Organisationsthema. Wir beraten das oft für Kunden, die im ersten Ansatz bei der Einführung gescheitert sind und dann einen neuen Aufschlag suchen. Wenn man es mit der nötigen Einbettung angeht, funktioniert "Teams" viel besser. Gruß, Nils PS. dieses Video illustriert, was ich meine: https://www.youtube.com/watch?v=vWqUp3IyUkY

Moin, typischerweise wird dafür heute "Self-Service" empfohlen. Das lässt sich dann über Office 365 Groups und über Teams lösen. (Wobei man Teams nicht wegen sowas einführen würde, das ist ein Organisationsprojekt.) Ist nicht dasselbe, aber ist die typische Antwort. DDL werden allgemein skeptisch gesehen, weil bei der Dymamik eben auch viel Unerwünschtes geschehen kann. Manche Kunden bauen sich selbst eine Lösung, indem sie "herkömmliche" Gruppen per Skript pflegen und dabei selbst die Logik festlegen. Gruß, Nils

Moin, am Ende heißt der sinnvolle Weg dafür: Nutzungskonzept entwickeln und den Anwendern vermitteln. Das ist vermutlich nicht das, was du hören willst, aber Teams ist nun mal keine Software, sondern ein Organisationswerkzeug. Gruß, Nils

Moin, vielleicht solltest du dich mit den Grundlagen des Themas erst mal in Ruhe befassen - nichts für ungut. Deine Fragen deuten darauf hin, dass dir das grundlegende Verständnis fehlt. Eine Access-Datei ist eine Datenbankdatei. Diese ist darauf ausgerichtet, dass man sie ständig verändert. Es wäre daher sinnlos, eine solche Datei zu signieren, denn die Signatur ist in dem Moment ungültig, wo sich auch nur ein Bit der Datei ändert. Das passt schlicht nicht zu einer Datenbank. Gruß, Nils

Moin, dann arbeitest du in einer Umgebung, von der es in der freien Wildbahn nicht viele gibt. Tatsächlich ist es in vielen Umgebungen genau umgekehrt: durch den Einsatz von RDS (mit oder ohne Citrix oben drüber) reduziert man die Komplexität. Weder das eine noch das andere fällt aber in die Kategorie "one size fits all". Gruß, Nils

Moin, willkommen an Board. Wenn du keinen anderen User hast, mit dem du dich mit ausreichenden Rechten anmelden kannst, dann gibt es keine Möglichkeit. Das ist ja der Sinn so eines Aufbaus. Du müsstest dann also den Server aus einem Backup wiederherstellen. Der Vollständigkeit halber verweise ich auf die Boardregel Nr. 8, dass wir Angriffe auf Systeme und "vergessene Kennwörter" hier nicht unterstützen und nicht diskutieren. Gruß, Nils

Moin, ah, jetzt dämmert's. Du meinst die Standard-Einstellungen im Hyper-V-Manger? Mit dem Speicherort für Virtuelle Maschinen meint Microsoft den Ort, wo die Konfigurationsdateien der VMs liegen. Das sind wenige Kilobytes und ist für Platz und Performance völlig egal. Relevant sind die VHDX-Dateien - eigentlich ausschließlich diese. Sogar der Speicherort des Host-Betriebssystems ist ziemlich egal, weil auf diese Dateien eher selten zugegriffen wird. Als Best Practice gilt, dass man alle Dateien einer VM in denselben Ordner speichert. Man legt also, vereinfacht gesagt, auf dem Volume, das die VMs beherbergt, einem Ordner "VM" an und dort einen Ordner pro VM. In diesen kommen alle Dateien, die zu der VM gehören. Das passt für die allermeisten Zwecke. Gruß, Nils

Moin, Du verwendest anscheinend die Begriffe nicht korrekt. Leider lässt sich nicht verstehen, was deine Frage ist. Gruß, Nils

Moin, Möglicherweise hattest du auch noch nicht bedacht, dass du für einen 2019-Server auch 2019-CALs brauchst. Wenn du jetzt feststellst, dass es auch mit 2012 R2 geht, dann hättest du ja vielleicht eine Menge Geld umsonst ausgegeben. Gruß, Nils PS: in einem RZ installiert man selbstverständlich neu. Dort packt man aber auch nicht mehrere Funktionen auf denselben Server.

Moin, ich würde sowas auch nie per Cloning machen. Neuinstallation ist schnell und risikolos. Die wenigen Parameter, die man in Hyper-V dann noch setzen muss, kann man vorher dokumentieren - mit diesem Skript eine Sache von Minuten. https://gallery.technet.microsoft.com/Get-HyperVInventory-Create-2c368c50 Gruß, Nils

Moin, ob du die CA noch brauchst, kannst du recht einfach feststellen, indem du dir ansiehst, ob sie Zertifikate ausgestellt hat, die noch gültig sind. Wenn ja, schaust du dir die Systeme an, auf denen diese verwendet werden. Solltest du feststellen, dass du noch eine CA brauchst, musst du die alte aber auch nicht migrieren. In den meisten Fällen ist dann der bessere Weg, eine neue PKI ordentlich (!) aufzusetzen und die verwendeten Zertifikate gegen neue von der neuen CA auszutauschen. Oft wird nur migriert, weil man es kann, und dann hat man eine unnötig schlecht eingerichtete PKI. Gruß, Nils

Moin, wenn du gar nicht in der PowerShell unterwegs bist, würde ich das mit adfind.exe auf der Kommandozeile lösen. http://joeware.net/freetools/tools/adfind/index.htm Gruß, Nils

Moin, stell es dir vor wie bei einem Webserver und dessen TLS-Zertifikat ("SSL-Zertifikat") - das ist ziemlich exakt dasselbe. Der Webserver hat ein Zertifikat, mit dem er die Verschlüsselung einleitet. Der Client braucht kein Zertifikat, er muss nur dem Zertifikat des Servers vertrauen. Dafür muss man ihm das Root-Zertifikat seiner PKI zugreifbar machen. Genauso ist das auch beim DC und dem LDAPS-Zertifikat. Die Artikel, die du zitierst, gehen von anderen bzw. speziellen Voraussetzungen aus. Sie gelten nicht allgemein. Im ersten Fall geht es um LDAP-Loadbalancer (die ohnehin im AD nicht supported sind), im zweiten um spezielle Szenarien bei DCs, die mehr als ein Zertifikat haben (was man vermeiden sollte, aber in den meisten Fällen auch kein Problem darstellen würde). Gruß, Nils

Moin, gut, dann dürfte der Principal "Domänencomputer" der richtige sein. Da ich keine Erfahrungen mit diesem Setup habe, würde ich versuchen, ob es ausreicht, dieser Gruppe Schreibrechte auf den Ordner zu geben. Leserechte würde ich nur einer Gruppe geben, die auf die Keys wirklich zugreifen darf. Allerdings würde ich auch noch mal bewerten, ob diese "zweite Option" wirklich sinnvoll ist. Die Ablage im AD erfolgt mit einem anderen Mechanismus, der (vermutlich) besser abgesichert ist als ein Share. (So genau habe ich das noch nicht analysiert, aber in der Tendenz gehe ich davon aus.) Eine zweite Option hat immer einen grundsätzlichen Nachteil: In der Regel ist sie leichter anzugreifen als die primäre Option, mindestens aber eröffnet sie einen zusätzlichen Angriffsweg. Gruß, Nils

Moin, ähem, liebe Kollegen - bitte seid doch einfach mal deutlich. Also: "System" bezeichnet in Berechtigungen immer das lokale System. Bei einem Share wäre das also das Betriebssystem des Dateiservers. Also mit Sicherheit nicht die Instanz, die da zu schreiben versucht - das wäre ja das Betriebssystem des Clients. Diese Berechtigung passt also schon mal nicht. Dann: Man sollte auf Share- und NTFS-Ebene nicht in dieser Form die Berechtigungen unterschiedlich halten. Da NTFS das leistungsfähigere Berechtigungssystem hat, sollten nur dort die Berechtigungen stehen. Das Share wird dann für "Jeder: Vollzugriff" berechtigt. [Datei- und Freigabeberechtigungen in Windows | faq-o-matic.net] https://www.faq-o-matic.net/2015/12/28/datei-und-freigabeberechtigungen-in-windows/ Ob der Mechanismus, den du beschreibst, den Sicherheitsanforderungen genügt, die man zur Ablage von Bitlocker-Schlüsseln haben sollte, kann ich nicht einschätzen. Seltsam klingt für mich, dass du die Keys von "Standalone-Clients" in das Share legen willst. Sind die nicht Mitglieder im AD? Dann wirst du dort kaum eine sinnvolle Berechtigung vergeben können. Gruß, Nils

Moin, heißt was? Wie viele Clients, wie viele User? Wie viele Server sind AD-Mitglieder? Sind Dateiserver mit Berechtigungen dabei? Andere Systeme mit Windows-basierten Berechtigungen? SharePoint? SQL Server? Ein internes Mailsystem, das die Daten (Adressen, Gruppen) aus dem AD nutzt? Drucker, Scanner mit LDAP-Abfragen? Web-Gateways mit LDAP-/AD-Abfragen? All das sind Beispiele für Systeme, die bei einer Migration (oder einer Umbenennung per rendom.exe für die, die auch bei 220 auf der Autobahn noch beschleunigen) zu berücksichtigen - und sehr wahrscheinlich zu bearbeiten - sind. Das mag eine Idee des Aufwands und des Risikos vermitteln. Und möglicherweise die Argumentation gegenüber der Marketing-Abteilung erleichtern. Auch die genannten Workarounds sähe ich kritisch. Das mag vordergründig das Problem "lösen", aber wehe, man ändert irgendwo mal irgendwas - in ein paar Wochen kann sich niemand erinnern, was da hingebastelt wurde. Gruß, Nils

Moin, ja, man hat sowas früher oft mit SUBST "gelöst". Ist aber auch eher halbgar. Gruß, Nils

Moin, oha. Ich wage energisch zu bezweifeln, dass du auf dem Weg irgendein sinnvolles Ziel erreichst. Ich verstehe den Ansatz, aber das wird nix. Schon deshalb nicht, weil du heutzutage nicht davon ausgehen kannst, dass zu jedem "langen" Namen tatsächlich ein 8.3-Name vorhanden ist. Schau dich einfach mal mit "dir /X" in einem CMD-Fenster in verschiedenen Ordnern um. Wenn wirklich eine Software beteiligt ist, die mit langen Pfaden nicht umgehen kann, dann ist der einzige sinnvolle Weg, die Pfade tatsächlich zu kürzen, d.h. die Daten in eine einfachere Struktur zu verschieben. EDIT: Weil ich jetzt doch noch ein wenig rumgesucht habe, hier eine interessante Fundstelle dazu. Aber: du bist gewarnt. Für produktionsreif halte ich das nicht. Bei mir gibt es mehrere Volumes ohne Kurznamen. https://devblogs.microsoft.com/scripting/use-powershell-to-display-short-file-and-folder-names/ Gruß, Nils

Moin, könntest du bitte noch mal erläutern, was du dir unter einer vorstellst? Gruß, Nils

Moin, meine letzten Kunden, die gegen meinen Rat angefangen haben, ihr AD "umzubenennen" (= in ein neues AD zu migrieren), wollten mir nicht glauben, dass das zu einem empfindlich fünfstelligen Projekt wird. Das haben sie dann erst getan, als sie mittendrin mal die Rechnungen addiert haben. Aber bitte, muss jeder selbst wissen. "rendom.exe" willst du nicht benutzen. Sofern Exchange im Einsatz ist, kannst du es auch nicht. Nur damit du nicht sagst, es habe dich keiner gewarnt. Gruß, Nils

Moin, die schlichte Antwort noch mal deutlicher: Weil das AD dann nicht mehr geht. [Was muss ich beim DNS für Active Directory beachten? (Reloaded) | faq-o-matic.net] https://www.faq-o-matic.net/2007/01/09/was-muss-ich-beim-dns-fuer-active-directory-beachten-reloaded/ Gruß, Nils

Moin, wer baut denn sowas? Die übliche Weiterleitung geht andersrum, also von "kein Hostname" zu "www". Am einfachsten (möglicherweise auch die einzige Möglichkeit): Ihr sprecht mit eurem Marketing, dass sie diese hinderliche Konfiguration entfernen und den Webserver mit www-Hostnamen zum Standard erklären. Dazu böte es sich an, wie oben erwähnt die Umleitung umzukehren. Und weil du vermutlich als nächstes danach fragst: Das AD umzubenennen, erfordert eine vollständige Migration in einen neuen AD-Forest. Kann man machen, ist aber sehr aufwändig. Und dann nimmt man (um auch das schon erwähnt zu haben) einen abstrakten AD-Namen, der nichts mit dem Firmennamen und der Domain zu tun hat. Gruß, Nils

Moin, das (der vertrauenswürdige Speicherort) scheint mir durchaus ein Element zu sein, das den Makroschutz fragwürdig macht. Wie immer bei Pfadregeln. Gruß, Nils

Moin, liegt die Datei an einem Speicherort, der zuvor als "vertrauenswürdig" deklariert wurde? Dann prüft Office erst gar nicht ... Quelle: https://support.office.com/de-de/article/ändern-der-makrosicherheitseinstellungen-in-excel-a97c09d2-c082-46b8-b19f-e8621e8fe373 Kann ich hier auch nachstellen. Schalte ich auf "deaktivieren", kann ich xlsm-Dateien von einem Ordner öffnen (und Excel führt die Makros aus), den ich früher als vertrauenswürdig deklariert habe. Kopiere ich dieselbe Datei in einen lokalen Pfad, den ich für sowas noch nie genutzt habe, führt Excel die Makros nicht aus. Ohnehin muss man sagen, dass die heise-Meldung (wie so oft) von falschen Annahmen ausgeht, was den Umgang in Unternehmen angeht. Da wird i.d.R. viel mit Makros gearbeitet, aber selten signiert oder sowas. Daher schalten nur wenige Unternehmen Makros wirklich aus. Gruß, Nils