Hello,
I would like to get an advice how to implement the following setup.
A LAN with Samba file server on Debian. User based authentication to shares. Mixed clients, Win7 and Debian. We would like some of the Samba shared folders to be encrypted. These folders will have read only user access. Win7 and Debian clients shell be able to read/open files from this encrypted shares. But if a Win7/Debian client copy a file from encrypted share, it shell be still encrypted and the only clients able to open it to be from the LAN. The purpose is, protection of data leakage. Copied file or sent file through e-mail client to another PC outside the LAN, shell remain encrypted. ecryptfs is cool but asap the share is mounted the files can be copied/sent unencrypted. Hope this was enough clear what we need
BR,
eoncho

We looked at this before at a different company and we found that we needed software installed on the client side such that the files were only unencrypted when they hit the client PC. We found there wasn't a simple open-source way of doing it.

Unfortunately I can't remember the provider of the software we ended up using

We also found that no matter what the solution that was available the file decoded on the client, so if it was opened on the client machine it could be saved un-encoded to the local file-system and therefore could be e-mailed. The end result was that the machines on that LAN segment were fully segregated from other machines and had NO e-mail access, NO internet access, NO usb access etc. They could JUST be used to view the protected files.

You might be able to accomplish this objective – without encryption – through the use of Access Control Lists (ACLs) and other features of the standard Windows security model.

Windows' authentication and authorization mechanisms are quite extensive and well-developed, if you want them to be. You can easily make particular directories accessible to ... and even, only visible to ... selected groups of users as determined by OpenDirectory (LDAP) settings that can be managed globally by your security organization.

(Yes, I just complimented Microsoft's work – again – on a Linux forum.)

I'm not 100% sure about Samba's implementation of some of these things, but you can certainly put the files-of-interest on a "true Windows" server elsewhere within the same SMB network, using Samba to give access to that network but not actually to store these files. You'd like to avoid a "hybrid file-system setup" situation that will be inherently harder for you to manage, when you can avoid such a thing simply by putting the files somewhere else in the company.

If you can tweak the windows side, this might be helpful: http://techgenix.com/secure-smb-connections/

sundialsvcs do you think it could work with samba ACLs? https://wiki.samba.org/index.php/Set...g_Windows_ACLs

I have not been "deep into Windows" like this for several years, so I really don't feel qualified to say. But it superficially appears that Samba knows enough of the protocol to get the job done.

However, my original thought was that you would store the assets somewhere on the network under "real Microsoft" hardware – so that you know that it's their software that's protecting it. Then, you access those protected resources through Samba.

One thing to consider about this is, "what is the underlying filesystem here?" If Samba is storing the resources, the underlying filesystem is Linux. Now, Linux has an ACL implementation of its own – but it's somewhat different from Windows' model so there is "mapping" from one to the other. (And, unless you are authenticating all of your Linux users through the Microsoft-managed LDAP/OpenDirectory that is used on the Windows side, there could be identity/authorization hiccups, too.

Perhaps you don't want that. If the resources are truly sensitive, maybe you want to store them where Microsoft's ACLs are known to apply natively. They know how to write a good, high-performance file server. At the end of the day, you simply want secure storage for your assets in a way that you (and everyone else at your company) can easily understand and manage.

I'm being vague because my understanding of the situation on the Microsoft side is imperfect.