Showing posts with label domain. Show all posts
Showing posts with label domain. Show all posts

Friday, March 30, 2012

One last xp_cmdshell Q (sorry)

I run the below on the box that has psExec installed as sa (dbo) in QA.
The MSSQLSERVER service is set to Local Account.
Domain\Administrator will run c:\psexec \\10.2.27.230 -I cmdmgr_Resume.bat
from a CmdExec job sucessfully. I run same from command prompt successfully.
Do I have to set MSSQLSERVER agent to start as admin.?
Or can I explicitly say exec master.Domain\Administrator.cp_cmdshell or
similar?
Even our DBA is stumped!!
EXEC xp_cmdshell 'c:\psexec \\10.2.27.230 -I cmdmgr_Resume.bat' ;
output
---
NULL
PsExec v1.60 - Execute processes remotely
Copyright (C) 2001-2005 Mark Russinovich
Sysinternals - www.sysinternals.com
NULL
Access is denied.
Connecting to 10.2.27.230...
Couldn't access 10.2.27.230:
NULL
It looks like psExec doesn't have permission but it is SQL QA that is the
sourcer of the problem.Local Account? or Local System? The SQL Server service must execute with
the credentials needed to execute commands on the other computer. It cannot
execute as Local System. It must execute as a domain user account.
WARNING!!! It is extremely dangerous to use xp_cmdshell in this way. It is
even more dangerous to run as a domain admin. If you're a consultant, be
sure you have a battalion of lawyers in your pocket and review your
professional insurance contract, because it would be a simple thing for a
smart lawyer to prove gross negligence on your part.
"marcmc" <marcmc@.discussions.microsoft.com> wrote in message
news:642C7D5B-DA48-427D-9535-0BF66E90ADA4@.microsoft.com...
> I run the below on the box that has psExec installed as sa (dbo) in QA.
> The MSSQLSERVER service is set to Local Account.
> Domain\Administrator will run c:\psexec \\10.2.27.230 -I cmdmgr_Resume.bat
> from a CmdExec job sucessfully. I run same from command prompt
successfully.
> Do I have to set MSSQLSERVER agent to start as admin.?
> Or can I explicitly say exec master.Domain\Administrator.cp_cmdshell or
> similar?
> Even our DBA is stumped!!
> EXEC xp_cmdshell 'c:\psexec \\10.2.27.230 -I cmdmgr_Resume.bat' ;
> output
> ---
> NULL
> PsExec v1.60 - Execute processes remotely
> Copyright (C) 2001-2005 Mark Russinovich
> Sysinternals - www.sysinternals.com
> NULL
> Access is denied.
> Connecting to 10.2.27.230...
>
> Couldn't access 10.2.27.230:
> NULL
> It looks like psExec doesn't have permission but it is SQL QA that is the
> sourcer of the problem.|||thx again, what are the alternatives, create an account and lock it down,
maybe? or
"Brian Selzer" wrote:

> Local Account? or Local System? The SQL Server service must execute with
> the credentials needed to execute commands on the other computer. It cann
ot
> execute as Local System. It must execute as a domain user account.
> WARNING!!! It is extremely dangerous to use xp_cmdshell in this way. It i
s
> even more dangerous to run as a domain admin. If you're a consultant, be
> sure you have a battalion of lawyers in your pocket and review your
> professional insurance contract, because it would be a simple thing for a
> smart lawyer to prove gross negligence on your part.
> "marcmc" <marcmc@.discussions.microsoft.com> wrote in message
> news:642C7D5B-DA48-427D-9535-0BF66E90ADA4@.microsoft.com...
> successfully.
>
>|||Create an external process to do whatever it is you need to do. Then you
don't have to worry about the xp_cmdshell security hole. Another solution
is to use replication, but if you can't, then you can queue up the
information in a table and create a dequeue process to move it. Both of
these solutions is more robust, because you can still collect information if
the other system is down.
"marcmc" <marcmc@.discussions.microsoft.com> wrote in message
news:97BD8606-7F5A-4904-B13C-533FE167A77D@.microsoft.com...
> thx again, what are the alternatives, create an account and lock it down,
> maybe? or
> "Brian Selzer" wrote:
>
with
cannot
is
be
a
QA.
cmdmgr_Resume.bat
or
the|||On Wed, 7 Sep 2005 05:46:10 -0700, marcmc wrote:

>I run the below on the box that has psExec installed as sa (dbo) in QA.
>The MSSQLSERVER service is set to Local Account.
>Domain\Administrator will run c:\psexec \\10.2.27.230 -I cmdmgr_Resume.bat
>from a CmdExec job sucessfully. I run same from command prompt successfully
.
>Do I have to set MSSQLSERVER agent to start as admin.?
>Or can I explicitly say exec master.Domain\Administrator.cp_cmdshell or
>similar?
>Even our DBA is stumped!!
Hi marcmc,
(S)he should check out what BOL says about services accounts.
If you really want to do it like this, than the least unsafe way is to:
a) Have your network administrator set up a domain account for use by
the SQL Server service. Make sure to change the password policy to not
automatically age the password.
b) Give this account all privileges required for SQL Server operation,
plus all privileges required to run your batch file. Don't give any
other privileges to this account. If your version of windows allows it,
disable the posibility to log on using this account as a normal user
(i.e. make it an account that can only be used by services)
c) Change the startup parameters for your SQL Server instance to log in
using this account instead of logging in as Local System.
d) Keep your fingers crossed :-)
But I agree with Brian that there are other ways to do this, and that
they are probably better!
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)

Monday, February 20, 2012

Old Users / New Domain - Any way to directly update SYSXLOGINS

FIRST - I already know I it is not recommended to directly update systems
tables - no need to remind me. That being said, here is the scenario. I
have a bunch of users who are switching from one domain to another. EXAMPLE
login -
myco.us.east\joe should NOW be myco.us.west\joe
So, is there any easy way to just change the LOGIN name. I know that
SYSLOGINS is a view and that SYSXLOGINS is the root table. Problem is that
NAME in SYSXLOGINS doesnt seem to reflect the login name, rather the user
name. It would be great is I could just change the login name via SQL - Any
ideas on this' Exactly what columns and where?What is the version of SQL Server?
Take a look at sp_change_users_login in the BOL
"MSSQLServerDeveloper" <MSSQLServerDeveloper@.discussions.microsoft.com>
wrote in message news:CC69F7B5-2B63-4C12-AF93-D883BB692B28@.microsoft.com...
> FIRST - I already know I it is not recommended to directly update systems
> tables - no need to remind me. That being said, here is the scenario. I
> have a bunch of users who are switching from one domain to another.
> EXAMPLE
> login -
> myco.us.east\joe should NOW be myco.us.west\joe
> So, is there any easy way to just change the LOGIN name. I know that
> SYSLOGINS is a view and that SYSXLOGINS is the root table. Problem is
> that
> NAME in SYSXLOGINS doesnt seem to reflect the login name, rather the user
> name. It would be great is I could just change the login name via SQL -
> Any
> ideas on this' Exactly what columns and where?|||hi,
i feel it will not do what you want. Could you do it from EM ?
Regards
--
Andy Davis
Activecrypt Team
---
SQL Server Encryption Software
http://www.activecrypt.com
"MSSQLServerDeveloper" wrote:

> FIRST - I already know I it is not recommended to directly update systems
> tables - no need to remind me. That being said, here is the scenario. I
> have a bunch of users who are switching from one domain to another. EXAMP
LE
> login -
> myco.us.east\joe should NOW be myco.us.west\joe
> So, is there any easy way to just change the LOGIN name. I know that
> SYSLOGINS is a view and that SYSXLOGINS is the root table. Problem is tha
t
> NAME in SYSXLOGINS doesnt seem to reflect the login name, rather the user
> name. It would be great is I could just change the login name via SQL - A
ny
> ideas on this' Exactly what columns and where?|||Hi,
FYI - The undocumented sysxlogins table doesn't exist in SQL 2005. The
syslogins view is preserved for backwards compatibility, but it's
deprecated.
Unfortunately, I think you will need to drop and recreate the logins.
I think it should be reasonably straightforward to generate the code to
do that. Since you have NT authenticated users, you won't have to
worry about passwords, which simplifies the task somewhat.
Good luck.
Regards,
Clifford Dibble [MSFT]
Andy Davis wrote:[vbcol=seagreen]
> hi,
> i feel it will not do what you want. Could you do it from EM ?
>
> Regards
> --
> Andy Davis
> Activecrypt Team
> ---
> SQL Server Encryption Software
> http://www.activecrypt.com
>
> "MSSQLServerDeveloper" wrote:
>

Old SQL Cluster to Join a New Domain?

Hi. In general terms, what would be the steps to have my
SQL2000 (on W2K OS) 2 node-clusters join a new domain?
They are member servers authenticating with a W2K DC on
their subnet, but we would like to install W2003 on that
DC (bare-metal NO upgrade, due to past history of AD
replication issues on that W2K DC. It's now the only DC
on it's own subnet, with very old AD info it. We figure
a clean install of W2003 with new clean domain would be
better).
Thanks.
Last time I did this, I just went into Windows, ignored the message that
popped up, and changed the domain name for each machine. (I stopped the
entire cluster first.)
Mike
Principal Mentor
Solid Quality Learning
"More than just Training"
SQL Server MVP
http://www.solidqualitylearning.com
http://www.mssqlserver.com
|||Look at the following article:
HOW TO: Change Domains for a SQL Server 2000 Failover Cluster
http://support.microsoft.com/?id=319016
Rand
This posting is provided "as is" with no warranties and confers no rights.