5
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...
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 480386
Url: https://administrator.de/contentid/480386
Printed on: April 23, 2024 at 18: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
danke... demzufolge dürfte wohl das UAC eine Option sein, der ich noch mal nachspühren werde... dann finde ich es aber merkwürdig, daß ein AD Benutzerkonto, das Mitglied der Gruppe der Domain Admins ist (aber nicht Administrator heißt) sich anmelden kann wenn ich für das Konto ein Login am SQL Server anlege. Aber genau das wollte ich mir eigentlich ersparen.
Sprich das SSMS startet ohne "run as Administator" bzw. ich krieg auch nie einen Prompt daß das SSMS irgendwie extra Rechte einfordert und der User kann sich am SQL Server anmelden wenn er in seinem Login die Rolle "public" oder auch das gewünschte "sysadm" hat. Und wenn er keinen eigenen Login am SQL Server hat aber Mitglied der Gruppe "Administrators" ist dann gehts net.
Da ist auch nichts mit "deny" eingetragen, den einen SQL server hab ich frisch installiert und dem dabei halt die Gruppe "administrators" spendiert worauf der SQL Server dann ein Login mit dem Namen "builtin\administrators" anlegt.
Den Kommentaren am Blogartikel entnehme ich daß wohl auf Windows AD Seite etwas umgefallen ist, aber auch mein AD in der Testumgebung ist "frisch", praktisch unmodifiziert bis auf einen Registrykey in den Benutzerprofilen, um den "Erststartdialgo" des Acrobat Reader DC zu unterbinden.
Ein SCCM ließ sich da problemlos integrieren und läuft, wohingegen das Integrieren eines SCCM in komplexere GPO-Konstrukte eher nicht-trivial sind...
edit
der Stackexchange Artikel behandelt das Problem nicht und in den anderen fand ich keine sinnvollen Hinweise, nur der MS Blogartikel war etwas hilfreich
Sprich das SSMS startet ohne "run as Administator" bzw. ich krieg auch nie einen Prompt daß das SSMS irgendwie extra Rechte einfordert und der User kann sich am SQL Server anmelden wenn er in seinem Login die Rolle "public" oder auch das gewünschte "sysadm" hat. Und wenn er keinen eigenen Login am SQL Server hat aber Mitglied der Gruppe "Administrators" ist dann gehts net.
Da ist auch nichts mit "deny" eingetragen, den einen SQL server hab ich frisch installiert und dem dabei halt die Gruppe "administrators" spendiert worauf der SQL Server dann ein Login mit dem Namen "builtin\administrators" anlegt.
Den Kommentaren am Blogartikel entnehme ich daß wohl auf Windows AD Seite etwas umgefallen ist, aber auch mein AD in der Testumgebung ist "frisch", praktisch unmodifiziert bis auf einen Registrykey in den Benutzerprofilen, um den "Erststartdialgo" des Acrobat Reader DC zu unterbinden.
Ein SCCM ließ sich da problemlos integrieren und läuft, wohingegen das Integrieren eines SCCM in komplexere GPO-Konstrukte eher nicht-trivial sind...
edit
der Stackexchange Artikel behandelt das Problem nicht und in den anderen fand ich keine sinnvollen Hinweise, nur der MS Blogartikel war etwas hilfreich
soderle bin jetzt auf der Arbeit und
die Lösung ist "run as Administrator" mit dem Management Studio
oder die passende GPO dazu setzen... im SSMS sind irgendwelche Schweinereien drin, die seit einen mutmaßlich 2017 herausgekommenen Patch ohne "run as administrator" die Gruppenmitgliedschaften in Windows nicht mehr auflösen.
die Lösung ist "run as Administrator" mit dem Management Studio
oder die passende GPO dazu setzen... im SSMS sind irgendwelche Schweinereien drin, die seit einen mutmaßlich 2017 herausgekommenen Patch ohne "run as administrator" die Gruppenmitgliedschaften in Windows nicht mehr auflösen.
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
ja ein blindes Huhn findet auch mal ein Korn. Da aber die Builtin-Gruppen eigentlich feste und unveränderliche SIDs haben, hielt ich das erstmal für wenig plasibel daß ich einen SID Mismatch haben könnte.
das Thema ist mir auch nicht unbekannt.. kommt bei Datenbank-Restores nach Migrationen auf neuere Server vor, ich meine unterhalb des SQL Servers 2012 wurde bei einem Restore die SID zwischne Benutzer im Backup und akteull am Server nicht aktualisiert und dann mußte man einen Befehl hinterherwerfen:
sp_change_users_login AUTO_FIX, ‘LoginName/UserName’
das Thema ist mir auch nicht unbekannt.. kommt bei Datenbank-Restores nach Migrationen auf neuere Server vor, ich meine unterhalb des SQL Servers 2012 wurde bei einem Restore die SID zwischne Benutzer im Backup und akteull am Server nicht aktualisiert und dann mußte man einen Befehl hinterherwerfen:
sp_change_users_login AUTO_FIX, ‘LoginName/UserName’
