Hello,
We have discovered that unless a user is an administrator on the MS SQL 2005
server, they cannot connect to SSIS server locally or remotely.
The SQL Junkies site has the solution. They recommend that you first add the
user to the Distributed COM Users group. Then you should run
%windir%\system32\Com\comexp.msc to launch Component Services to launch
component server. On the properties of MsDtsServer you can choose security
and from there you can set the Remote Activation permissions to allow the
user to connect the SSIS server remotely. The SSIS service should then be
restarted.
I tried it and it works. However, what are the security implications with
this solution?The implications are basically just what you set - you allow
that user to connect remotely to the process for
MsDtsServer. Not much outside of that really - you're only
changing this for SSIS and that particular user.
-Sue
On Thu, 8 Jun 2006 14:04:04 -0600, "Loren Zubis"
<Loren.Zubis@.gov.ab.ca> wrote:
>Hello,
>We have discovered that unless a user is an administrator on the MS SQL 200
5
>server, they cannot connect to SSIS server locally or remotely.
>The SQL Junkies site has the solution. They recommend that you first add th
e
>user to the Distributed COM Users group. Then you should run
>%windir%\system32\Com\comexp.msc to launch Component Services to launch
>component server. On the properties of MsDtsServer you can choose security
>and from there you can set the Remote Activation permissions to allow the
>user to connect the SSIS server remotely. The SSIS service should then be
>restarted.
>I tried it and it works. However, what are the security implications with
>this solution?
>|||The implications are basically just what you set - you allow
that user to connect remotely to the process for
MsDtsServer. Not much outside of that really - you're only
changing this for SSIS and that particular user.
-Sue
On Thu, 8 Jun 2006 14:04:04 -0600, "Loren Zubis"
<Loren.Zubis@.gov.ab.ca> wrote:
>Hello,
>We have discovered that unless a user is an administrator on the MS SQL 200
5
>server, they cannot connect to SSIS server locally or remotely.
>The SQL Junkies site has the solution. They recommend that you first add th
e
>user to the Distributed COM Users group. Then you should run
>%windir%\system32\Com\comexp.msc to launch Component Services to launch
>component server. On the properties of MsDtsServer you can choose security
>and from there you can set the Remote Activation permissions to allow the
>user to connect the SSIS server remotely. The SSIS service should then be
>restarted.
>I tried it and it works. However, what are the security implications with
>this solution?
>
Showing posts with label discovered. Show all posts
Showing posts with label discovered. Show all posts
Wednesday, March 21, 2012
Remote SSIS Access
Friday, March 9, 2012
Remote Laptop SA Password
Hi All,
We have remote users using sql server 7 on laptops. They use a vb app and replicate with the main server.
I have just discovered they have weak passwords on their sa account.
Others are suggesting that the laptops do not need strong passwords for their sa account as they are only subscribers . Are they talking rubbish?
Thanks,
JJCYou may want to give a look at the article in BOL about xp_cmdshell. Basically, if a dba (or many programmers for that matter) can get your sa password, that dba/programmer can own your laptop. There was a virus that searched the internet for SQL Servers that had no sa password, and it was shockingly effective.
If the laptops are only subscribers, and you do not allow anonymous pull subscriptions, you should be ok at the central server, but those laptops really should have their security beefed up.|||END USERS SHOULD NOT BE USING SA ACCOUNTS!
Even DBAs shouldn't be using the SA account!
Even System Administrators should not use the SA account! They should set up an account that grants themselves only the permissions necessary to do their day-to-day tasks, and only log in as SA when absolutely necessary. Otherwise, sooner or later you WILL do something you wish that you hadn't. Don't think of user accounts as restricitions. Think of them as safeguards!
Give all your users SQL logins or NT logins, and then change your sa password.
blindman|||If possible, set your users' laptops to Windows Authentication only. This way you'll come out clean without having to remember each laptop's SA password, or having to create a user on each laptop.
We have remote users using sql server 7 on laptops. They use a vb app and replicate with the main server.
I have just discovered they have weak passwords on their sa account.
Others are suggesting that the laptops do not need strong passwords for their sa account as they are only subscribers . Are they talking rubbish?
Thanks,
JJCYou may want to give a look at the article in BOL about xp_cmdshell. Basically, if a dba (or many programmers for that matter) can get your sa password, that dba/programmer can own your laptop. There was a virus that searched the internet for SQL Servers that had no sa password, and it was shockingly effective.
If the laptops are only subscribers, and you do not allow anonymous pull subscriptions, you should be ok at the central server, but those laptops really should have their security beefed up.|||END USERS SHOULD NOT BE USING SA ACCOUNTS!
Even DBAs shouldn't be using the SA account!
Even System Administrators should not use the SA account! They should set up an account that grants themselves only the permissions necessary to do their day-to-day tasks, and only log in as SA when absolutely necessary. Otherwise, sooner or later you WILL do something you wish that you hadn't. Don't think of user accounts as restricitions. Think of them as safeguards!
Give all your users SQL logins or NT logins, and then change your sa password.
blindman|||If possible, set your users' laptops to Windows Authentication only. This way you'll come out clean without having to remember each laptop's SA password, or having to create a user on each laptop.
Subscribe to:
Posts (Atom)