Re: Windows Security vs. Application Security
From: David Cross [MS] (dcross_at_online.microsoft.com)
Date: Thu, 20 Jan 2005 05:31:58 -0800
are you calling LoadUserProfile after impersonating the user?
-- 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?