NilsK

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

Moin,

die beiden Server fragen unterschiedliche DNS-Server. Wenn die nicht denselben Datenbestand haben, ist da der Fehler oder ein Teil des Fehlers.

Gruß, Nils

Moin,

vor einer Stunde schrieb Hellwege:

Windows USN-Filesystem

was soll das denn sein?

Gruß, Nils

Moin,

deine Frage ist nicht saublöd, aber im Detail nicht ganz verständlich. Was haben deine Befürchtungen mit der Namenskonvention zu tun?

Womit du Recht hast: Ja, das Konzept kann zu sehr vielen Gruppen führen. Im Umkehrschluss aber - wenn du so komplexe Strukturen hast, wirst du immer sehr viele Berechtigungseinträge haben. Wenn du dazu die Zahl der Gruppen klein hältst, hast du sehr viele sehr komplexe Berechtigungseinträge. Das beschriebene Konzept versucht hingegen, die tatsächlichen Berechtigungseinträge möglichst einfach zu halten und dafür die Zuweisung über die (vielen) Gruppen deutlich zu machen. 

Eine erwünschte Folge ist die Erkenntnis, die du geäußert hast: Komplexe Berechtigungsstrukturen sind das eigentliche Problem, weil die dazu führen, dass jede Form der Abbildung schnell aufwändig und u.U. auch unübersichtlich wird. Das ist der Grund, warum große Organisationen dort schnell dazu übergehen, die möglichen Berechtigungen einzuschränken und nicht alles, was technisch möglich ist, auch umzusetzen.

Spätestens da ist man dann auf der organisatorischen Ebene. Und das führt zu Erkenntnis 2, vor der sich die meisten IT-Abteilungen aber noch viel mehr sträuben: Die IT hängt mit der Organisation des Unternehmens zusammen. Um zu einer leistungsfähigen Abbildung zu kommen und den IT-Service passend zu organisieren, muss die IT mit den Fachabteilungen und der Orga reden.

Gruß, Nils

PS. "hab ich noch nie so gemacht" ist irgendwie kein Argument ... 

Moin,

tja ... wie gesagt, ich bin kein Developer, aber - meiner Kenntnis nach wirst du dich entscheiden müssen. Packst du mehrere (oder sogar "viele") Statements in einer Transaktion, dann hält SQL Server die Sperren so lange offen, wie die Transaktion andauert. In deinem Fall sperrt also durch den Foreign-Key-Constraint die eine Tabelle die andere.

Da beide Anweisungen schreiben, hilft dir auch eine geringere Isolationsstufe nicht, die etwa einen Dirty Read zuließe.

Gruß, Nils

Moin,

Glaub uns, wir machen das hier schon ziemlich lange. Es ist nicht nötig, dass du uns die Augen öffnest.

Gruß, Nils

Moin,

Ich bin kein SQL-Developer, aber soweit ich mich an das Thema erinnere, ist das der Sinn der Locks beim Insert. Die Lösung für solche Sperrkonflikte ist typischerweise, dass man ein Vorgehen strikt einhält, das diese vermeidet. In deinem Fall also der Commit der Transaktion, die die Sperre auslöst.

Arbeitet die Applikation denn anders als der Beispielcode? Normalerweise sind Anweisungen beim SQL Server ja implizite Transaktionen, die auch sofort geschlossen werden. Das würde erklären, warum es im SSMS geht.

Gruß Nils

Moin,

vor 10 Minuten schrieb MaWiTi:

warum soll man nicht hier weiter fahren

simple und kurze Antwort: Weil es hier im Board nicht erwünscht ist. Weder das Antworten auf "uralte" Threads, noch das Übernehmen vorhandener Threads mit eigenen Fragen (auch als "Kapern" bezeichnet).

Etwas längere Antwort: Es ist deshalb nicht erwünscht, weil wir - wie auch viele, viele andere Foren - die Erfahrung gemacht haben, dass eine Frage zu "demselben Problem" fast immer eben doch eine Frage zu einem "doch etwas anderen Problem" ist. Und das handelt man nun mal besser in einem neuen Thread ab - denn nur dann entsteht der Mehrwert für andere User.

Danke für dein Verständnis und deine künftige Rücksicht auf diese einfache Boardregel.

Gruß, Nils