August 19, 2009 at 5:24 am
I've upgraded SQL 2005 to SQL 2008 on a server. Separate instance and i've recreated all logins.
My app, ssis packages etc all still work via NT authentication but I need to ascertain 'how'.
Other than removing each login in turn and testing, can anyone suggest a way i can prove which login is reponsible.
I have the following collection of logins on my instance.
BUILTIN\Administrators
NT AUTHORITY\NETWORK SERVICE
NT AUTHORITY\SYSTEM
I also have
NT SERVICE\MSSQLSERVER and
NT SERVICE\SQLSERVERAGENT
which have been created despite me providing domain accounts for my services.
Any help tracking this down is much appreciated.
September 4, 2009 at 3:35 am
Dont really understand what you are trying to achieve here. if you can give more detail
--------------------------------------------------------------------------------------
[highlight]Recommended Articles on How to help us help you and[/highlight]
[highlight]solve commonly asked questions[/highlight]
Forum Etiquette: How to post data/code on a forum to get the best help by Jeff Moden[/url]
Managing Transaction Logs by Gail Shaw[/url]
How to post Performance problems by Gail Shaw[/url]
Help, my database is corrupt. Now what? by Gail Shaw[/url]
September 6, 2009 at 3:42 pm
The accounts listed in my first post are present on servers, i'm trying to reduce them to just those absolutely necessary.
Basically I want to simplify the security model.
r
December 8, 2009 at 7:43 am
NT SERVICE\MSSQLSERVER and
NT SERVICE\SQLSERVERAGENT are created when you set up the service for SQL Server and Agent. It does not create the user that is assigned to the service in the DB but it will have these two NT Service.
NT AUTHORITY\SYSTEM is used by quite a few internal tasks if I am not mistaken. If you want to remove BuildIN Administrators, make sure you add your user name (Windows Login) as sysadmin.
Check this link. You will get all the info you need regarding all these users.
http://msdn.microsoft.com/en-us/library/ms143504.aspx
-Roy
December 8, 2009 at 8:54 am
If you want to reduce the logins you need, you can remove logins from within SQL Server, but as you find out what's being used, you'll be breaking things. Make sure the business knows that. You can add them back, but you are asking for downtime or issues.
If that's a problem, you'd be better off going through your packages and checking the connections.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply