locked
File history backup on bitlocker protected target

    Question

  • I am testing Windows 8 CP.
    I tried to enable the “File History” feature. 
    Since the “File History” backup feature seems to not protect efs files (see my other post at http://social.technet.microsoft.com/Forums/en-US/w8itprosecurity/thread/0ab105fd-1287-4009-a33c-f791b275ac82), I tried to set as a target of the file history service a bitlocker protected drive.
    Having scheduled the file history service to run daily I exported the xml task from the task scheduler and, as you can see from the file attached, the task is an automatic maintenance task (that is it has the scheme element -<MaintenanceSettings>  set and the <UseUnifiedSchedulingEngine> set to true) so it is executed together with other automatic maintenance tasks when Windows 8 performs “Automatic maintenance”. In my case I scheduled the automatic maintenance to start at 3.00 a.m.
    I do not have the auto-unlock feature of the target bitlocker drive enabled but I thought that the “local service” account that executes the file history task could be able to unlock the drive to perform the backup and lock it again at the end of the backup. Unfortunately this was not the case, the backup simply didn’t run. Even if I had the auto-unlock feature enabled on the bitlocker target drive the file history service wouldn’t have been able to access the target in case of system reboot, for example due to windows update automatic reboot unless someone (the one who enabled the auto-unlock feature or some other account who has the password for unlocking the target) unlocks the target drive.
    Does this means that, again, the file history service cannot be used to backup sensitive data?
    Regards
    Tuesday, March 13, 2012 10:17 PM

All replies

  • Thanks for using the File History feature! Here are some details on how it works, which will hopefully address your questions:

    Even though this task runs under Local Service, actual backups are done under local user accounts. This means the following: 1) the user needs to be logged on at the time of backup (the console may be locked, of course); 2) that user has to have read access to all the files that are being backed up. File History is designed to perform backups on per-user basis only, and it does not have any provisions for unlocking Bit Locker protected volumes just for the time of backup.

    Arguably, capability to auto-unlock the backup target for backup of sensitive data on an unattended machine could be a security issue in itself. If such a capability existed, it would mean that no user token is needed for unlocking the target device containing sensitive data, which is probably undesirable.

    With regards,
    Grigory.

    Friday, March 16, 2012 10:26 PM
  • Thanks Grigory.

    You are right, the actual backups are done under local user accounts but the user doesn't not need to be logged on at the time of backup, this can be proved executing simple tests.

    I am almost sure that the scheduled task is performed under local user account with the option "Run whether user is logged on or not" and the option "Do not store password" both checked. From technet: "If you select the checkbox labeled 'Do not store password', Task Scheduler will not store the credentials supplied on the local computer, but will discard them after properly authenticating the user. When required to run the task, the Task Scheduler service will use the “Service-for-User” (S4U) extensions to the Kerberos authentication protocol to retrieve the user’s token. When using S4U the ability of the service to use the security context of the account is constrained. In particular, the service can only use the security context to access local resources. If you are using the S4U functionality, the task will not have access to encrypted files."

    It is obvious that a scheduled task running using the S4U extensions will not have access to encrypted files since the password fortunately is not stored in the system and cannot be used to decrypt efs files.

    Regarding the bitlocker auto-unlock of the backup target i partially agree. If the os volume is bitlocker protected the option to auto unlock bitlocker protected fixed drives volumes confirms that Microsoft itself considers the auto-unlock feature very secure, that is storing the unlock key in a volume protected by bitlocker is very secure since an attacker, in order to gain access to the fixed or removable volume auto-unlock key, needs first to mount a brute force attack to the key that protects the os volume.






    Monday, March 19, 2012 8:56 PM
  • Same behavior occurs on Windows Backup in Windows Vista, Windows 7 and Windows 8. Windows systems never has auto-unlock feature for Windows Backup or other programs. Otherwise BitLocker will not be safe anymore.

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”

    Tuesday, March 20, 2012 3:27 AM
    Moderator
  • Thanks for your comment.
    I do not agree. In my previous reply to Grigory I explained my reasons.
    If the os that performs the backup is bitlocker protected too I would have given the option to automatically unlock the bitlocker protected backup target at boot without having to log on. The same option is available for bitlocker protected fixed drive if the os drive is bitlocker protected too so the point is , in my opinion, to give this option for bitlocker protected removable drives too in order for the scheduled backup to run successfully.
    Tuesday, March 20, 2012 8:19 PM
  • Let's clearly separate "how it works now" and "how it could work in theory". Here is how File History works now:

    • Backups are performed by a service impersonating logged on users and using their security tokens to get access to FH configuration, source files and backup targets.
    • The task that you found is just a way for the service to hook into the maintenance scheduler to get a wake up call at the middle of the night (notice it's executed under LocalService vs an individual user). When that happens the service performs a slightly more aggressive backup. Usually, the amount of data backed up per cycle is capped to reduce FH impact on system performance, but there is no cap for backups performed as a part of system maintenance.

    Your comments pertain to how File History could work:

    • The task could impersonate a local user without having their credentials stored on the system.
    • The security token of the task could then be used for backups.

    This alternative approach has its pros and cons. Yes, it would be able to perform backups while the user is not logged on, but that would not work for network targets, which could create confusing user experience and is part of the reason why the second approach was not used.

    By the way, FH does not back up EFS protected files at all for a number of reasons, no matter whether the user is logged on or not.

    To summarize, FH has certain design limitations making it unsuitable for your particular scenario. This first public release of FH is focused on consumer scenarios, instead. Thanks for the feedback, though, as it helps us understand user needs and plan future releases.

    Grigory.

    Wednesday, March 28, 2012 6:34 PM
  • Thank you again, Grigory.
    I have to make some clarifications.
    First of all I'm not sure I understand correctly the differences between your explanations about the “how File History works now” case and the “how File History could work” case, that is, in my understanding,  in your explanations there are no differences between the two cases, please forgive me if I did not understand that correctly.
    Second, In my tests both the file history scheduled maintenance task and the file history scheduled UI backup (the one you set inside the control panel) perform whether the user is logged on or not. The only way I know that allows a service to use the security token of a user (or, as you said in your “how it works now” scenario, impersonating logged on users) when he/she is not logged on is using the “Service-for-User” (S4U) extensions to the Kerberos authentication protocol to retrieve the user’s token, and this, as I said in my first reply, would also explain why the file history service is not able to handle efs encrypted files, this is one of the limits of the S4U extensions
    So I think this is how the file history actually works not how the File History could work.
    Regarding the fact that the File history does not backup EFS protected files It’s not absolutely my intention to debate the legitimacy of those reasons, there should be for sure very good reasons  and I perfectly agree that, as you said, this first public release of FH is focused on consumer scenarios. I don't think, in any case, that this is a problem since there are at least two other standard ways that a Windows user can use to backup efs encrypted files, that is through the volume image command and using the old windows 7 files backup.

    About the feedback, You are very welcome. As you can say from all my posts, I am participating very actively in the Microsoft forums just to ask for help on aspects of windows that I do not know or about which I have some doubts, to give my modest contribution to help Microsoft build an operating system even better and to help users of Windows to better understand how It works.


    Wednesday, March 28, 2012 10:54 PM
  • Second, In my tests both the file history scheduled maintenance task and the file history scheduled UI backup (the one you set inside the control panel) perform whether the user is logged on or not. The only way I know that allows a service to use the security token of a user (or, as you said in your “how it works now” scenario, impersonating logged on users) when he/she is not logged on is using the “Service-for-User” (S4U) extensions to the Kerberos authentication protocol to retrieve the user’s token, and this, as I said in my first reply, would also explain why the file history service is not able to handle efs encrypted files, this is one of the limits of the S4U extensions
    So I think this is how the file history actually works not how the File History could work.

    I guess what you might observe is that File History continues to perform backups for previously logged on users after they logged off. While that usually works, there are some conditions under which it stops working, so formally speaking backups are guaranteed only as long as the user is logged on. After a reboot, backups are not started for users until they log on, regardless of the task that you found.

    Grigory.

    Wednesday, April 04, 2012 10:44 PM
  • Thanks Grigory.
    This means that Microsoft changed the way a user security token is used by the operating system.
    In previous Microsoft operating systems it was not possible to use a user security token after the user logged off unless the user explicitly scheduled a task or a service using the S4U extensions to the Kerberos authentication protocol or he/she explicitly saved his/her windows password so that the task scheduler service or other services could logon the user with the saved credentials.
    If this is an intentional behavior I consider this a serious step backwards from the point of view of security, mainly because this makes the user unaware of the fact that there are services that could use his/her security token after he/she logged off, even if this happens only in particular circumstances.
    If this is not a bug of the consumer preview, I hope that Microsoft will consider reviewing this decision or at least clearly informing users that, in some circumstances, the file history service could use their security tokens after they logged off.


    Wednesday, April 04, 2012 11:41 PM