NilsK

Moin, Ich denke auch, dass die Virtualisierung hier nahezu keinen Einfluss hat. Hingegen scheinen mir an anderer Stelle die Grundlagen noch nicht gefestigt zu sein. Natürlich ist der Router das Gateway, was denn sonst? Gruß, Nils

Moin, Für die Aufgabe aber sehr hoch gegriffen. Da finde ich ein Skript auch günstiger. Gruß, Nils

Moin, Nein, das angesprochene Problem lässt sich so nicht lösen. Dafür wird man einen separaten Rechner brauchen, typischerweise einen Admin-Client. Wäre auch deutlich sauberer gelöst. Gruß, Nils

Moin, Norbert, deine ersten beiden Sätze verstehe ich nicht. Der Hinweis auf die 111.1 scheint mir aber richtig. Entweder fehlt der in der Liste, oder das ist der Fehler. Gruß, Nils

Moin, das PowerShell-Skript ist nicht von mir. Die Grundidee hatte ich per Batch umgesetzt. Ich bin mir nicht sicher, ob so ein Skript wirklich so dauerhaft laufen und seine Daten in ein OneDrive schreiben sollte. Gedacht ist der Ansatz für kurze Prüfungen. Aber für eine Zeit kann man das vielleicht auch durchgehend tun. Deine Zusatzanforderung würde ich einfach über einen Zähler abbilden. Momentan dürfte das Skript einmal pro Sekunde pingen. Man könnte also in jeder Ausführung einen Zähler um 1 hochsetzen und dann bei 3600 eine Statusmeldung ins Log schreiben und den Zähler zurücksetzen. Sofern die Auflösung des Skripts nicht sekündlich sein soll, wäre noch eine Wartezeit pro Durchlauf denkbar, dann müsste man natürlich den Zähler anpassen. Gruß, Nils

Moin, ein wesentlicher Fehler in deinem ursprünglichen Code dürfte gewesen sein, dass %PingCheckA% keinen Wert hat. Damit verlangst du eine ungültige Dateioperation. Sowas passiert, wenn man Variablennamen nur an einer Stelle ändert ... Gruß, Nils

Moin, Sowas hab ich mal gebaut: https://www.faq-o-matic.net/2016/06/22/testskript-ist-der-reboot-schon-durch/ Gruß, Nils

Moin, dann verstehe ich nicht, was du vorhast. Wie sollen denn die Clients die Server erreichen, wenn es kein lokales Routing gibt? Und gerade an kleinen Standorten stellt sich für mich dann immer die Sinnfrage. Gruß, Nils

Moin, Und der Durchsatz der Red-Geräte reicht für den internen Traffic aus? Das wäre sehr untypisch. Gruß, Nils

Moin, Fangen wir doch erst mal vorne an: was ist das Ziel des Ganzen? Und: sollen die Firewalls das interne Routing übernehmen? Gruß, Nils

Moin, ja, und dann? Was soll damit geschehen? Was ist die Anforderung? Mir erscheint der ganze Ansatz ziemlich umständlich. Vielleicht gibt es aber einen Grund dafür. Sonst würde ich dir raten, das gar nicht per PowerShell zu machen, sondern z.B. mit adfind. Gruß, Nils PS. in einem Forum gehört ein bisschen mehr Sorgfalt beim Tippen zur Höflichkeit. Beim Scripting geht es gar nicht ohne. Und wenn du Fragen zu deinem Code stellst, dann bitte mit exaktem Code (und auch als Code formatiert) - sonst raten wir hier nur rum. Danke.

Moin, also, zunächst solltest du natürlich Tippfehler vermeiden. "Struktur" ist nicht dasselbe wie "Strucktur". Das Wort "Gruop" wird die PowerShell auch nicht kennen. Dann ist es auch keine gute Idee, eine Variable "true" zu nennen, das ist ein reseviertes Schlüsselwort. Das ist technisch an der Stelle zwar (leider) zulässig, aber es erschwert das Verständnis deines Codes. Und schließlich wäre noch mal zu prüfen, was du überhaupt willst. Dein Code, wenn er funktionierte, würde wohl alle User der OU durchgehen und dann versuchen, diejenigen, die in der Gruppe sind, in eine Variable zu schreiben. Ist es so gedacht? (Funktionieren wird es schon deshalb nicht, weil die Logik immer nur die Daten des letzten abgefragten Users in der Variable ablegen würde ...) Abgesehen davon, dass der Code noch einige Fehler hat: Warum machst du das so? Was soll mit den Werten hinterher geschehen? Was ist das übergeordnete Ziel? Gruß, Nils

Moin, ich würde eher die Frage stellen, ob dein Aufbau überhaupt OCSP braucht. Wenn du Probleme damit hast, macht Stapling es nicht besser. Entweder löst du also die eigentlichen Probleme - oder du prüfst, ob du nicht ganz auf OCSP verzichten kannst. Das Protokoll wird meist völlig missverstanden, es ist nicht nur nicht nötig, sondern in vielen Implementierungen sogar von Nachteil. Gruß, Nils

Moin, ich werfe noch mal in die Runde, dass man sich gerade bei DCs durchaus die Sinnfrage einer Netztrennung stellen darf. Praktisch alle relevanten Funktionen eines DCs müssen für User und für Admins gleichermaßen erreichbar sein und werden dann über Berechtigungen usw. voneinander getrennt. Anders als bei manchen anderen Serverdiensten gibt es keine Aufteilung in Nutz- und Admintraffic. Es braucht also schon gute Gründe und gute Beherrschung des Netzwerks, um so eine Separation sinnvoll umzusetzen. Kann man das nicht gewährleisten, dann ist es die falsche Baustelle. Gruß, Nils

Moin, Ich werde deine Logs jetzt hier nicht in Detail lesen. Relevant sind nur Fehler - werden welche genannt? Die ursprüngliche Fehlermeldung bezieht sich nicht auf die Betriebsmaster der Domäne, sondern der DNS-Partition. Ich vermute mal, dass es zum das Phänomen geht, das hier ausführlich beschrieben ist: https://blogs.msmvps.com/ulfbsimonweidner/2008/07/31/how-many-infrastructure-masters-do-you-have/ Wenn das also das einzige Problem ist, kannst du es ignorieren, es jetzt lösen oder es später lösen. Gruß, Nils

Moin, der Meldung nach könnte es sein, dass der Betriebsmaster für die DNS-Datenpartition nicht gültig eingetragen ist. Das wäre in deiner Situation evtl. aber kein wesentliches Problem, wenn der Rest funktioniert. Was sagen denn die Eventlogs der "anderen" beiden DCs? (Habe ich es richtig verstanden, dass es aktuell drei DCs gibt?) Was sagt die Ausgabe von dcdiag /E > c:\Pfad\dcdiag-result.txt? Gruß, Nils

Moin, Der ganze Ansatz ist doch unsinnig. Wenn der User das Kennwort für den Admin hat, dann ist er Admin. Das Versteckspiel kannst du dir sparen. Gruß, Nils

Moin, danke, Jan, für die Ergänzung. Das entspricht teils dem, was ich meinte - mit dem wichtigen Unterschied, dass du schon einen Schritt weiter recherchiert hast. Also, zusammengefasst bis hier: Mit einem "reinen" Key würde das nicht bzw. vermutlich nicht gehen. Treibt man mehr Aufwand und hat einen passenden "erweiterten" Key, dann ist es anscheinend möglich. Gruß, Nils

Moin, ich glaube kaum, dass das jenseits von Bastellösungen geht. Der Key ist, wenn ich die Technik richtig verstehe, nur für den Vorgang der Authentifizierung da, nicht um die Session dauerhaft zu legitimieren. So eine Funktion müsste vom Hersteller im Treiber implementiert sein - wenn es da nicht vorgesehen ist, hast du wenig Chancen, das von außen sinnvoll hinzubekommen. Denkbar wäre ein Skript, Programm, Dienst ..., der während der Laufzeit der Session prüft, ob das Gerät noch da ist. Das wäre nach meinem Verständnis aber eben eine Bastellösung (oder würde sehr viel Aufwand verursachen), weil der Code sichergehen müsste, dass er das richtige Device erkennt und nicht von irgendwas in die Irre geführt wird (hier käme der Hersteller ins Spiel - um das sicher zu machen, käme man kaum um ein Zertifikat oder sowas herum). Und da wiederum dürften die Eigenheiten von USB eine Rolle spielen (das nicht in jeder Situation zuverlässig im Sinne der Security ist) - und damit den Aufwand noch mal erhöhen. Gruß, Nils

Moin, Auch bei 150 Usern brauchst du keine besonders große Struktur. Ich würde alle User in eine OU stecken. Gruppen in eine separate OU, die Aufteilung nach Globalen und Lokalen Gruppen ist nicht schlecht. Mehr an OUs wirst du kaum benötigen. Und wenn doch, änderst du es halt, sobald es ansteht. Eins der größten Missverständnisse beim AD-Design ist, dass man eine Struktur für die Ewigkeit entwerfen müsse. Muss man nicht. Gruß, Nils

Moin, Wie ich schon schrieb: richtig oder falsch gibt es da nicht. Das ist eine Frage der Organisation. Man kann das so machen wir in dem Video. Oder anders. Wie groß ist denn die Domäne? Gruß, Nils

Moin, ich bin auch kein Freund von Videos ... ich hab mir nur ein paar Ausschnitte angesehen, mein Eindruck ist: Der Typ hat es nicht verstanden. Es geht nicht darum, Globale Gruppen mit Domänenlokalen Gruppen zu doppeln, wie er es zeigt. Seine Darstellung geht am Kern vorbei und ist - gemessen am Thema - mindestens teilweise falsch. Ich habe das hier mal so beschrieben, wie es eigentlich gedacht ist - du findest den Link ca. 1000-mal hier im Board: [Windows-Gruppen richtig nutzen | faq-o-matic.net] https://www.faq-o-matic.net/2011/03/07/windows-gruppen-richtig-nutzen/ Und zu den Freigabeberechtigungen - das macht er zwar richtig, begründet es aber falsch: [Datei- und Freigabeberechtigungen in Windows | faq-o-matic.net] https://www.faq-o-matic.net/2015/12/28/datei-und-freigabeberechtigungen-in-windows/ Die AD-Struktur selbst kann man nicht "richtig" oder "falsch" bauen, aber "günstig" oder "weniger günstig". Das hängt von der Administrationsstruktur ab. Wichtig: Bilde nicht das Organigramm ab, sondern die administrativen Anforderungen. Gruß, Nils

Moin, zu dem User gehört dem Statement nach kein Login. Er kann also nicht zur Anmeldung verwendet werden. Und genau das sagt auch die Fehlermeldung. Du brauchst einen Login, nicht nur einen User. Schließlich willst du ja auf Objekte außerhalb der Datenbank zugreifen. Vielleicht wäre das der richtige Zeitpunkt, mal über Ziel, Sinn und Ansatz nachzudenken. Mir kommt das Vorhaben schon etwas seltsam vor. Wenn man wüsste, was am Ende erreicht werden soll, könnte man vielleicht Lösungswege vorschlagen. Gruß, Nils

Moin, noch mal etwas ausführlicher: Deiner Beschreibung nach ist ein Trust genau das, was ihr braucht. User aus Domäne A sollen ihr A-Konto verwenden, um auf Ressourcen der Domäne B zuzugreifen. Sie sollen dafür keine separaten Anmeldedaten verwenden müssen. Exakt dafür dient ein Trust. Der geht sogar noch einen Schritt weiter: Die User nutzen nicht nur dieselben Anmeldedaten (also denselben Namen und dasselbe Kennwort in beiden Domänen), sondern sie verwenden jeweils nur ein einziges Konto, nämlich das aus Domäne A. Wie Norbert schon sagt, kann man einen Trust einschränken. Dazu gibt es im Wesentlichen zwei Mechanismen: Selektive Authentifizierung legt fest, dass (alle) A-Benutzer nur auf ganz bestimmte Systeme von Domäne B zugreifen können. Das kann sinnvoll sein. Der zweite Mechanismus ist die normale Berechtigungssteuerung: Auch bei einem Trust können die B-Admins festlegen, dass nur bestimmte A-Benutzer bestimmte Ressourcen nutzen können - genau wie innerhalb derselben Domäne steuert man das über Gruppen und Berechtigungen. Beide Mechanismen lassen sich auch kombinieren, viele Admins lassen den ersten aber weg (meist allerdings deshalb, weil sie ihn gar nicht kennen). Voraussetzung ist, dass die Applikation(en) in Domäne B, die genutzt werden sollen, auch mit einem Trust klarkommen. Das ist in den meisten Fällen aber gegeben. Theoretisch ist es aber möglich, dass das bei eurer Finanz-Applikation nicht so ist und deshalb der sehr umständliche Weg mit dem Sync gegangen wurde. Gruß, Nils

Moin, Und da solche Anforderungen selten so einfach enden: setz dich mit den Kollegen zusammen und kläre, was sie wirklich brauchen, auch auf mittlere Sicht. Sonst bastelst du ihnen etwas und nach einer Woche kommen sie mit der nächsten Idee, dann mit noch einer ... und schnell bist du an dem Punkt, wo du feststellst, dass man mal lieber vorher gesprochen hätte. Vielleicht stellt ihr dabei auch fest, dass es wirtschaftlicher ist, ein paar Tage jemanden zu beauftragen. Als DBA bist du ja vermutlich kein Web-Developer. Gruß, Nils