Yikes, I did not realize the thread was so long. I posted on the community site also but just to link back, here are some thoughts.
1: You are correct in the local user (created in system preferences) can not participate in single sign on. The reason is that even though the local workstation user is UID 501 and that local admin may share the same name as the server 501 local admin, the accounts are different. They have different GUIDs. In addition, the local account on the server is not "seen" by the shared domain "Open Directory." This is why when you log into a workstation with a locally created account you must then auth to file services. While the device is trusted by the domain due to the bind, the user is unknown and thus is prompted to authenticate. This is also why in one of your examples you mentioned John Smith has a local account and a domain account. Follow this logic:
John is given a Mac. He creates the first account on the machine as is given a DSLocal UID of 501 and a GUID generated at time of account creation. His home folder on the workstation ALREADY is created and exists at /Users/jsmith. Next, his company creates an account for him in Open Directory. The Open Directory account is also jsmith but it has a UID of 1030 and a GUID generated at time of creation (GUID is generated UNIQUE id). So while John has an account in two location that based on name appear to be the same, these accounts are different based on UID and GUID.
2: Network Home Folders users (users with home folders on the server) only require binding to the domain. A simple bind will allow the user to login because the network home folder path is part of the user ID. It is that attribute that directs the machine to mount the net home share and grant access to the home folder. Now, since the account is a domain account, access to other resources is transparent because of the Kerberos infrastructure. Network Home folder users can only access the workstation when on the LAN and the net home is accessible. Network Home Folder is not a solution for laptop users (unless in a shared use environment like a school).
3: Mobile accounts. I think I know what you are missing. Mobile accounts need a bit more. First, let's take the user account.
a: If you create the account as Local Only, the proper home path will be created in the user account. For this example, let's use the user John Doe with short name of jdoe. If you make his account using Local User as the Home folder popup, then a folder is created on the server's /Users folder. I hate this and thus is why I suggest creating the account as None - Services Only and then editing the account to define a valid home path. (Yes it is more work but creating the folders in /Users on the server and auto-sharing them is a disaster waiting to happen.) In this case, /Users/jdoe.
b: Technically, that is all that is needed of the user account. Ah, now for device trust. This is binding. If you are manually binding to the OD domain you are using System Preferences > Accounts or, as I prefer, Directory Utility. This creates a machine record in OD and forms a trust between the workstation and the server. By having device trust, we assume things like DNS and time match or are within tolerance.
c: Ah, but as you are discovering, setting a valid home folder path and binding to OD is not enough... In the old days it was. You would then use OD to define MCX for the mobility payload. MCX is effectively gone, leaving Profile Manager in its place. You need to set the mobility settings allowing mobile accounts. Aha you say! How do I do that?
So you have two methods to make this happen. Both involve enabling Profile Manager. Now, you don't need to enroll your devices into profile manager (although in the long run it is easier). You can enable Profile Manager, create or manage an OD group and define the Mobility setting. Once you have it defined, you can download the profile and manually install it on your workstation. But that is a lot of work.
If you want to go the full experience, you will enable device enrollment, enroll your workstation into profile manager, and then deliver the Mobility profile to the machine. At minimum, you simply need to check the box to allow mobile accounts. (oh, take a look at the second tab and uncheck the highly annoying auto-logout feature...). Also, the ideal way to do this is to enroll the device first and use the Directory and Mobility payloads to bind the machine and enable mobile account access. It remains good to understand the individual steps but as you understand you can streamline the individual actions into a single process.
These steps are covered extensively in El Capitan Server - Control & Collaboration. The pages you want to look at are:
Profile Manager chapter starting on page 10
Enabling Device Management on page 20
Enrolling Devices on page 33
Setting policy on page 44 - Jump to My First Policy on page 42 for exactly what you are trying to do
Then there is the Users and Groups chapter that tries to cover the myriad of account types in OS X. And finally the Putting is all Together chapter has a complete walk through in the John Q Public - Managed Mobile User section.
Let me know if this helps! I missed the discussion on the forum. Sorry about that. I tried to help the community when I can. I've posted in both locations with minor variations.
Let me know if you get unstuck or if you need more help.
Reid
Apple Consultants Network
Author "El Capitan Server – Foundation Services" :: Exclusively available in Apple's iBooks Store
Author "El Capitan Server – Control & Collaboration" :: Exclusively available in Apple's iBooks Store
Author of Yosemite Server and Mavericks Server books
