Re: Security context used for DBPROP_MULTIPLECONNECTIONS sessions

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Uwa Agbonile [MSFT] (uwaag_at_online.microsoft.com)
Date: 12/31/04

  • Next message: ensteitieh: "RE: how to use CDBErrorInfo" 
    Date: Thu, 30 Dec 2004 17:51:23 -0800

    When you use integrated security, you are asking the provider to make
    connections using the current security context and maintaining state would
    appear to violate the fundamental goal of using Integrated security in the
    first place.

    I suspect you should be able to achieve your goal if you have the
    impersonating thread that makes the connection the one that always executes
    your commands. I'm don't know what you are doing so bear with me here but
    have you explored the SQL Server Roles security model? It might serve your
    needs. 

    -- 
This posting is provided "AS IS" with no warranties, and confers no rights.
Regards,
Uwa Agbonile[MSFT]
"Laszlo Szentendrei" <laszlos@netpro.com> wrote in message
news:1104362783.424325.285480@c13g2000cwb.googlegroups.com...
> Yes, we are deliberately reverting to the original security context
> after opening our datasource.  We immediately revert to the original
> security context.  We keep this datasource around and open sessions off
> of it as needed.  This works fine unless a command is opened on a
> session that already has an open command.
>
> We need our threads to run in the original security context because of
> the work being done in the process.  A thread running in the context of
> some account configured for database access can't be relied on to do
> anything except access the database.  We wanted to avoid impersonating
> accounts and opening datasources every time we access the database, or
> having a dedicated thread for database access.
>
> Are you saying that when a new session is opened by the system that it
> simply opens it in the context of the current thread?  It doesn't seem
> to make sense to me to ignore the credentials of the session I am
> passing into the function.
>
> Thanks for your reply,
> Laszlo
>
>
> Uwa Agbonile [MSFT] wrote:
> > One possible reason for this behavior may be that the thread reverted
> back
> > to the original security context after the connection was opened but
> before
> > the command was executed. Could you please verify this?
> >
> > --
> > This posting is provided "AS IS" with no warranties, and confers no
> rights.
> > Regards,
> > Uwa Agbonile[MSFT]
> >
> > "Laszlo Szentendrei" <laszlos@netpro.com> wrote in message
> > news:1103836768.939393.235890@c13g2000cwb.googlegroups.com...
> > > We moved our code to the main thread to test this.  We get the same
> > > results whether it's the main thread or a new thread.
> > >
>
  • Next message: ensteitieh: "RE: how to use CDBErrorInfo"

    Relevant Pages

    • Re: Security context used for DBPROP_MULTIPLECONNECTIONS sessions
      ... behind using the current security context for the new sessions. ... connections and ensured that only one command is active on a session at ... >> session that already has an open command. ... >> having a dedicated thread for database access. ...
      (microsoft.public.data.oledb)
    • Re: sp_setapprole problem (using LINQ)
      ... when the connection is returned ... rights to the database objects. ... subsequently assumed a new security context, ... see Help and Support Center at ...
      (microsoft.public.dotnet.framework.adonet)
    • sp_setapprole problem (using LINQ)
      ... The connection has been dropped because the principal that opened it ... the connection under its impersonated security context. ... see Help and Support Center at ...
      (microsoft.public.dotnet.framework.adonet)
    • Re: Connection pooling
      ... if I create a connection object in my application ... on a per db 'instance' per security context basis. ... A pool is established the first time you create a connection with a certain ... When your application opens a subsequent connection with the same DB ...
      (microsoft.public.dotnet.languages.csharp)
    • Re: DCOM, threads, impersonate?
      ... > I have a com server that can run as a service. ... > creates one thread per connection and a connection can be shared ... Why not use a specific account other than the logged-on user? ... The thread inherits the security context of the ...
      (microsoft.public.vc.atl)