I am attempting to deploy an SSIS package to a server. I can build connection managers to the target server and databases on that server. However, attempting to deploy the error appears:
There is an spn problem here: "The target principal name is incorrect." This typically happens when the SQL service originally ran under the Local System account and then was changed to a domain account. When running under the Local System account, sql-server registers an spn for every service it controls automatically up to active-directory, and attempts to unregister them when the service shuts down. The Local System account has the ability to communicate over the network as the computer account and thus can indicate to Active Directory as to when to make changes about itself and the SPN SQL Service wants to register. When you change the SQL Server account over to an AD domain user account, the Local System account immediately loses it's ability to control this; therefore you must manually delete the existing SPNs previously registered for that SQL service by Local System before registering new SPNs.
The Microsoft Kerberos Configuration Manager for SQL Server tool Hadi mentioned will, when run, very helpfully generate a script to fix the SQL service SPN from the command line. From the tool's instructions:
To Generate SPN List from Command Line:
Go to command line.
Switch to the folder where KerberosConfigMgr.exe
is.
Type KerberosConfigMgr.exe -q -l
For more command line option, type KerberosConfigMgr.exe -h
The SQL server script will call for deletion of old SPN(s) followed by the registration of new one(s) in order to fix issues. Until this is done you'll continue to get an authentication error when the kerberos clients obtain a ticket for the old invalid SPN - because it was never deleted and any Kerberos-aware service will always reject a ticket for a wrong SPN. After you make SPN changes, always be sure to restart the SQL Server service and right after that if you’re testing with a user have that user log out and log back in.
According to this Microsoft support article:
"Kerberos Configuration Manager is a diagnostic tool that helps troubleshoot Kerberos-related connectivity issues with SQL Server. These issues may trigger errors such as "Cannot generate SSPI context." "
You can get more info at :New tool: "Microsoft Kerberos Configuration Manager for SQL Server" is ready to resolve your Kerberos/Connectivity issues
Related
I'm new to SQL Server. I was a postgres user before. I installed the default SQL Server on my local machine and I'm trying to get an old react with node js application of mine working with a SQL Server. When ever my frontend makes more than 1 call to the backend, if my SQL Server has admin privileges it throws
Error: 17810: Could not connect because the maximum number of '1' dedicated administrator connections already exists.
If not, it throws:
Error 18451: Only administrators may connect at this time.
I checked my database configs and it's set to MULTI_USERS, so I don't understand why I can't login without admin privileges. Can someone help me with this? I wasn't able to find anything online.
My NodeJS backend is using TypeORM to connect to the database
The dedicated administrator connection is a different kind of connection. It's not just "a connection being made by someone with administrative access". You would use the DAC when the SQL instance is having some kind problem, and you can't connect at all because resources are all tied up. SQL will reserve some resources especially for the DAC connection to make sure you can still connect.
A DAC connection can be made by specifying ADMIN: as part of your connection string, which will connect to the assigned DAC port.
You shouldn't use this for "routine" admin work. Just connect using a login with the required administrative server roles (eg, sysadmin). You definitely shouldn't use this as part of a regular application's connection string. You shouldn't be using a SQL Server sysadmin login either. Create a user with the appropriate permissions for your application, and don't use the admin connection.
Regarding your second issue: Make sure the instance wasn't set to start in single user or minimum configuration mode using startup flags. Note that this is for the whole instance, it's not the same as the configuration for an individual database.
I have a client that I can't use SQL Server client tools to remote connect to his database
He is running SQL Server 2012 installed in instance name INTERNAL
I narrowed down the problem
I run
execute XP_READERRORLOG
and get the error:
The SQL Server Network Interface library could not register the Service Principal Name (SPN) [ MSSQLSvc/SERVERNAME.domainname.com:INTERNAL ] for the SQL Server service. Windows return code: 0xffffffff, state: 63. Failure to register a SPN might cause integrated authentication to use NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies and if the SPN has not been manually registered.
So I checked the sql service is running under the default virtual account "NT Service\MSSQL$INTERNAL"
and I follow the advice here http://msdn.microsoft.com/en-us/library/ms191153.aspx
setspn -A MSSQLSvc/ServerName.domainname.com:1433 "NT Service\MSSQL$INTERNAL"
however it tells me:
Unable to locate account MSSQL$INTERNAL
What am I doing wrong in my command prompt command?
I read a blog here.
If the instance of SQL Server is running under the LocalSystem account, you do not have to run the SETSPN utility.
but I don't understand then why I get the error?
Since the service runs as network service, I believe the account name will need to be the machine name.
Tristan shows something similar in his blog at http://blogs.technet.com/b/tristank/archive/2006/05/08/spns-r-fn.aspx.
His example is for HTTP but you should be able to change it to MSSQLSvc:
For an App Pool running as NetworkService on the default port:
SETSPN -A HTTP/intranetweb syd-inet-web01 (that last part's the machine name)
As you can see from abatishchev's message the SQL service is running under a virtual account (common scenario in Windows7/Server2008R2) not Network Service. I have the same issue and my conclusion is that it is not possible to register manually an SPN for a Virtual (and possibly MSA) account...
Other than MS191153 you can read ms143504(SQL.110) where it states:
"If the virtual account fails to register the Service Principal Name (SPN), register the SPN manually". And sends you to MS191153 which doesn't provide any useful info for doing that specifically other than saying that both VA and MSA have permissions to register an SPN by default. If you dig the article "Service Accounts Step-by-Step Guide" you can read that Domains at the Windows Server 2008 R2 functional level provide native support for both automatic password management and SPN management for both MSA and VA. For Windows 2003/8 additional configuration is required. What is your domain FL?
In my case after the service restarted the SPN registered automatically without any further issue. Thanks MS once again for "Simplifying" things...
I recently installed Microsoft SQL Server 2012 on a fresh Windows 7 installation, but whenever I want to run the server, I get the following error:
Error 1069: The service did not start due to a logon failure.
The following user is configured to start the service: NT Service\MSSQL$SQLEXPRESS
How can I fix this problem?
The answer to this may be identical to the problem with full blown SQL Server (NTService\MSSQLSERVER) and this is to reset the password. The ironic thing is, there is no password.
Steps are:
Right click on the Service in the Services mmc
Click Properties
Click on the Log On tab
The password fields will appear to have entries in them...
Blank out both Password fields
Click "OK"
This should re-grant access to the service and it should start up again. Weird?
NOTE: if the problem comes back after a few hours or days, then you probably have a group policy which is overriding your settings and it's coming and taking the right away again.
This happened to me. A policy on the domain was taking away the SQL Server user account's "Log on as a service" rights. You can work around this using JLo's solution, but does not address the group policy problem specifically and it will return next time the group policies are refreshed on the machine.
The specific policy causing the issue for me was:
Under, Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignments: Log on as a service
You can see which policies are being applied to your machine by running the command "rsop" from the command line. Follow the path to the policy listed above and you will see its current value as well as which GPO set the value.
While ("run as SYSTEM") works, people should be advised this means going from a minimum-permissions type account to an account which has all permissions in the world. Which is very much not a recommended setup best practices or security-wise.
If you know what you are doing and know your SQL Server will always be run in an isolated environment (i.e. not on hotel or airport wifi) it's probably fine, but this creates a very real attack vector which can completely compromise a machine if on open internets.
This seems to be an error on Microsoft's part and people should be aware of the implications of the workaround posted.
Short answer:
install Remote Server Administration tools on your SQL Server (it's an optional feature of Windows Server), reboot, then run SQL Server configuration manager, access the service settings for each of the services whose logon account starts with "NT Service...", clear out the password fields and restart the service. Under the covers, SQL Server Config manager will assign these virtual accounts the Log On as a Service right, and you'll be on your way.
tl;dr;
There is a catch-22 between default settings for a windows domain and default install of SQL Server 2012.
As mentioned above, default Windows domain setup will indeed prevent you from defining the "log on as a service" right via Group Policy Edit at the local machine (via GUI at least; if you install Powershell ActiveDirectory module (via Remote Server Administration tools download) you can do it by scripting.
And, by default, SQL Server 2012 setup runs services in "virtual accounts" (NT Service\ prefix, e.g, NT Service\MSSQLServer. These are like local machine accounts, not domain accounts, but you still can't assign them log on as service rights if your server is joined to a domain. SQL Server setup attempts to assign the right at install, and the SQL Server Config Management tool likewise attempts to assign the right when you change logon account.
And the beautiful catch-22 is this: SQL Server tools depend on (some component of) RSAT to assign the logon as service right. If you don't happen to have RSAT installed on your member server, SQL Server Config Manager fails silently trying to apply the setting (despite all the gaudy pre-installation verification it runs) and you end up with services that won't start.
The one hint of this requirement that I was able to find in the blizzard of SQL Server and Virtual Account doc was this: https://msdn.microsoft.com/en-us/library/ms143504.aspx#New_Accounts, search for RSAT.
I had a similar issue that was resolved with the following:
In Services.MSC click on the Log On tab and add the user with minimum privileges and password (on the service that is throwing the login error)
By Starting Sql Server to run as Administrator
If the user is a domain user use Domain username and password
One possibility is when installed sql server data tools Bi,
while sql server was already set up.
Solution:-
1.Just Repair the sql server with the set up instance
if solution does not work ,
than its worth your time meddling with services.msc
I don't know how good of a solution this is it, but after following some of the other answer to this question without success, i resolved setting the connection user of the service MSSQLSERVER to "Local Service".
N.B: i'm using SQL Server 2017.
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!!
I have created an SSIS package that will be deployed to client SQL installations (2005, 2008 or 2008 R2) to perform data extracts which provide a support tool for our product. The deployment process requires that a Windows AD account (normal user, no elevated privileges) is created as this is used as a service account to execute the SSIS package in a SQL Agent job by way of a credential and a proxy account. This all works perfectly and means I can restrict the privileges required to perform this job.
However, I wanted to include error logging in the SSIS package to the Windows Event Log. When I run the package in BIDS (which of course uses my own credentials) and force the failure of the package, it logs just fine. When I force the package to fail (by putting a duff connection string into the config file) whilst being run by the SQL Agent job, nothing is logged. The service account is being used and it is an authenticated user on my SQL Server host machine but it will not write to the event log. If I add the service account to the local administrators group, it writes to the log just fine, but I thought the idea of the Windows event log was that you did not need elevated privileges to write to it?
Our support teams are keen to use the Windows Event Log but I can see no way of doing so without granting high privileges to a service account which I would rather not do. Am I missing something? The Logging tab in the SSIS job step page doesn't seem to do a lot but perhaps that's what I'm missing?
Apologies if this is more suited to ServerFault, but I couldn't quite decide which side of the line this fell as it is a problem encountered during development. If it is then I'll relocate it.
Many thanks
Steve
If OS is 2003, check the SDDL syntax on who has access to write to the log with this: http://support.microsoft.com/kb/323076
If 2008, you can use wevtutil instead of manually typing in SDDL:
http://support.microsoft.com/kb/2028427
The service account can be given the permissions using the above.