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.
Related
I have an IIS 7.0 server connecting to an SQL 2012 Database. On the SQL database I have added a number of linked servers and created a distributed partitioned view to consolidate data from the multiple linked servers. I have a common Windows account on the main server and the linked servers that is common to all (same password). Querying this view from SSMS on the SQL server works fine logged in as the common user. The application pool I am using uses this same user (also on the IIS server) to connect to the SQL server using Integrated Security. I have a simple query of SELECT SYSTEM_USER when run from IIS reports the common user. When trying to retrieve the data from the linked server view I get Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. instead of the data in the view.
Help appreciated
This is basically what is happening: If you are running Active Directory, this is the famous "double-hop" problem. Double-hop is a term used to describe Microsoft's method of maintaining Kerberos authentication credentials over two or more connections. You must configure Kerberos delegation on the AD account running the application pool so that it can forward credentials to the SQL 2012 database server. You configure this on the Delegation tab of the AD account. Without Kerberos delegation, the AD credentials are not forwarded and instead local credentials are sent by the IIS server and get denied by the SQL server. Since the SQL Server doesn't understand the local credentials of the IIS 7 server it denies it as an anonymous logon attempt. The link I provided describes the resolution to this problem in full detail and explains how to expand it out to other servers. Note that if you are not using Active Directory and only local authentication then NTLM is being used and NTLM credentials cannot be delegated off the system so authentication to the SQL server will be in the form of anonymous authentication.
I have been attempting to configure SQL Server 2008 R2 (Standard) for replication between two instances running on Windows 2008 R2. Both machines are on an internal AD domain (2008R2 domain). The issue I am having is specifically with the subscription process being unable to push transactions (yes, doing transactional replication) from the distributor to the subscriber. It is using a domain user (sqlrepl_distrib) which is in the domain users group by default to do this.
The error from the logs is:
Login failed for user 'XXXX\sqlrepl_distrib'. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors. [CLIENT: ]
I have tried numerous things to get it work, but the only way I could get the subscription to work was to use my domain admin login (which is obviously unacceptable as a permanent solution).
The sqlrepl_distrib user has permissions as db_owner on both the publisher and subscriber database, as well as the distribution database, so that shouldn't be related to the issue. SQL Server is configured for Windows authentication only. I verified the user/pass also works by logging into the domain with it. DBs and MSSQL instances are owned by the domain administrator, I think this may possibly be the problem, but not sure.
I have also tried to disable UAC on both SQL Server machines, but this did not help (yes I rebooted).
Hoping someone would have a clue as to what's going on. I am fairly new to SQL Server, so I expect it could be something dumb, but Google has failed me to find a solution (the error that comes up in google seems to be with users being unable to access SSMS, which isn't my problem... that works fine).
To setup the replication, I followed the guide from Microsoft at http://msdn.microsoft.com/en-us/library/aa337389.aspx. It does not mention this particular error. I tried 3 times to setup the process all over again with the same results.
Anything pointing me in the right direction would be helpful (but please don't point me to a 1000 page long MSDN article and expect me to parse through that).
Thanks!
What's the user running the service?
Do check if the spn of the named instance is registered, and also the spn for sql server browser service, as a named instance will force the kerberos authentication to be delegated from the browser service.
And make sure that the browser service is enabled to delegate to the sql spn on windows ad.
First check in SOL server configure manager LOG ON with what users---> for
example user log on as :-NT AUTHORITY\NETWORK SERVICE
check all publisher and distributor and subscriber 'logins' (for this goto your instance--> security-->logins . you must check 'NT AUTHORITY\NETWORK SERVICE' this login is there or not. if dose't have login create New login with the name 'NT AUTHORITY\NETWORK SERVICE' all publisher and distributor and subscriber.
you can right click the above login--> take properties-->usermapping--> change options-->here select that database and give permitions DB_woner and PUBLIC to database
like thaat you can change all publisher and distributor and subscriber.
ofter that re-run your replication
Note:
here I'm LOGON with NT AUTHORITY\NETWORK SERVICE
and
my DATABASE is: Sudheer
Check your own what are LOGON with '????' and Database is '???' in 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
I'm having a very confusing error between SharePoint and SQL Server 2k5.
My SQL Server acting as backend to my MOSS farm has several logins in it which correspond to the web front end servers in my farm, with the pattern: {my-domain}{my-machine}$
Now, those accounts do not exist in AD anywhere, despite the login name syntax, and were generated somehow (assume by MOSS, but can't confirm). One (and only one) of the servers is throwing login failures every 2 minutes; that server was the first in the farm and holds most of the services, just not search and indexing.
I did a number of traces in SQL Profiler, and all I can tell is that the failure is a type 16 error on 'master'; so the login exists but doesn't have rights to 'master'.
Having found that, I went back in and gave it progressively greater rights on Master, including db_owner, and eventually making it a sysadmin. Still no joy, same error.
Diggin further w/ tracing, I found that the actual failure was due to the SSO db not existing; probably b/c it wasn't configured in MOSS. When I tried configuring the error, I got a "Sorry, you're not authorized to do that" error in Central Admin, even though I was logged in as the farm admin, who's also a forest-level admin w/ rights to everything I can think of.
Turning off SSO as a windows service worked, but I'm concerned about my inability to configure it in MOSS, so I dont' want to leave that as a solution.
I'm out of ideas, anyone else have thoughts or experience on this?
Thanks
The {my-domain}{my-machine}$ account is an alias for the NETWORK SERVICE built-in local machine account. NETWORK SERVICE is a low privilege predefined account that was introduced in Windows 2003. It has network credentials and can therefore connect to remote databases (as long as they're within the same domain).
It sounds like you've created your SharePoint web applications with the default application pool identity. This will create the logins named {my-domain}{my-machine}$ in SQL Server. So yes, SharePoint created the SQL logins, but they're based on the built-in NETWORK SERVICE machine accounts on the servers in your farm.
I'd check that the account you're using to configure SSO has the rights to create the SSO database. Have a look at the table in Plan for single sign-on. It lists all the privileges required for all the different types of SSO accounts. For the configuration account, the document lists:
SSO configuration account:
Must be a user domain account. Cannot be a group account.
The user account must be a server farm administrator.
Must be a member of the Administrators group on the
encryption-key server computer.
Must be a member of the following SQL Server security roles on the
computer running SQL Server:
Dbcreator
Securityadmin
Must be either the same as the SSO administrator account, or be a member
of the group account that is the SSO
administrator account.
If that doesn't help, follow Alex Angas' advice and post this question to serverfault.com.
Try and follow this to configure SSO:
http://technet.microsoft.com/en-us/library/cc262932.aspx
We had this same problem - the source of your "Not authorized to do that" message when you configure SSO is that you need to be logged into Sharepoint Central Admin as the SSO user (in our case, it was DOMAIN\SSO_Proxy). This allowed us to make the changes we needed.
Good luck!
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