Windows Server 2016 failover cluster fileserver role, configurable authentication domain.
Hi all,
I wanted to put this suggestion forward because it seems like a feature that Microsoft, and its customers, would be very interested in.
MS seems to want to enter the Software Defined Storage and Software Defined SAN space with it's design decisions in WS 2016 and this puts it up against the likes of traditional vendors such as IBM, EMC and Netapp. This would place commodity hardware at the same level of these NAS / SANS with WS 2016 running over it and for the vast majority the OS can handle those demands with its new features such as storage replica, storage spaces direct and other goodies.
However I have found one major flexibility point where I think MS needs to improve and that is when you create a cluster fileserver role you can only place that role in the same domain, or lack of domain if it's a workgroup cluster, of that cluster node. This runs up against some issues if you want to transparently serve files to people in non trusted domains or if you don't want to have to split up your cluster nodes to host them on differing domains thereby having to invest in more hardware or reducing redundancy.
Say for example you have a "production" storage cluster serving iscsi, NFS and SMB to hypervisor systems as well as clients directly, as a NAS / SAN would, but you have separate authentication principals for your test and development environments that you don't trust. It would be much easier to create a new file server role, choose the domain for which it will authenticate to and then allow it to serve files to those non trusted environments transparently. Netapp, for example, achieves this through it's vserver configuration so you can have your production hardware and slice up your SMB servers for each environment as you need them.
This feature would involve a few changes to the way file server roles function, most likely spawning off a new SMB server process for that role as well as a separate SMB "stack", the process would run under an originating domain account but would have access to the Kerberos tokens of the untrusted domain through a created service account. This account would probably be the computer account that the file server role creates in the AD. You would also have to change the way permissions were queried on the cluster node so that cluster disks handled by the file server role went through a slightly different lookup process as well as filtering out any ACLs that the cluster role displayed to clients that didn't consist of local server permissions or the configured authenticating domains.
So why would you do all this and not create a trust between the domains and make your life a **** of a lot easier? Politics, that and environment separation. The storage environment for enterprises is in a unique situation where it needs to provide clients access to resources in separate environments that may not want to have anything to do with each other. You could also hyper-V up your hardware and cut the environments up but that is a lot more complicated and raises other configuration issues that are a lot more complicated than this proposal.
Anyway, I think this would be a useful addition to the storage bow that is Windows.
Thanks for reading. :)
P.S.: Please add tiering to parity storage spaces, thanks! :)
