Practical limit of access tokens or kernel objects in one process?

Practical limit of access tokens or kernel objects in one process?

Post by Stefan Kuh » Sat, 30 Jun 2007 01:56:01


Hello everyone,

I am currently writing a service that will accept client connects via
RPC and will store the impersonated client's access token in an RPC
context handle. This will leave the impersonation token of the client as
state on the server until the client closes the context handle or dies
for whatever reason (resulting in a rundown).

I expect that several hundreds or thousands of clients will access the
server during its processes' lifetime so my question is whether there is
a practical limit of access tokens (and thus logon sessions) or kernel
objects in general that can be held simultaneously in a server
application. Is my approach of keeping client access tokens around in
the server for a long time a viable approach or should I strive to keep
the time the server has to hold the access token/logon session as short
as possible?

My Definition of "a long time" would be several days or weeks. My idea
is that clients start during an interactive logon session of a user on a
client computer and end with the interactive user logging out.

Any help appreciated,

--
Stefan Kuhr
 
 
 

Practical limit of access tokens or kernel objects in one process?

Post by Ivan Brugi » Sun, 01 Jul 2007 02:32:00

First of all, before rolling-up a token caching / identity tracking
mechanism,
can you use the built-in features exposed by RpcBindingSetAuthInfoEx ?
If you want to associate an identity with a context_handle, maybe you can
use static identity tracking.

That said, the practical limitation of token objects might be in the
order of tens thousands (Non-Page pool limited),
while practical order limits of concurrent RPC
connections might be something shorted than that, assuming that each RPC
connection does something non trivial.

There are knonw RPC servers that handle 5/8 thusands concurrent RPC
connection over weeks and months with no issues.


--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.yqcomputer.com/

 
 
 

Practical limit of access tokens or kernel objects in one process?

Post by Stefan Kuh » Tue, 03 Jul 2007 03:36:04

Hello Ivan,




Thanks a lot for the clarifications. I already use static identity
tracking, however in my case, the rare situation may arise in the rpc
server that a special private object gets created and in this case I
want to do an AccessCheck of this private object's security descriptor
against all clients that are currently connected with the rpc server, so
I can notify each individual client if its AccessCheck succeeds.
Therefore my idea was to associate the impersonation token along with
other client information in a context handle and store this in some
container (set, list, ...). So in that situation I would enumerate all
clients in the container and do an AccessCheck for all tokens.
RpcGetAuthorizationContextForClient is not an option for me, because the
server also supports ncacn_tcpip and has to run on Windows 2000 as well.

Is there an easier way to do what I want to do than store the client's
impersonation token in a context handle?

Any help appreciated,

--
Stefan
 
 
 

Practical limit of access tokens or kernel objects in one process?

Post by Ivan Brugi » Wed, 04 Jul 2007 00:59:38

Your requirement of notifying all connected clients of the outcome
of an Access-Check call that may or may not happen is bizzare to say the
least.

Cound you do it the other way around ?
Each RPC client uses Dynamic-Tracking, and, you do the access-check
on the new resource at the next call coming in ?
It look to me that you are trying to solve the main problem of static
identity tracking
by building a too complicated mechanism of `re-authentication`.

Also, I don't understand your comment regarding the protocol-sequence and
Win2000.

In the simplest world, if you have Dynamic Identity tracking, you can always
call RpcImpersonateClient, perfrom the access check, and call-it-a-day.

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.yqcomputer.com/
 
 
 

Practical limit of access tokens or kernel objects in one process?

Post by Stefan Kuh » Wed, 04 Jul 2007 01:53:44

Hi Ivan,



Yes, you are right, it is bizarre and it is the exception to the normal
behaviour of the service.



You are describing the normal behaviour of the service as it already is:
Each client connects to the service in a fixed polling interval of, say
10 Minutes, and I am doing an access check of the newly created private
objects and their associated security descriptor with the client's
token. That's what I am already doing. However, the requirements are
that in very rare and urgent cases, an administrative user can create a
private object in the service that is so utterly important and urgent,
that those clients that have access to the object should be notified
immediately and do a premature connect to the service, disregarding
their polling interval.



I hoped that RpcGetAuthorizationContextForClient would be an option for
me, but this API is not available on Windows 2000 and ncacn_tcpip.


Anyway, thanks for your help, I hope I could explain a bit where these
bizarre implementation ideas come from.

--
Stefan