Ray Van Dolson wrote:
I'm fairly certain there's no clever way to stick with a single domain and configure only certain datasets to require additional auth?
First of all: I have no idea.
You write:
"additional authentication requirements -- probably two-factor authentication."
I'm not sure what you mean in your scenario with MFA (multi-factor auth). But your Q is if you could set up so that a true subset of the [users in] an MS AD domain require MFA.
Thinking CIFS, but presumably kerberized NFSv4 could also work here.
About Kerberized NFS. Attempting to go to NFSv4.1 (don't touch 4.0) *and* Kerberize at the same time in a stable NFS environment in production is a daunting task to say the least. There are so many things that can make you trip. Hard.
If your NFS basline is sec=sys (default, implicit trust of UID & GID) then it's possible to mix and match very granularly, but exacly how to configure it in C.DOT I cannot say, other than it's fully possible. For 7-mode, see below. This has nothing to do with MFA of course.
Just for everyones info: one can Kerberize NFSv3 in this way -- using the tickets in MS AD. It works, we've tested it. Can cause some trouble with older NFS (Linux) clients or other obscure things. Of course the main obstacle is around how to integrate the NFSv3 clients with MS AD in a way that's user friendly enough. On the ONTAP side, it's quite easy, just do:
Enable Kerberos för NFSv3 on the vfiler and then use: sec=krb5 or krb5i in /etc/exports. This will not at all affect the lines (entries) in /etc/exports which have sec=sys. The NFSv3 clients specify something with Kerberos according to their syntax, in their mounts.
1. Enable Kerberos for NFS in a vfiler by running 'nfs setup' and answer 'y' on the Q about Kerberos. Same config you'd use for a CIFS service (cifs setup) in a vfiler
N.B. In this situation, if you have UNIX users in NIS and use that for NFSv3 and in parallel have an MS AD domain (forest, whatever) which has the same usernames so that the implicit user name mapping works (usermap.cfg) then all is OK. The encrypted auth doesn't touch the NIS name service system at all.
2. Example in RHEL you need to enable SECURE_NFS in /etc/sysconfig/nfs. And then point out a valid keytab file which is stored on the box somewhere when it joined the domain. rpc.gssd needs the contents of this file to do its job, again in RHEL it's specified like this:
RPCGSSDARGS="-k <path to hosts.keytab>"
The big hurdle is how to handle all the keys (host keytab is needed by the NFS client) and the Computer Objects aka Machine Accounts for all your NFS clients. All the machines need to be joined to the MS AD domain in the same way as you do with MS Windows PCs.
So, they need to all be in MS AD w.r.t. NFS like you do when you join a Samba server to an MS AD domain. And so do all the users (they're already there of course if you have a Microsoft environment).
Finally the users need a way to periodically renew their tickets, preferrably with high automagicality (is there such a word? :-) ) In MS Windows it's just taken care of under the hood, as long as you're logged in and have a running desktop with CIFS mounts the ticktes will just renew automagically
There are various more or less convoluted ways to do all this for Linux/UNIX NFS clients, if you wish to integrate everything with MS AD and its LDAP service, then it's advisable to have 'UNIX enabled users' everywhere.
That will make it possible to ditch NIS for ONTAP and instead use the LDAP client 100% for everything (incl automount maps etc) -- everything is then manged in MS AD and there's no NIS master anywhere anymore
One way of getting rid of the big project to try and do all this 'yourself' is to procure this SW product for your organisation:
Vintela -> Quest -> Dell Authentication Services
it's no breeze to deploy this in a big NFS client environment of course but easier than trying to patch it all together on your own
/M