Here's the trouble I'm running into and the question that it raises.
I'm getting ready to turn on CIFS on our filer (F820) so that our users have one file system to deal with and not two. In my experiments I have seen some strange behavior that goes something like this:
If the qtrees are unix mode then my unix host that has root privs can see and manipulate files just fine.
If the qtrees are mixed mode then on some files the unix host can manipulate files and on some it cannot.
It can even get to the point that a file/directory that a user creates under windows cannot be accessed by that same user from unix (if the filer is in mixed mode).
So, my questions are:
1. Has anyone seen this behavior before?
2. If a user disappears from Active Directory and I have to recreate them will the new SID be a problem if the user has the same name?
3. Does anyone have any thoughts on which security mode (unix or mixed) for a filer that is serving NFS to an NIS domain and CIFS to a Windows AD Domain?
Thanks Colin J.
We converted from "unix" to "mixed" 2 or 3 years ago. The benefits have outweighed any oddities, although one does need to educate the users a bit about both.
Do make sure that you map Unix root to the Domain Administrator account (and vice-versa) in the usermap.cfg file. You can do this one-way, if appropriate for your environment, but our NT administrators found that to be confusing.
If the qtrees are unix mode then my unix host that has root privs can see and manipulate files just fine.
If the qtrees are mixed mode then on some files the unix host can manipulate files and on some it cannot.
We saw this in testing, but "options cifs.nfs_root_ignore_acl on" took care of that problem. Another way around it is to first take ownership of ("chown" to root) the file(s) before manipulating them, which is what you would have to do if operating from the Windows admin account.
There's an option "wafl.nt_admin_priv_map_to_root" which (if enabled) allows all NT admin users to act like Unix root for files where the Unix permissions are in effect. We're Unix-centric here and have that option turned off (except for an explicitly-mapped Domain Admin account).
It can even get to the point that a file/directory that a user creates under windows cannot be accessed by that same user from unix (if the filer is in mixed mode).
If you craft an NTFS ACL which would keep the Windows user from accessing their own file, then yes, the equivalent Unix user would also be kept out. But other than this scenario, as long as Unix account names and Windows account names are kept in sync (or mapped in the "usermap.cfg" file), this should happen rarely, if at all.
- If a user disappears from Active Directory and I have to
recreate them will the new SID be a problem if the user has the same name?
We have no experience with this issue (old NT Domain still in use). When the same scenario happens with NT Domain users, it's not a problem, because the old files remain owned by the old SID -- the re-created account should end up with a new SID, and someone (root/admin) would need to assign ownership to that new account, if indeed it is the same user (it's been awhile since I did this, so you'll want to test it out for yourself).
- Does anyone have any thoughts on which security mode (unix or
mixed) for a filer that is serving NFS to an NIS domain and CIFS to a Windows AD Domain?
In my opinion, this is one of the big benefits to even having a NetApp filer in the first place. No other product that I've studied seems to handle this issue as well.
The most common issue we've experienced here with mixed security mode is the case where it looks from the Unix side like you should have access to a file (e.g. permissions may show up as 777), but the filer prevents you from accessing it. This is invariably because an NTFS ACL is in effect which cannot be mapped to an equivalent Unix permission, and the filer will always enforce the more restrictive set of permissions when both are available. In this case, the filer is doing the right thing.
There's an excellent article on NOW, with a title something like "Security Troubleshooting Guide", which describes all these issues in great detail. Definitely read through this before converting.
Another recommendation: Create a new qtree with mixed security mode and have your users try that out before converting your existing qtrees.
Regards,