Hi Adam -
ONTAP has some good home directory share mechanisms, but as you say, to my knowledge, autocreate of the folder isn't one of them. The mechanism I've used at scale leverages the dynamic home shares which goes a long way to aid automation.
In an SVM, you can designate a path (or paths) as a home directory location. These are the base paths relative to storage where home directories might be located - you might have more than one in a large environment spread across multiple volumes, nodes, etc. The actual user homedirs are created under these base directory paths. So for automation, what I have done in conjunction with the AD user admin team is to create the home directory locations on storage and created a hidden share for those locations only accessible to a "user creation" service account. The script which adds the user to AD also creates the user's homedir folder under a designated home directory path using the share and the service account.
The next logical step in general terms would be to create a share and/or set permissions on the user specific homedir just created. Those steps can be skipped if you use dynamic home directory share mapping, another feature in ONTAP which simplifies things as well. You don't have to give an account access to the SVM to create new shares, instead you can define a single share using dynamically supplied data that will active a share on demand for every user. So here's how this works.
Let's say we create and mount (junction-path) a volume at "/home". In the SVM, we add that to the home directory search path using "vserver cifs home-directory search-path add -path /home". Now define a single share that uses variable substitution to define the share name and the path relative to the home directories.
This takes a little explanation. A normal share of course is a share-name, for instance "shared" and a path relative to the root of the SVM, for instance "/myvolume/shared" which you create with the usual "vserver cifs share create -vserver SVM1 -share-name shared -path /myvolume/shared" command. Dynamic home directories are different. You will specify on the share creation that a dynamic home directory share is specifically for home directories using a share property "home-directory". Then you can use the following dynamic variables in the share name and share path:
%w - the user's Windows user name
%d - the user's Windows domain name
%u - the user's UNIX user name
The path created is relative to any of the defined home directory search paths - so you can have multiple locations where it would be. An example helps:
Let's assume SVM has two volumes on different aggregates, mounted at "/home1" and "/home2". So first we add them to the home directory search paths:
vserver cifs home-directory search-path add -vserver SVM1 -path /home1
vserver cifs home-directory search-path add -vserver SVM1 -path /home2
Good. So now we define a dynamic share for home directories. Let's assume we want to further break up the volumes by putting the user's domain as part of the file path - that is user "DOM1\BOB" might be be physically stored on the volume as /home1/DOM1/BOB. Let's further assume that the share name we want to be a little unique for clarity, so we want the share name to be "HD_BOB" - that is HD for home directory and the user name as part of the share name. So we we expect user BOB to connect to \\SVM1\HD_BOB and get to actual path /home1/DOM1/BOB.
The share we define like this: vserver cifs share create -share-name HD_%w -path %d/%w -properties homedirectory,oplocks,browseable,changenotify
Notice that the share creation doesn't specify /home1 or /home2. Because it uses the property "homedirectory", this share is automatically checking both physical locations as defined by the home-directory share paths. When user "DOM1\BOB" attempts to connect to share \\SVM1\HD_BOB, the SVM sees that the share name matches the "HD_%w" definition, because here %w is dynamically substituted with the Windows user name "BOB". The share has the home directory property set, so the the SVM now searches the home directory path list for locations /home1/DOM1/BOB and /home2/DOM1/BOB, again substituting in the physical path of the share definition. The search order is configurable based on how the home directory search paths are maintained. Since for this user there is a match, the SVM connects \\SVM1\HD_BOB to /home1/DOM1/BOB.
By default, if any other user attempts to connect to the same path, it will fail because the substitutions are based on the connecting user's defined credentials.
To bring this all together for automation. I define a home directory base path "/home1" and share it as "HOME1$" and assign security only for a service account to create and delete folders. When a user creation process fires, the script connects to the HOME$ share and creates a folder with the same name as the user. The same script updates the home directory of the user to be \\SVM1\username.
I've already defined a share with the homedirectory property as share-name "%w" and path "%w". This dynamically matches every user to their folder under the "/home1" path in this example. So no SVM level administrative access is required to make this work. Because it's a home directory, the security is also hard locked to the connecting user, so no extra permissions or security settings are needed at the folder level.
I also use the option to configure home directory access for administrative users. This allows users defined as in the "BUILTIN\Administrators" group on the SVM CIFS configuration to access home directories as well for whatever reason needed.
This gets rather involved to understand at first, but it's very powerful at scale. It greatly simplifies SVM management activities around home directory management. There are a few gotcha's - first is that the Windows GUI functionality to set someone's homedirectory doesn't work as you'd expect. Assume you have a service user who has permission to update a users home directory as part of their role. When using the Windows GUI to change a user's properties, the GUI tries to protect you from yourself. For instance, if I set a user home directory, the GUI will first check to see if that share exists and is accessible. But, I'm not the matching user, so by default it isn't accessible to just anyone. Thus setting the home directory property in the GUI fails. PowerShell scripting will succeed because it doesn't do such "protection" checks - it just does what you ask it to do whether right or wrong.
The second gotcha is trying to get overly complex with where home directory data is stored. You can create some huge data structures and divisions to store the data. Doesn't mean you should - whatever you create on the storage side the user creation script must also understand. Also, the user creation script, if there are home directory paths to search, must determine on it's own which of the multiple paths might be used to create a new user folder.
Finally - you must ensure absolutely unique usernames/sharenames. This is especially true if you have multiple domains with trusts - you could easily create a dynamic share that matches the same user name in different domains to the same share name. Not likely what you want.
The online ONTAP 9 documentation center has much more info available. You can find it under the path Provisioning and protocols > CIFS management > Deploying CIFS server-based services topic Managing home directories.
I hope this helps you.
Bob Greenwald
Senior Systems Engineer | cStor
NCIE SAN ONTAP, Data Protection
Kudos and accepted answers are never necessary, but always appreciated.
