NilsK

Moin,

sehe ich auch so. Das Missverständnis ist vermutlich: Einstellungen in verschiedenen Bereichen der Gruppenrichtlinien können durchaus "additiv" sein bzw. sind es in der Regel. Hier ergibt das Konzept der "Delta-Richtlinien" durchaus Sinn (übrigens ist das so eine Erfindung der Autoren, das ist kein allgemein üblicher Ausdruck). Einstellungen für denselben Eintrag sind aber in aller Regel nicht "additiv". In dem Beispiel, das wir hier diskutieren, geht es ja um genau einen Wert (nämlich die Angabe, wer ein bestimmtes Benutzerrecht erhält). Der wird durch die GPOs vollständig gesetzt. Die Komponente, die das umsetzt, geht nicht die einzelnen Teile des Werts durch und prüft, was es da nun wie zusammenbasteln müsste. Hier also "ganz oder gar nicht", wenn man so will.

Das ist möglicherweise in dem Buch nicht so ausdrücklich beschrieben. Sowas liegt dann daran, dass die Autoren selbst nicht auf diesen Gedanken bzw. auf diese Lesart gekommen sind. (Ansonsten kann man den Autoren durchaus vertrauen, Peter kenne ich sogar persönlich. Und dem Verlag natürlich auch. )

Gruß, Nils

Moin,

vor 5 Minuten schrieb michelo82:

Aber warum geht es denn nicht additiv?

weil GPOs (leider) nicht nur einen Umsetzungsmechanismus haben, sondern mehrere Dutzend. Und die funktionieren nicht einheitlich.

Ein guter Bekannter und ich sind uns gerade nicht ganz sicher, wir vermuten aber, dass die Zuweisung von Benutzerrechten einfach nicht additiv bzw. modular ist. Dort gilt dann das Prinzip "Last Writer Wins".

Andere Einstellungen sind durchaus modular, vor allem die unter den Administrativen Vorlagen.

Gruß, Nils

PS. falls du mit der "Fachliteratur" einen Autor mit den Initialen T.J. meinst - dem würde ich praktisch nix glauben. Da fehlt oft die Sorgfalt.

Moin,

ich wäre an der Stelle bei Mark "gruppenrichtlinien.de" Heitbrink und würde das direkt in der DDCP eintragen. Es geht hier ja offenbar um Einstellungen, die direkt und ausschließlich auf die DCs wirken sollen. Da würde ich mir den modularen Krempel einfach sparen.

Die Gruppen würde ich hier allerdings anders bauen. Ich entwärfe eine DL-Gruppe "DL-DC-Local-Logon", der ich das Recht zuwiese. Danach müsste ich das Recht (und das GPO) nie wieder anfassen, sondern verwaltete ausschließlich die Gruppenmitgliedschaften.

Für RDP-Anmeldung gibt es sogar schon eine Gruppe, da muss man an das Recht überhaupt nicht ran.

Edit: Hier noch der Link zu Marks Artikel - und der Hinweis, dass er sogar einen handfesten Vorteil nennt, genau diese Einstellung in der DDCP zu machen.

[Default Domain Policy und Default Domain Controllers Policy ändern oder nicht? - Gruppenrichtlinien]
https://www.gruppenrichtlinien.de/artikel/default-domain-policy-und-default-domain-controllers-policy-aendern-oder-nicht

Und es steht auch da, dass die eigene Policy, wenn vorhanden, oben stehen muss ...

Gruß, Nils

Moin,

vor 2 Stunden schrieb joseph_halter:

dass es von der Netzwerkperformance her kein Problem ist

das "Netzwerk" hat damit nun überhaupt nichts zu tun. Und die Zahl an Zertfikatsempfängern, die du angibst, ist gering, nicht hoch. Das sind gerade mal ein paar hundert Zertifikate, die werden ja nicht alle auf einmal ausgestellt. Und selbst wenn - es wäre ja kein Problem, wenn das "ein paar Minuten" dauert. Wir reden hier ja von einmaligen Vorgängen, die sich normalerweise nur alle paar Wochen, Monate oder noch seltener abspielen. Die Verzögerung in dem Prozess ist auch organisatorisch, denn jemand (oder etwas) muss das Zertifikat ja genehmigen. Das Erzeugen spielt da zeitlich keine Rolle.

Behalte auch im Kopf, dass asymmetrische Verschlüsselung nicht für Massendaten eingesetzt wird, sondern nur für den Schlüsselaustausch (fast ausschließlich). Die VPN-Session selbst (oder der Web-Traffic, die Dateiverschlüsselung, ... usw.) wird symmetrisch verschlüsselt, das geht viel schneller. Und der Schlüssel dafür wird eben asymmetrisch verschlüsselt.

vor 2 Stunden schrieb joseph_halter:

Was für Quellen fügst du zu deinen Empfehlungen oben an, wenn jemand kritisch ist und diese Laufzeiten länger haben will.

Gar keine, solche Fragen hat mir an der Stelle noch niemand gestellt. Auch nicht im Finanzsektor oder in der Atomindustrie. Abgesehen davon, ist das dermaßen "Best Practice", dass das niemandem fragwürdig erscheint, der die Materie kennt.

Gruß, Nils

PS. ich habe mir gerade mal dieses gruselige BSI-Papier angesehen, das sicher zu einem der schlimmsten aus dem Hause zählt. Abgesehen davon, dass man dort die relevanten Informationen geschickt zwischen akademischem Blabla versteckt (das in dem Papier nichts zu suchen hat), sind die Aussagen zur Laufzeit von Zertifikaten alle nur "sollte"-Angaben. Daraus ergibt sich also nicht mal für die Organisationen eine Verpflichtung, die sich den Maßnahmen unterwerfen. Die Jahreszahlen, die dort angegeben sind, beziehen sich auf den Einsatz vom Schlüsseln "geringer" Länge, also auf konkrete Verschlüsselungsvorgänge (das hat mit Zertifikatslaufzeiten nichts zu tun). Selbst das ist aber nur theoretisch hergeleitet.

Moin,

ich glaube, bezüglich der Performance hast du falsche Vorstellungen. Ein Zertifikat mit 4096 Bit auszustellen (was heute übliche Empfehlung ist), ist keine ernsthafte Herausforderung. Ein CA-Server ist typischerweise nicht groß dimensioniert, die meisten Kunden betreiben sowas als eine eher kleine VM. 

Die Zertifikatslaufzeit berechnet man normalerweise rückwärts, ausgehend von der maximalen Laufzeit der Endzertifikate. Eine typische Rechnung geht so:

• Laufzeit ausgestellter Zertifikate nicht über 2 Jahre (wobei der typische Wert darunter liegt, etwa 1/2 oder 1 Jahr; manchmal auch nur Wochen oder Tage)
• Die Issuing CA soll Zertifikate mindestens einmal verlängern können, bevor ihr eigenes Zertifikat ausläuft, also: Lifetime Issuing CA = 2 * Laufzeit Zertifikat + Puffer; im Beispiel also: 2 * 2 Jahre + 1 Jahr = 5 Jahre
• Genauso auch die Root CA, deren Zertifikat es auch zulassen soll, die CA-Zertifikate einmal zu verlängern: Lifetime Root CA = 2 * Laufzeit Issuing CA + Puffer; also: 2 * 5 Jahre + 1 Jahr = 11 Jahre

Wichtig ist, dass das Design der PKI zu den Anforderungen des Unternehmens passt und dass man die Technik einordnen kann. Eine interne CA setzt man praktisch nur noch für interne Zwecke ein, extern erreichbare Systeme versorgt man mit kommerziellen Zertifikaten oder per Let's Encrypt. Die Laufzeit eines (internen) Webserver-Zertifikats ist dann weniger kritisch, wobei ich da heute auch nicht mehr über 1 Jahr setzen würde, eher weniger. Der Bequemlichkeitsgewinn durch lange Laufzeiten rächt sich zumeist durch mangelnde Routine mit dem Wechselvorgang.

Gruß, Nils

Moin,

ja, die Idee kam mir auch, aber zu spät. 

Gruß, Nils

Moin,

Naja, ich nehme man an, dass es hier erst mal um das Wurzelverzeichnis geht. Nicht um das lokale Speichern insgesamt.

Gruß, Nils

Moin,

fein, danke für die Rückmeldung.

Gruß, Nils

Moin,

icacls könnte das Problem sein. In vergleichbaren Situationen wird oft auf SetACL von Helge Klein verwiesen. Ich probierte also, ob es damit ginge.

Geprüft habe ich das nicht und zur Ursache des beschriebenen Phänomens habe ich auch keine Hypothese.

Gruß, Nils

Moin,

Ist nicht irgendwie alles vergebens?

Gruß, Nils

Moin,

Ist ja auch ziemlich genau das, was da steht: Kennwort läuft nie ab. Das bedeutet, dass das Kennwort nie abläuft.

Wenn man einen regelmäßigen Wechsel erzwingen möchte, dann darf das Häkchen nicht gesetzt sein. Eine andere Frage wäre, ob man heute tatsächlich noch einen regelmäßigen Wechsel erzwingen will. Aber das gehört vielleicht hier nicht her.

Gruß, Nils

Moin,

Mit iPads dürfte zumindest das, was wir gemacht haben, nicht gehen. Dort hatten wir per gruppenrichtlinie Einstellungen vorgegeben, durch die die clients irgendwie den Ordner eingebunden haben. Danach ging es automatisch, aber die Richtlinie musste einmal laufen. Soweit meine erinnerungen.

Gruß, Nils

Moin,

die Richtlinie zum Ablauf greift nicht, der Rest schon.

Gruß, Nils

Moin,

Wir haben kürzlich Office-Vorlagen per Ohnedrive auf alle Rechner gebracht. Das dürfte dem ja entsprechen. Leider weiß ich den genauen Weg aus dem Kopf nicht mehr, aber am Ende war es simpel. Bei Bedarf könnte ich nachfragen.

Gruß, Nils

Moin,

hier noch der Link - übrigens ist der Artikel von einem ehemaligen Boardmember:

[Wann läuft ein Maschinenaccount / Computerkonto ab? Gar nicht! | Microsoft Docs]
https://docs.microsoft.com/de-de/archive/blogs/deds/wann-luft-ein-maschinenaccount-computerkonto-ab-gar-nicht
 

vor 4 Stunden schrieb testperson:

P.S.: Ist da irgendeine Form der Autokorrektur in die Hose gegangen oder verstehe ich den Zusammenhang mit dem Teddybär nicht?

Kann man so sagen. Ich hab den Beitrag am Handy geschrieben bzw. genauer: diktiert. Und das, was Android da anstelle meiner Grußformel fabriziert hat, fand ich so putzig, dass ich es habe stehen lassen.

Gruß, Nils

(sprich: Gruß Komma Nils ...)

Moin,

ich zitiere mal ein verdientes Boardmitglied: Es ist immer die Firewall.

Gruß, Nils

PS. und DNS natürlich.

Moin,

Auch wenn es um Kennwörter geht und Computer logisch User sind - ein nicht geändertes Kennwort ist bei Computern längst nicht so problematisch wie bei Benutzern. Einem Computer kann man nicht über die Schulter sehen, wenn er ein Kennwort eingibt. Und wir reden nicht von Strings wie "papa2020".

Es gibt einen guten alten Artikel darüber von einem deutschen Microsoft-Mitarbeiter, den suche ich später noch mal raus.

Gruß, Nils

Moin,

Natürlich haben Computer im AD auch Kennwörter. Wie sollen sie sich sonst an der Domäne anmelden?

Technisch betrachtet sind Computer im AD auch User. Die Attribute dafür sind also dieselben. pwdLastSet in dem Fall.

Wozu brauchst du die Informationen?

Grosse comme un nounours

Moin,

das ist korrekt, aber für das, was der TO vorhat, würde es ausreichen. Tatsächlich ist das ja auch genau das, was DNS macht: Eine zentrale Datenbank für die Zuordnung von Namen zu IP-Adressen bereitstellen. Da ist auch kein Protokoll und kein Port angegeben, das macht dann der Browser. Einen Redirect sucht der TO ja auch nicht, sondern er möchte eine Namensauflösung sicherstellen.

Gruß, Nils

Moin,

siehste, das meine ich mit "sich besser auskennen als ich". 

Das mit dem Timestamp hatte ich mir auch schon gedacht, aber wenn ich das Verfahren richtig verstehe, nutzt es gar kein Code-Signing-Zertifikat. Das wäre dann vielleicht eine Alternative für die Zukunft, denn denselben Effekt müsste man ja auch per Code Signing erzielen können.

Gruß, Nils

PS. "lösen lösen" ist sehr schön. 

Moin,

theoretisch würde das gehen, aber glaub mir: Du willst keine hosts-Dateimanipulation. Das macht nur Ärger.

Um wie viele Clients geht es denn und was gibt es sonst noch im lokalen Netzwerk? Einen DNS-Server mit Split-DNS und Forwarding einzurichten, ist ja nun kein Hexenwerk.

Gruß, Nils

Moin,

wer auch immer "das RDX" ist ... aber ja, das geht problemlos. Hyper-V kann eine VM importieren, ohne dass man diese vorher ausdrücklich exportiert hat. Einfach die Ordnerstruktur mit allen Daten der VM an die gewünschte Stelle kopieren, dann im Hyper-V-Manager "Importieren" auswählen. Für nicht laufende VMs ist das die einfachste Methode.

Wie die Partition (bzw. das Volume) dann heißt, ist egal. Falls der Pfad hinterher derselbe ist wie vorher, kannst du dir evtl. auch das Importieren sparen, aber das macht vielleicht zwei Minuten Unterschied. 

Gruß, Nils

Moin,

ah, OK. Wie man vielleicht merkt , habe ich mit RDS nicht so viel zu tun. Daher die Nachfrage, ich wollte schauen, ob da nicht was missverstanden ist. Ist es anscheinend nicht, passt.

Also, vorbehaltlich einer Äußerung von jemandem, der die RDS-Dinge besser kennt als ich, bin ich (weil ich mich hier ja schon eingemischt habe) der Meinung, dass ein abgelaufenes Zertifikat vom System sicher nicht akzeptiert wird. Daher wird man die RDP-Datei mit dem neuen Zertifikat neu signieren müssen.

Gruß, Nils

Moin,

vor 9 Minuten schrieb Alith Anar:

Im letzten Jahr wurde aber auch das RDS Icon mit dem sich die Benutzer auf den RDS verbinden signiert, natürlich mit dem damals aktuellen jetzt ablaufenden Zertifikat.

was genau soll das heißen? Wie signiert man ein Icon?

Gruß, Nils

Moin,

wer Bedenken hat, kann ja auch mit separaten Rechnern arbeiten. So abwegig ist das nun auch wieder nicht. Und unbequem - ja, meine Güte, sicher. Das relativiert sich spontan, wenn man sich mal die Umstände ansieht, die an wirklich regulierten Bereichen gelten (Krankenhaus, Pharma, Kraftwerke ...). Wir reden hier ja nicht von den Normalanwendern, sondern von den Admins.

Gruß, Nils