NilsK

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

Moin, mangels Bedarf kenne ich mich mit dem Kiosk-Modus nicht aus, habe aber im Hinterkopf, dass Browser generell und der Edge im Besonderen da eine eigene Behandlung brauchen. Hilft das Folgende? [Microsoft Edge-Kioskmodus | Microsoft Docs] https://docs.microsoft.com/de-de/deployedge/microsoft-edge-kiosk-mode Gruß, Nils

Moin, der Thread ist über sechs Jahre alt. Das Board hat dich daher gewarnt - bitte richte dich nächstes Mal danach und mach einen neuen Thread auf. An dem Zustand, wie er hier diskutiert wurde, hat sich nichts geändert. Wenn es bei dir um eine VM geht und ihr dem User nicht das Recht nehmen könnt oder wollt, einen Shutdown auszuführen, wäre evtl. ein Task auf dem Host oder auf einem Management-Rechner eine Option, der die VM startet, wenn sie (länger als eine definierte Zeit) aus ist. Gruß, Nils

Moin, jupp. Ich will auch niemandem was unterstellen, aber da solche Threads leicht in guter Absicht mit juristischen Vermutungen weitergehen, wollte ich noch mal drauf hinweisen. Da besteht auch durchaus ein Abmahnrisiko für die Betreiber, soweit ich weiß, daher lieber einmal mehr. Gruß, Nils

Moin, hierzulande dürfen i.W. nur Anwälte Rechtsberatung durchführen. Wir sollten also nicht mutmaßen, was "rechtsverbindlich" sein könnte. Abgesehen davon, hat der TO diese Anforderung auch gar nicht gestellt. Gruß, Nils

Moin, Ich glaube nicht, dass irgendwer, der das AD versteht, einen oder gar mehrere Domain Controller auf diese Weise installieren würde. Um wie viele DCs geht es denn? Gruß, Nils

Moin, du kannst weiter dabei bleiben, keine Informationen preiszugeben, selbst wenn man dich danach fragt, um dir helfen zu können. Erfahrungsgemäß werden wir alle dann aber nicht weiterkommen. Üblicherweise liegt das Problem in solchen Fällen an fehlenden Zugriffsrechten. Dein Shutdown-Skript wird durch den Computrer ausgeführt, nicht als Benutzer. Vermutlich fehlen also die passenden Rechte. Hat Olaf aber auch schon gesagt. Gruß, Nils

Moin, ihr habt gemerkt, dass hier im Board normalerweise deutsch gesprochen wird, oder? Meiner Vermutung nach sind alle in diesem Thread deutschsprachig, da können wir es doch einfacher haben. Gruß, Nils

Moin, gut, aber das ist ja gar kein Punkt, über den wir diskutieren müssten. Wichtiger wäre, ob der TO mit einer der Varianten (die im Prinzip ja identisch sind, wie wir jetzt herausgearbeitet haben) seinen Wunsch umsetzen kann. Falls nicht, wäre interessant, warum nicht, denn wir beide sind ja der Meinung, dass es damit passen müsste. Gruß, Nils

Moin, ISNULL braucht auch kein IF und so. Scheint sich sehr zu ähneln. Gruß, Nils

Moin, ich werfe mal ISNULL() in die Runde. Gruß, Nils