Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

SQL Server Security Part 1 Expand / Collapse
Author
Message
Posted Tuesday, February 1, 2005 4:21 PM


SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Wednesday, April 30, 2014 9:23 AM
Points: 649, Visits: 206

I'm looking into the restriction of access rights (via "guest" and "public") in the master database, and have a question. In the list of procedures to remove access to, you list "xp_perfmonitor". What is this procedure? What does it do? And why can't I find it in the master database, the Microsoft web site, or anywhere on Google that doesn't show the exact same list?

Oh.

I (mostly) figured it out while writing the question, but will still post it for potential discussion purposes.

   Philip




Post #158931
Posted Tuesday, February 1, 2005 4:26 PM


SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Wednesday, April 30, 2014 9:23 AM
Points: 649, Visits: 206

And that goes double for xp_schedulersignal!

   Philip

 




Post #158933
Posted Friday, February 11, 2005 12:04 PM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Monday, July 7, 2014 12:50 PM
Points: 292, Visits: 264

I don't think the account you log into the machine under for the installation of SQL Server has anything to do with the account that the service(s) run under afterwards. If you create domain accounts for the SQL Server services and specify those during installation, those are the accounts the services are configured to use, not the account you're logged in as. Also, when you specify those accounts, SQL Server sets up the minimum necessary permissions for the accounts so you don't need to go through the trouble of doing it manually. Also, if you change the service account later through Enterprise Manager, it sets up the appropriate permissions though it probably does not remove them from the other account.

Also, file-system encryption does put a hit on performance. Putting database files in an encrypted location is not recommended unless the sensitivity of the data warrants the performance hit and, even then, there are probably better options such as third-party solutions. Encrypting backups is not  bad idea but using file-level encryption is. NTFS encryption is too heavily dependant on the keys for the service accounts. If you want to encrypt your backups, go ahead and fork out some extra dough for LightSpeed for SQL Server (http://www.imceda.com) or something similar. It will perform better and has the added bonus of providing encryption and compression simulataneously which NTFS does not permit.



Bryant E. Byrd, BSSE MCDBA MCAD
Business Intelligence Administrator
MSBI Administration Blog
Post #161185
Posted Monday, February 14, 2005 8:31 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Friday, June 6, 2014 2:06 PM
Points: 1,040, Visits: 277

Under the section labeled "The SA Account" you have the following statement regarding the "sysadmin" role,  "Never grant this privilege to any other user, there is simply no reason to in a production environment.> "  I wonder if this holds true regardless of the environment and number of DBA's.  >

>In our environment we have three DBA's that share responsibility for mananging our production SQL Server environment.  We all know the SA password, and could use it to perform production work if we chose to go that route.  But instead each DBA has a SQL Server Logon for performing sysadmin duties.  We have done this for audit trail purposes.  Doing this allows us to identify which DBA has done what.  If we shared the SA account we won't be able to determine which DBA has made a particular change. >



Gregory A. Larsen, MVP

Need SQL Server Examples check out my website at http://www.sqlserverexamples.com
Post #161467
Posted Monday, February 14, 2005 9:16 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Yesterday @ 9:28 AM
Points: 1,233, Visits: 2,737

  We have quite a few software packages running on SQL Server here. It is amazing when a tech. person comes to install their app. and they either create or already have an extremely simple ID with a matching password or one letter password. AND or use 'sa' or grant 'sa' rights to a new ID..... When I question this and or say I want a different password assigned to the ID they look at me like I have two heads....

 Personally, I believe Microsoft needs to really change the thinking about security in SQL Server as with it being so open today small companies do this type of stuff and some of this poor security we are stuck with due to the design of the application. I know some of this has been addressed in SS2005 but I am not sure how much nor to what degree either.

 




Post #161488
Posted Thursday, March 9, 2006 2:38 PM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Saturday, March 14, 2009 5:17 PM
Points: 85, Visits: 63

sa is a tabu for remote connections (password goes as open text if there is no forced network encryption). a dba has to have a good reason to make me think they need sa to login.

another exeption for a user to be in master is sql service account (when buildin/administrators is removed). this accoun doesn't need to be windows administrator, syadmin has to be granted to it. in my case service account sit in master in addition to sa.

Post #264668
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse