none
Login failed RRS feed

  • Frage

  • Hallo liebes Forum,

    ich habe ein Problem mit einer Anmeldung an einem Server. Die Fehlermeldung lautet:

    Message
    Login failed for user 'Domäne\User'. Reason: Could not find a login matching the name provided. [CLIENT: 110.70.30.67]

    Es handelt sich hier um einen AD- User. Sein Account befindet sich in der Gruppe, diese Gruppe besitzt ein dB-mapping. Der AD-account ist nicht gesperrt und der User behauptet, sein Passwort ist korrekt und wurde nicht geändert. Die AD Gruppe habe ich schon entfernt und wieder zugefügt.

    Hat hier bitte jemand eine Idee, woran es noch liegen könnte und wie dieser Fehler behoben werden kann?

    Viele Grüße

    Claudia


    CF

    Mittwoch, 24. Oktober 2018 11:41

Alle Antworten

  • Hi Claudia,
    ist denn der Anwender oder seine Sicherheitsgruppe überhaupt berechtigt, auf den SQL Server zuzugreifen (Reiter Sicherheit im Managment Studio)?

    --
    Viele Grüsse
    Peter Fleischer (ehem. MVP für Developer Technologies)
    Meine Homepage mit Tipps und Tricks

    Mittwoch, 24. Oktober 2018 12:04
  • Hallo Peter,

    ja, ist er. Das create sieht wie folgt aus:

    USE [master]
    GO

    /****** Object:  Login [Domäne\AD-Gruppe]    Script Date: 24.10.2018 13:57:23 ******/
    CREATE LOGIN [Domäne\AD-Gruppe] FROM WINDOWS WITH DEFAULT_DATABASE=[tempdb], DEFAULT_LANGUAGE=[us_english]
    GO

    Viele Grüße

    Claudia


    CF

    Mittwoch, 24. Oktober 2018 12:10
  • Hi Claudia,
    funktionieren denn andere Anmeldungen, d.h. ist firewall entsprechend konfiguriert?

    --
    Viele Grüsse
    Peter Fleischer (ehem. MVP für Developer Technologies)
    Meine Homepage mit Tipps und Tricks

    Mittwoch, 24. Oktober 2018 12:13
  • Hallo Peter,

    ja, es gibt noch einen :-(

    Die User müssen immer erst durch die Firewall mit User und PW. Das funktioniert bei beiden, leider aber die SQL Anmeldung aber nicht. Ich hab jetzt auch die Default DB auf master gesetzt, hat aber nix gebracht.

    Viele Grüße

    Claudia


    CF

    Mittwoch, 24. Oktober 2018 12:32
  • Hi Claudia,
    wenn der Weg bis zum Server funktioniert, dann protokolliere mal:

    In SQL Server Management Studio, open SQL Server Properties > Security > Login Auditing select "Both failed and successful logins".


    --
    Viele Grüsse
    Peter Fleischer (ehem. MVP für Developer Technologies)
    Meine Homepage mit Tipps und Tricks

    Mittwoch, 24. Oktober 2018 13:17
  • Hallo Claudia,

    kann es sein, dass der AD-Account mal gelöscht wurde und anschließend wieder neu angelegt wurde?
    Versuche doch mal, den Account aus der Gruppe herauszunehmen und anschließend wieder im AD hinzufügen.

    Danach soll sich der Benutzer erneut an seinem Rechner anmelden (ausloggen ist wichtig!) und erneut einen Versuch starten.


    Uwe Ricken (Blog | Twitter)
    Microsoft Certiied Master - SQL Server 2008
    Microsoft Certified Solution Master - CHARTER Data Platform
    Microsoft Certified Solution Expert - Data Platform
    db Berater GmbH
    Microsoft SQL Server Blog (german only)

    Mittwoch, 24. Oktober 2018 17:07
  • Hallo Claudia,

    Sieh auch mal im SQL Server ErrorLog nach, dort findest Du auch die Login Meldung und direkt davor eine Meldung mit Fehlercode, Schweregrad und Status, das gibt zusätzliche Informationen darüber, warum der Login fehlschlägt.

    Sieht z.B. so aus:

    Fehler: 18456, Schweregrad: 14, Status: 11


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Donnerstag, 25. Oktober 2018 05:37
  • Hi Claudia,
    wenn der Weg bis zum Server funktioniert, dann protokolliere mal:

    In SQL Server Management Studio, open SQL Server Properties > Security > Login Auditing select

    Hallo Peter,nicht böse sein, aber der Tipp bringt einen Nachteil mit sich: die Einstellung zieht erst nach einem Neustart der Instanz und man muss dann das SQL Server Protokoll konsultieren.

    Zudem geht das Ganze auch in die Windows Events Logs und wenn auf dem System richtig viel los ist, dann "müllt" man sich das in kürzester Zeit voll und hat im Endeffekt gar nichts gewonnen.

    Etwas einfacher wäre es, das Ganze mit Extended Events kurz zu monitoren. Die sind, verglichen mit dem alten SQL Profiler, etwas leichtgewichtiger unterwegs.

    Hier ein Beispiel, wie so eine Session ausschauen kann (kommt von den dbatools)

    CREATE EVENT SESSION [Login Tracker] ON SERVER
    ADD EVENT sqlserver.sql_statement_starting(SET collect_statement=(0)
        ACTION(sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.database_name,sqlserver.server_instance_name,sqlserver.server_principal_name)
        WHERE ([package0].[equal_boolean]([sqlserver].[is_system],(0)) AND NOT [sqlserver].[like_i_sql_unicode_string]([sqlserver].[client_app_name],N'%dbatools%')
        AND NOT [sqlserver].[like_i_sql_unicode_string]([sqlserver].[client_app_name],N'%management studio%') AND [sqlserver].[not_equal_i_sql_unicode_string]([sqlserver].[database_name],N'tempdb')))
    ADD TARGET package0.event_file(SET filename=N'Login Tracker',max_file_size=(10))
    WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=1 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)
    GO

    Oder man nutzt mit einem aktuellen SSMS (17.x) die Möglichkeit schnell einen Xevent Profiler anzuwerfen, um ad hoc mal zu gucken.

    Um wirklich noch mal zu verifizieren, dass das Konto, das auch am Server ankommen soll, wirklich über die Gruppe ankommt:

    xp_logininfo 'domain\user','all'

    Das wäre die schnellste Variante.

    Gruß

    Dirk


    May you never suffer the sentiment of spending a day without any purpose

    Mittwoch, 31. Oktober 2018 17:51
  • Hi Dirk,
    vielen Dank für die Erläuterungen. Ich bin Dir dafür nicht böse :-)

    --
    Viele Grüsse
    Peter Fleischer (ehem. MVP für Developer Technologies)
    Meine Homepage mit Tipps und Tricks

    Donnerstag, 1. November 2018 10:31