Re: Security context used for DBPROP_MULTIPLECONNECTIONS sessions
From: Laszlo Szentendrei (laszlos_at_netpro.com)
Date: 01/04/05
- Next message: Plucky: "Can't connect with SQL Auth OBDC / vba"
- Previous message: Christian Westerlund: "Unexpected error when reading a text-file"
- In reply to: Uwa Agbonile [MSFT]: "Re: Security context used for DBPROP_MULTIPLECONNECTIONS sessions"
- Messages sorted by: [ date ] [ thread ]
Date: 3 Jan 2005 16:18:30 -0800
Yes, after looking at the broader picture, I can see the reasoning
behind using the current security context for the new sessions. In
most cases, I can see that the client's expectation would be to use the
security context of the thread.
Thanks for pointing out the Roles model. It's not what we need, but I
appreciate the suggestion. Also, for the sake of future readers, the
Update section at the end of this article
http://www.sqlteam.com/item.asp?ItemID=864 gives me pause.
We're sticking with our method, but have turned off multiple
connections and ensured that only one command is active on a session at
a time.
Thanks for your responses. They were very helpful.
Laszlo
Uwa Agbonile [MSFT] wrote:
> 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: Plucky: "Can't connect with SQL Auth OBDC / vba"
- Previous message: Christian Westerlund: "Unexpected error when reading a text-file"
- In reply to: Uwa Agbonile [MSFT]: "Re: Security context used for DBPROP_MULTIPLECONNECTIONS sessions"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
