NilsK

Moin, was ist das Ziel des Ganzen? Da das schnell in Richtung Mitarbeiterüberwachung geht, bewegst du dich da möglicherweise auf dünnem Eis. Rein technisch könnte das schwierig werden. Auch hier wäre also interessant, was denn als Anforderung dahintersteht, vielleicht gibt es Alternativen. Gruß, Nils

Moin, meines Wissens aktualisiert der Client dies, wenn er dem Konto "beitritt" oder wenn sein Betriebssystem aktualisiert wird. Einen zusätzlichen Update-Mechanismus für das Feld gibt es nicht, meine ich. Das müsste man also, wenn man es haben will, irgendwie selbst machen. Ich rate allerdings davon ab, derartige Informationen im AD zu speichern bzw. sie von dort zu beziehen. Wie du siehst, ist das AD für solche Details nicht gemacht. Wenn du organisatorische oder technische Prozesse mit solchen Daten füttern willst, dann nimm dafür ein System, das auch dazu gedacht ist (in diesem Fall wohl eine Inventarisierung). Gruß, Nils

Moin, du hast aber gesehen, dass es sich da nicht um ein GPO-Buch handelt, sondern um eins zu Windows-Sicherheit insgesamt? Vor dem Hintergrund finde ich deine Kritik jetzt ausgesprochen hoch gegriffen. Gruß, Nils

Moin, vor allem nervt es, dass du hier so rumbrüllst. Vielleicht denkst du darüber mal nach. Gruß, Nils

Moin, ach schau. Auf die Betrachtung wäre ich gar nicht gekommen. Danke für den Hinweis. Und das könnte der Grund sein, warum ich so nicht gedacht habe. Gruß, Nils

Moin, möglicherweise ein sehr alter Artikel. Man liest auch oft noch Kompatibilitätsbedenken zu 4096-Bit-Schlüsseln, wie Norbert es ja oben auch angemerkt hat. Tatsächlich habe ich aber schon jahrelang keine Geräte mehr bei Kunden angetroffen, die das nicht gekonnt hätten. Solche Pauschalbedenken halten sich aber gern ewig. Die Einwände, die man wirklich zu PKI haben kann, beziehen sich einerseits auf die konzeptionellen Grundlagen (aus meiner Sicht ist das ganze Prinzip "krank" und nicht vertrauenswürdig, aber wir haben nichts Besseres) und vor allem auf die organisatorische Umsetzung. Mit Zertifikaten wird einfach unglaublich geschlurt, und dann sollte man es lieber ganz bleiben lassen. Wer die passenden Prozesse nicht festlegen und einhalten kann, sollte einfach keine PKI betreiben. Gruß, Nils

Moin, kann ich dir bei dem Detail nicht genau sagen, aber im Wesentlichen wird es dasselbe Phänomen sein. Vielleicht kommt an der Stelle noch dazu, dass die beiden Konfiguratoinsmethoden für die Überwachung nicht richtig kompatibel miteinander sind. Falls du gerade dabei bist, dir Wissen anzueignen: Nimm dir weniger komplexe Beispiele. Du hast hier gerade zwei Stellen, die "speziell" sind. Wie gesagt - mehrere Dutzend Mechanismen bei der GPO-Abarbeitung. Falls es um konkret umzusetzende Einstellungen geht: Nimm dir viel Zeit, eine gute Laborumgebung, die du auf einen definierten Stand zurücksetzen kannst, und befasse dich erst mit den Mechanismen selbst und dann mit der Verteilung. Gruß, Nils

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, 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, 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. 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 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