Re: help on caller credentials !! :-(

ok - so then it works as expected, right?

Local Service has not Windows network access (all outgoing traffic will be done as anonymous) Network service has network access (all outgoing traffic will be done as the machine account)

This distinction is more relevant to domain environments.

Let's wrap up:

Bob calls the remoting server - the server gets bob account from Thread.CurrentPrincipal and you can pass that e.g. to a sproc.

Mission accomplished?


-----
Dominick Baier (http://www.leastprivilege.com)

Developing More Secure Microsoft ASP.NET 2.0 Applications (http://www.microsoft.com/mspress/books/9989.asp)

hello dominick,

here are few test I have made. I hate things when I am not 100%
undersatnd what is going on.

I am runing my client application under user BOB on an Windows 2000
machine Then my server component is hosted in a windows service
runnning on Vista machine. So far so good.

First test BOB is nnot existing at all under vista machine: Running my
client will generate an InvaluidCredential Exception (sounds logic)

Then I create BOB account on my Vista machine and run the same test.
At this phase BOB has been identified and I can log credentila info
from
server side and I get :
Authentication Type=NTLM
isAuthenticated = True
Name : VISTA-PC\BOB
So first of all, I am able to read client credential from my remote
object whaterver my service is running under LocalService, Local
System, or Network System

So what are the difference at this stage of runing my Service as
Network Service ??

The impersonation level your are talking about in previous post, do I
have to set it from my server side or client side ?

Also I have read that setting "Delegation" or delegate is useonly
under windows 2000 and prefer mode should be "Impersonate" . Did I get
right info ?

Extratc form help on line:
------>
Anonymous:
The client is anonymous to the server. The server process can
impersonate
the client, but the impersonation token does not contain any
information
about the client.
Default:
Uses the default impersonation level for the specified authentication
service. In COM+, this setting is provided by the
DefaultImpersonationLevel
property in the LocalComputer collection.
Delegate:
The most powerful impersonation level. When this level is selected,
the
server (whether local or remote) can impersonate the client's security
context while acting on behalf of the client
Identify The system default level. The server can obtain the client's
identity, and the server can impersonate the client to do ACL checks.
Impersonate:
The server can impersonate the client's security context while acting
on
behalf of the client. The server can access local resources as the
client.
<-----
thanks to clarify my mind
regards
serge
"Dominick Baier" wrote:

several things..

a) as Joe pointed out - switch to Network Service

b) you get the client identity from Thread.CurrentPrincipal

c) if you want to delegate the token to a backend service you need an
impersonationLevel="Delegation"

d) you additionally need impersonate="true" in your config file, you
you

wanto to use the auto impersonation feature

very much like the sample you downloaded ;)

-----
Dominick Baier (http://www.leastprivilege.com)
Developing More Secure Microsoft ASP.NET 2.0 Applications
(http://www.microsoft.com/mspress/books/9989.asp)

Dear all,

I start to loose my hairs. Hoep someone could help me to
recover..:-)
I have build a remote object hosted in a Windows Service runing as
LocalService.
I have then a claient application which calling that remote object
and
based
on the caller credential I shouzld authorise hit or not to access to
back end
database.
The situation is as follow :
My client is running as BOB. BOB is calling the remote object for
data
storage. What I try to do is retriveing the caller credential from
my
remote
object in order to athauticated for further process. The problem is
that when
I check the wndows identity on my server side, it return the context
on which
my service is running and not my caller's context.
MY server config file is as follow :
<channels>
<!--<channel ref="tcp" port="8090"
useDefaultCredentials="False">-->
<channel ref="tcp" port="8090" secure="True"
impersonationLevel="Impersonate" protectionLevel="EncryptAndSign">
<serverProviders>
<formatter ref="binary" typeFilterLevel="Full"/>
</serverProviders>
</channel>
</channels>
Note that I am using .NEt 2.0
Thnaks again for your help ( I am fighting for a full week now on
this
grrr
:-()
regards
serge


.

Relevant Pages

  • Re: help on caller credentials !! :-(
    ... I am runing my client application under user BOB on an Windows 2000 ... machine Then my server component is hosted in a windows service ... under windows 2000 and prefer mode should be "Impersonate". ...
    (microsoft.public.dotnet.security)
  • Re: help on caller credentials !! :-(
    ... the back end SQL server maybe. ... In fact I simply try to flow the client user until the database level. ... Hosting my remote object in IIS would be much more simple but thi is not my ... under windows 2000 and prefer mode should be "Impersonate". ...
    (microsoft.public.dotnet.security)
  • Re: IsInRole always return fasle on secure remoting call (Framework 2.0)
    ... I doing remoting calls over a TCP channel set to "SECURE", ... means that on the server side the ... information about the client, and it cannot impersonate the client. ...
    (microsoft.public.dotnet.distributed_apps)
  • Re: Under which credentials COM makes calls from another process?
    ... There are two ways our server application (server here is not ... authenticate via SSPI. ... which is used later to impersonate thread on the server ... can get some properties of these objects: client IP address and port, ...
    (microsoft.public.platformsdk.security)
  • Re: Under which credentials COM makes calls from another process?
    ... There are two ways our server application (server here is not ... authenticate via SSPI. ... which is used later to impersonate thread on the server ... can get some properties of these objects: client IP address and port, ...
    (microsoft.public.win2000.developer)