Users and Security

  • Hi all,

    We are installing SQLserver 2005 in our production environment for the first time.

    Normally the SQLserver services (2000) are running with a different account then Local System.

    Does anyone know if this would be a problem if we would do the same in SQL2005 ?

    thanks in advance.

     

    Jurgen

     

     

     

  • Jurgen

    No problem and in fact recommended by Microsoft.  Under 2005 there are more services than just sql server engine and agent service. You could use a different login for each.

    The main thing is to ensure you understand whther or not sql server services need to access other none local resources.  If the agent service needs to do this then it must be a domain account not local.  MS articles also indicate that the sql engine service should have least privs and not be in the local admin grp, the agent however needs to be a local admin if running cmdexec or does autorestart of services. 

    Basically I use a separate local account for each service with the agent account in local admin group.  If any connectivity is required which is external to the server then the account is made a domain acct. 

     

    See article here for full info

    http://msdn2.microsoft.com/en-us/library(d=printer)/ms143504.aspx

    Regards

    Derek

     

  • Thx for the reply Derek,

    I just need to know if there are issues when running with a different account, because we are using Aggregate function (CLR) and DTsx packages that will write to the filesystem (local).

    Regards,

     

    Jurgen

     

     

  • So long as the account has perms on the dir or path and file it is writing to then no problem.

    Note that depending on what the dts package does (SSIS has new features, it can for example change the context of who is performing the operation to the filesystem).  If all else fails test it (in a devt or test environment first).  You can always change the login that starts the various services anyway.

  • These settings/configurations i can handle, as long as Microsoft did not include new configuration tools for this.

    Thx

  • Exnted stored procedures are the old way - managed code and CLR integration is the new way.

    If your old processes use xp_cmdshell you should instead write an assembly to do the specific task and grant it WITH PERMISSION_SET = EXTERNAL_ACCESS

    Simmilar to 2000 it will then by default run as the SQL Server service to access the resources, but you can set it to impersonate the context of the calling user if that is more appropriate by using the WindowsImpersonationContext object.

  • thx for the info

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply