The Forums on slxdeveloper.com are now retired. The forum archive will remain available for the time being. Thank you for your participation on slxdeveloper.com!
|
|
SQL SA Account 
Posted: 24 Jul 07 12:31 PM
|
Does anyone know the minimum SQL security settings for the SA
account required by SalesLogix to cut remote DBs. Our IT dept will not
let us use SA. We can create another account but cannot give full SA
rights. Please advise |
|
|
|
Re: SQL SA Account
Posted: 24 Jul 07 4:03 PM
|
The local MSDE SA password can be blank.
You are probably speaking of the user account for the SQL server to create remote databases. Just create a user named 'saleslogix' on the SQL server and use it for creating remote databases. The account WILL need to have SQL server admin rights.
See page 16 of the SalesLogix 6.2 Implementation Guide.
|
|
|
|
Re: SQL SA Account
Posted: 25 Jul 07 7:17 AM
|
Originally posted by Tom A
Does anyone know the minimum SQL security settings for the SA
account required by SalesLogix to cut remote DBs. Our IT dept will not
let us use SA. We can create another account but cannot give full SA
rights. Please advise |
|
Been down this road MANY times over many years w/MANY clients.. and their "DBA's".....
You must have Create DB rights....
Some of the best DBA's in the best companies have tried to avoid using sa.. in the end they all give up..
--
rjl |
|
|
|
Re: SQL SA Account
Posted: 25 Jul 07 8:19 AM
|
Ahh yes... the text book use of SA versus reality. Yeah.. I've seen reality hit text book techies many times.
John G. |
|
|
|
Re: SQL SA Account
Posted: 25 Jul 07 8:23 AM
|
So if I understand you correctly, you're saying that if I create a separate SQL user Account and give that account "dbcreator" roles and use that as the HOST DB Admin ID in the SLX Administrator that I will be able to sucessfully cut and detach remote DBs for users? I thought we had tried this before and it didn't work. Why did SalesLogix Tech support tell me I had to use "Sysadmin"? Are there any other DB Roles or settings I need to have on this account?
sysadmin: Can perform any activity in SQL Server
serveradmin: Can set server-wide configuration options, shut down the server
setupadmin: Can manage linked servers and startup procedures
securityadmin: Can manage logins and CREATE DATABASE permissions, also read error logs and change passwords
processadmin: Can manage processes running in SQL Server
dbcreator: Can create, alter, and drop databases
diskadmin: Can manage disk files
bulkadmin: Can execute BULK INSERT statements
|
|
|
|
Re: SQL SA Account
Posted: 26 Jul 07 11:21 AM
|
NO..
What I am saying is that you can try all day long and you are wasting your time.
--
rjl |
|
|
|
Re: SQL SA Account
Posted: 26 Jul 07 1:29 PM
|
| I'm sorry I don't understand your comment. Is the role of DB Creator enough security rights to use for an SA 'like' account? Or do you have to have SysAdmin roles? |
|
|
|
Re: SQL SA Account
Posted: 26 Jul 07 1:31 PM
|
| We cannot give any account sysadmin rights because that gives access to all of the SQL databases on the cluster. Is there anyway around having to give sysadmin roles to cut a remote DB? |
|
|
| |
|
Re: SQL SA Account
Posted: 27 Jul 07 10:35 AM
|
| We tried using an SA-like account, but it still didn't work. We ended up using the actual SA account. |
|
|
|
Re: SQL SA Account
Posted: 27 Jul 07 11:12 AM
|
SLX 6.2 sp2
We had this same issue with sa rights but came up with a work around. For generating the remote databases, we were able to use sysdba (we could get those rights) and we of course use that for the Host db owner id. As for the Host DB Admin id, we have a user id "slxsa" which has the following server level permissions: setup administrators, process administrators, disk administrators, and database creators and slxsa also is a dbo for SalesLogix.
This works well enough to create the database but despite what is noted in Administrator when the remote is created, the remote database could not be detached (rights). Our dba team then created a detach_request database on the server with a user id having execute rights on a few stored procs that show databases and detaches the requested database.
The process adds a couple steps to the remote database process but it does skirt the sa rights issue.
We are testing the upgrade to 7.0.1 and we found that the slxsa id needs os rights to run extended stored procs (xp_cmdshell) so heads up on that . |
|
|
|
Re: SQL SA Account
Posted: 27 Jul 07 11:13 AM
|
How about switching to a SYSDBA like account? Say SYSDBA2?
We are using monitoring software on our databases and want to know when the application is making changes or when someone is logging into the database directly, and have proposed using a different ID for database access for the application.
Thanks,
Ian |
|
|
|
Re: SQL SA Account
Posted: 23 Aug 07 10:33 AM
|
Actually I just found out that there is a very simple way around it if you're running 7.0.1
In the Create Db Options you simply use Create on MSDE instance from SQL Host and plug in your local machine name and sysdba password and change the path to your local machine. This works rovided you have MSDE installed on your local machine which is on the remote CD. |
|
|
|
Re: SQL SA Account
Posted: 23 Aug 07 10:35 AM
|
Still gives full access to SQL Enterprise which is what we're trying to avoid because of multiple databases.
Actually I just found out that there is a very simple way around it if you're running 7.0.1
In the Create Db Options you simply use Create on MSDE instance from SQL Host and plug in your local machine name and sysdba password and change the path to your local machine. This works rovided you have MSDE installed on your local machine which is on the remote CD. |
|
|
|
Re: SQL SA Account
Posted: 23 Aug 07 10:35 AM
|
Actually I just found out that there is a very simple way around it if you're running 7.0.1
In the Create Db Options you simply use Create on MSDE instance from SQL Host and plug in your local machine name and sysdba password and change the path to your local machine. This works rovided you have MSDE installed on your local machine which is on the remote CD. |
|
|
|