2014-12-03 1 views
5

Wie behandelt SQL Server Anmeldungen, wenn eine Mehrdeutigkeit vorliegt, z. B. Logins für das Windows-Benutzerkonto und für eine AD-Gruppe, die diesen Benutzer enthält?Berechtigungen auf Datenbankebene für einen Windows-Benutzer mit einer Anmeldung, die sowohl für den Benutzer als auch für die AD-Gruppe erstellt wurde?

Wir hatten ein kleines Problem mit Berechtigungen in SQL Server 2008 mit Windows-Benutzern aus unserem Active Directory und Gruppen aus diesem AD. Ich werde versuchen, es mit einem Beispiel zu erklären.

Stellen Sie sich einen Windows-Domänenbenutzer DOMAIN\myUser vor, der zu einer AD-Gruppe DOMAIN\SomeGroup gehört.

In SQL Server habe ich 2 Datenbanken SomeAppDb und PublicDb.

Das Ziel ist es, dass alle Benutzer, die Mitglieder DOMAIN\SomeGroup sind sollten in der Lage sein PublicDb zugreifen, aber nur DOMAIN\myUser sollte SomeAppDb zugreifen können.

in SQL Server zunächst eine Windows-Anmeldung DOMAIN\SomeGroup (zu der AD-Gruppe abgebildet) wurde auf der Instanz erstellt, und ein Benutzer in der Datenbank PublicDb mit dem richtigen Rollenmitgliedschaft geschaffen, und das hat gut funktioniert, können Benutzer aus Gruppe SomeGroup konnte greifen Sie auf die Daten zu, die sie in PublicDb benötigten.

Für die Bedürfnisse einer neuen Anwendung wollten wir dem Benutzer DOMAIN\myUser expliziten Zugriff für db SomeAppDb geben, während weiterhin Zugriff auf PublicDb möglich ist. Wir haben daher in SQL Server eine Windows-Anmeldung für DOMAIN\myUser erstellt, und ein Benutzer in der Datenbank SomeAppDb, mit einer Zuordnung zwischen dem 2.

Von diesem Moment erstellt, myUser SomeAppDb zugreifen konnte, wie erwartet, konnte aber nicht mehr darauf zugreifen PublicDb , und wir hatten einen Fehler wie:

Cannot open database "PublicDb" requested by the login. The login failed. 
Login failed for user 'DOMAIN\myUser' 

Meine Intuition sagt mir, dass, wenn der Benutzer die SQL Server-Instanz zugreift, SQL Server eine Anmeldung, die Spiele der Windows-Benutzer sieht und ignoriert die Anmeldung für eine Gruppe bestehenden, dass der Benutzer gehört. Ein Ansatz besteht darin, explizit den Zugriff auf die db PublicDb für den Benutzer myUser hinzuzufügen, aber ich würde diese Lösung lieber vermeiden, da sie PublicDb jedes Mal aktualisiert, wenn wir neuen Benutzern Zugriff gewähren wollen, was genau das ist, was wir vermeiden wollten zunächst ... (wir haben das als vorübergehende Lösung gemacht, in der Hoffnung, eine bessere Option zu finden).

Ist jemand anderes auf dieses Problem gestoßen? Gibt es einen besseren Ansatz?

Dank im Voraus

+0

sollte meine Frage möglicherweise auf http://dba.stackexchange.com verschoben werden? – tsimbalar

+0

Nur neugierig, ob Sie die Möglichkeit hatten, einen der vorgeschlagenen Tests zu testen und Dinge wie Gruppenzugehörigkeit usw. zu überprüfen? –

+1

Die Dinge sind diese Woche verrückt geworden, aber ich hoffe, dass ich noch ein bisschen tiefer tauchen werde, noch vor Ende der Woche. Vielen Dank – tsimbalar

Antwort

7

Meine Intuition sagt mir, dass, wenn der Benutzer die SQL Server-Instanz zugreift, sieht SQL Server eine Anmeldung, die Spiele der Windows-Benutzer und ignoriert die Anmeldung für eine Gruppe bestehenden, die der Benutzer gehört zu.

Diese Intuition ist nicht korrekt. Und das ist eine gute Sache, da die Sicherheitseinstellung so funktionieren soll, wie sie funktioniert: sollte funktionieren; Berechtigungen sind additiv. Ich habe nur Ihre Einstellungen reproduziert und die Erstellung des Login für die Windows-Anmeldung hatte keine negativen Auswirkungen auf die Berechtigungen (d. H.DB-Zugriff), die nur dem Login auf Basis der Windows-Gruppe zugewiesen wurden. Ich bin sogar in der Lage, die Standarddatenbank für die Windows-Login-basierte Anmeldung in einer Datenbank festzulegen, auf die nur über ein Mapping im Zusammenhang mit dem Windows-Gruppen-basierten Login zugegriffen werden kann. Und ja, meine Test-Anmeldung war nur ein Mitglied der Server- und Datenbankrollen public, und ich habe überprüft, dass keine Datenbank, die nicht explizit der Windows-Gruppenanmeldung oder der Windows-Anmeldung zugewiesen wurde, überhaupt nicht zugänglich war.

Also ich bin mir ziemlich sicher, dass sich etwas entweder außerhalb des Erwähnten geändert hat oder eine andere Konfiguration diese Situation verursacht. Aber zuerst sollten wir uns über das genaue Problem im Klaren sein. Die Beschreibung des Problems lautet:

Von diesem Moment myUser SomeAppDb wie erwartet zugreifen konnte, konnte aber

nicht mehr Zugang PublicDb

Dies würde bedeuten müssen, dass myUser der Lage war, um sich einzuloggen. Der Benutzer konnte jedoch nicht über USE [PublicDb] zu PublicDb wechseln? Oder reden wir über etwas anderes? Vielleicht etwas anderes als die genaue Fehlermeldung impliziert:

Kann Datenbank "PublicDb" nicht öffnen, die von der Anmeldung angefordert wird. Die Anmeldung ist fehlgeschlagen. Anmeldung für den Benutzer ‚DOMAIN \ myUser‘ failed

Wenn myUser in und einfach protokolliert veränderten Datenbanken oder eine Cross-Datenbank-Abfrage zu tun, dann würde es nicht eine „Anmeldung fehlgeschlagen“ Fehlermeldung. Dies führt zu dem Verdacht, dass die Standarddatenbank (oder die Datenbank, die in der Verbindungszeichenfolge angegeben ist) SomeAppDb ist und wie gesagt gibt es dort keine Probleme. Aber dann müsste es eine Verbindungszeichenfolge sein, die "PublicDb" angibt, das das Problem hatte. Wenn ja, würde dieselbe Verbindungszeichenfolge, kopiert und eingefügt (nicht neu eingegeben) für jemand anderen arbeiten? Vielleicht gibt es in der Verbindungszeichenfolge, die "PublicDb" angibt, ein typo, sogar ein verstecktes Zeichen? Die einzigen Möglichkeiten, wie ich in der Lage gewesen, dass Fehler zu reproduzieren, ist von über SQLCMD verbinden, während eine Datenbank angeben, die:

  • nicht
  • existierte nicht existierte, hatte das Konto Zugriff auf, hatte aber quadratisch Klammern um den Namen (zB -d "[PublicDb]")
  • existierten aber das Konto hat keinen Zugang zu (das heißt, es gibt mehr Dinge zu testen, wie unten angegeben ;-)

Wenn kein Verbindungszeichenfolge Problem, hier sind einige Dinge zu überprüfen :

  1. Während DOMAIN\myUser in SQL Server protokolliert wird, sollten DOMAIN\myUser den folgenden:

    -- http://msdn.microsoft.com/en-us/library/ms186271.aspx (IS_MEMBER) 
    SELECT IS_MEMBER(N'DOMAIN\SomeGroup'); 
    

    Wenn das Anmelden wirklich in dieser Gruppe ist, dann wird es eine 1 zurück.Wenn dies nicht der Fall, dann entweder:

    • 0 bedeutet, dass die Anmeldung ein Windows-Anmeldung ist aber nicht in dieser Gruppe, so dass er von der Gruppe entfernt wurde, oder
    • NULL bedeutet dies nicht eine Windows-Anmeldung ist (der Login-Name in SQL Server scheint unwahrscheinlich, da ein \ hat, die für eine SQL Server-Anmeldung)
  2. Während DOMAIN\myUser wird protokolliert, in SQL Server kein gültiges Zeichen ist:

    1. Entfernen Sie das temporäre Fix des DOMAIN\myUser Benutzers, der sich in PublicDb befindet.
    2. DOMAIN\myUser sollten Sie Folgendes ausführen:

      SELECT HAS_DBACCESS(sd.[name]) AS [HasAccess], * 
      FROM sys.databases sd 
      ORDER BY 1 DESC, [name] ASC; 
      

      Zeigt PublicDb in der Liste nach oben?

  3. Führen Sie die folgende Abfrage:

    SELECT * 
    FROM sys.server_principals 
    WHERE [name] IN ('DOMAIN\myUser', 'DOMAIN\SomeGroup'); 
    

    die folgenden Felder prüfen: sid, type_desc und default_database_name. Stellen Sie sicher, dass die "Standarddatenbank" wirklich eine Datenbank ist. Es könnte sein, dass der Wert falsch festgelegt wurde, als Sie das Login ursprünglich für DOMAIN\myUser hinzugefügt haben. Wenn nichts anderes, versuchen Sie es vielleicht auf [master], um zu sehen, ob das den Fehler umgeht. Wenn das funktioniert, setze es zurück auf [PublicDb].

  4. Haben "myUser" log in Windows zu einer Eingabeaufforderung gehen und laufen:

    SQLCMD -E -Q"SELECT DB_NAME(), USER; USE [PublicDb]; SELECT DB_NAME(), USER;" 
    

    Die erste Reihe zurück SomeAppDb DOMAIN\myUser sein sollte. Dann eine Nachricht zum Wechseln der Datenbankkontexte. Und dann sollten sie PublicDb DOMAIN\myUser sehen.

    • Wenn ja, dann ist dies definitiv kein Problem mit "db access".
    • Wenn nein, dann ist entweder diese Anmeldung nicht mehr Teil dieser Gruppe oder etwas bestimmtes blockiert sie. In diesem Fall wurde alles getan, wenn das spezifische Login für DOMAIN\myUser über "ein Benutzer wurde in der Datenbank SomeAppDb erstellt wurde, mit einer Zuordnung zwischen den 2." wie zum Beispiel die Ablehnung von Berechtigungen auf Server- oder Datenbankebene?
  5. Haben "myUser" log in Windows zu einer Eingabeaufforderung gehen und laufen:

    SQLCMD -E -Q"SELECT DB_NAME(), USER;" -d"PublicDb" 
    

    Sie sollten eine Reihe bekommen sein PublicDb DOMAIN\myUser zurückgegeben. Wenn ja, dann ist das definitiv kein "Login" -Problem.

  6. Ein einfacher Test wäre:
    1. ein
    2. dies ein Mitgliedskonto Active Directory-Konto neu erstellen
    3. Machen von
    4. Melden Sie sich bei Windows-Domäne \ Einegruppe ", wie dieses Konto
    5. Verbindung mit SQL Server
    6. Versuchen Sie, auf beide Datenbanken zuzugreifen. Das Konto sollte zugreifen können nur PublicDb
    7. Trennen von SQL Server
    8. Erstellen Sie einen Login in SQL Server für diesen Test Windows-Konto
    9. erstellen Benutzer (keine zusätzlichen Optionen) in SomeAppDb für die Anmeldung (zB CREATE USER [DOMAIN\myUser] FOR LOGIN [DOMAIN\myUser])
    10. Mit SQL Server verbinden
    11. Versuchen Sie, auf beide Datenbanken zuzugreifen. Dieser Account sollte jetzt in der Lage sein.
  7. Eine letzte Sache zu prüfen wäre, alle Stücke zu entfernen, die scheinen, die Ursache dieses Fehlers gewesen zu sein. So loswerden die DOMAIN\myUser Benutzer in SomeAppDb und dann loswerden der DOMAIN\myUser Login. Wenn eines dieser Dinge wirklich diesen Fehler verursacht hat, dann sollte DOMAIN\myUser zu diesem Zeitpunkt erneut auf PublicDb zugreifen können.
  8. Welche anderen Windows-Gruppen ist die Windows-Anmeldung ein Mitglied von (zumindest alle, die eine Anmeldung haben würde)?
  9. Von welcher "Rollenmitgliedschaft" sprachen Sie? Sind diese Rollen oder benutzerdefinierten Rollen eingebaut?

P. S. Die meisten verwandten Posts, die sich dort befinden, die mit dem gleichen Fehler umgehen, erstellen entweder eine SQL Server-Anmeldung, um die Windows-basierte Anmeldung für die Rolle "db_owner" zu verwenden oder hinzuzufügen. Ich denke, dass diese beiden Lösungen Ausgliederungen sind und dass Computer nicht willkürlich in ihrem Verhalten sind, so dass wir nur die Ursache finden müssen.

+1

Vielen Dank, ich werde ein bisschen mehr überprüfen, was die tatsächliche Konfiguration ist, und höchstwahrscheinlich Ihre Antwort als akzeptiert markieren, denn es ist ziemlich komplett! – tsimbalar

+0

@tsimbalar danke und kein Problem. Auch wenn du es als akzeptiert markierst, bevor du es vollständig herausgefunden hast (so dass das Kopfgeld nicht nach/dev/null geht ;-), werde ich dir weiterhelfen, bis es gelöst ist. Es muss mindestens einen dokumentierten Fall geben, der eine Reparatur irgendwo im Netz enthält, also bin ich bereit, es durchzustehen :) –

+1

ok, ich werde das tun, hier kommt das Kopfgeld! : P – tsimbalar

Verwandte Themen