none
Linked Server Zugriff Fehlermeldung: NT AUTHORITY\ANONYMOUS LOGON RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    folgende Infrastruktur:

    2x MS SQL Server 2012 SP3 Standard Edition
       SQLProd.Test.Local
       SQLTest.Test.Local

    2x Applikations-Server Windows Server 2012 R2 Datacenter Edition
        APPProd.Test.Local
        APPTest.Test.Local

    Benutzer:
        Test\Customer (DBOwner-Rolle für 2 Benutzer-Datenbanken)

    Auf den Applikations-Servern ist das SQL Server Management Studio installiert,
    über welches sich der Kunde mit dem Benutzer Test\Customer remote gegen den jeweiligen SQL Server verbindet.

    Auf SQLProd habe ich einen Linked Server eingerichtet, welcher auf SQLTest verweist.
    Im Sicherheits-Reiter ist Test\Customer mit "Impersonation" angegeben.
    Nun habe ich das Problem, dass die Verbindung mit Test\Customer nur dann funktioniert, wenn Test\Customer direkt am MS SQL Server angemeldet ist und den Linked Server direkt von SQLProd aus aufruft.

    Wird der Linked Server auf SQLProd über das Management Studio auf APPProd aufgerufen, erhalte ich beim Verbindungs-Test folgenden Fehler:

    Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. Reason: Could not find a login matching the name provided.

    Es scheint also ein Delegierungs-Thema zu sein. Allerdings fehlt mir nun eine Idee, wo ich genau nachsehen muss. Alle 4 AD Computer-Objekte sind im Reiter "Delegation" mit "Trust this Computer for Delgation (Kerberos only)" konfiguriert. Für Test\Customer ist die Option "Account is sensitive and cannot be delegated" deaktiviert.

    Ein entsprechender SPN scheint für alle beteiligten Server auch gesetzt zu sein. Ob dieser für meinen Zweck richtig gesetzt ist, kann ich allerdings nicht ganz beurteilen:

    APPPROD.Test.Local

    setspn -l APPPROD
Registered ServicePrincipalNames for CN=APPPROD,OU=Servers,OU=Datacenter,DC=Test,DC=local:
        TERMSRV/APPPROD
        TERMSRV/APPPROD.Test.Local
        WSMAN/APPPROD.Test.Local
        WSMAN/APPPROD
        RestrictedKrbHost/APPPROD
        HOST/APPPROD
        RestrictedKrbHost/APPPROD.Test.Local
        HOST/APPPROD.Test.Local

    SQLPROD.Test.Local

    setspn -l SQLPROD
Registered ServicePrincipalNames for CN=SQLPROD,OU=Servers,OU=Datacenter,DC=Test,DC=local:
        TERMSRV/SQLPROD
        TERMSRV/SQLPROD.Test.local
        WSMAN/SQLPROD
        WSMAN/SQLPROD.Test.local
        RestrictedKrbHost/SQLPROD
        HOST/SQLPROD
        RestrictedKrbHost/SQLPROD.Test.local
        HOST/SQLPROD.Test.local

    SQLTest.Test.Local

    setspn -l SQLTest
Registered ServicePrincipalNames for CN=SQLTest,OU=Servers,OU=Datacenter,DC=Test,DC=local:
        TERMSRV/SQLTest
        TERMSRV/SQLTest.Test.local
        WSMAN/SQLTest
        WSMAN/SQLTest.Test.local
        RestrictedKrbHost/SQLTest
        HOST/SQLTest
        RestrictedKrbHost/SQLTest.Test.local
        HOST/SQLTest.Test.local
    Anbei auch der gescriptete Linked Server von SQLProd
    /****** Object:  LinkedServer [SQLPROD\MSSQL]    Script Date: 12.10.2017 16:09:55 ******/
EXEC master.dbo.sp_addlinkedserver @server = N'SQLTest\MSSQL', @srvproduct=N'SQL Server'
 /* For security reasons the linked server remote logins password is changed with ######## */
EXEC master.dbo.sp_addlinkedsrvlogin @rmtsrvname=N'SQLTest\MSSQL',@useself=N'True',@locallogin=NULL,@rmtuser=NULL,@rmtpassword=NULL
EXEC master.dbo.sp_addlinkedsrvlogin @rmtsrvname=N'SQLTest\MSSQL',@useself=N'True',@locallogin=N'Test\Customer',@rmtuser=NULL,@rmtpassword=NULL

    Kann mir jemand Schützenhilfe geben, wie ich den Zugriff auf den Linked Server auch von APPPROD aus funktionsfähig bekomme?

    Viele Grüße
    Kai


    Donnerstag, 12. Oktober 2017 14:13
    |

Antworten

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Hallo Kai,

    kennst Du schon den Microsoft Kerberos Configuration Manager for SQL Server ?

    Vielleicht spukt der ja etwas hilfreiches aus?

    Einen schönen Tag noch, Christoph -- Data Platform MVP - http://www.insidesql.org/blogs/cmu

    Freitag, 13. Oktober 2017 09:12
    |
    Beantworter
  • Question
    Anmelden
    0
    Anmelden

    Hi Kai,
    die Impersonation erfordert funktionierende Kerberos-Einstellungen, da die Anmeldung über mehrere Server weitergegeben wird. Wenn das nicht funktioniert (z.B. fehlende Delegation), dann wird in den anonymen Modus "zurückgefallen".

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

    Freitag, 13. Oktober 2017 10:50
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Kai,

    für mich sieht das so aus, dass die Kerberos Verbindungen zu SQL Server NICHT registriert sind! Hierbei handelt es sich um ein komplexes Thema. Genauere Informationen dazu erhältst Du hier:

    https://docs.microsoft.com/de-de/sql/database-engine/configure-windows/register-a-service-principal-name-for-kerberos-Connections

    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)

    Samstag, 14. Oktober 2017 14:19
    |
  • Question
    Anmelden
    0
    Anmelden

    Guten Abend zusammen,

    ich konnte mein Problem mittlerweile lösen, indem ich mich etwas genauer mit dem Thema Kerberos beschäftigt habe. Ich unterlag dem Irrtum, dass der SPN der Hosts wichtig wäre.

    Tatsächlich aber hätte ich die SPN der Dienste-Benutzer für beide MS SQL Server prüfen müssen.
    Mit SetSPN -l <ServiceUserProd> und SetSPN -l <ServiceUserDev> fiel mir auf, dass kein Service Principal Name für beide Dienste-Benutzer registriert war.

    Im SQL Server Protokoll stand dazu folgender Eintrag:

    The SQL Server Network Interface library could not register the Service Principal Name (SPN) [ MSSQLSvc/SQLDEV.Test.local:MSSQL ] for the SQL Server service. Windows return code: 0x2098, state: 15. Failure to register a SPN might cause integrated authentication to use NTLM instead of Kerberos.

    Da bei mir also ein eigener definierter Domänen-Account als Dienste-Benutzer fungiert,
    hat dieser nicht das Recht, einen Service Principal Name zu registrieren. Managed Service Accounts oder LocalSystem bspw. hätten dieses Recht von Haus aus.

    Folgende Lösung funktioniert nun für mich:
      - Über ADSIEdit den Dienste-Benutzern beider MS SQL Server über die Sicherheits-Deskriptoren
        das Recht Write ServicePrincipalName / Read PrincipalName auf sich selbst (SELF) erteilen.
      - Anschließend den SQL Server Dienst durchstarten und das positive Ergebnis im Protokoll sehen:

    The SQL Server Network Interface library successfully registered the Service Principal Name (SPN) [ MSSQLSvc/SQLDEV.Test.local:MSSQL ] for the SQL Server service.

    Nun funktioniert auch der Verbindungstest vom Applikations-Server aus mit jedem beliebigen Domänen-Benutzer. Mit einem Check der Tabellen sys.dm_exec_sessions & sys.dm_exec_connections kann man sehen, dass nun auch korrekterweise Kerberos zum Einsatz kommt:

    SELECT DISTINCT c.auth_scheme, c.session_id, s.host_name, s.login_name
FROM sys.dm_exec_connections c
right join sys.dm_exec_sessions s ON
c.session_id = s.session_id
WHERE nt_user_name = 'Test'

    Ergebnis

    auth_scheme	session_id	host_name	login_name
KERBEROS	57	        SQLTEST	        Test\Customer


    Viele Grüße
    Kai




    Dienstag, 24. Oktober 2017 20:27
    |