|
|
|
date: Thu, 9 Feb 2006 11:07:53 +0530,
group: microsoft.public.sqlserver.securitytools
back
Re: ImpersonateClient Property in DMO / SMO
Hi Dan,
Thanks for the reply.
Do you mean to say that ..
if( a proxy acc is there && client is !sysadmin )
{ impersonation occurs therefore , impersonatclient =true in this case }
else
{ No impersonation occurs therefore , impersonatclient =false in this
case }
??
I am facing problem regarding the impersonateClient property in "Sql server
2000" also.
By documents , The ImpersonateClient property exposes the security context
for nonadministrative users executing xp_cmdshell.
This property applies To the IntegratedSecurity Object (DMO).
I tried the following ...
1. Firstly I removed the proxy account on the agent.
2. Tried to print the value of the ImpersonateClient ..
code snippet ::
//
Set oIntegratedSecurity = oSQLServer.IntegratedSecurity
oIntegratedSecurity.ImpersonateClient = False
x = oIntegratedSecurity.ImpersonateClient
MsgBox x
//
It prints False.
// its Obvious behaviour
3. Now I created a proxy account on the agent.
4. Again Tried to print the value of ImpersonateClient.
It again prints False.
// its unexpected behaviour
Internally when I saw the registery value ::
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer\ImpersonateClient
It was false.
5. Then I manually set the value as true by ..
oIntegratedSecurity.ImpersonateClient = True
6. Then I repeated the above steps ( Disabling Proxy account) .. I GET
ImpersonateClient = True ( whn used to print )
( reEnabling Proxy account) .. I GET ImpersonateClient = True ( whn used
to print )
Please Help Me out , in which case I should get ImpersonateClient = True
(without explicitly doing that).
According to my observations I think that property is never being used evn
in 2000. Is
it a really useless property ??
TIA fr help
Vaibhav
...
"Dan Guzman" wrote in message
news:%238738VkLGHA.1536@TK2MSFTNGP11.phx.gbl...
> The documentation states that the ImpersonnateClient property is a
> Settings class property but I don't see it implemented there. As a
> workaround, another method to retrieve the value:
>
> string proxyAccount = (string) ServerConn.ExecuteScalar(
> "SELECT credential_identity" +
> " FROM sys.credentials" +
> " WHERE name = N'##xp_cmdshell_proxy_account##'");
>
> I'm not sure if this a documentation or product issue. I submitted
> feedback at http://lab.msdn.microsoft.com/productfeedback/.
>
> --
> Hope this helps.
>
> Dan Guzman
> SQL Server MVP
>
> "Vaibhav" wrote in message
> news:eutmMuTLGHA.3100@tk2msftngp13.phx.gbl...
>> Hello,
>> In SQL-DMO , under the object IntegratedSecurity, the ImpersonateClient
>> property exposes the security context for nonadministrative users
>> executing xp_cmdshell.
>>
>> I am facing problems in accesing this property using DMO on Yukon (as its
>> not supported).
>>
>> Does anybody knows about how to access this propery for Yukon (Sql Server
>> 2005) using SMO ?
>>
>> The Documentation says that , the Functionality of IntegratedSecurity
>> Object of DMO is moved to ServerConnection object in
>> Microsoft.SqlServer.Management.Common namespace of SMO
>>
>> Please post your comments asap.
>>
>> Thanks
>>
>> Regards,
>>
>> Vaibhav
>>
>>
>>
>
>
date: Mon, 13 Feb 2006 10:29:28 +0530
author: Vaibhav
Re: ImpersonateClient Property in DMO / SMO
ImpersonateClient is true when only sysadmin users can execute xp_cmdshell
and false when non-sysadmin users are not permitted to execute xp_cmdshell.
This is internally implemented as a registry setting and also maps to the
'only users with SysAdmin privileges...' checkbox in Enterprise Manager
under SQL Server Agent properties-->Job System. Importantly, the
ImpersonateClient setting is independent of the proxy account configuration
so the property does not change when you set or delete the proxy account
outside the EM GUI.
If ImpersonateClient is false and a non-sysadmin user attempts to execute
xp_cmdshell, they'll get an error because proxy account security context
can't be set.
> Do you mean to say that ..
>
> if( a proxy acc is there && client is !sysadmin )
> { impersonation occurs therefore , impersonatclient =true in this case }
> else
> { No impersonation occurs therefore , impersonatclient =false in this
> case }
>
> ??
What I mean is:
if( client is sysadmin )
{
//ImpersonateClient setting is not relevant.
//xp_cmdshell is run under SQL Server service account
}
else
{
if( impersonateClient == true )
{
//Raise error since non-sysadmin users can't execute xp_cmdshell
}
else
{
//ImpersonateClient is false.
//Attempt to use proxy account security context.
//Error will result of proxy account is not configured properly.
}
}
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Vaibhav" wrote in message
news:uVx$HpFMGHA.3196@TK2MSFTNGP09.phx.gbl...
> Hi Dan,
> Thanks for the reply.
> Do you mean to say that ..
>
> if( a proxy acc is there && client is !sysadmin )
> { impersonation occurs therefore , impersonatclient =true in this case }
> else
> { No impersonation occurs therefore , impersonatclient =false in this
> case }
>
> ??
>
> I am facing problem regarding the impersonateClient property in "Sql
> server 2000" also.
>
> By documents , The ImpersonateClient property exposes the security context
> for nonadministrative users executing xp_cmdshell.
> This property applies To the IntegratedSecurity Object (DMO).
>
> I tried the following ...
>
> 1. Firstly I removed the proxy account on the agent.
> 2. Tried to print the value of the ImpersonateClient ..
> code snippet ::
> //
> Set oIntegratedSecurity = oSQLServer.IntegratedSecurity
> oIntegratedSecurity.ImpersonateClient = False
> x = oIntegratedSecurity.ImpersonateClient
> MsgBox x
> //
>
> It prints False.
> // its Obvious behaviour
>
> 3. Now I created a proxy account on the agent.
>
> 4. Again Tried to print the value of ImpersonateClient.
>
> It again prints False.
> // its unexpected behaviour
>
>
> Internally when I saw the registery value ::
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer\ImpersonateClient
>
> It was false.
>
> 5. Then I manually set the value as true by ..
> oIntegratedSecurity.ImpersonateClient = True
>
> 6. Then I repeated the above steps ( Disabling Proxy account) .. I GET
> ImpersonateClient = True ( whn used to print )
>
> ( reEnabling Proxy account) .. I GET ImpersonateClient = True ( whn used
> to print )
>
>
> Please Help Me out , in which case I should get ImpersonateClient = True
> (without explicitly doing that).
>
> According to my observations I think that property is never being used evn
> in 2000. Is
> it a really useless property ??
>
>
> TIA fr help
> Vaibhav
>
>
>
> ..
>
>
>
>
> "Dan Guzman" wrote in message
> news:%238738VkLGHA.1536@TK2MSFTNGP11.phx.gbl...
>> The documentation states that the ImpersonnateClient property is a
>> Settings class property but I don't see it implemented there. As a
>> workaround, another method to retrieve the value:
>>
>> string proxyAccount = (string) ServerConn.ExecuteScalar(
>> "SELECT credential_identity" +
>> " FROM sys.credentials" +
>> " WHERE name = N'##xp_cmdshell_proxy_account##'");
>>
>> I'm not sure if this a documentation or product issue. I submitted
>> feedback at http://lab.msdn.microsoft.com/productfeedback/.
>>
>> --
>> Hope this helps.
>>
>> Dan Guzman
>> SQL Server MVP
>>
>> "Vaibhav" wrote in message
>> news:eutmMuTLGHA.3100@tk2msftngp13.phx.gbl...
>>> Hello,
>>> In SQL-DMO , under the object IntegratedSecurity, the ImpersonateClient
>>> property exposes the security context for nonadministrative users
>>> executing xp_cmdshell.
>>>
>>> I am facing problems in accesing this property using DMO on Yukon (as
>>> its not supported).
>>>
>>> Does anybody knows about how to access this propery for Yukon (Sql
>>> Server 2005) using SMO ?
>>>
>>> The Documentation says that , the Functionality of IntegratedSecurity
>>> Object of DMO is moved to ServerConnection object in
>>> Microsoft.SqlServer.Management.Common namespace of SMO
>>>
>>> Please post your comments asap.
>>>
>>> Thanks
>>>
>>> Regards,
>>>
>>> Vaibhav
>>>
>>>
>>>
>>
>>
>
>
date: Mon, 13 Feb 2006 07:21:09 -0600
author: Dan Guzman
|
|
