I am setting up service broker between two servers. The environment I am implementing this does not have a domain.
The two SQL servers service run under "NETWORK SERVICE"
I am getting following error message
Service Broker login attempt by user 'NT AUTHORITY\ANONYMOUS LOGON.' failed with error: 'Connection handshake failed. The login 'NT AUTHORITY\ANONYMOUS LOGON' does not have CONNECT permission on the endpoint. State 84.'.
If I add NT AUTHORITY\ANONYMOUS LOGON to SQL server and grant the connect permission then everything works fine.
I am not sure granting the permission to NT AUTHORITY\ANONYMOUS LOGON is a good idea.
A little bit of Google research tells me, I need to configure SPN for Kerberos but I have no knowledge to do that.
Can you help, or direct me to a good article to refer please?
Configuration
SQL 2008 R2 and Windows 2008
I have come across this issue before also.
This guide got me through it. If you're not an AD admin you might need to get your server guys involved.
guide to fix double hop issue
I am setting up service broker between two servers. The environment I am implementing this does not have a domain.
Then you should use Certificate based authentication instead of Windows:
CREATE ENDPOINT [broker]
STATE = STARTED
AS TCP (LISTENER_PORT = 4022)
FOR SERVICE_BROKER (
AUTHENTICATION = CERTIFICATE [MyCertName]);
The setup is quite complex, as it involves exchanging certificates between the hosts, creating logins and users to map to the other host and granting endpoint connectivity. And you'll then need to also do the dialog security layer. You can read here How does Certificate based Authentication work, and this blog explains step by step how to do it: A simple secure dialog with transport certificates.
Note that even though the error message is about anonymous logon, this is not a Kerberos 'double-hop' issue (better known as constrained delegation).
Related
Preface: SSIS packages are deployed on SQL server, say serv1, and in these packages connections are made,using windows authentication, to another SQL server, serv2. And
I am using windows authentication, a domain account, to login on serv1
This account also has login on serv2, although through different windows group
SPN are registered for both SQL server's service accounts and delegation is ON.
auth_scheme is kerberos. Although for service accounts NTLM is being used because network layer protocol is Shared memory. And for other domain accounts kerberos, TCP is being used.
While executing these packages, they fail with error message Login failed for user 'NT AUTHORITY\ ANONYMOUS LOGON'. All solutions to this scenario point to Double Hop problem. Everywhere the solution includes the steps mentioned above. Is there anything that I am missing here.
While you could probably figure out the kerberos issue, I generally avoid the issue altogether. Here are a few ways that you might address it:
Execute the package with SQL Agent under the sql agent service account, if the service account is a Group managed service account (GMSA) or an actual domain account. A login can be created for the account on the target server. GMSA accounts provide an extra level of security - more on that here: https://learn.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview.
Execute the package with SQL Agent under a proxy account. This stores the credentials in SQL Server and is easier to do if you do not have the permissions to change the account for the sql agent service. More on setting up a proxy here: https://learn.microsoft.com/en-us/sql/ssms/agent/create-a-sql-server-agent-proxy?view=sql-server-ver15. Once the proxy account is created, you'll be able to select as an option in the sql agent job
You could change the connections to use SQL authentication, though the options above are preferred in terms of security. This would be an option if you do not have sql agent for some reason.
An application that has been working without problem (and has not had any active development done on it in about 6 months or so) recently began failing to connect to database. Operations admins cant say what might have changed that would cause the problem.
The client application uses a hardcoded connection string with Integrated Security=True, but when the applications attempts to create a connection to the database, it throws an SQLException saying "Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON".
I can log on to the database through Management Studio on this account without problem. All of the things that I have seen for this issue are for ASP.NET projects and it is apparently the "Double Hop Problem" which being a client application darned well better not be a problem. Any help would be greatly appreciated.
Edit
The client machine and server machine as well as user accounts are on the same domain.
This occurs when Windows Firewall is off.
Leading theory is:
Server was restarted about a week or so ago, and failed to register Service Principal Name (SPN). Failure to register an SPN may cause integrated authentication to fall back to NTLM instead of Kerberos.
If your issue is with linked servers, you need to look at a few things.
First, your users need to have delegation enabled and if the only thing that's changed, it'l likely they do. Otherwise you can uncheck the "Account is sensitive and cannot be delegated" checkbox is the user properties in AD.
Second, your service account(s) must be trusted for delegation. Since you recently changed your service account I suspect this is the culprit. (http://technet.microsoft.com/en-us/library/cc739474(v=ws.10).aspx)
You mentioned that you might have some SPN issues, so be sure to set the SPN for both endpoints, otherwise you will not be able to see the delegation tab in AD. Also make sure you're in advanced view in "Active Directory Users and Computers."
If you still do not see the delegation tab, even after correcting your SPN, make sure your domain not in 2000 mode. If it is, you can "raise domain function level."
At this point, you can now mark the account as trusted for delegation:
In the details pane, right-click the user you want to be trusted for
delegation, and click Properties.
Click the Delegation tab, select the Account is trusted for delegation
check box, and then click OK.
Finally you will also need to set all the machines as trusted for delegation.
Once you've done this, reconnect to your sql server and test your liked servers. They should work.
First off: My problem isn't the exact same as yours, but this post is the first thing that comes up in google for the Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' error at the time I wrote this. The solution may be useful to people searching for this error as I did not find this specific solution anywhere online.
In my case, I used Xampp/Apache and PHP sqlsrv to try to connect to an MSSQL database using Windows Authentication and received the Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' error you described. I finally found the problem to be the Apache service itself running under the user "LOCAL SERVICE" instead of the user account I was logged in as. In other words, it literally was using an anonymous account. The solution was to go into services.msc, right click the Apache service, go to Properties, go to the Log On tab, and enter the credentials for the user. This falls in line with your problem related to SPN's as your SPN's are set up to run from a specific user on the domain. So if the correct SPN is not running, windows authentication will default to the wrong user (likely the "LOCAL SERVICE" user) and give you the Anonymous error.
Here's where it's different from your problem. None of the computers on the local network are on a Domain, they are only on a Workgroup. To use Windows Authentication with a Workgroup, both the computer with the server (in my case MSSQL Server) and the computer with the service requesting data (in my case Apache) needed to have a user with an identical name and identical password.
To summarize, The Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' error in both our cases seems to be caused by a service not running and/or not on the right user. Ensuring the right SPN or other Service is running and under the correct user should solve the anonymous part of the problem.
I think there must have been some change in AD group used to authenticate against the database. Add the web server name, in the format domain\webservername$, to the AD group that had access to the database. In addition, also try to set the web.config attribute to "false". Hope it helps.
EDIT: Going by what you have edited.. it most probably indicate that the authentication protocol of your SQL Server has fallen back from Kerberos(Default, if you were using Windows integrated authentication) to NTLM. For using Kerberos service principal name (SPN) must be registered in the Active Directory directory service. Service Principal Name(SPNs) are unique identifiers for services running on servers. Each service that will use Kerberos authentication needs to have an SPN set for it so that clients can identify the service on the network. It is registered in Active Directory under either a computer account or a user account. Although the Kerberos protocol is the default, if the default fails, authentication process will be tried using NTLM.
In your scenario, client must be making tcp connection, and it is most likely running under LocalSystem account, and there is no SPN registered for SQL instance, hence, NTLM is used, however, LocalSystem account inherits from System Context instead of a true user-based context, thus, failed as 'ANONYMOUS LOGON'.
To resolve this ask your domain administrator to manually register SPN if your SQL Server running under a domain user account.
Following links might help you more:
http://blogs.msdn.com/b/sql_protocols/archive/2005/10/12/479871.aspx
http://support.microsoft.com/kb/909801
You probably just need to provide a user name and password in your connectionstring and set Integrated Security=false
Try setting "Integrated Security=False" in the connection string.
<add name="YourContext" connectionString="Data Source=<IPAddressOfDBServer>;Initial Catalog=<DBName>;USER ID=<youruserid>;Password=<yourpassword>;Integrated Security=False;MultipleActiveResultSets=True" providerName="System.Data.SqlClient"/>
One of my SQL jobs had the same issue. It involved uploadaing data from one server to another. The error occurred because I was using sql Server Agent Service Account. I created a Credential using a UserId (that uses Window authentication) common to all servers. Then created a Proxy using this credential. Used the proxy in sql server job and it is running fine.
FWIW, in our case a (PHP) website running on IIS was showing this message on attempting to connect to a database.
The resolution was to edit the Anonymous Authentication on that website to use the Application pool identity (and we set the application pool entry up to use a service account designed for that website).
A similar case solved:
In our case, we wanted to set up linked servers using cnames and with the logins current security context.
All in order we checked that the service account running SQL Server had its' proper spns set and that the AD-object was trusted for delegation. But, while we were able to connect to the cname directly, we still had issues calling a linked server on its' cname: Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
It took us far too long to realize that the cnames we used was for A-record, [A], that was set on a higher dns level, and not in its' own domain AD-level. Originally, we had the cname directing to [A].example.com and not (where it should) to: [A].domain.ad.example.com
Ofcourse we had these errors about anonymous logon.
Got it! Solved the issue modifying the user properties in security session of SQL Server. In SQL Server Management, go into security -> Logon -> Choose the user used for DB connection and go into his properties. Go to "Securators" tab and look for line "Connect SQL", mark "Grant" option and take a try. It works for me!
Regards
Just Go to app pool select Process model in Advance Setting then select Identity and in identity set your account details like username and password of your system.
We have a 3rd party product that allows some of our users to manipulate data in a database (on what we'll call SvrSQL) via a website on a separate server (SvrWeb).
On SvrWeb, we have a specific, non-default website setup for this application so instead of going to http://SvrWeb.company.com to get to the website we use http://application.company.com which resolves to SvrWeb and the host headers resolve to the correct website.
There is also a specific application pool set up for this site which uses an Active Directory account identity we'll call "company\SrvWeb_iis". We're setup to allow delegation on this account and to allow it to impersonate another login which we want it to do. (we want this account to pass along the AD credentials of the person signed into the website to SQL Server instead of a service account.
We also set up the SPNs for the SrvWeb_iis account via the following command:
setspn -A HTTP/SrvWeb.company.com SrvWeb_iis
The website pulls up, but the section of the website that makes the call to the database returns the message:
Cannot execute database query.
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
I thought we had the SPN information set up correctly, but when I check the security event log on SrvWeb I see entries of my logging in, but it seems to be using NTLM and not kerberos:
Logon Type: 3
Logon Process: NtLmSsp
Authentication Package: NTLM
Any ideas or articles that cover this setup in detail would be extremely appreciated!
If it helps, we are using SQL Server 2005, and both the web and SQL servers are Windows 2003.
There are several possible reasons for kerberos failures which includes lack of SPN and duplicate SPN as well.
If SQL is running under custom account you would need to add SPN for SQL as well.
Also keep in mind, you should be adding SPN for the FQDN which is the host (A) entry in DNS and not a CNAME.
Check the value of NTAuthenticationProviders
http://support.microsoft.com/kb/215383
Try DelegConfig which would show what is missing if its SPN or something else.
http://www.iis.net/community/default.aspx?tabid=34&g=6&i=1887
MSSQL Server is in the "abc" domain and have mixed mode authentication.
I am connecting from the machine which is not in domain or in a domain "xyz" but with in the same network using MSSQL Jdbc driver 2.0. I have logged in as admin or account in xyz domain.
It works fine using following url for connection for "sa" or SQL Mode Authentication.
jdbc:sqlserver://%DB_IP%:%DB_PORT%;SelectMethod=cursor;DatabaseName=dbname
It doesn't work For window authentication using credential "MSSQLDomain\username" i.e "abc\username", using following url
jdbc:sqlserver://%DB_IP%:%DB_PORT%;SelectMethod=cursor;integratedSecurity=true;DatabaseName=dbname;
Gives following error.
Login failed for user ''. The user is not associated with a trusted
SQL Server connection.
I have tried adding property Trusted_Connection=Yes to url, but still gives same error.
I don't want to map the drive of the SQL Server. I am able to access the any shared folder of the SQL Server Machine by providing "MSSQLDomain\username" and password.
It works fine for both authentication mode, if both machine is in same domain.
If I am using jtDS Driver from the machine which is not in domain or in "xyz" domain within same network i.e same subnet, it works fine.
This is the deliberate and correct behaviour of Windows Authentication.
It is because the Domain from which you are connecting from, is not the same Windows Domain as the one where your SQL Server instance resides.
I believe there are methods for bridging the Domains so to speak, however they require custom and tricky implementation. You also will have to configure a trust relationship between the domains.
The following thread contains discussions which you will likely find useful.
http://sql-server-performance.com/Community/forums/p/24601/137574.aspx
Changing the login credentials might help,
use SQL authentication instead of nt authentication
https://support.microsoft.com/en-us/kb/555332
Symptoms
After you install Microsoft SQL Server 2014, SQL Server 2012, SQL Server 2008, SQL Server 2005, or SQL Server 2000 and you try to connect to the server that is running SQL Server, you receive one of the following error messages:
Login failed for user '%.*ls'. The login is a SQL Server login and cannot be used with Windows Authentication.%.*ls
Login failed for user ''. The user is not associated with a trusted SQL Server connection. (Microsoft SQL Server, Error: 18452)
Login failed for user ''. (Microsoft SQL Server, Error: 18456)
Resolution
This problem occurs if the user tries to log in with credentials that cannot be validated. This problem can occur in the following scenarios:
Scenario 1:
The login may be a SQL Server login but the server only accepts Windows Authentication
To resolve this issue, configure SQL Server in Mixed Authentication Mode.
Scenario 2:
You are trying to connect by using SQL Server Authentication but the login used does not exist on SQL Server
To resolve this issue, verify that the SQL Server login exists. For more information, see Create a login in SQL Server Books Online.
Scenario 3:
The login may use Windows Authentication but the login is an unrecognized Windows principal
An unrecognized Windows principal means that Windows can't verify the login. This might be because the Windows login is from an untrusted domain. To resolve this issue, verify that you are logged in to the correct domain.
I have been involved with making a SQL server connection cross to domains like that, and it is exceptionally painful. In order to use credentials from another domain, the domain where you are assigning the permissions has to trust the domain, where the account is coming from. IT Pro's are generally VERY reluctant to trust another domain in this manner, and for good reason, so if this trust relationship has not been established it might not be very likely to convince the admins to do this.
Once you have the trust relationship established, you will probably need to register the SPN's for your SQL server in Active Directory, and assign delegation permissions. This type of environment is very difficult to setup, troubleshoot and maintain.
I hope that there is some other way that you can do this, because it sounds like you are headed for a very difficult scenario.
Hope it helps
Rihan
I am trying to run a SQL Server Reporting Services where the data for the report is on a SQL Server database that's on a different server. Integrated Authentication is turned on for both the Report Server and the report. I have confirmed that Kerberos delegation is working fine by using Internet Explorer to run the report from inside the network.
However, when I open the report server through the firewall, I cannot run the report. I get the following error: An error has occurred during report processing. Cannot create a connection to data source 'frattoxppro2'. Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
Does Kerberos authentication not work outside a firewall?
Kerberos requires a port 88 connection to the KDC, in this case, most likely your DC.
What you probably want to look at is HTTPS + Basic Authentication + Protocol Transition to take the Basic Authentication and translate it into a DC based Kerberos Ticket for delegation and back end authentication.
Protocol Transition with
Constrained Delegation Technical
Supplement
How To: Use Protocol Transition and
Constrained Delegation in
ASP.NET
Not exactly the easiest to set up, but when its working, it works amazingly well.
I'm not really in a position to tell you why kerberos isn't working for you, but did have a alternative suggestion for your configuration. You can use ISA services to expose the reporting server rather than simply poking a hole in your firewall. This is something our company has done successfully - it republishes the reporting services site so the browsers are talking to ISA, not directly to the server. ISA Services is quite happy to pass through your credentials as well.