What is the best practice to secure the ifs share and filesystem?

Hi Sean,

A few things.

1. Delete the ifs SMB share and the /ifs NFS export that are created by default on a new cluster.  They are useful for building the cluster, loading the latest code and firmware prior to joining AD, that kind of think, but after that, I would suggest getting rid of them. (side-effect if you have insightIQ, you need to create an NFS export at /ifs/.ifsvar/modules/fsa for InsightIQ to get filesystem analytics data)

2. Don't use /ifs/data to store anything.  There is a very long reason as to why and how you should layout your filesystem, and you can read up on it from my comments in this thread here:  Isilon folder layout - /ifs/data usage

3. Keeping the UNC's the same for your users i certainly understand, but be careful how you do it.  By that I mean that if you are collapsing 5 windows servers and 2 CIFS servers into a single cluster (the consolidation play is very common when coming to Isilon), then don't use CNAMES, and you cannot keep your old IPs.  Go with me here as to why:

    a.)  As storage administrators we've been telling our users for years not to use IP addresses, but instead to only use DNS names to get to things, because the IPs may change.  If you were to try and keep the IP addresses of your 5 boxes that I proposed above, assuming they are all in the same subnet [to keep the discussion simple], you would have to at the point of cutover, down the interface on the source, and then add the IP to a static smartconnect zone on the Isilon cluster, because Static is required for SMB.  Now remember what a static smartconnect zone is when it comes to failover behavior (important because this behavior comes into play even during normal rolling code upgrades).  With SMB clients, the clients timeout, do a new nslookup and connect to a different node.  There will be no disconnected mapped network drives, etc.  But that is only if the user is using a name, so that smartconnect can do it's job properly.  If you permit users to use IP addresses for any client connections, then they might not failover correctly, and also all traffic will always be pointed at just 1 interface on 1 node, which doesn't scale.

     b.) As you may have seen in the past, CNAMES usually work well in DNS to redirect clients from an old name to a new one, but they are simply impossible to track down.  So if I had a CNAME called winfileserver.domain.local that pointed to my new cluster at isilon01-static.domain.local, it'll work fine, but 3 years from now, how can you tell what cnames are pointing at your Isilon cluster if you decide to change it's name?  The answer is that you cannot, without digging through DNS zone files, or something crazy.  NSLOOKUP can handle forward and reverse lookups and tell you from looking at a cname what it is pointing at, but not the reverse.  Therefore the better way to do this is create a smartconnect zone alias, like this:

isi networks modify subnet0:pool0 --add-zone-alias=winserver.domain.local

This can be done now, prior to any cutovers, it just lets the cluster's smartconnect service answer back with IPs from subnet0:pool0 when a request comes in for the name winserver.domain.local .  This assumes that subnet0:pool0 is your static smartconnect zone for SMB connections.

The add 2 steps as part of your cutover procedure:

               1. isi auth ads spn check --domain=domain.local

    This will show you which SPN entries (for your new aliases) are missing from the AD Machine Account.  You can fix it also from the CLI, however you will need someone with access to AD to do it. (meaning credentials)

     isi auth ads spn check --domain=domain.local --repair --user=username  #it will prompt for a password.

                2. Modify DNS.  Delete the old A record and PTR for your source box, and create another NS record or delegation (if AD integrated DNS) in your DNS for the old name, again following our example it would be winfileserver.domain.local in [NS] to isilon01-ssip.domain.local.  (SSIP stands for Smartconnect Service IP address).  This assumes that the A record and PTR for the SSIP already exist.  Now your old servername can be answered by any node that is in subnet0:pool0.

4. When copying data to an isilon cluster over SMB, be certain that the account doing the copies (and only that account), is added to local administrators and backup operators of the source box, and is given 'run-as-root' to the SMB share on the target.  I prefer to use a top level share, like /ifs/clustername/system as system$ or something like that, and give run-as-root to my AD service account that I will use emcopy with. 

5. When doing any file data migration, be certain that you test user access prior to the cutover, and spot-check permissions all over the place.  Problems like SidHistory in ownership or ACLs frequently crop-up only during a cutover window because of not enough UAT before the event.  So test, test, test.

I hope this isn't too much information, but I like to see our new customers get off on the right foot.

~Chris Klosterman

Senior Solution Architect, EMC Isilon

Offer and Enablement Team

chris.klosterman@emc.com

twitter: @croaking