Ok, I am running SQL Server 2008 R2 on a small environment. I currently have the data on the same drive as the backups (I know, bad idea, but I just inherited this challenge). I have several jobs setup to notify me if they fail.
My boss is good with SQL and knows how to maintain the system, but is not a dedicated DBA, which is why they hired me. Well I was just going thru their setup for the AM jobs and they had several fail last night. Wondering why this did not generate any emails, I decided to do a little digging.
One thing I found was that the SQL Server Agent service was running under a domain login that really isn't used anymore except for SQL. I changed the agent to start under the "local system account" and restarted the service and the emails started coming in. The problem is, that the agent needs to run under the domain credentials due to some of the jobs that run.
How can I set the user account to have the privileges as the local system, to be able to run the emails? As soon as I set the agent back to the domain login, then the emails stopped working.
I can't comment until my reputation is higher so forgive me if this "answer" is off the mark. But the first thing I would check is whether the domain account has permissions to the MSDB database.
http://technet.microsoft.com/en-us/library/ms188719(v=sql.105).aspx
"To send Database mail, users must be a user in the msdb database and a member of the DatabaseMailUserRole database role in the msdb database."
Related
List of unidentified sql jobs
Our SQL Server 2008 R2 has lots of auto generated jobs from nowhere as can be seen from image above. I strongly suspect this causes our server password keeps reset daily for no reasons (I had untick those 'Enforce password policy' checkboxes). For now I had delete the jobs but I am not sure can this really solve the root of the problems. Any idea on this? Thanks guys...
Your server has most likely been compromised. The most appropriate thing to do in this situation is to either reinstall everything from scratch and restore your last known good data backup (prior to getting compromised), or perform a bare metal restore of the server from the last known good (uncompromised) backup. At this point you don't know what malicious software is still on that server, so you have to assume that it's riddled with it.
Do this after you've ensured that the server will be secured from network attacks and don't leave it exposed to the public internet. If it wasn't previously exposed, you may have malicious software on your company network.
have a .net app that talks to a locally hosted MSDE instance -does anyone know the user account the MSDE runs under?
The business sysadmins have released a bunch of "upgrades" to PC's (apparently for active directory and a bunch of other stuff) and now the app cannot connect to the database - so we figure the user account may have been deleted.
Buzz
MSDE - I haven't come across that in a while, that dates back to SQL Server 2000! (MSDE was replaced with SQL Server Express in 2005, so you're a bit out of date).
Anyway, MSDE runs as an NT service, and every service (at least up to Windows Vista) runs under a user account: often one of SYSTEM, NetworkService, or LocalService (Windows 7 and later introduces the concept of Service Identities, which is complicated). You can also run a service under its own user identity, which can be a built-in principal like SYSTEM, a local user account, or a domain account.
I've forgotten the defaults that MSDE uses, but considering it was made in 1999/2000 before NetworkService was invented, it probably runs under SYSTEM or LocalService. To be sure, check your Services.msc listing.
As for the failure-to-connect, that could be caused by anything: firewall, configuration error, etc, not just a wrong service identity.
So anyway, check your services.msc and your Application Event Log, then report back with your findings.
My windows server 2008 allows only one user to login at a given time. When another user tries to remote login into the same server, the previously active user's session gets disconnected. This is creating few problems for us.
Can anyone tell me a way to find whether a user has already logged into the server/ to find currently active user without actually having to login into the server so that the already active user's session will not be disturbed.
Pl provide your valuable thoughts.
there are 2 type of users interactive (which you are looking for?) and non-interactive (System, batch, network etc.)
So there is an API Win32_LogonSession which you can see. also there is a good article on http://www.codeproject.com/Articles/7483/Enumerating-Logon-Sessions
Is it wise to use Domain Administrator as a SQL Windows Authentication log-in?
No. Local admin, perhaps, yes: never domain admin
For example, xp_cmdshell would allow complete control over AD and your environment. CLR code could do the same. Although these are disabled by default, you can't rely on that to protect your entire network.
Edit:
Logging in as a user as domain admin is no different to using Exchange or similar with the same acount. For SQL Server. no extra rights are conferred or implied because all permissions are defined within SQL Server.
So if you only have a "SQL Server Admin" group as sysadmin, and the domain and local admins are not in this group or set up as logins, then they get normal user rights as per their login. Or they can't even connect.
Of course, as domain or enterprise admins they could just add themselves to the "SQL Server Admin" group... but this requires an extra step and restricts your sysadmin to the correct admin group.
After all, you wouldn't let me as SQL God near your Exchange server...
I think some of the posts have assumed you mean to run the SQL Server service under a domain administrator account (which I agree, would be a security hole), but as you have said in your clarification, it is just to log in to do stuff against the database, I don't see a problem with it....As long as the user in question (I'm guessing it's you here), knows not to drop the production database etc.!
Certain things you need to do against an install require DBA priveleges, if you acquire those by being a domain admin, then what difference does it make?
a. If you have no security problems than - it doesn't matter.
b. if you are connected to the internet, you shouldn't. someone can attack your domain using holes in sql code if the app you're using uses the domain admin authentication. or if someone get access to your administration machine.
c. there is no linkage between domain admin and sql server admin - so why do it ?
Just to be clear - It is not wise !
In my opinion, I wouldn't use an Administrator account for anything management related (that's my Linux background telling me that root accounts shouldn't be used).
It depends a lot about - well - your size and security practices. It does show a security risk, but whethe rit is wise o wnot depends on the rest of the setup.
I am using SQL Server 2008. I am confused about which account will be used when a SQL Server agent job runs. My confusions are,
SQL Server agent as a Windows Service which we could control from Windows Service Management Console, from there we could set the account to run SQL Server Agent (LocalSystem in my computer);
Could I set SQL Server agent job level account to run on?
Could I set in each step which account SQL Server agent job step will run on?
I have above confusions because 3 different account systems may be used and my concern is what is the actual account each step will run on, and I want to avoid any permisson issues (i.e. I want to make sure the account have enough permission.). Any comments or advice? Appreciate anyone could clarify the 3 levels of accounts, which makes me very confused.
thanks in advance,
George
I would typically run the SQL Server Agent jobs under the same account as your app accesses the database.
If that account is too limited in its permissions (which might be a good thing!), I would create a single account for that app and all its SQL jobs (if that's possible) and run all SQL jobs under that account.
You could potentially run each step under a different account, but I wouldn't use that in general (it just makes it really hard to know and understand what is run under which account). Only use it if you have to run a particularly sensitive step that needs a bunch of extra permissions and those permissions are only available to a particular system account or something.
The account under which the SQL Server Agent windows service runs really doesn't have an impact on what your job steps will be run under.
So it boils down to really just two accounts:
one account is needed to run the SQL Server Agent Windows service - this is a Windows account on your machine / server which needs to have enough permissions to run the service, start and stop it - either use LocalSystem, Network Service, or whatever other Windows account you have to run services with
The other account would be the account to run your SQL Server Agent steps under - that's typically a SQL Server account (which could be based on a Windows account), and it needs enough privileges inside SQL Server to do its job, e.g. it needs access to the database objects and all. I would strive to have just one account for each app that runs the SQL Server jobs - makes life a whole lot easier!
Marc
PS: To set the user to run a step under, you need to use the "Advanced" page on the Job step property dialog and select the user from a popup window:
You can create Credentials in SQL Server (use Mgt Studio, under Security). Then create a Proxy in SQL Agent to use those credentials, telling it what kind of job steps can be used by the proxy. Then you get the choice to use that Proxy in the job step itself.
So... I make accounts for various SSIS packages to run under, so that I can keep the SQL Agent Service Account low privilege, and use a proxied credential with slightly higher privilege (not admin though, just enough permission to connect to other systems, including the File System).
Rob