SQL Server 2016 und Windows AD Gruppen für Logins ohne User-Login
hi,
ich hab da ein seltsames Problem.... ich hab da eine SQL Server RDS Instanz im AWS erstellt und dem hatten wir zwecks Vereinfachung der Administration eine Gruppe "builtin\administrators" als Login hinzugefügt und ihr auch "sysadm" als REcht gegeben, später zum Probieren auch "public", "connect" und "SQL connect". Sinn und Zweck war daß wir per Skript eine RDS Instanz im AWS erstellen wollten und über ein AD Gruppe die Administration machen wollten ohne daß jemand Kenntnis von irgendeinem SQL-Benutzerkonto haben muß.
Nur kann ein User der eigentlich Mitglied jener Gruppe ist, sich nicht einloggen, Fehler 18456 Severity 14 state 11, was übersetzt bedeutet "Token konnte nicht überprüft werden wegen einem IT Infrastrukturproblem". Das wäre dann mal der allererste Microsoft-Fehler, der die Qualität von Oracle-Fehlermeldungen hätte... wird auch so am Server mitgeloggt. Logins sind nur möglich wenn das Konto selbst angegeben wird... "public" wird dafür benötigt. Allerdings erbt das nicht den "sysadm" der eigentlich über die Gruppenmitgliedschaft erteilt werden sollte.
Kann das sein daß SQL 2016 (als Instanz auf AWS oder Azure) bzw. 2014 (damit hab ich on premise getestet) überhaupt keine AD Gruppen auswerten? Diversen Kommentaren zufolge war das bis SQL Server 2005 möglich, aber der ist Neandertal, den faß ich nicht ernstahft an.
Bisher hatte ich nur AD gruppen für db_owner-Rechte für Datenbanken verwendet und das wird ab SQL Server 2012 korrekt unterstützt. Deshalb dachte ich (und auch andere Kollegen) daß das auch für Logins am Server gilt...
ich hab da ein seltsames Problem.... ich hab da eine SQL Server RDS Instanz im AWS erstellt und dem hatten wir zwecks Vereinfachung der Administration eine Gruppe "builtin\administrators" als Login hinzugefügt und ihr auch "sysadm" als REcht gegeben, später zum Probieren auch "public", "connect" und "SQL connect". Sinn und Zweck war daß wir per Skript eine RDS Instanz im AWS erstellen wollten und über ein AD Gruppe die Administration machen wollten ohne daß jemand Kenntnis von irgendeinem SQL-Benutzerkonto haben muß.
Nur kann ein User der eigentlich Mitglied jener Gruppe ist, sich nicht einloggen, Fehler 18456 Severity 14 state 11, was übersetzt bedeutet "Token konnte nicht überprüft werden wegen einem IT Infrastrukturproblem". Das wäre dann mal der allererste Microsoft-Fehler, der die Qualität von Oracle-Fehlermeldungen hätte... wird auch so am Server mitgeloggt. Logins sind nur möglich wenn das Konto selbst angegeben wird... "public" wird dafür benötigt. Allerdings erbt das nicht den "sysadm" der eigentlich über die Gruppenmitgliedschaft erteilt werden sollte.
Kann das sein daß SQL 2016 (als Instanz auf AWS oder Azure) bzw. 2014 (damit hab ich on premise getestet) überhaupt keine AD Gruppen auswerten? Diversen Kommentaren zufolge war das bis SQL Server 2005 möglich, aber der ist Neandertal, den faß ich nicht ernstahft an.
Bisher hatte ich nur AD gruppen für db_owner-Rechte für Datenbanken verwendet und das wird ab SQL Server 2012 korrekt unterstützt. Deshalb dachte ich (und auch andere Kollegen) daß das auch für Logins am Server gilt...
Please also mark the comments that contributed to the solution of the article
Content-Key: 480386
Url: https://administrator.de/contentid/480386
Printed on: April 26, 2024 at 03:04 o'clock
5 Comments
Latest comment
Moin,
Die üblichen Verdächtigen hast du schon gelesen bzw. kontrolliert:
https://sqlblog.org/2011/01/14/troubleshooting-error-18456
https://dba.stackexchange.com/questions/214374/login-lacks-connect-endpo ...
https://billg.sqlteam.com/2014/10/08/error-18456-severity-14-state-11/
Gruß,
Dani
Fehler 18456 Severity 14 state 11, was übersetzt bedeutet "Token konnte nicht überprüft werden wegen einem IT Infrastrukturproblem
dazu gibt es sogar einen Blogartikel von Microsoft. D.h. so schlimm wie bei Oracle wird's nicht werden. Die üblichen Verdächtigen hast du schon gelesen bzw. kontrolliert:
https://sqlblog.org/2011/01/14/troubleshooting-error-18456
https://dba.stackexchange.com/questions/214374/login-lacks-connect-endpo ...
https://billg.sqlteam.com/2014/10/08/error-18456-severity-14-state-11/
Gruß,
Dani
Moin,
Beim SQLTeam habe ich evtl. gedacht, dass in xp_logininfo noch Reste sind von deinen vorherigen Tests. Das sehe ich von hier nicht.
Im SQLBlog ist neben dem Artikel von Microsoft noch ein weiterer Artikel verlinkt. Dort ist ein Skript gepostet, mti dem mane die SIDs der Benutzer/Gruppen auf korrekt prüfen lassen kann.
Freut mich, dass du den Fehler auf Anhieb gefunden hast. Zeit für das Wochenende.
Gruß,
Dani
der Stackexchange Artikel behandelt das Problem nicht und in den anderen fand ich keine sinnvollen Hinweise, nur der MS Blogartikel war etwas hilfreich
Beim StackExchange ging es mir um den Kommentar mit der Konfiguration TCP/IP, welcher als Lösung markiert wurde.Beim SQLTeam habe ich evtl. gedacht, dass in xp_logininfo noch Reste sind von deinen vorherigen Tests. Das sehe ich von hier nicht.
Im SQLBlog ist neben dem Artikel von Microsoft noch ein weiterer Artikel verlinkt. Dort ist ein Skript gepostet, mti dem mane die SIDs der Benutzer/Gruppen auf korrekt prüfen lassen kann.
Freut mich, dass du den Fehler auf Anhieb gefunden hast. Zeit für das Wochenende.
Gruß,
Dani