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!!
Related
I have done much searching on this without a solid solution.
I just set up a new SSRS instance on the same server as my SQL 2016 instance. Everything is running fine report wise, etc. The problem is that when a report is scheduled, it creates a Sql Agent Job in SQL Server, and the SQL Agent is erroring out with the following:
The job failed. Unable to determine if the owner
(MyDomain\ReportService) of job 17F8E31D-0838-4829-8C3C-E3FE5BBD3483
has server access (reason: Could not obtain information about Windows
NT group/user 'MyDomain\ReportService', error code 0x5. [SQLSTATE
42000] (Error 15404)).
Current setup:
SSRS using an Active Directory account as the service account called
Report Service
Sql Server 2016 Engine is using an Active Directory account as the service
account called SqlService
Both SSRS and SQL Database are on the same machine
I double checked that SqlService is SysAdmin and has all other
permissions, and non-SSRS jobs run fine
From my research, I can solve this in one of three ways:
Change the SSRS SQL Agent job created by SSRS to be owned by SA (by
default the job is owned by MyDomain\ReportService). The problem
with this is that I would have to do this every time a user creates
a new subscription via SSRS or create an ongoing script because SSRS
by default will use the service as the owner. And I KNOW that this
was not done at my previous employer.
I could make the SqlService a
domain administrator. I don't want to do this for security reasons,
obviously.
I could give the SqlService "SeImpersonatePrivilege"
(Impersonate a client after login) on my domain via the security
policy. This also works, but there seems like there would be a
better way, and I would think this is also a security risk as
setting this doesn't explicitly limit SqlService to only
impersonating the ReportService.
So, my question is hopefully from those who have set SSRS up, what is the best practice for allowing SQL Server to run the SSRS subscriptions? It's possible that something in our environment is messed up permissions wise, but I guess mostly I'm looking for advice on how should this be set up. Thank you greatly in advance.
I eventually discovered that we had some kind of limitation on the active directory rights of the service account. I wasn't unable to pinpoint the exact permissions, but after adding the account to a group that explicitly allowed viewing active directory users and groups, it worked. So, this was due to abnormal limitations for basic domain user rights.
Link
From the site listed above:
Could not obtain information about Windows NT group/user ‘domainuser’, error code 0x5. [SQLSTATE 42000] (Error 15404)(ConnIsLoginSysAdmin)
The solution to this is to add the SQL Server service account to the ‘BUILTINWindows Authorization Access Group’ on your DC.
You can then run “EXECUTE AS USER = ‘domainuser’” on SQL Server to check.
From server1, I've created a connection to a remote server (server2) with the Linked Server facilities. Both servers are on the same domain. When I log to server1 I can successfully execute my stored procedures from SQL Server Management Studio but when I execute my stored procedures from my browser application I get the following error on server 2.
Error: 18456, Severity: 14, State: 58.
Login failed for user 'sa'. An attempt to login using SQL authentication failed.
Server is configured for Windows authentication only.
I've searched the Internet and Stackoverflow for solutions but I'm not sure what's the best way to solve this issue. I'm sure it involves adding/changing database security settings but I'm unsure where to make these changes.
Thanks in advance.
Right-click the server in Enterprise Manager, select properties, goto Security, and change to SQL Server and Windows Authentication mode.
Mixed mode is required if you want to use sa or any other sql-account for authentication. However i believe that the recommended way is to keep the server at Windows authentication mode, and use domain accounts for authentication. The sa-account is the quick and dirty way.
If you have the exact same security setup on both servers, the link between them should work if you select "Be made using the login's current security context" in the linked server properties. That way, the account will be "inherited" in the connection to the linked server.
Check under Security - Logins on each of the server so that the same account is added to both servers. Also check the properties of both entries, under Server Roles you can try to add the sysadmin-role to make sure the accounts will have access to all databases on the server. You should however limit this access in live environments :)
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 SQL Server 2005 running on Windows Server 2003. I noticed that when I query the server from my web app (IIS 6.0 running app pool with Network Service) with a command containing "SELECT USER_NAME()", I get "dbo" instead of "NT AUTHORITY\NETWORK SERVICE". I don't even have the NETWORK SERVICE running as dbo on my database.
How do I prevent NETWORK SERVICE running as dbo on my database?
As a side note, I ran the same code and database on my PC with Windows 7 (IIS 7), SQL Server 2008, and it returned the "SELECT USER_NAME()" as "NT AUTHORITY\NETWORK SERVICE" which is exactly what I expect. What gives?
Edit:Sorry I didn't make changes to this post instead. I'm new at this. As I was saying, the original login was indeed network service and it's accessing the database as dbo which I didn't expect. The network service account didn't have sysadmin role or db_owner for the database. However, I looked up it's effective permissions and it's similar to that of a sysadmin. I made sure that network service isn't part of the local administrator group and it's not running the SQL server service itself.
Looking up google for answers, I did come across someone with similar situation and they ended up querying the sys.login_token when running as the app to see what principal role it's giving the network service permission.
Anyway, it's late Friday and I'm gonna have to continue Monday. Cheers!
If you want to verify the actual login name then use system_user or suser_sname()
From books online regarding user_name():
*If a Windows principal accesses the database by way of membership in a group, USER_NAME returns the name of the Windows principal instead of the group.*
Regarding the second part of your question, keeping it from running as dbo...
Read up on the definition of dbo here, but in short anything that is a sysadmin on your instance is going to be a dbo.
It returns "dbo" on most of the servers I tried.
On one server it returned "guest".
Check this out.
http://msdn.microsoft.com/en-us/library/ms188014.aspx
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!