NilsK

Moin, vor allem ist das ein Thema, für das man sich Zeit und Ruhe nehmen muss und das man nicht mit ein paar Notizen und Anmerkungen in Foren abhandelt. Auch wenn Admins das ungern hören. Das muss kein monatelanges Schwärzen von Papier in Aktenordnern sein, aber ohne Plan und Sorgfalt kann man es gleich bleiben lassen. Die ganze Idee beruht darauf, von dem hemdsärmeligen Mal-Eben wegzukommen, das insbesondere in Windows-Netzwerken üblich ist. Gruß, Nils PS. ... und auch wenn man nicht monatelang an Konzepten schreiben muss, dauern Konzeption, Planung und Umsetzung in der Praxis eben durchaus Monate.

Moin, um das mal einzuordnen: Es gibt eine Menge zu berücksichtigen, wenn man eine PKI sinnvoll einrichten und betreiben will. Mit kundiger und erfahrener Beratung ist das aber auch kein Hexenwerk. Eine "normale" mittelständische Umgebung braucht einen bis drei Tage Planung und einen bis drei Tage Einrichtung. Dazu vielleicht bzw. sinnvollerweise noch Einweisung/Schulung der Admins. Für typische interne Zwecke ist man dann gut gerüstet. Da die ganze Technik aber leider seit Ende der Neunziger praktisch nicht weiterentwickelt wurde, ist sie wenig intuitiv. Ohne Erfahrung läuft man also Gefahr, Wichtiges zu übersehen. Gruß, Nils

Moin, wir verlassen damit das Thema dieses Threads. Da es mit dem Thema ja sicher noch weitergehen wird - willst du dafür nicht lieber einen neuen Thread aufmachen? Das hilft allen, die nach einem der Themen suchen. Gruß, Nils

Moin, das setzt voraus, dass man das Problem definiert. Was willst du unter welchen Rahmenbedingungen erreichen? Ganz ernsthaft: Wenn du Admin Tiering machen willst, musst du dir ein bisschen mehr Gedanken machen als "Ein Konto muss doch ähnlich des Domain-Admins handlungsfähig sein". Was wäre denn da "ähnlich"? Der Ansatz, ein Tiering zu bauen, ist gut, aber dann beginnen eben die Mühen der Details. Das ist auf der Ebene nix für ein Forum. Wir kommen dann ggf. wieder ins Spiel, wenn es um technische Details der Implementierung geht. Gruß, Nils

Moin, Also, so sehr mich dienstliche Reisen oft genervt haben - mittlerweile wäre ich schon ganz gern mal wieder unterwegs. Das letzte Mal war im Mai. Davor im letzten Dezember Gruß, Nils

Moin, Martin, dein Einsatz! Gruß, Nils

Moin, also ... wenn es wirklich "nur" monatlich sein soll und dahinter dann eine organisatorische Auswertung steht ... würde ich Automatisierung vermutlich für verzichtbar halten. Nach dem, was ich dazu weiß, ist das entweder aufwändig oder kostet Geld. Siehe etwa: [Microsoft 365 admin center: automate report collection - Rencore] https://rencore.com/blog/microsoft-365-admin-centers-automate-report-collection/ Gruß, Nils

Moin, gut, und was genau wollt ihr rausfinden? Was genau wollt ihr dann mit den erhaltenen Daten machen? Und warum genau passen die vorhandenen Reports nicht? Gruß, Nils

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