Re: Windows Security vs. Application Security
From: Hao Zhuang [MSFT] (hzhuang_at_online.microsoft.com)
Date: Thu, 20 Jan 2005 19:08:48 -0800
as a complement to david's comments, you should also avoid using
HKEY_CURRENT_USER directly when you impersonate. use RegOpenCurrentUser to
obtain a current user HKEY instead.
-- This posting is provided "AS IS" with no warranties, and confers no rights. "David Cross [MS]" <firstname.lastname@example.org> wrote in message news:uAgBrRv$EHA.2112@TK2MSFTNGP14.phx.gbl... > are you calling LoadUserProfile after impersonating the user? > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/policy/policy/loaduserprofile.asp > > -- > David B. Cross [MS] > -- > This posting is provided "AS IS" with no warranties, and confers no rights. > > Top Whitepapers: > > Auto-enrollment whitepaper: > http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/autoenro.mspx > Best Practices for implementing Windows Server 2003 PKI: > http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws3pkibp.mspx > Troubleshooting Certificate Status and Revocation whitepaper: > http://www.microsoft.com/technet/security/topics/crypto/tshtcrl.mspx > Windows Server 2003 web enrollment and troubleshooting guide: > http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/webenroll.mspx > Windows Server 2003 web enrollment and troubleshooting guide: > http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/webenroll.mspx > > "Rami Jaschek" <RamiJaschek@discussions.microsoft.com> wrote in message > news:4F5396A5-4D13-4BF9-9E52-8912079D8D59@microsoft.com... > > We are developing a client sever application that generates files on a > > common > > server. We wish for the application to be able to generate(/delete) files > > in > > directories where the users have no permission to generate(/delete) files. > > > > The problem is that the security context of the application is the same as > > the logged in user running the application. > > > > Two solutions we tried and ran into problems with: > > A. Impersonation - we can switch to a different user context inside the > > application - but this has many side effects (such as suddenly not seeing > > the > > default printer for that user). > > B. Sepcific agents - as the file access is needed in many places in the > > software and we write a lot - that creates both inconvenience for the > > developers and a bottleneck. > > > > Suggestions? > >