Showing results for 
Search instead for 
Do you mean 
Community Home Request Access Read Blogs Share Your Ideas Search Community View My Settings
Reply
Highlighted
Copper Elite Contributor
Posts: 153
Registered: ‎02-27-2010

Remote Client Security Risks (7.2.2)

When cutting a new remote database to a SQL Express Instance from a SQL Host we've noticed that the host sysdba password must be entered instead of the SQL Express sysdba password (i.e. we suspect that the coding behind Option 9 may be a defect since the SQL Express Instance sysdba password would make more sense than the host sysdba password which is redundant to Option 3). Furthermore, in order to attach the remote to a user's SQL Instance we need to update the Connection Manager to reflect the host's sysdba password rather than the default provided by Sage/Microsoft. Is anyone familiar with this issue and more importantly, is there an easy way to update the sysdba password provided to the remote database prior to attaching it to the user's SQL Instance (so that we don't have to update all our remote user's connection managers and more importantly, give them access to the host sysdba password)?

 

Additional Info:

SalesLogix Administrator > Tools > Create Remote User Databases > Options:

1. Creation Option: Create on SQL Host Host

2. Database Owner Login: sysdba

3. Password: ******

4. Target Database Administration Login: sa

5. Password: ******

6. Remote Path: [Drive Shared to Admins Only]

7. DTS Options: Create DTS package and run it immediately

 

A recent security audit understandably flagged SalesLogix admin access to the sa password as a violation to be corrected immediately so we switched our Creation Option to Create on SQL Express Instance from SQL Host which added 2 new fields to the above list of 7 that were required in Options for cutting a new Remote Database:

8. SQL Express Instance Name:  [SLX Admin's SQL Express Instance Name]

9. SQL Express sysdba password: ****** (note: actually requires host sysdba password to successfully cut remote!)

 

The critical difference which should satisfy our security's concerns is the fact that the sa password (#5 above) now refers to the sa password of the SLX Admin's SQL Express Instance rather than the sa password to our dba's SQL Server which has other sensitive dbs on it. We also update Option 6 to a valid path on the SLX Admin's PC. But I think we still need to remedy the sysdba problem noted above even though it's not as critical as the sa password.

 

Thanks,

Larry Esposito

Highlighted
Gold Super Contributor
Posts: 3,087
Registered: ‎03-19-2009

Re: Remote Client Security Risks (7.2.2)

Works the same in 7.5.3

--
RJ Ledger - rjledger@rjlSystems.net +1 603.369.3047 x101

".. Innovators in Mobility - Experts in Workflow Automation..."
http://www.rjlSystems.net - blog: www.rjlSystems.net/blog.html
Highlighted
Copper Elite Contributor
Posts: 153
Registered: ‎02-27-2010

Re: Remote Client Security Risks (7.2.2)

Is that how it should work?
Highlighted
Copper Elite Contributor
Posts: 153
Registered: ‎02-27-2010

Re: Remote Client Security Risks (7.2.2)

I found a Mike Spragg post in SLX Developer which helped me test and confirm the following workaround:

 

  1. Cut the db using the 9 options above including the host sysdba pw twice and slx admin's sql instance sa pw
  2. Update the slx admin's sql instance sysdba pw to the host sysdba pw using standard osql commands
  3. Attach the db to the slx admin's sql instance
  4. Update the slx admin's sql instance sysdba pw to the standard slx sysdba pw using standard osql commands
  5. Detach the db from the slx admin's sql instance using the \admin switch
  6. Copy the mdf to the user's desktop and Attach it to their sql instance
  7. Have the user login to their new remote (no need to update connection manager since the sysdba pw was corrected)

So I have 3 questions:

  1. Does the above process sound like the most reasonable workaround to keep host sysdba & sa pws away from users?
  2. Is the sysdba pw coded within a db such that it can only be attached to a SQL instance with the same sysdba pw?
  3. Why do osql commands allow you to update sysdba and sa passwords without knowing the existing sql instance pws?

Again, the whole purpose here is not to compromise the host sa and sysdba pws to our users or their pcs. Hopefully, the SLX remote cutting defect will be identified and corrected some day soon so that we can eliminate the extra steps.

 

Thanks,

Larry Esposito

 

Highlighted
Copper Elite Contributor
Posts: 153
Registered: ‎02-27-2010

Re: Remote Client Security Risks (7.2.2)

SalesLogix was unable to replicate the problem. So we tried again and sure enough it's now working as it should. My DBA and I can't explain what happened but originally I was unable to cut the remote db until she entered the host pw which I didn't even know. But I'm glad it's working.

 

As for the 3 questions, the first one is a moot point now that it's working. I would assume the second answer is yes from our experiences trying to attach the remote. But it's number 3 that still perplexes me. What good is a password if commands allow you to change that password without knowing the original?

 

Hopefully, I'll get an answer from that one sooner or later.

 

Thanks,

Larry Esposito