none
Login für angemeldeten Benutzer identifizieren RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo Community,

    ich wollte mir die Konfiguration eines Logins (Windows Authentifizierung) ansehen und musste feststellen, dass ich kein Login für den entsprechenden Benutzer finden kann obwohl dieser angemeldet ist.

    Im Activity Monitor und mit sp_who/sp_who2 sehe ich das Login (Domäne\benutzername) jedoch unter Sicherheit -> Anmeldungen kann ich das Login nicht finden.

    SQL Instanz: Microsoft SQL Server 2008 R2 (SP2) - 10.50.4319.0 (X64) 

    Habt ihr mir einen Tipp wie ich hier weiter vorgehen kann bzw. wie kann es überhaupt möglich sein, dass ich eine Anmeldung im Activity Monitor sehe das dort angezeigte Login aber unter den Logins nicht finden kann?

    Vielen Dank
    Andreas

    Freitag, 29. Januar 2016 13:53
    |

Antworten

  • Question
    Anmelden
    4
    Anmelden

    Das erfährt man am einfachsten direkt mit der extended stored procedure xp_logininfo

    Einfach mal so ausführen. Dort wird dann das Mapping des Login gezeigt.

    xp_logininfo 'Domain\Username'

    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform, MCM, MVP
    www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com

    Freitag, 29. Januar 2016 16:55
    |
  • Question
    Anmelden
    2
    Anmelden

    Hallo in die Runde,

    ich habe heute die Lösung/Gründe des Problems gefunden.

    Nochmal kurz zum Hintergrund:
    Das Login <Domäne>\10010014 ist im Activity Monitor zu sehen, jedoch taucht es unter Security\Logins im SQL Server nicht auf. Weder xp_logininfo noch sys.server_principals oder sonstige Abfragen liefern Informationen dazu.

    Lösung/Hintergrund:
    An anderer Stelle habe ich herausgefunden, dass der AD Account früher mit 10020609 benannt war und (irgendwann) in 10010014 umbenannt wurde.

    Obwohl das Login 10010014 nicht vorhanden scheint, konnte ich es nicht anlegen. Der SQL Server meldete, dass dieses bereits existiert. Über einen Blog auf SQL-assistance habe ich wie beschrieben die SIDS verglichen. (Danke an den Author tom.green ;) )

    Folgender Befehl gibt die SID des Benutzers aus:

    SELECT SUSER_SID('Domain\10010014')

    Mit diesem Befehl kann man die SID einem Login aus sys.server_principals zuordnen:

    SELECT * FROM sys.server_principals WHERE sid = <sid>

    ... und siehe da, diese SID gehört zu 10020609. Fehler gefunden, es wurde damals als der AD Account umbenannt wurde nicht darauf geachtet was noch alles hinten dran hängt, das betrifft auch Profile auf Servern, ...

    Weiterführende Info:

    SQL Server gibt die SID in einem anderen Format aus als das AD. Um hier auch noch einen Abgleich zu ermöglich kann man die "SQL SID" in das Format der "AD SID" konvertieren. Hilfe habe ich in einem Blog auf sqlserver-help gefunden. (Am Ende des Artikels stellt der Author ein Skript zur Verfügung das die SID entsprechend konvertiert).

    Darüber konnte ich dann die SID des Logins im SQL Server auch noch mit dem AD Account abgleichen und verifizieren, dass diese zu 10010014 gehört.

    Danke an alle für die Unterstützung und meinen Dank an die Blog Authoren, deren Artikel hilfreich waren.
    Vielleicht hilft dieser Post in Zukunft auch anderen :)

    Viele Grüße
    Andreas

    Dienstag, 21. Juni 2016 12:58
    |

Alle Antworten

  • Question
    Anmelden
    2
    Anmelden

    Hallo Andreas,

    der User wird sicherlich über eine Domänengruppe berechtigt sein.

    SELECT * FROM sys.server_principals
WHERE	type_desc = N'WINDOWS_GROUP';

    Damit erhältst Du alle Windows-Gruppen, die einen Zugriff auf den Server besitzen.

    MCM - SQL Server 2008
    MCSE - SQL Server 2012
    db Berater GmbH
    SQL Server Blog (german only)

    Freitag, 29. Januar 2016 14:10
    |
  • Question
    Anmelden
    1
    Anmelden

    Hallo Andreas,

    analog zu Uwe: Du kannst diese PowerShell Skript verwenden um zu ermitteln, welche Windows Gruppen und Mitglieder es gibt: List Member of Sql Server AD Group Logins

    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Freitag, 29. Januar 2016 14:17
    |
  • Question
    Anmelden
    0
    Anmelden

    Danke euch für eure schnellen Antworten,

    ich habe mit Uwes Statement die Domänengruppen ausgegeben und diese mit den Gruppenmitgliedschaften des Benutzers verglichen. Keine Übereinstimmung.

    Ich habe auch die Mitglieder der Gruppen angesehen, nicht dass der Zugriff über eine Verschachtelung gewährt wird. Keine Übereinstimmung.

    Gruß
    Andreas

    Freitag, 29. Januar 2016 14:38
    |
  • Question
    Anmelden
    1
    Anmelden

    Hallo Andreas,

    das ist eher ungewöhnlich! Eventuell "Impersonation" - aber auch das sollte fehlschlagen, wenn der Account nicht auf dem Server vorhanden ist. Was gibt Dir denn die folgende Abfrage an Informationen zurück:

    SELECT	session_id,
		login_time,
		host_name,
		login_name,
		nt_domain,
		nt_user_name,
		original_login_name
FROM	sys.dm_exec_sessions WITH (NOLOCK)
WHERE	is_user_process = 1 AND
		login_name LIKE '%LoginName%' OR
		original_login_name LIKE '%LoginName%';

    Einfach %LoginName% durch den gesuchten Account ersetzen.

    MCM - SQL Server 2008
    MCSE - SQL Server 2012
    db Berater GmbH
    SQL Server Blog (german only)

    Freitag, 29. Januar 2016 14:46
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Uwe,

    die Abfrage erzeugt folgende Ausgabe.

    Freitag, 29. Januar 2016 14:55
    |
  • Question
    Anmelden
    1
    Anmelden

    Hallo Andreas,

    also das Bild ist - aus meiner Sicht - eindeutig. Der DOMAIN-User arbeitet auf dem SQL Server und muss demnach auch einen Zugang zu diesem Server haben.

    Dieser Zugang kann nur über den eigenen Account oder aber über eine Domain-Gruppe sein. Eine andere Möglichkeit gibt es nicht. SQL Server ist, was Security angeht, bei solchen "Grundaufgaben" nicht liederlich :)

    MCM - SQL Server 2008
    MCSE - SQL Server 2012
    db Berater GmbH
    SQL Server Blog (german only)

    Freitag, 29. Januar 2016 16:20
    |
  • Question
    Anmelden
    4
    Anmelden

    Das erfährt man am einfachsten direkt mit der extended stored procedure xp_logininfo

    Einfach mal so ausführen. Dort wird dann das Mapping des Login gezeigt.

    xp_logininfo 'Domain\Username'

    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform, MCM, MVP
    www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com

    Freitag, 29. Januar 2016 16:55
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Uwe,

    ich gebe dir absolut Recht, nur scheint es nicht so zu sein oder ich übersehe etwas. Ich kann das Login unter Sichert-Anmeldungen nicht identifizieren. Auch eine Abfrage von sys.server_principals oder sys.syslogins findet das Login für den Benutzer nicht.

    Hallo Andreas,

    ich werde die Extended stored procedure gleich am Montag testen und mich mit dem Ergebnis zurück melden. Danke schon mal dafür.

    Vielleicht noch zum Hintergrund: Der Benutzer meldet sich mit seinem Domänen Account an einem Citrix Desktop an, dort startet dieser die Anwendung Navision und verbindet sich zur Datenbank. Mir wurde aufgetragen herauszufinden welche Rechte das Login hat und auf welche DBs dieses Zugriff hat, etc ... Somit ging es los, dass ich anfing das Login zu suchen :)

    Ich danke euch für eure Unterstützung und wünsche ein erholsames Wochenende
    Am Montag gebe ich Feedback, sobald ich im Büro bin

    Freitag, 29. Januar 2016 18:36
    |
  • Question
    Anmelden
    0
    Anmelden

    Guten Morgen,

    hier das Ergebnis von xp_logininfo.

    Im Activity Monitor ist das Login zu sehen, der Benutzer arbeitet gerade im System. Die Extended stored procedure findet jedoch nichts.

    Zum Vergleich mit einem anderen Login, hier zum Beispiel ein Admin. Das funktioniert.

    Ich wird da echt nicht schlau draus.

    Grüße

    Montag, 1. Februar 2016 07:55
    |
  • Question
    Anmelden
    1
    Anmelden

    Hallo Andreas,

    rein spekulativ:

    • Der User / Login WAR Mitglied einer berechtigten AD-Gruppe.
    • Der User / Login wurde aus der Gruppe entfernt, um den Zugriff zum SQL Server zu sperren
    • Der User / Login hat sich aber bisher noch nicht von seinem Rechner abgemeldet

    In diesem Fall sollte das Sicherheits-Token noch gültig sein und er kann auf den SQL Server zugreifen. Wenn ein AD-User Mitglied einer Gruppe wird, muss er sich neu anmelden, damit die Sicherheitseinstellungen greifen. Ich denke, dass es genau so auch mit dem "Entfernen aus einer AD-Gruppe" sein wird.

    Ansonsten kann ich mir das obige Ergebnis nicht erklären!

    MCM - SQL Server 2008
    MCSE - SQL Server 2012
    db Berater GmbH
    SQL Server Blog (german only)

    Montag, 1. Februar 2016 08:59
    |
  • Question
    Anmelden
    0
    Anmelden
    Hallo,
     
    es gibt ja auch die Application Role Security, ich weis jetzt nicht genau wie es da aussieht wenn man darüber auf die Datenbank zugreift, aber ich könnte mir vorstellen, dass dies einen ähnlichen Effekt hat.
     
    Grüße
    Jörg Schneider
     
    Am 01.02.2016 um 08:55 schrieb ABurger:
    > Guten Morgen,
    >
    > hier das Ergebnis von xp_logininfo.
    >
    > Im Activity Monitor ist das Login zu sehen, der Benutzer arbeitet gerade im System. Die Extended stored procedure findet jedoch nichts.
    >
    > Zum Vergleich mit einem anderen Login, hier zum Beispiel ein Admin. Das funktioniert.
    >
    > Ich wird da echt nicht schlau draus.
    >
    > Grüße
    >
    > -----
    > -----
    >
     
     
    Montag, 1. Februar 2016 09:38
    |
  • Question
    Anmelden
    1
    Anmelden

    Hallo Jörg,

    die Idee ist nicht schlecht - aber sie scheitert daran, dass zunächst ein Zugriff auf den SQL Server vorhanden sein muss. Erst dann kann man mittels sp_setapprole eine Applikationsrolle verwenden.

    MCM - SQL Server 2008
    MCSE - SQL Server 2012
    db Berater GmbH
    SQL Server Blog (german only)

    Montag, 1. Februar 2016 09:59
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Uwe,

    ich hab das gerade nochmal geprüft. Der Benutzer arbeitet mit Navision ausschließlich über Citrix und meldet sich dort Abends immer ab. (Zumal werden Sitzungen nach acht Stunden Inaktivität abgemeldet).

    Ich gebe Feedback sollte sich das klären. Ansonsten bin ich für jeden Hinweis dankbar :).

    Viele Grüße

    Montag, 1. Februar 2016 10:46
    |
  • Question
    Anmelden
    2
    Anmelden

    Guten Morgen,

    hier das Ergebnis von xp_logininfo.

    Im Activity Monitor ist das Login zu sehen, der Benutzer arbeitet gerade im System. Die Extended stored procedure findet jedoch nichts.

    ...

    Ich wird da echt nicht schlau draus.

    ...

    Hallo

    ich habe es fast befürchtet. Es gibt/gab da mal einen Bug in SQL Server, der sich beim Neu-Anlegen von Gruppen oder Accounts mit gleichem Namen zeigte. So in der Art. Ich hatte das nur einmal bisher gesehen.

    "Universal Groups" würde xp_logininfo übrigens auch nicht anzeigen. Eigentlich sollten diese auch nicht in SQL Server berechtigt sein, aber wer weiß..

    Navision verwendet keine Application Roles, sondern einfach Windows-Accounts, und der Effekt würde da auch nicht so auftreten.

    Klingt auf jeden Fall "interessant", um es mal so auszudrücken ;-)

    Eine Lösung gibt es zum Glück immer. Hier müsste man mal systematisch alles durchgehen, was wir so per Forum nur Häppchenweise können...

    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform, MCM, MVP
    www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com

    Montag, 1. Februar 2016 10:50
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    vielleicht ein interessanter Nachtrag. Ich habe in sys.server_principals nach dem Login gesucht und es nicht gefunden. Beim Versuch das Login zu erstellen erhalte ich jedoch den Hinweis, dass es bereits existiert.

    Gruß
    Andreas





    • Bearbeitet ABurger Dienstag, 14. Juni 2016 10:30
    Dienstag, 14. Juni 2016 10:24
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Andreas,

    mal eine ganz dumme Frage.

    Kann es sein dass es sich um eine Contained Database handelt und der Nutzer ist in der Datenbank vorhanden aber nicht auf dem Server selber? Wenn ich das nämlich nachstelle ergibt sich dieses Bild

    Sieht zumindest genau so aus. 

    Gruß Benjamin

    Benjamin Hoch
    MCSE: Data Platform
    MCSA: Windows Server 2012
    Blog

    Dienstag, 14. Juni 2016 11:22
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Benjamin,

    ich weiß das nicht zu 100%, da ich das System geerbt habe, gehe jedoch stark davon aus, dass es sich nicht um eine contained database handelt.

    Man findet weder das Login auf Serverebene noch den User innerhalb der Datenbank.

    Gruß
    Andreas

    Dienstag, 14. Juni 2016 11:57
    |
  • Question
    Anmelden
    1
    Anmelden

    Contained Databases gibt es erst seit SQL Server 2012.

    Was mir noch einfällt, ist dass man ähnliche Effekte auch mit Sonderzeichen erzeugen kann. Das Prinzip habe ich bereits bei der Verschleierung von Konten verwendet. (natürlich nur für Testzwecke und Demos ;-) )

    Also beim Kopieren des Login-namens mal genau darauf achten, dass mit Unicode gearbeitet wird. Und natürlich nur über die DMVs - nicht Activity Monitor. So sollte man dem geheimnis auf die Schliche kommen. Ohne einen Eintrag in den Systemtabellen kann niemand irgendwelche Prozesse ausführen.

    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
    MCM SQL Server 2008
    MVP Data Platform
    www.SarpedonQualityLab.com | www.andreas-wolter.com

    Mittwoch, 15. Juni 2016 21:17
    |
  • Question
    Anmelden
    2
    Anmelden

    Hallo in die Runde,

    ich habe heute die Lösung/Gründe des Problems gefunden.

    Nochmal kurz zum Hintergrund:
    Das Login <Domäne>\10010014 ist im Activity Monitor zu sehen, jedoch taucht es unter Security\Logins im SQL Server nicht auf. Weder xp_logininfo noch sys.server_principals oder sonstige Abfragen liefern Informationen dazu.

    Lösung/Hintergrund:
    An anderer Stelle habe ich herausgefunden, dass der AD Account früher mit 10020609 benannt war und (irgendwann) in 10010014 umbenannt wurde.

    Obwohl das Login 10010014 nicht vorhanden scheint, konnte ich es nicht anlegen. Der SQL Server meldete, dass dieses bereits existiert. Über einen Blog auf SQL-assistance habe ich wie beschrieben die SIDS verglichen. (Danke an den Author tom.green ;) )

    Folgender Befehl gibt die SID des Benutzers aus:

    SELECT SUSER_SID('Domain\10010014')

    Mit diesem Befehl kann man die SID einem Login aus sys.server_principals zuordnen:

    SELECT * FROM sys.server_principals WHERE sid = <sid>

    ... und siehe da, diese SID gehört zu 10020609. Fehler gefunden, es wurde damals als der AD Account umbenannt wurde nicht darauf geachtet was noch alles hinten dran hängt, das betrifft auch Profile auf Servern, ...

    Weiterführende Info:

    SQL Server gibt die SID in einem anderen Format aus als das AD. Um hier auch noch einen Abgleich zu ermöglich kann man die "SQL SID" in das Format der "AD SID" konvertieren. Hilfe habe ich in einem Blog auf sqlserver-help gefunden. (Am Ende des Artikels stellt der Author ein Skript zur Verfügung das die SID entsprechend konvertiert).

    Darüber konnte ich dann die SID des Logins im SQL Server auch noch mit dem AD Account abgleichen und verifizieren, dass diese zu 10010014 gehört.

    Danke an alle für die Unterstützung und meinen Dank an die Blog Authoren, deren Artikel hilfreich waren.
    Vielleicht hilft dieser Post in Zukunft auch anderen :)

    Viele Grüße
    Andreas

    Dienstag, 21. Juni 2016 12:58
    |