Benutzer mit den meisten Antworten
Login für angemeldeten Benutzer identifizieren

Frage
-
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
Antworten
-
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- Als Antwort vorgeschlagen Uwe RickenMVP Freitag, 29. Januar 2016 17:43
- Als Antwort markiert Teodora MilushevaModerator Freitag, 11. März 2016 13:18
-
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- Als Antwort vorgeschlagen Stefan FalzModerator Dienstag, 21. Juni 2016 13:13
- Als Antwort markiert Dimitar DenkovMicrosoft contingent staff, Administrator Donnerstag, 30. Juni 2016 11:59
Alle Antworten
-
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) -
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 -
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) -
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) -
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- Als Antwort vorgeschlagen Uwe RickenMVP Freitag, 29. Januar 2016 17:43
- Als Antwort markiert Teodora MilushevaModerator Freitag, 11. März 2016 13:18
-
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 -
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
-
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) -
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üßeJörg SchneiderAm 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>> -----> ----->
-
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) -
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
-
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 -
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
-
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 -
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 -
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 -
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- Als Antwort vorgeschlagen Stefan FalzModerator Dienstag, 21. Juni 2016 13:13
- Als Antwort markiert Dimitar DenkovMicrosoft contingent staff, Administrator Donnerstag, 30. Juni 2016 11:59