On my test environment (Windows Server 2016 with SQL Server 2017), I have a working Powershell DSC configuration in push mode using SqlServerDsc, in which I add logins to the server, add database users to database roles etc. I don't use PsDscRunAsCredential so the Local Configuration Manager on the server uses SYSTEM to connect to the SQL Server instance. In SQL Server, I can see the connection coming in as domainname\computername$. No surprises there.
What I don't understand is how this can work, as domainname\computername$ is not configured as a login, nor are 'NT AUTHORITY\SYSTEM' and 'BUILTIN\Administrators'. EXEC xp_logininfo 'domainname\computername$', 'all';, EXEC xp_logininfo 'NT AUTHORITY\SYSTEM', 'all'; and EXEC xp_logininfo 'BUILTIN\Administrators', 'all'; return empty. I've also run a bunch of security report scripts I've found online, but none of them include useful information.
The SQL Server service runs under a low-privileged domain account.
Does 'NT AUTHORITY\SYSTEM' have some kind of implicit sysadmin permissions in SQL Server? I've been working with SQL Server for quite a few years now, but I can't figure this one out. The only way I can make DSC stop working ('Failed to connect to SQL instance') is by creating a login for 'NT AUTHORITY\SYSTEM' and disabling it, which somehow overrides the implicit permissions (if that's what it is).
Any ideas or pointers? Thanks!
Update: The behavior is the same on a freshly installed instance.
Related
I have a Windows 2012 Server running SharePoint 2010 using an SQL Server Express locally installed. Unfortunately my logs are currently flooding with message "An exception occurred while enqueueing a message in the target queue. Error: 15404, State: 19. Could not obtain information about Windows NT group/user 'DOMAIN\user', error code 0x5." It can be 20 such messages every second!
(...and the 'DOMAIN\user' happens to be my personal account.)
Are there a job running that has missing rights? "Qoute from https://serverfault.com/questions/277551/mssqlserver-exception-occurred-while-enqueueing-a-message-in-the-target-queue-e "Try to changing the owner of the jobs to the sa account, on the properties of the job." If I'm correct the express version of SQL server cannot run jobs? Or is there someone/something that wants access to our AD? Why do that account wants to obtain information about my account 20 times every second?
I do find lot's of blogs and hints about this task, but I just dont understand the solutions. One says "To repair this, login as one of the SA accounts and grant SA access for the account that needs it." But what account needs sa access?
Change the owner to sa. Here are the steps I took to solve this issue:
Right-Click on the database and select properties
Click on Files under the Select a page
Under the Owner, but just below the Database Name on the right-hand pane, select sa as the owner.
In my case, sa was not the owner of the DB, I was. When I tried to execute CLR configuration that required sa privileges, I got the error too.
The solution:
USE MyDB
GO
ALTER DATABASE MyDB set TRUSTWORTHY ON;
GO
EXEC dbo.sp_changedbowner #loginame = N'sa', #map = false
GO
sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
sp_configure 'clr enabled', 1;
GO
RECONFIGURE;
GO
I used help from the db team at work and this post to find the answer.
In my case the owner of the database was a domain account Domain\Me.
The error message was
Error: 15404, State: 19. Could not obtain information about Windows NT
group/user 'Domain\MyAccount'
The problem was that the database didn't know what to do with the domain account - so the logical thing to do was to use a local account instead.
I tried changing the owner of the database, but things still wouldn't work correctly.
In the end I dropped and recreated the entire database MAKING SURE THAT THE OWNER WAS SA
I also set the Broker to Enabled in the settings
Thing started magically working after this
No Domain Authentication
Failure was ultimately due to the fact that it was not able to authenticate when I was not vpn-ed into the corporate network.
For I was connecting to a local db on my work laptop, however the User 'DOMAIN\user' needed to be authenticated by AD on the corporate network.
Error was resolved as soon as I reconnected and refreshed; the error disappeared.
I had this error from a scheduled job in sql Server Agent, in my case, just after I changed the hostname of the Windows Server. I had also ran sp_dropserver and sp_addserver. My database was owned by "sa", not a Windows user.
I could login into SQL as the Windows user NEWHOSTNAME\username (I guess after a hostname change, the SID doesn't change, that's why it worked automatically?).
However, in SQL, in Security/Logins node, I had SQL logins defined as OLDHOSTNAME\username. I connected to SQL using "sa" instead of Windows Integrated, dropped the old logins, and create new ones with NEWHOSTNAME\username.
The error disappeared.
to do a bulk update for all databases, run this script and then execute its output:
SELECT 'ALTER AUTHORIZATION ON DATABASE::' + QUOTENAME(name) + ' TO [sa];'
from sys.databases
where name not in ('master', 'model', 'tempdb')
I was having the same problem. In my case it was due to the fact that my machine was part of a domain, but I was not connected to the company VPN. The problem was solved after connecting to the VPN (so the domain user could be resolved by the SQLAgent).
I had the same issue where my domain login was not being recognized. All I did was go into the SQL Server configuration manager and start the services as Network Services instead of a local service. The sql server / agent was then able to recognize the AD logins for the jobs.
In my case, it was VPN issue. When I turned on the VPN to connect with my office network & then tried to start the snapshot agent again, it started successfully.
I was facing the same issue.
Fix for me was changing the log-on from NT User to global user in Sql Server Configuration Manager => Sql Server Service => Sql Server Agent => Properties => Account name.
You should be connected with your domain. (VPN)
I have created an application pool called "schoolPool" and assigned it to my web application. Identity for this pool has been set to LocalSystem.
When I try to access my database from within the application, i.e. open a SQL connection, I get the following error all the time:
Login failed for user 'NT AUTHORITY\SYSTEM'
I tried to add NT AUTHORITY/SYSTEM to SSMS (SQL Server Management Studio) logins, but it was already a principal, showing the following error:
Allow NT AUTHORITY/SYSTEM to server Role as sysadmin.
I tweaked the application settings a lot, changing the application pool's identity (in Windows 8.1's IIS) to LocalSystem, LocalService, NetworkService, and ApplicationPoolIdentity. However, all of them failed to solve the problem I had logging into my database.
Finally I set the pool identity on LocalSystem and thought why it might be preventing "NT AUTHRITY\SYSTEM" from opening a connection to my database. I opened up SQL Server Management Studio as "Administrator" and checked the Server Roles for NT AUTHORITY\SYSTEM under "logins" section. The default server role for this user was public by default. I also checked sysadmin and refreshed my web application form. This time it worked! Everything working perfectly now.
There is another fix. You should open Command Prompt (cmd) and write the following:
sqlcmd -S (server name)
select name from sys.server_principals where name = 'NT AUTHORITY\SYSTEM'
go
SP_ADDSRVROLEMEMBER 'NT AUTHORITY\SYSTEM','SYSADMIN'
go
The first line will give you an access to the sql server on you machine, the second will
take the following result NT AUTHORITY\SYSTEM an the stored procedure addsrvrolemember will add sysadmin to it. Be careful, because you have to type the following code the way it is.
Rerun following query which will assign 'NT SERVICE\MSSQLSERVER' to sysadmin
EXEC master..sp_addsrvrolemember #loginame = N'NT SERVICE\MSSQLSERVER', #rolename = N'sysadmin'
Musakkhir's answer of granting sysadmin seems poorly thought out as far as security goes, and Pinal's answer involved giving the unknown process db_owner rights, still almost certainly overkill. I've 'solved' it myself by simply granting "public" rights, which normally just allows CONNECT, but nothing else, even SELECT. If gets rid of the login error and stops flooding the error log, since it now logs in, but whatever unknown process is doing the connecting still can't do anything.
You should give your User ID and pwd of SQL server authentication login in the connectionStrings as User ID="username";pwd="yourpassword". You can use the following query
CREATE LOGIN login name WITH PASSWORD = 'password' ;
GO
I have Microsoft SOL Server 2008 R2 on my server. When I am trying to open SOL Server Management Studio as administrator and creating new database, I get this error message
create database permission denied in database 'master' error 262
Also when I am adding sysadmin in login property window section in my login. Then this message appeared:
add member failed for server role 'sysadmin'
Please let me know how to add admin permission on my login and easily to create database
you need to login with SQL server authenticaton for craeting DataBase.
If you are using Windows Authentication then you need to run SQL server as Run As Adminstrator to avoid this error.
Further details Here People Having similar error
Login to your workstation as an administrator and execute the following query
EXEC sp_addsrvrolemember 'Domain\User', 'sysadmin';
CheckHere
Sql Server will not consider if you are admin to your workstation ,but you have to explicitly
make user as a sysadmin.
Intresting
I've been trying to connect to SQL Server using SQL Server Management Studio to no avail.
This is what the error says:
Cannot connect to .\HAMED.
ADDITIONAL INFORMATION:
Login failed for user 'HAMED'. (Microsoft SQL Server, Error: 18456)
I have an instance of SQL Server by the name of Hamed which is run in Network Sevice mode. I'm using Windows 7.
I'm guessing you didn't grant yourself SQL admin during the install, but are you sure the DB instance is "HAMED"? That sounds like the machine name. Try connecting to .\sqlexpress
Do you remember the SA password? If so, you can add yourself by logging in with that account. Otherwise, you'll have to jump through some hoops and loops to get yourself added.
If you forgot to add yourself to the SQL admin group, read this article:
http://blogs.ameriteach.com/chris-randall/2009/12/11/sql-server-2008-forgot-to-add-an-administrator-account.html
It looks like you're trying to use "SQL Server Authentication" in the login dialog in SSMS, but the user that you're trying to use is a Windows user/administrator? If so, the fix should be as simple as choosing "Windows Authentication" in the drop-down.
UPDATE: looks like I jumped the gun - this sql server forum thread lists lots of possible issues, including permissions issues, orphan users, etc.
sa... the answer was sa.
I had set the administrative password but didn't know the username to go with it. Very nube, I know, you can hit me with it later.
When I installed SQL it asked me to set administrative password - right now SSMS can login.
Under users I see 1\cory (1 is my machine name - I'm trying a numbering scheme). But if I type that in it fails with the error. SQL says "no, that's an NT login, I can't use those".
Under the users list SQL does in fact show the user as Windows authentication but as I said - for some reason I can't connect using Windows authentication. The connection times out.
I'll just add a direct user name here.
All this is to do the MSVA courses for SQL certification. First exam: get sql SSMS to work.
We are running deployment scripts using pstrami. Part of the deployment is to execute database migrations. The migrations are using an connection string with Integrated Security.
When the script executes on the remote machine the migrations fail with a sql error saying Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'
The person executing the script is a domain administrator. Other deployments that we run execute the remote scripts with the user who started the process.
The problem is that the credentials are not hopping to SQL Server for integrated security. You need to do the following:
On the server (the one that is making the SQL Server connection, as administrator run:
Enable-WSManCredSSP -Role server
On the client machine, as administrator run:
Enable-WSManCredSSP -Role client -DelegateComputer YOUR_SERVER_NAME
To open this up to all servers, you can run:
Enable-WSManCredSSP -Role client -DelegateComputer *
Finally, your invoke command make sure you run -authentication credssp. An example:
invoke-command -computername $remoteServer -authentication credssp -scriptblock { write-host "hello!" } -credential $credentials
This is the scenario:
You run the pstrami(deployment) script from desktopA. The script pushes your installation files to serverA. Then on serverA the scripts are run remotely as the person inititating the script from desktopA. One of the steps is to run a sql database upate with fluentmigrator using a connection string paramter using "integrated security" and the database is on serverB.
Connection string example:
$migration_db_connection = Data Source=serverB;Initial Catalog=PropertyDb;Integrated Security=SSPI;
.\migrate.exe /conn "$migration_db_connection" /db SqlServer /a $migration_assembly /profile DEBUG
Pstrami uses the powershell command invoke-command which uses the account you are running the script under as the default user. So, what happens is that when you run the script from desktopA as "jonDoe" it then authenticates on serverA. So your pstrami scripts run under "jonDoe" on serverA. When you execute the fluentmigrator script on serverA as "jonDoe", fluentmigrator returns an error Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. In IIS, you run into an interesting situation when you need to access another resource off of the IIS server and certain fairly common situations occur. When using Integrated Security, anonymous access is disabled, and impersonation is turned on, a Windows security measure kicks in and doesn't allow your site to access resources on any network servers. (http://weblogs.asp.net/owscott/archive/2008/08/22/iis-windows-authentication-and-the-double-hop-issue.aspx)
This is how I got around the Windows Authentication and the Double Hop problem I ran into. Run your migration scripts directly on your sql database server and include it as a server target in your pstrami environments.
Example:
Environment "dev" -servers #(
Server "serverA" #("InstallWeb")
Server "serverB" #("RunMigrations")
)
More on Double Hop
http://www.spdoctor.net/Pages/message.aspx?name=login-failed-for-user-bdc
http://www.sqlservercentral.com/blogs/sqlsandwiches/2011/06/20/double-hop-of-doom/
I am not able to comment on your question and posting this as an answer. I will update the same later.
It may be due to SQL Server not having the login account for your windows login account. If that is the problem please add the logged in user to the SQL Server in the remote machine.
If this is already addressed, then you have the option of giving Rights as DB_Owner to " NT AUTHORITY\ANONYMOUS LOGON " on the SQL Server as well as on the specific database you are using.