Re: Impersonating a domain user for debugging purposes

From: Raterus (raterus_at_spam.org)
Date: 06/22/04 

Date: Tue, 22 Jun 2004 09:44:36 -0400

Thank you so much, that is going to work great!

"Dan Guzman" <danguzman@nospam-earthlink.net> wrote in message news:OtYn5qFWEHA.3024@TK2MSFTNGP09.phx.gbl...
> 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
    ... 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, ...
    (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)