Re: Using EFS with Network Shares and SFU 3.5
- From: "Roger Abell [MVP]" <mvpNoSpam@xxxxxxx>
- Date: Wed, 22 Nov 2006 17:33:32 -0700
Thanks for the post-back. Although some might call this scenario
an edge case, in terms of frequency of occurrance, it seems a rather
nasty error case to me !!!
You may indeed be on to something with the caching idea.
The success events logged on the sharing server indicate that
access is allowed per NTFS. It does not take EFS into account.
Evidently all that accounts are allowed at the NTFS level.
To determine whether it is the NFS client caching perhaps you
could again use the sharing server audit logs to see if success
is recorded for a delayed reattempt that theoretically is serviced
from the cache. For this to be effective you would need to tweak
the auditing (Edit in Advanced) in order to distinguish between
Read extended attribute and Read data, since the NFS client may
(one would hope) be checking the modified timestamp to see if
the cache should be invalidated.
If it is not the caching, then this is very difficult to understand
since the EFS decryption is totally dependent on access to the
profile, and hence EFS key, of the EFS-allowed account, and
you are seeing the other accounts logged as the accessors.
Roger
"dln" <dnadon_nospm@xxxxxxxxxxx> wrote in message
news:ucYqdAmDHHA.4024@xxxxxxxxxxxxxxxxxxxxxxx
"Roger Abell [MVP]" <mvpNoSpam@xxxxxxx> wrote in message
news:ed2EKFkDHHA.4680@xxxxxxxxxxxxxxxxxxxxxxx
Roger,
"dln" <dnadon_nospm@xxxxxxxxxxx> wrote in message
news:eySgT7aDHHA.4832@xxxxxxxxxxxxxxxxxxxxxxx
Hello all,
Our site is running in an environment that is required to support both
Windows and *nix clients. To help support our clients, we have a
central Windows 2K3 SP1 file server that also has the NFS server
component from Services For Unix 3.5 installed and running on it. The
idea is that our users can access their home directory, regardless of
the OS they are using. This setup hasn't presented any problems, but
today I was doing some testing with EFS on the file server and I found
some inconsistencies when I access an encrypted file over a network
share via Windows Explorer versus accessing the same file from a Linux
client that has my home directory mounted from the Windows file server
via NFS.
On my Windows XP client, I can access my home directory on the file
server and encrypt a file. This file is then inaccessible to other
network users via Windows Explorer as I would expect. However, if I log
into a Linux client that has my home directory mounted via NFS, "su" to
another user (same user that couldn't access the file via Windows
Explorer - _not_ the root user), this user can then open that same
encrypted file (using vi) that was previously inaccessible when going
through Windows Explorer. If this file was actually encrypted, I would
have expected to see a bunch of gooblygook.
I have read that EFS encrypted files are transmitted over the network in
the clear and maybe this is a result of that behavior, but I would have
expected that file server check the requesting user's credentials before
allowing access to the file? Along those lines, it may be a result of
the file server being delegated, a topic that I must admit I don't
understand that well. In any event, I'm hoping someone can tell me
whether or not I have a (mis)configuration problem or if this is
expected behavior?
I am not familiar with the specifics of your scenario. However, I did
want to point out that, if the network access is not being made with the
credentials to which you have su'd, but the base account, then what you
experience would be pretty much what one would expect.
As tests, can you access this if logged in directly as the account that
you had su'd to ? What are the NTFS permissions allowing on the
file (both accounts?, only the base account?). Can you place an audit
on the files used for testing in order to see what credentials the server
is seeing sent? The delegation only allows use of the credentials that
are received, so it comes down to how the network access is done.
Thanks for the response. While testing your suggestions, I think I
discovered the root of the problem. I attempted to log into the Linux
system as a non-me user (who shouldn't have access to the file). When I
attempted to access the encrypted file with this user account, I received
an I\O error. I took this to mean that the encryption was working. I
then switched to my user account and opened the file without any problems.
I then switched back to the user for which the open previously failed and
he could access the file without any issues. I even had several other
users attempt to access the file and they didn't experience any problems
opening it. Additionally, I turned on auditing for the file and it does
show successful access by the users who should otherwise not be allowed to
access the file.
I used the same process to test access to the file from another server
that mounts the same file system and I was able to duplicate the behavior;
the non-me user couldn't access the file until I accessed it and then the
non-me user could then read the file. I'm thinking the NFS client is
caching a copy of the file after it is successfully opened. There's
probably an NFS option I can specify somewhere to disable this behavior on
the client, but it could impact performance if caching is turned off on
the client. I'll need to investigate this further.
Thanks again for the suggestions.
.
- References:
- Using EFS with Network Shares and SFU 3.5
- From: dln
- Re: Using EFS with Network Shares and SFU 3.5
- From: Roger Abell [MVP]
- Re: Using EFS with Network Shares and SFU 3.5
- From: dln
- Using EFS with Network Shares and SFU 3.5
- Prev by Date: Re: Using EFS with Network Shares and SFU 3.5
- Next by Date: Re: Create a domain account with full access to all files and folders?
- Previous by thread: Re: Using EFS with Network Shares and SFU 3.5
- Next by thread: Re: user secuity inwindows 2003 server
- Index(es):
Relevant Pages
|
