Re: Impersonating a domain user for debugging purposes

From: Dan Guzman (danguzman_at_nospam-earthlink.net)
Date: 06/22/04 

Date: Tue, 22 Jun 2004 08:13:33 -0500

As a sysadmin role member, you can execute a SETUSER command to use
different security context. For example:

SETUSER 'MyDomain\MyUser'
GO
EXEC MyProcedure
GO

You can revert back to your own security context by running SETUSER with no
parameters. See the Books Online for more information. 

-- 
Hope this helps.
Dan Guzman
SQL Server MVP
"Raterus" <raterus@spam.org> wrote in message
news:%23uCRFd9VEHA.716@TK2MSFTNGP11.phx.gbl...
Here is one big "gotcha" I always run into.  Our SQL Server is based
entirely off Integrated Windows Authentication.  When I create SProcA and
test it with my permissions, it works great.  Security isn't really a
question, since my account is in the Domain Admins group.  Unfortunately
when UserA attempts to execute SProcA, it fails for them, because they do
not have the appropriate permissions.
I'd like to debug these scripts at the comfort of my workstation, and not
rely on the end-users interaction in this process, except for the initial
error report.  My problem is that since I have Domain Admin rights,
everything works fine for me.  It usually boils down to a simple permission
somewhere, but that's hard to track when I don't have any errors I can see
at my workstation..
So my question is:
Is there some way I can impersonate a specific users login, in order that I
can test what exactly happened on their end?  I'd prefer not to have to
change their password.

Relevant Pages

  • Re: Jet.OLEDB and Access 2003
    ... what permissions does the security context under which ASP is running ... requires at least Read, Write, eXecute and Delete. ... > I'm running an old ASP program that worked just fine w/ Access 2000 ...
    (microsoft.public.vb.database)
  • Re: Impersonating a domain user for debugging purposes
    ... > As a sysadmin role member, you can execute a SETUSER command to use ... > You can revert back to your own security context by running SETUSER with no ... > test it with my permissions, ... > when UserA attempts to execute SProcA, it fails for them, because they do ...
    (microsoft.public.sqlserver.security)
  • Re: Run an SP as another user
    ... To the best of my knowledge, the security context of a stored procedure is ... > doesn't have permissions to execute some of the statements in it. ...
    (microsoft.public.sqlserver.security)
  • Re: Difficult qualified name problem
    ... > Make sure these procedures are created under an admin user so that they ... > should equate to DBO. ... SQL Server does not run procedures in the security context of the ...
    (microsoft.public.sqlserver.security)
  • Re: Execute DTS Package from non-privileged VB Client
    ... the user having sysadmin privileges? ... the package will execute on the users machine under the users security context, so they will need rights perform the actions inside the package. ... They may also need the public role in msdb, which all users get by default, to load the package if stored in SQL Server. ... It may be better to devise an alternative process which means the job is executed on the server, which hopefully means another more privileged security context Perhaps it can be scheduled? ...
    (microsoft.public.sqlserver.dts)