Wednesday, August 22, 2018

ERROR NT AUTHORITY\ANONYMOUS LOGON when you authenticate against SQL server

I have seen this error so many times and once for all I will write down how to get rid of this. It´s surprisingly often developer and technicians does not know that you need to configure Kerberos and so on to have it up and running.

Some background
When you setup a SQL server and use a common domain account as service account for the service you need to create SPN for this account. If not it will only authenticate with NTML. (If you should use domain account those days are a different story). Very often this is missed. If you run other services like Reporting service, Analyses services etc you often design it to run those on separate servers. This is common design and something you should do if your environment isn’t quite small. If you do as best practices is with the design, you will definitely get problem with authentication if you haven´t think about this.

Example















Let say you run Explorer from a client against a report on a reporting server where you have a datasource configured with windows authentication (As the user viewing the report). This datasource connects to a second SQL server where the database resides. You now have an authentication chain which do a so called double hop. This is not possible to do with NTML authentication, so Kerberos is required.

Configuration
So how do we configure the authentication to work? First the involved service account for SQL Server and Reporting server need to have their respective SPN set. This is done as follow if we assume that the servernames are SQLServer and SQLRSServer and the service account are SQLService and SQLRSService. The domainname and domain is what you havein your environment of course.

SETSPN -s MSSQLSvc/SQLServer.domainname.com:1433 domain\SQLService
SETSPN -s MSSQLSvc/SQLServer.domainname.com domain\SQLService
SETSPN -s http/SQLRSServer.domainname.com domain\SQLRSService

Now the services are ready to use Kerberos authentication. Restart the services and then verify connection with this query if you like, you should see KERBEROS as auth_scheme:

select c.auth_scheme, c.client_net_address, s.program_name from sys.dm_exec_connections c
inner join sys.dm_exec_sessions s
on c.session_id = s.session_id
where c.session_id >50

But then we also need to configure delegation on the reporting services account. Since this account “delegate” authentication to the SQL service account. This is done in the active directory management tool. You can chose the easy one, “Trust this user to any service” or if you are a security freak, you can point out exactly what to trust. Just brows for the service account for SQLServer (SQLService) and you see the SPN registered on this object as the first picture below.


























Some more information from Microsoft about how to do this with Reporting services is find in this link. But they does not mention trusted for delegation which is strange since this is needed.
https://docs.microsoft.com/en-us/sql/reporting-services/report-server/register-a-service-principal-name-spn-for-a-report-server?view=sql-server-2017