DFS , EFS and NTFRS

[David Bowen]

OK, I'll start by apologizing for all the abbreviations that are about to
turn up.

I have Windows 2003. 3 machines, all DCs. Two of them are running DNS and
DHCP (with the 20/80 trick).

I have files that I replicate using NTFRS. I also use DFS extensively. The
combination of DFS and NTFRS appears to work well. I've also got some group
policy entries for "My Documents" re-direction targetting a DFS folder
(different per user) - I know it's against best-practice, but it's terribly
useful.

My problem is that I'm going on holiday in six months time and I'd like to
encrypt my files so that if someone steals my servers whilst I'm away they
can't just slot the drive into their server and use their local admin
priviliges to give themselves permission to my files (which are obviously
locked down by ACLs in my environment).

I dreamt of using EFS to do this and so I set myself up as a CA and
configured the auto-enrollment magic etc. I did have an issue with the fact
that the list of users who can transparently access the file is *not*
associated at the folder level. That's OK because I made myself and my
girlfriend Data Recovery Agents so she can get to everything that I encrypt
(and vice-versa).

So then I ran a number of tests and all was well. I thought I'd be brave
and so I encrypted my "My Documents" folder as my first real-world test.
Sadly I then discovered quite a few errors in
%WINDOWS%\Debug\NtFrs_0005.log.

<StuGenerateStage: 5780:00:00 4171:00:00 S0: 19:44:03> ++
OpenEncryptedFileRaw failed on \\?\V:\DFS Secure\David\My
Documents\Apple3.txt; WStatus: ERROR_SHARING_VIOLATION

Now this seemed a bit odd as there wasn't anyone using the file. I even
popped to www.sysinternals.com and fetched Process Explorer which I admit
didn't help much on this occasion.

Having decided this was probably an encyption-related issue I tried to setup
the NTFRS Service to have an "EFS Recovery Agent" certificate. That was a
silly thing to try because certificates are only issued to machines or
users. So I created a new "Service" account and gave it a certificate, made
it and Enterprise Admin, added it to my list of users that are mentioned in
the file ACL and then setup the NTFRS service on all three machines to use
this new account. That yielded:

<SndCsMain: 3264:00:00 873:00:00 S0: 19:44:28> ++ ERROR - EXCEPTION
(00000721) : WStatus: RPC_S_SEC_PKG_ERROR


which doesn't look nice.

So I reverted all my NTFRS service accounts to be LocalSystem and then did
what you do in these cases - I went back to Google. Now I'll admit to
reading a lot of the documentation on DFS, EFS, NTFRS and NTFS but I never
came across:

http://support.microsoft.com/?kbid=229928

which is titled:

Design Decisions, Defaults and Behavior for FRS File and Folder Filters in
DFS and SYSVOL Replica Sets

And this document kindly informs me (amongst other things):

Other files excluded by FRS
In addition to files and directories excluded by filters, replication does
not occur for the following cases:
- EFS-enabled files and folders. EFS-encrypted files are computer-specific
and excluded from replication.

Well as you can imagine I stopped smiling. Well I would have done if I
wasn't pretty glum already.

Seeing as how all my certificates are auto-enrolled in AD and that my CA is
fully accessable and that all my machines are in the same domain I'm a bit
surpised to find out that my encrypted files are "computer-specific". So I
did the obvious test and copy-and-pasted an encypted file to another machine
and it de-crypted just fine from a user session on the remote machine (which
assumedly picks up my EFS certificate / key from AD). That was what my
other tests showed and it appears to make sense to me.

Basically I'm now confused as I can't see why NTFRS doesn't just lift the
file up and squirt it (still encrypted) over to the other NTFRS hosts. I
would have more luck using XCopy than NTFRS in this case.

Does anybody have any experience that could help me here (notably a way to
stop NTFRS filtering EFS'd files)?

David Bowen

 

[David Bowen]

I should mention that:

http://support.microsoft.com/default.aspx?scid=kb;en-us;272279&sd=tech

How to Troubleshoot the File Replication Service and the Distributed File
System

Seems to occur over-and-over in my searches too. This is because of the
phrase:

9. Verify whether or not the source file had been excluded from replication.
Confirm that the file is not Encrypting File System (EFS) encrypted, a NTFS
file system (NTFS) junction, or excluded by a file or folder filter on the
originating replica member. If any of these situations are true, FRS does
not replicate the file or directory

 

[Daniel Billingsley]

I've never heard that. Got any references? It's something I do here as
well.

 

[David Bowen]

Sigh. It just took about an hour to find this.

http://support.microsoft.com/support/kb/articles/q301/4/79.ASP

 

[Jill Zoeller [MSFT]]

David,

FRS monitors the USN journal to detect when files have changed. Once a file is encrypted, FRS ignores all changes to the file. If you decrypt the file, FRS does notice this change and will replicate the file. Unfortunately there's no way that I know of to "trick" FRS into replicating encrypted files.

For more information about how FRS works, see http://www.microsoft.com/technet/tr...erver2003/proddocs/techref/w2k3tr_frs_how.asp

 

[David Bowen]

Jill,



Thanks for the feedback and the link.



In my case there is only one server facing the world at large and so that
will be the only one that should be updated whilst I'm away. I could set it
to de-crypt "new" files each day and then re-encrypt them. That would
ensure they got moved to the remote machines in case the house burns down /
the server gets stolen. If I did this I'd need to figure out how to setup
encryption on the other servers so that the updated file could arrive OK.
This sounds like it's getting tricky.



My day job is writing systems and I know how frustrating it can be when you
see people in the real world doing very strange workarounds because they are
(ab)using a feature you created. It appears to be the way of the world.



In reality it'll probably be easier to setup XCopy for the small amount of
things that are likely to change whilst we're away. Something like a
scheduled task doing:



XCOPY /M /E /C /H /R /K /Y /Z \\Server1\DFSReplicaSet1
\\Server2\DFSReplicaSet1



or possibly:



XCOPY /D /E /C /H /R /K /Y /Z \\Server1\DFSReplicaSet1
\\Server2\DFSReplicaSet1





I can even freely XCopy into the "true" target location (my other DFS
Servers) as the USN updates won't fire. The only minor snag then is when I
get home and de-crypt everything (8GiB) which will cause my Wireless LAN to
light up for quite a while.



Thanks again.



David Bowen






David,

FRS monitors the USN journal to detect when files have changed. Once a file
is encrypted, FRS ignores all changes to the file. If you decrypt the file,
FRS does notice this change and will replicate the file. Unfortunately
there's no way that I know of to "trick" FRS into replicating encrypted
files.

For more information about how FRS works, see
http://www.microsoft.com/technet/tr...erver2003/proddocs/techref/w2k3tr_frs_how.asp


<<

 

[Daniel Billingsley]

Well, man thanks for that effort!

That article refers to "Home folders" - IMO Microsoft has not done a very
good job of differentiating between the blurring terms/technologies like
Folder Redirection vs. Roaming Profiles vs. Home Folders. The term "home
folder" refers to a particular setting you make in a user's account
settings - I'm not sure if it's the same thing as a GPO redirection,
although in effect it may very well be.

Jill, could you clarify/verify if that KB article is talking about GPO
folder redirection of My Documents or App Settings? Unless you have some
more references to that end David.

 

[Jill Zoeller [MSFT]]

From a DFS/FRS perspective, what's important here is the type of data that's
being replicated. The article talks about how "home folder" scenarios
typically have files that are kept open by users, and this can cause
replication delays. The article also mentions that the rate of change of the
data can be high, which again can cause replication delays and bandwidth
issues. In organizations that require minimal replication latency, using FRS
is not the best solution for home folder scenarios. I don't think it matters
whether Group Policy is involved--basically any folder that has files kept
open and a high rate of change could be problematic unless the organization
is OK with latency issues, has adequate bandwidth, and has good monitoring
procedures in place.

As for whether there are specific problems using DFS with Group Policy
features, I'm not sure. I've heard that roaming profiles on DFS can have
problems, but I can't recall the specific issues at this point. I will ask
around and get back to you.

 

[David Bowen]

Thanks Daniel, Jill.

I can confirm that I've been using a GPO to redirect "My Documents" to a DFS
target. This is safe and effective in my environment as I only have two
users (myself and my girlfriend). The only time it's likely to catch us out
is when she's planning a holiday in Excel and of course I can open the same
Excel file if my DFS target is different. We're both quite computer
literate so she's knows I'll only see the saved data and I know not to alter
it until she's finished. We co-ordinate this activity verbally

In general if we want safer multi-user access to data we use Exchange
Server. It's great for web / PDA / Workstation multi-access. I can update
an appointment on my Outlook Web Access at work and it'll pop up on her desk
at home straight away.

So, to conclude, I'd agree with Jill that it's the type of access to the
data / lock duration that is the issue rather than any specific GPO / My
Documents / HOME folder issue.

David