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
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.
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've a user account on a development SQL express on a remote server. This account has all privileges granted to it but when I use SQL express remotely then I'm not able to make changes to tables. If I log into the virtual machine and sign in with same user I can make changes.
It says I'm not database owner or system administrator. I think I may need to use ownership chaining or somehow designate my user account as administrator?
Thanks.
This is what I'm seeing:
http://fogcreek.com/FogBugz/kb/errors/SysAdminRole.html
I'm using SQL Server Authentication but I'm not the owner but have 'grant' all rights.
Got it! This explains how I can add my user to the appropriate role and that fixes the problem.
https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-1061781.html?tag=mantle_skin
This is rather embarrassing, but I accidentally deleted my Windows account from the list of SQL Server 2008 users and I cannot for the life of me figure out how to re-add myself now that I don't have login privileges.
The server is running on my machine and the only other Windows users with access are IUSR, NETWORK SERVICE and SYSTEM. Is there anything I can do short of re-installing?
I also recently deleted my windows account from my local development 2008 server. I was able to use SQL server's Single User Mode to recreate my login and add it to the sysadmin role. It took just a few minutes, and I didn't have to admit my terrible error to anyone.
From MSDN:
Starting SQL Server in single-user mode enables any member of the
computer's local Administrators group to connect to the instance of SQL
Server as a member of the sysadmin fixed server role.
Here's how I reinstated myself:
Exit out of SSMS
Stop any SQL related services. I had to stop Reporting Services. Other SQL services such as SQL Agent will also use up your one, valuable connection.
Stop the SQL service
Start the SQL service with the extra parameter -m. This will put the SQL into Single User Mode. This means that SQL will only accept one connection.
Use sqlcmd to connect to your server with the -E trusted connection option. SQL will accept you into the sysadmin role if you're a local administrator.
In the interactive session, create your login and add to the sysadmins role.
USE master
GO
CREATE LOGIN [domain\username] FROM WINDOWS WITH DEFAULT_DATABASE=[Master]
GO
EXEC sp_addsrvrolemember #loginame=N'domain\username', #rolename=N'sysadmin'
GO
Stop the SQL service, remove the -m parameter and restart the service. You should now be able to go back into SSMS and continue using the server normally.
If you get the message:
Login failed for user 'domain\username'. Reason: Server is in single user
mode. Only one administrator can connect at this time.
Then there is something using your single connection. You'll need to find that service or connection and stop it before you can log in. Check SQL Agent, SQL Reporting Services, SQL Analysis Services etc.
Luckily, this wasn't too hard to fix (not that it should have been hard...)!
This blog post explains the steps for starting SQL Server in Single User Mode, which (for some reason) allowed me to login as my Windows administrator account, add the account to the user list (with CREATE LOGIN), enable the SA user and set its password to something I actually knew, and finally login as SA and give the Windows account sysadmin privileges.
Edit 07/05/13: Try this link instead.
Often SQL Server is installed so that any any local administrator is a SQL Server sysadmin.
If this is your case you can run Management Studio as administrator and then add any other windows user as a login in the Security section.
This solution worked for me.