NorbertFe

Dann gib mal Bescheid, wenn du es eruiert hast, damit der Thread hier nicht erodiert. ;)

Doch. Und die genauere Erklärung siehe unten. Deine Filter überschneiden sich. Sinnvoller wäre vermutlich auf ein Attribut zu filtern, welches einen Techniker eindeutig identifiziert und das nicht ein Teil des DN ist. ;)

Wie Nils schon schrub, ist das nicht möglich im AD.

Was deutlich angenehmer ist/war. ;)

Wobei das Argument der Interoperabilität ja jeder bringen kann, um sich nicht zu verändern. ;) An der Stelle würde ich von SAP eben auch erwarten, dass sie zwar drauf hinweisen, aber die Empfehlung sollte ja trotzdem lauten die höchstmögliche Sicherheit umzusetzen. Was dann eben bedeutet, dass die interoperablen Systeme sich mitändern müssen. :)

Sehe ich auch so. Von TLS 1.2 steht ja nix drin.

Wenn die Lizenz aber durch Lizenzgründe mit win10 teurer wird, sind die Kostengründe ja eher für Server. ;)

Dann solltest du ihnen sagen, sie sollen bei extensiv bleiben, wegen Gründen siehe Nils' Antwort. :)

Na dann ist ja nicht so schlimm. Echtes Problem wäre, wenn er es exzessiv oder intensiv nutzen würde. ;)

Stimmt Wolfpack war zumindest deutlich instabiler und genauso schlecht dokumentiert. ;)

Und das muss unbedingt ein Windows 10 sein? Tuts nicht ein Windows Server 2016/2019? Wär lizenztechnisch definitiv einfacher.

Mit dem KMS vom 2022 DC bspw. also zumindest wenn die alle in einem entsprechenden Netzwerk hängen. Und einen Berater der mir sowas wie oben erzählt, würd ich komisch anschauen und fragen, wo das steht. :) Bye Norbert

Alles andere was ich kenne, würde nicht billiger. ;)

Wär bei O365 direkt sowas hier möglich: https://learn.microsoft.com/de-de/microsoft-365/compliance/ome?view=o365-worldwide

standardmäßig auf jeden Fall übers I-net. Kann man per Policy abdrehen, damit nicht ständig Anfragen an der Firewall ankommen. Da könnte man dann aber sehen, wo die Kisten hinwollen. Lt. obigem Link muss das dann ja http://ctldl.windowsupdate.com sein.

Die Empfehlung lt. Security Guide ist sowieso den Store komplett zu leeren und nur die reinzunehmen, von denen man weiß, dass man sie benötigt. ;) Alternativ schau mal, ob das auch noch für 2016 aufwärts gilt. Ich habs nicht getestet: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn265983(v=ws.11)

Du könntest dir natürlich auch die notwendigen Zertifikate selbst verteilen. :) Dann hast du komplette Kontrolle.

Häh? Sbs?

Die kms Schlüssel ändern nix an irgendwelchen Versionen. Die aktivieren alle Versionen für die sie vorgesehen sind. Also kms win10 aktiviert Client os ab Vista Aufwärts (egal ob, pro, Business, Enterprise) und kms Server 2019 aktiviert alles was Client und Server ab Vista aufwärts ist. Und welche Dinge sind das? Ja.

Full Access vergibt man sinnvollerweise weder auf Share noch auf ntfs Ebene für Nutzer. ;) auch wenn das hier alles eher nach „Ausprobieren“ klingt.

Nimm ihm die Rechte auf ntfs doch mal weg. Dann siehst du was er in der Freigabe machen kann. Nämlich nix. zu deinem Problem. Welche Rechte gibts denn auf ntfs Ebene?

Das kann man so sehen, aber wenn die ntfs rechte nicht stimmen, siehst du auch nix trotz Share. ;) einfach mal mit der gui Ausprobieren, dann wird’s klarer.

Wo ist denn da der Zusammenhang? net Share erstellt freigabeberechtigungen. Icalcs vergibt ntfs Berechtigungen. Sieht man bspw. Hier: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/icacls shareberechtigungen sind gegenüber ntfs Berechtigungen nachrangig. Wenn man also keine ntfs rechte auf eine date im c:\Briefe hat, kommt man da auch nicht über die Freigabe ran.

Ich hab ja keinen Twitter Account (auch noch nie besessen), aber manchen gehts eben ums Prinzip. So wie mir, weswegen ich keinen Account habe. ;)

Nein exposed host ≠ bridge mode. Hier schön erklärt mit Bildern. :) https://schroederdennis.de/allgemein/fritzbox-bridge-mode-aktivieren-und-genau-erklaert-6591-6660/