gherzog
asked on
EFS over the network - authenticating 2 different ways
So I have a weird issue. We have a server located in a DMZ that is a drop server for files from our clients. We have two different accounts (local to the server) that we use to log in and retrieve these files. These accounts each have a locally encrypted directory (EFS) with a share off of it.
Both accounts are local admins on the box.
When we log in (map a drive) with account A to its share, no problem, send/receive files.
When we log in (map a drive) with account B to its share, I can see the files, but I can not cut or paste to it.
Since EFS over the network only works with Kerberos, it seems to me that I'm authenticating with kerberos for account A, but account B is defaulting to NTLM. This is from any workstation. Anyone have any ideas?
Greg
Both accounts are local admins on the box.
When we log in (map a drive) with account A to its share, no problem, send/receive files.
When we log in (map a drive) with account B to its share, I can see the files, but I can not cut or paste to it.
Since EFS over the network only works with Kerberos, it seems to me that I'm authenticating with kerberos for account A, but account B is defaulting to NTLM. This is from any workstation. Anyone have any ideas?
Greg
ASKER
The server is running Windows 2003. It is not configured for delegation in Active Directory, nor is the account that works fine. Both accounts are local accounts, not domain.
I think my logic on binding NTLM vs Kerberos is sketchy. that makes no sense. If i can connect and use the one account (obviously kerberos), it's not going to bind via NTLM based on a different set of user credentials. The binding should be all workstation based. So now I'm trying to figure out what the possible differences might be between these two accounts that would cause this behavior.
Greg
I think my logic on binding NTLM vs Kerberos is sketchy. that makes no sense. If i can connect and use the one account (obviously kerberos), it's not going to bind via NTLM based on a different set of user credentials. The binding should be all workstation based. So now I'm trying to figure out what the possible differences might be between these two accounts that would cause this behavior.
Greg
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
http://www.microsoft.com/technet/prodtechnol/winxppro/deploy/cryptfs.mspx#EME (see the last bullet point below)
When copying an encrypted file:
• If using Windows 2000 and the target server is running Microsoft® Windows NT Server 4.0, the file will be silently decrypted and copied to the server. If using Windows XP or Windows Server 2003, the user will be warned and prompted to allow the decryption operation.
• If the target server is running Windows 2000 or Windows Server 2003, and the machine account of the server is trusted for delegation in the Active Directory, the file will be silently decrypted and copied to the server where it will be re-encrypted using a local profile and encryption key.
Note The file is transmitted on the network between the client and the server in an unprotected format. If this file contains confidential information, care should be given to ensure that the network connection also provides secure transmission of the data. Such network data protection might include IP Security (IPSec).
• If the target server is running Windows 2000 or Windows Server 2003 and the machine account of the server is not trusted for delegation in the Active Directory, or the server is in a workgroup or a Windows NT 4.0 domain, the file will not be copied and the user will receive an "access denied" error message.
The "access denied" error message is returned to applications from the NTFS file system in order to ensure compatibility with existing applications. The use of an alternate or more descriptive error message would cause many applications to fail or behave erratically.
The Windows XP Professional client contains some enhancements in the area of copying encrypted files. Both the shell interface and the command-line now support an option to allow or disallow file decryption. When an encrypted file is copied to a target location that does not allow remote encryption, the user will be prompted with a dialog box that allows a choice of whether or not to decrypt the file.
=========================
I assume account A is a domain account and account B is a work group account? Try copying the recovery agent key to the workgroup pc.
http://support.microsoft.com/kb/887414
http://support.microsoft.com/kb/241201
-rich