|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Thread securityI have a client/server scenario where I need the client to impersonate a
specific account, depending on rules established on the server. Essentially this a call back event that happens occasionally where the server needs to temporarily elevate the clients permissions to do some work. I really dont want to pass back credentials to use, and I dont want to give the user account any "dangerous" permissions. The server is running as the system account and I can genrate any access token (aka windows identity) or impersonation context I need. I am trying to figure out how to pass this back to the client and so far I have not been successful. I have figured out how to attach to the clients thread and can succesfully call SetThreadToken, however the thread (which is a managed thread) does not appear to change to the new security context. Any thoughts or ideas appreciated -Robert Hi,
are client and server on the same machine? --------------------------------------- Dominick Baier - DevelopMentor http://www.leastprivilege.com Show quoteHide quote > I have a client/server scenario where I need the client to impersonate > a specific account, depending on rules established on the server. > Essentially this a call back event that happens occasionally where the > server needs to temporarily elevate the clients permissions to do some > work. I really dont want to pass back credentials to use, and I dont > want to give the user account any "dangerous" permissions. The server > is running as the system account and I can genrate any access token > (aka windows identity) or impersonation context I need. I am trying > to figure out how to pass this back to the client and so far I have > not been successful. I have figured out how to attach to the clients > thread and can succesfully call SetThreadToken, however the thread > (which is a managed thread) does not appear to change to the new > security context. > > Any thoughts or ideas appreciated > > -Robert > yes
Show quoteHide quote "Dominick Baier [DevelopMentor]" <dbaier@pleasepleasenospamdevelop.com> wrote in message news:4580be631955538c7ebf5f901d9c4@news.microsoft.com... > Hi, > are client and server on the same machine? > > --------------------------------------- > Dominick Baier - DevelopMentor > http://www.leastprivilege.com > >> I have a client/server scenario where I need the client to impersonate >> a specific account, depending on rules established on the server. >> Essentially this a call back event that happens occasionally where the >> server needs to temporarily elevate the clients permissions to do some >> work. I really dont want to pass back credentials to use, and I dont >> want to give the user account any "dangerous" permissions. The server >> is running as the system account and I can genrate any access token >> (aka windows identity) or impersonation context I need. I am trying >> to figure out how to pass this back to the client and so far I have >> not been successful. I have figured out how to attach to the clients >> thread and can succesfully call SetThreadToken, however the thread >> (which is a managed thread) does not appear to change to the new >> security context. >> >> Any thoughts or ideas appreciated >> >> -Robert >> > > Can you pass back the token handle via whatever IPC mechanism you have and
then let the client create a WindowsIdentity from that and do the impersonation inside the thread method? I'm not sure why the other approach isn't working, but you should be able to do most of this with managed code anyway. Having the server change the client's thread seems weird to me. Joe K. Show quoteHide quote "Robert Ginsburg" <robert.ginsb***@ver3.com> wrote in message news:Oohlq8eHGHA.2940@tk2msftngp13.phx.gbl... > yes > > "Dominick Baier [DevelopMentor]" <dbaier@pleasepleasenospamdevelop.com> > wrote in message news:4580be631955538c7ebf5f901d9c4@news.microsoft.com... >> Hi, >> are client and server on the same machine? >> >> --------------------------------------- >> Dominick Baier - DevelopMentor >> http://www.leastprivilege.com >> >>> I have a client/server scenario where I need the client to impersonate >>> a specific account, depending on rules established on the server. >>> Essentially this a call back event that happens occasionally where the >>> server needs to temporarily elevate the clients permissions to do some >>> work. I really dont want to pass back credentials to use, and I dont >>> want to give the user account any "dangerous" permissions. The server >>> is running as the system account and I can genrate any access token >>> (aka windows identity) or impersonation context I need. I am trying >>> to figure out how to pass this back to the client and so far I have >>> not been successful. I have figured out how to attach to the clients >>> thread and can succesfully call SetThreadToken, however the thread >>> (which is a managed thread) does not appear to change to the new >>> security context. >>> >>> Any thoughts or ideas appreciated >>> >>> -Robert >>> >> >> > > The IPC mechanism is currently either COM or the IPC Remoting channel,
neither of which seem to be able to pass the token handle (or at least I cant figure it out). In any case, the primary reason I want the server to change the clients thread, is that I don't want the account the client is operating under to have impersonation privilidges. Show quoteHide quote "Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com> wrote in message news:elC8RGfHGHA.3144@TK2MSFTNGP10.phx.gbl... > Can you pass back the token handle via whatever IPC mechanism you have and > then let the client create a WindowsIdentity from that and do the > impersonation inside the thread method? > > I'm not sure why the other approach isn't working, but you should be able > to do most of this with managed code anyway. Having the server change the > client's thread seems weird to me. > > Joe K. > > "Robert Ginsburg" <robert.ginsb***@ver3.com> wrote in message > news:Oohlq8eHGHA.2940@tk2msftngp13.phx.gbl... >> yes >> >> "Dominick Baier [DevelopMentor]" <dbaier@pleasepleasenospamdevelop.com> >> wrote in message news:4580be631955538c7ebf5f901d9c4@news.microsoft.com... >>> Hi, >>> are client and server on the same machine? >>> >>> --------------------------------------- >>> Dominick Baier - DevelopMentor >>> http://www.leastprivilege.com >>> >>>> I have a client/server scenario where I need the client to impersonate >>>> a specific account, depending on rules established on the server. >>>> Essentially this a call back event that happens occasionally where the >>>> server needs to temporarily elevate the clients permissions to do some >>>> work. I really dont want to pass back credentials to use, and I dont >>>> want to give the user account any "dangerous" permissions. The server >>>> is running as the system account and I can genrate any access token >>>> (aka windows identity) or impersonation context I need. I am trying >>>> to figure out how to pass this back to the client and so far I have >>>> not been successful. I have figured out how to attach to the clients >>>> thread and can succesfully call SetThreadToken, however the thread >>>> (which is a managed thread) does not appear to change to the new >>>> security context. >>>> >>>> Any thoughts or ideas appreciated >>>> >>>> -Robert >>>> >>> >>> >> >> > > You should be able to pass the handle value as an int32 and then create an
IntPtr based on that to create the WindowsIdentity. However, if you don't want the client doing the work, you probably need to use an approach like what you are doing. Just out of curiosity, what does WindowsIdentity.GetCurrent() say after you do SetThreadToken? Also, would it be possible instead to have the client invoke a method on the server that performs the privileged operation? That seems cleaner to me... Joe K. Show quoteHide quote "Robert Ginsburg" <robert.ginsb***@ver3.com> wrote in message news:uTJRNjoHGHA.524@TK2MSFTNGP09.phx.gbl... > The IPC mechanism is currently either COM or the IPC Remoting channel, > neither of which seem to be able to pass the token handle (or at least I > cant figure it out). In any case, the primary reason I want the server to > change the clients thread, is that I don't want the account the client is > operating under to have impersonation privilidges. > Currently I pass in the treadid from GetCurrentThreadID() and the server
successfully calls duplicate token, then SetThreadToken() on the client thread, however the client thread always reports the same current user/identity. There are two problems with calling all of the functions on the server. the first is interactive UI (the server is running as a service) , the second is that one of the functions is to evaluate and execute a bunch of local code that the client has created, some of which should execute in the callers context, some of which should execute in the context sent to the caller from the system. The "application logic" works fine if I pass user names and passwords back and forth instead of access tokena, but it it tantalizing close (at least no API errors) to working using this technique. -Robert Show quoteHide quote "Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com> wrote in message news:ePVQSwqHGHA.2704@TK2MSFTNGP15.phx.gbl... > You should be able to pass the handle value as an int32 and then create an > IntPtr based on that to create the WindowsIdentity. However, if you don't > want the client doing the work, you probably need to use an approach like > what you are doing. > > Just out of curiosity, what does WindowsIdentity.GetCurrent() say after > you do SetThreadToken? > > Also, would it be possible instead to have the client invoke a method on > the server that performs the privileged operation? That seems cleaner to > me... > > Joe K. > > "Robert Ginsburg" <robert.ginsb***@ver3.com> wrote in message > news:uTJRNjoHGHA.524@TK2MSFTNGP09.phx.gbl... >> The IPC mechanism is currently either COM or the IPC Remoting channel, >> neither of which seem to be able to pass the token handle (or at least I >> cant figure it out). In any case, the primary reason I want the server to >> change the clients thread, is that I don't want the account the client is >> operating under to have impersonation privilidges. >> > > 
Other interesting topics
encrypting app.config with RSA
Application Security and Trust Mail merge with an MD5 hash. Having problem with Encryption using CryptoAPI Directory access check Kerberos S4U problem SHA1Managed class has different results in 2.0 vs. 1.1?? LogParser - Error security issue with with windows service account Which Certificate store does IIS look at |
|||||||||||||||||||||||
