Decrypt All Folders Option, support alternate scheduling options

Jul 11, 2007 at 8:29 PM
I also think you should add a Decrypt All Folders GPO option, it should probably be added to the reporting or some other option so you couldn’t have a combination of Encrypt and Decrypt folders together. Or you could have some option in reporting mode that says “Report and Decrypt All Files & Folders” or “Report Only”.

If a computer is having trouble they could be moved into an OU with this policy set to decrypt all folders which would run the appropriate cipher command to decrypt the files. This way the system doesn’t need to be touched by script, remote access or sneakernet.
Coordinator
Jul 19, 2007 at 12:11 AM
Edited Jul 19, 2007 at 12:16 AM
I want to call attention to the overlap between this request and the proposed Feature here:
http://www.codeplex.com/EFSAssistant/WorkItem/View.aspx?WorkItemId=250

In both of these cases, we're talking about providing a run-time control that would reverse encryption that the organization tried to enforce through centralized policy (which is the capability lacking in EFS for which the EFS Assistant was created in the first place). However, there is a conflict in the customer requirements that I've never been able to resolve.

One of the primary requirements expressed to us in our original customer research (as well as years of experience consulting with Microsoft customers who have tried to deploy EFS) was that customers need a way to enforce encryption of as much sensitive data as possible, such that (a) it's as easy as possible to encrypt all sensitive data on the target systems (i.e. laptops) and (b) make it as difficult as possible for someone to circumvent the encryption policy the organization is trying to enforce.

Whether it's frequent or not, there are many customers who'd expressed the concern that "it's too easy for an end user to decrypt data that was once encrypted using EFS - and that this leaves us exposed to regulatory liability." In other words, they're concerned that if and when they had to appear before a judge, and that judge asked them, "Have you taken all reasonable measures to ensure the sensitive data was encrypted on the lost/stolen device in question?", that they wouldn't feel comfortable answering "Yes" unless they could tip the balance in EFS towards the organization's policy.

(Yes, while it would still be possible for an end user to decrypt the data files manually using CIPHER or Windows Explorer, the intent would be that EFS Assistant would always re-encrypt the targeted folders, each time EFS Assistant ran.)

If I assume this requirement still stands for the customers for whom EFS Assistant was intended (i.e. larger organizations), then can anyone suggest how we might meet the goals of (a) and (b) and implement conditional support for the feature described above?

If not, then can anyone help me understand what aspect of the customers' requirements I've misunderstood?

(And as an aside: how does this make things so much easier than simply assigning a command-line script that calls CIPHER /D /I /S:%systemdrive%?)
Jul 19, 2007 at 3:52 PM
Edited Jul 19, 2007 at 4:06 PM
Hello Chris,

I see your point and agree. We could easily construct a logon script that decrypted files or folders for troubleshooting.

However you also raise a good point about “taking all reasonable measures to ensure the sensitive data was encrypted”. Considering the EFS Assistant will only run at login, doesn't that mean you are limited in your ability to enforce the encryption of files on the laptop? I know we have users here who stay logged in for weeks or until they are forced to reboot for a patch. If the user decrypted the files then they would be unprotected until their next logoff and logon.

Wouldn't it be a better idea to have the EFS Assistant triggered to run by another service or WMI trigger on a specific schedule? For instance you could have a service installed when installing the application that calls the EFS Assistant to run at a pre determined interval that is defined in GPO. You could specify run every hour or every 2 hours, etc...

I think this would be better approach than trying to invoke the EFS Assistant via a Scheduled Task because you couldn’t control these settings via GPO, where as the power of this tool is in its ability to be configured centrally via GPO.

Thanks,

-Eric

MikeSL wrote:
I want to call attention to the overlap between this request and the proposed Feature here:
http://www.codeplex.com/EFSAssistant/WorkItem/View.aspx?WorkItemId=250

In both of these cases, we're talking about providing a run-time control that would reverse encryption that the organization tried to enforce through centralized policy (which is the capability lacking in EFS for which the EFS Assistant was created in the first place). However, there is a conflict in the customer requirements that I've never been able to resolve.

One of the primary requirements expressed to us in our original customer research (as well as years of experience consulting with Microsoft customers who have tried to deploy EFS) was that customers need a way to enforce encryption of as much sensitive data as possible, such that (a) it's as easy as possible to encrypt all sensitive data on the target systems (i.e. laptops) and (b) make it as difficult as possible for someone to circumvent the encryption policy the organization is trying to enforce.

Whether it's frequent or not, there are many customers who'd expressed the concern that "it's too easy for an end user to decrypt data that was once encrypted using EFS - and that this leaves us exposed to regulatory liability." In other words, they're concerned that if and when they had to appear before a judge, and that judge asked them, "Have you taken all reasonable measures to ensure the sensitive data was encrypted on the lost/stolen device in question?", that they wouldn't feel comfortable answering "Yes" unless they could tip the balance in EFS towards the organization's policy.

(Yes, while it would still be possible for an end user to decrypt the data files manually using CIPHER or Windows Explorer, the intent would be that EFS Assistant would always re-encrypt the targeted folders, each time EFS Assistant ran.)

If I assume this requirement still stands for the customers for whom EFS Assistant was intended (i.e. larger organizations), then can anyone suggest how we might meet the goals of (a) and (b) and implement conditional support for the feature described above?

If not, then can anyone help me understand what aspect of the customers' requirements I've misunderstood?

(And as an aside: how does this make things so much easier than simply assigning a command-line script that calls CIPHER /D /I /S:%systemdrive%?)

Coordinator
Jul 19, 2007 at 10:19 PM
Eric, thanks for responding. First, please allow me to confirm: are you still interested in a feature for EFS Assistant that would allow it to decrypt data that was previously encrypted? If so, and if troubleshooting is out of scope, then what purpose would this feature serve? Under what kinds of circumstances would you invoke "decrypt all folders" or "decrypt encrypted folders no longer on 'Folders to Encrypt' list"?

Second, I completely agree that EFS Assistant can and should be run more frequently in environments where users stay logged on for days and weeks at a time. Originally we decided to leave it completely up to the Administrator how to schedule EFS Assistant, choosing among things like:
  • traditional logon script
  • Startup shortcut
  • Task Scheduler
  • third-party scheduler
  • Group Policy logon script

Q: I haven't reviewed the released documentation yet (just pre-release versions, when I was more heavily involved) - does the documentation imply that "run at logon" is the best/only approach?

Yeah, it sucks that Task Scheduler tasks can't be centrally distributed using Group Policy. I don't know what the current "best practices" are for centrally managing Task Scheduler tasks in general, but would it be sufficient to be able to use your software distribution mechanism to run a one-time script that just called schtasks.exe (at least in XP SP2, if not earlier Windows as well) to add a task of your liking? Heck, you might even be able to script schtasks.exe to remotely configure such a task from your IT workstation, since it can connect to remote computers in its command-line syntax.
Jul 23, 2007 at 3:58 PM
Edited Jul 23, 2007 at 4:00 PM
I see an issue here, that is how would you invoke the EFS Assistant from a scheduled task to run under the currently logged on user context? The thought of trying to use the Task Scheduler to run under a specific user on all laptops would be daunting! I still think this should be added "Natively" into the EFS Assistant and should be configurable from GPO. Most of the other capabilities the EFS Assistant provides could also be scriptable so I think you should put as much functionality as possible into the centralized control and configuration of the EFS Assistant via GPO. Otherwise why roll out a client that we would need to support and potentially upgrade if we can do 90% of that via GPO login script?

Don’t get me wrong I do like the tool and understand it is a wrapper for EFS but I think you have a good idea by allowing it to be configured centrally and should keep to that mantra with new or updated feature sets.


Second, I completely agree that EFS Assistant can and should be run more frequently in environments where users stay logged on for days and weeks at a time. Originally we decided to leave it completely up to the Administrator how to schedule EFS Assistant, choosing among things like:
  • traditional logon script
  • Startup shortcut
  • Task Scheduler
  • third-party scheduler
  • Group Policy logon script


Again, this should be a feature available native to the EFS Assistant, configurable via GPO. BTW, GPO logon scripts only run when the user logs on or off so you couldn't invoke the application to run more often if the user hadn't logged off/on.


Yeah, it sucks that Task Scheduler tasks can't be centrally distributed using Group Policy. I don't know what the current "best practices" are for centrally managing Task Scheduler tasks in general, but would it be sufficient to be able to use your software distribution mechanism to run a one-time script that just called schtasks.exe (at least in XP SP2, if not earlier Windows as well) to add a task of your liking? Heck, you might even be able to script schtasks.exe to remotely configure such a task from your IT workstation, since it can connect to remote computers in its command-line syntax.

Coordinator
Jul 25, 2007 at 2:48 AM
Thanks for your continued feedback Eric. I'd like the EFS Assistant to have more comprehensive scheduling options, but there are a couple of reasons why I'm reticent to try adding the code for such a feature:
  1. Slippery slope - Adding one or two specific features to support scheduling makes me worried that once we've started, others will request "one or two more features" until we've re-implemented much of the functionality of (much better) existing schedulers
  2. Vista supports an incredible number of ways to configure Scheduled Tasks http://msdn2.microsoft.com/en-us/library/Aa383614.aspx, and I'd hate to end up implementing things that Vista has already solved

While I realize this isn't a one-stop shop approach, I feel much better about my customers being able to support these custom solutions when they leverage as much off-the-shelf software as possible, and not spend time re-inventing the wheel (or dealing with the inadequacies of inferior wheels invented by others).

I'm hoping I can find a way to automate generating these scheduled tasks without requiring the user enter their password, by using SCHTASKS (see http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/schtasks.mspx?mfr=true for more details on this command-line tool):
  • I just tried running the following command to create a Scheduled Task that prompted the end user (i.e. me) to enter my logon password
  • You may want to try this, in which case I'd wrap a quick message around the password prompt warning the user
schtasks /create /sc HOURLY /MO 2 /TN "Run EFS Assistant every two hours" /TR "%PROGRAMFILES%\Microsoft EFS Assistant\EFSAssistant.exe"
  • SCHTASKS.EXE may support adding a task in the user's context without having to know the user's password
  • I could've sworn I had come up with at least one schtasks.exe command line that didn't require a user's password, but I can't seem to regenerate that so I'm hoping someone else might be able to show us how.
Jul 25, 2007 at 3:48 PM
Edited Jul 25, 2007 at 5:30 PM


  1. Vista supports an incredible number of ways to configure Scheduled Tasks http://msdn2.microsoft.com/en-us/library/Aa383614.aspx, and I'd hate to end up implementing things that Vista has already solved


Mike, you mention a lot of functionality that will be or is available in Vista; however we are not planning to roll Vista here any time soon. It will be at least a year before we consider that. This means we need something viable for XP now. I hope you are not relying on Vista to solve any potential issues that might be present in the applications current functional state.


  • I just tried running the following command to create a Scheduled Task that prompted the end user (i.e. me) to enter my logon password
  • You may want to try this, in which case I'd wrap a quick message around the password prompt warning the user
schtasks /create /sc HOURLY /MO 2 /TN "Run EFS Assistant every two hours" /TR "%PROGRAMFILES%\Microsoft EFS Assistant\EFSAssistant.exe"
  • SCHTASKS.EXE may support adding a task in the user's context without having to know the user's password
  • I could've sworn I had come up with at least one schtasks.exe command line that didn't require a user's password, but I can't seem to regenerate that so I'm hoping someone else might be able to show us how.


The “SCHTASKS” could be a way to solve some of the scheduling problems but if it prompts the user for a password this would be very difficult to deploy. Most users would just close the dialog because they would think it unsafe or a virus. If it has to prompt for a password I see it as potentially becoming a support nightmare.

I do understand that you do not want to partially implement a solution where people might want more functionality but I think that is the name of the game in Software development anyway. The more the application is used the more features the users will want (this is a good thing, keeps you and I employed). What we really want a solution that will work well “now” with XP as that is the dominate OS on our network. If other hooks are used for Vista that is fine, but we need good functionality from the application running on XP today.

-Eric
Nov 6, 2007 at 11:56 PM
I started off reading this thread thinking that I could solve our EFA Assistant scheduling issues....alas I have failed miserably. I have tried all iterations of schtasks.exe from Window 2003 and the XP codebase (the EXEs are actually different, as the 2003 supports the /IT flag). Actually got the commandline to create a task:
schtasks /create /sc:MINUTE /IT /MO 10 /ru fakeuser /rp "" /TN "OE" /TR "\"C:\Program Files\EFSA\EFSassistant.exe\"
without entering a password on a 2003 system. Problem is....the task will not start, unless I go into the scheduled tasks GUI and put a space at the end of the commandline ...then it works forever. Allegedly though, this is actually a bug and should never work !
Looking at the API calls, it doesn't even look like the Scheduler 1.0 APIs will allow us to do this in an autmated fashion :(

So....EFSAssistant devs folks, is there a way that we can actually get a scheduler into the app, because it seems external methods are really not up for it ? I appreciate what Mike says, but we are struggling to get EFSAssistant to run in the context of a user, on a frequent basis. Having it run at logon isn't really a good solution, as people don't login and logout that much anymore (standby and hibernate rules!). What other choices are there ? The tool is great, but without an scheduled enforcement method it really doesn't allow us to use it.

-Stuart
Coordinator
Feb 23, 2008 at 11:17 PM
Edited Feb 23, 2008 at 11:18 PM
Stuart, Eric, I've been working on other projects and haven't spent any time on EFS Assistant since these discussion threads slowed down. I generally don't have a ton of spare time, and when I do there's so many other things on my radar that it's hard to comeback to "old code". (Plus, I have to admit that as my first open-source project, I had higher expectations of how many folks would offer to contribute to the codebase, which never materialized, and that disappointment has seriously harmed my attitude towards this project. I'm not proud of it, but that's the unvarnished truth.)

I got to thinking last night about this request thread and how we could make this happen, leveraging your enthusiasm and interest, and my background with the code (and limited coding abilities). I have to tell you, my background in C# is pretty hit-or-miss, and while I'd love to say that I know how I'd code this scheduling capability, it's gonna take a lot of research.

Stuart, Eric, if either of you two have any time you'd be able to contribute to this research, I'll commit to implementing the code that is necessary to wire together whatever you can dig up. Here's a few thoughts to get you started:
  • are there any managed classes that wrap the Scheduler APIs?
  • are there any open-source projects that have tried to tackle managed code to wrap the Scheduler APIs (but aren't complete), or that have tried to implement a scheduler from scratch in managed code?
  • are there any WMI objects/methods that could be used for this? most WMI objects are accessible via the System.Management classes
  • are there any useful managed classes in the .NET Framework, or other framework additions like the Genghis Project, that would be used here?
  • would this scheduling interaction require the use of a separate thread in the EFSAssistant code?
  • if the scheduling required a separate thread, where should the thread "entry points" (I don't even know how to describe what I'm asking) be placed in the existing codebase?
  • would there need to be significant changes to the existing codebase?

Lastly, if either of you (or anyone else) has some background in coding (even if it's not .NET), and have some ideas on how a scheduler would be implemented, I'd be thrilled to hear it. If you can write any code that would either create a starting place for this effort, or even would be able to co-write the code with me, I'd be quite open to that.

Thanks everyone, and good luck hunting.

Mike
Feb 28, 2008 at 10:25 AM
Hi Mike,
I am not a coder either, so I can't really answer any of your questions, sorry. I can furnish some more about how we have worked around it though. We had one of our guys knock up some code, that was launched everytime the user was logged in and it is basically a stub scheduler to kick off any application (registry defined) in the context of the user. So, in our case, this app runs all of the time, and then every 15 mins, it calls the EFS Assistant EXE under the current user's context. It means our scheduler is running all the time (uses minmal memory), but atleast we can remotely tweak times with GPOs and add additional EXEs if we wanted. Not elegant, but reasonably affective.
Coordinator
Mar 4, 2008 at 12:51 AM
Hey all,

The proper way to do this is to add a background thread that sleeps after the first run (at logon) until a certain time has passed at which time it runs again. This is relatively simple to implement, but I'm not sure that I have the time right now. For those interested in such capability, drop me a line at david.mowers@securitay.com.nospam (delete the nospam portion) and we can discuss timing.

Thanks!
Dave