Unable to access SMB shares using network account credentials

As mentioned, I've not dealt with these versions is some time nor have I tried to replicate your environment. Please cross reference any recommendations.

A couple of points of feedback to your feedback...

1: Network user (Max)

A bound machine can support a variety of network logins. Since Max is showing as a "Network User," that means you are not doing managed mobile accounts. Since you don't mention an MDM, you likely have not create a profile to support cached account. Nor do I suspect you are using the createmobileaccount command to manually cache a network account's identity. This means that if you log out of Max's account and log back in as Edison (listed as a standard local account - means created on that machine in System Preferences), you will no longer "see" Max's account as visible on the machine. Now, one way around the lack of a profile or MDM is to use the createmobileaccount -n maxheadroom to create a stub DSLocal account for Max's account. But this does not include a cached password until the user logs in (if I recall). Oh, and you would need to do this for every network user on every machine.

The other issue with the use of Network users is that they are unable to login should the device be unable to communicate to the domain. For example, disconnect the machine from your network and Max cannot log into that machine. The only way to permit that is to make the account a mobile account (cache the identity to DSLocal).

In this case, if Edison is the active GUI user and another machine attempts to connect to ISS, you are expecting the local SMB service (which has no idea how to pass authentication to the domain) to auth a user that it only knows through the domain bind.

Now the difference with AD is that an Apple system cannot store a replica of the AD environments. This is an Apples vs Oranges challenge. When Macs participate in AD, they all start as domain clients. Even if you were using a Mac "Server" product. This allows domain users to log into the Mac client using domain credentials. Both Network and Mobile accounts are supported (Mobile to allow device access off network). Ah, but if you want a Mac to act as a domain member server in the AD world, that is where the dsconfigad -enablesso happens. This Kerberizes the services on the Mac so they are aware of how to pass authentication to the domain. Remember, in the AD mode, there are no users or credentials stored on the Mac. All auth requests are passed up the chain.

But on the LDAP side, you have the option of Master or Replica. There is no domain member option. Now, maybe you could create the required configuration files to mimic what AD service binding does, but you might need to do an AD bind to figure out all the pieces that are changed.

To demonstrate this in an OD environment (if I recall), run the following command on your OD Master:

sudo ktutil list

Now go to one of your bound clients and run the same command. My guess is that you will not see reference points to the OD server. You will likely only see references to the local machines LocalKDC.

As to your other question:

If I'm understanding you correctly, this isn't a scalable solution in an enterprise, such as a college computing lab. This would mean that to do proper peer-to-peer file sharing using network credentials, every single machine would have to be a server with its own OD replica!

I've supported and support a number of EDU and enterprise deployments. Never have we been asked to allow users to access each others machines. The fragmentation of data would be unmanageable. In general, there was always a departmental server that was controlled by IT and users would connect to it. If a teacher wanted to have something else, we often would allow file sharing with guest access and read only access to the Public folder. This would eliminate the need for user credentials but allow access to classwork or reference materials. In cases of work submission we would use the Drop Box folder (inside Public), allowing students to drop data to the teacher's system (work submission). And now, in these days, we run enforcement tools to prevent the enablement of local services (or users are standard users and cannot enable them). Plus, the use of AirDrop has greatly eliminated the need for peer to peer file sharing.

Take all this with a grain of salt. Like I said, the OS versions you are using I've not touched in a while and we are systematically abandoning Apple for file services (it pains me to admit that, but it is true). There very well may be a way to do this without making the units replicas. But you will need to figure out how to make the services on an OD bound client aware of the OD authority so the auth chain can be followed. Maybe some creative use of ktutil to manually construct the auth db?

Hope this helps.

Reid

Open Directory was designed to mimic Active Directory. And while Apple will use slightly different terms, we are still deploying a similar architecture. And, I was wrong. You don't need a replica on each machine. Apple removed the "connected to a directory system" and built the function into the bind. Who knew. In all the years of supporting this, I never had the need to enable file services on a bond machine.

After testing, I can confirm that what you are trying to do is possible and should be working in the way you defined. I just spun up a High Sierra Server and a Mojave client. And following this process, I was able to get a network user to access SMB on a bound client. Here is what I did.

Start on High Sierra Server

1: Setup DNS. In my case, one record for the server host. A record for high pointing to the IP address of the server itself

2: In Server.app, run a sudo changeip -checkhostname to confirm Server is using the proper hostname. Or using the UI to run the hostname change assistant.

3: Once the server is happy with DNS, start up an OD Master

4: Create a few users (alpha, beta), using "None - Sharing only" for home folder type

Go to Mojave Client

1: Set the DNS of the Mojave client to get primary DNS from the High Server

2: Open Directory Utility and create an authenticated bind to the High Server using the fully qualified host name of the server as the binding address

3: Confirm that the key tab has been passed to the Mojave client using sudo ktutil list

4: Create a folder to be shared in /Users/Shared/Data

5: Create an ACE targeting a network user (alpha) on the shared folder Data and set the rights to read/write

6: Go to another machine and attempt to connect to the Mojave client using smb://<ip_address>

7: Enter the OD credentials of the user alpha

8: Access to Data is granted.

The user, alpha, never logged onto the Mojave client locally. Server.app is not installed on the Mojave client. The Mojave client is simply a domain member, and if permitted, domain users could log into the machine via login window. Again, a mobility payload is required to cache the credentials for offline use.

So now the big question of why this is not working in your environment. This leads back to the concern of permissions or SACLs.

Your description of the root level folder with 777 permission would suggest you should have access. I did not emulate your folder location as future OS versions will restrict storage at the root of the drive. I opted for /User/Shared as a convenient path.

That leads back to SACLs. On the Mojave bound machine, can you do the following:

1: Run this command

sudo ktutil list

Do you see entries like:

cifs/mojave-host.local@HOST.SERVER.COM

The Mojave-host will be the host name of the Mojave client and the HOST.SERVER.COM will be the fully qualified host name of your OD Master. The all caps is the Kerberos realm name syntax.

Next, run this command:

dscl . -list /Groups

In the list of groups shown, do you see any com.apple.sharepoint.group.#? The number 1 is usually the initial admin's public folder. Run this command until you find your shared folder

dscl . -read /Groups/com.apple.sharepoint.group.#

Replace the # with the number of the group. You should get a result that includes the Real Name (name of the shared folder), and the NestedGroups GUID. Does the nested group end in 000000C? If so, that should be the Everyone group. Run this command to confirm by matching the GUID to a group name

dscl . -list /Groups GeneratedUID

If I have time today, I will redo the setup and post a video showing the results.

The good news is, you are correct. This should be working the way you expect. The key now is figuring out why it does not work in your setup.

Again, sorry for the rabbit holes we've gone down to this point. Bottom line. Don't deploy Server on your clients.

And full disclosure, I've written six books on Server. They are in Apple's Book Store. I loved Apple's Server offering and created massive scale deployments, starting with NetInfo back in the day and extending all the way through to complex Xsan deployments. Those days are all gone now. Apple has no interest in local server offerings. Last summer I shut down the last of our supported Xsans, moving 120 TB of content to the cloud. But in the process we lost our render cluster. As crazy as this sounds, the power of the M-class units are almost keeping up with the 80 cpu render cluster we had.

Ok, let's figure out what is wrong in your environment.

Reid

Ok, here is a down and dirty link of this working as you want. https://youtu.be/hPUQkQdAfyY

I took a number of shortcuts (like non-static address on server). However, the exact process you want is possible and demonstrated in the linked video. So the question is, why is your environment not working this way?

Glad to help. Your gratitude is more than enough. It was fun to go back and relive the joy and power of OS X Server. If you want a deep dive, check out my old books on the Apple Book Store. Here is the one with core services: https://books.apple.com/us/book/el-capitan-server/id1045748875. That El Cap series (3 books in total) is more than 550 pages of macOS Server infatuation. The second book in the series has over 60 pages dedicated to Users & Groups, including binding methods and all the ways a user account can be used. Oh, the days of Apple-centic server environments. I miss them.

So, to clarify, I now know what you did that caused this. You used System Preferences > Users & Groups to perform the bind. This results in an unauthenticated bind, effectively skipping the transfer of the keytab data. This can be a confusing point. And Apple has/had at least 4 ways of binding, each producing a slightly different result.

Method 1: System Preferences > Users and Groups will result in an unauthenticated bind. You effectively are able to find the server and read its public LDAP records. However, you do not participate in the domain for services (no keytab exchange). This is ideal if you have a bunch of client devices and all they need to do is allow users to log in with domain credentials. This method does NOT product a device record in OD.

Method 2: Directory Utility will result in an authenticated bind. This process has the device verify admin rights with the OD master and in the process, this does the magic of exchanging the keytab data and thus enabling service on the "client" to act as a domain server.

Method 3: The dsconfigldap command can be used to script LDAP binding. This can result in either an authenticated or an unauthenticated bind. The script method is great for a lab of devices and ARD enabled. Simply blast the command out to all devices at once and instant lab configuration.

Method 4: An MDM can also provide binding. A product like Jamf can do it a number of ways. For example, a profile can be used and this will include authentication. However, a policy with a Directory Binding payload can be either authenticated or unauthenticated.

Glad this was resolved for you. Keep at it.

Reid

This keeps running through my head and there may be a way to do this without replication. I've been digging through my documentation and went all the way back to the ancient days of 10.4/10.5 server. Yep... Doing this too long. In any case, here was a setup assistant for OD back then. Note the ability to join a domain but not as a replica.

So I kept digging and there seems to be some notes on LDAP binding should do the same as AD binding in that the services are setup to allow authentication.

Now I am beginning to wonder if the issue you are seeing is related to SACLs (service access controls). I am also concerned I am about to take you down a rabbit hole with many false starts.

And from one of my old books I found this:

“SACLs and Open Directory Replicas

Possibly one of the greatest features of Open Directory is that user access is defined on a per machine basis. Technically, it is easy to understand why. Since Apple is storing SACL information in the Local directory node, there is no way for one server to hand the information off to another server. But, the behavior is great!

We can use a simple illustration to demonstrate this. We have two servers, Wave and Curl. Wave is the OD Master and Curl is the OD Replica. Both machines are running File Services. The users created on the Master are replicated to the Replica. But just because they exist on the replica does not automatically grant them access to its services. You need to manage SACL lists on all servers independently”

This leads to looking to see if the client has the com.apple.access_smb group. However, the last time I have this documented is for El Cap (10.11). I am not sure when Apple reduced the SACL created by default but I will guess they declined with the reduction of services in Server.app. As more and more features moved to System Preferences or were outright dropped, the default SACL groups also reduced. You could try creating a group on a client called com.apple.access_smb and/of com.apple.access_afp (as at one point they were independently manageable but unified in the SACL UI as file sharing. Create the group on a Mac client, add OD users to the group on the Mac client, reboot, and try connecting with a domain user.

Again, I am throwing ideas at the wall. I hope I am not making you nuts with the suggestions and the directions.

Reid

Hey there,

First, you got some old stuff so I am going to dust off my brain and try and pull some magic out of my hat.

To summarize, you have:

• 1 Server that is the OD Master

• A number of clients that are bound to the OD server to allow mobile accounts

• On a bound client, you are adding an OD user to the ACL of a shared folder

• Attempting to log into the client with the OD user fails, but logging in with the local user is successful

I believe you have one of two issues going on...

I am going to speculate that the issue is that the Mac client cannot pass the authentication to the OD master because it is not a replica or domain server. The Macs are clients, not "servers" in the concept of the domain as they are bound to allow client access to the domain server (mobile account login, Kerberos SSO). Binding to the domain does not make the client a "server." If you were talking AD binding, then you could get away with a little dsconfigad -enablesso magic. But since this is LDAP, I don't recall a similar solution for either dsconfigldap or slapconfig. You just make replicas.

If you want to make this work, you will likely need to install Server.app on all of the devices and configure them as OD replicas. This will make each of the Macs capable of accepting authentication requests for domain users. Remember, client "binding" is to trust the client as a domain member. It is not to kerberize or otherwise integrate the services running on the client. Bindings role is to allow client authentication to the domain, not to enable additional function of services. In order to provide authentication, you need to make the units replicas. This will allow the device to forward the authentication request to the directory system while making the services aware of this additional authentication path.

For example, I suspect if you opened System Preferences > Users & Groups on the device ISS, you would see your wife's account listed as the local admin (or maybe as managed mobile). However, I am betting that Max Headroom is not in the list. This is because Max never logged into the device to establish an account record in DSLocal. Remember, mobile accounts still create a user record in DSLocal to allow for off-domain access to the machine. That is where your wife's account is and why that account can connect. When you sent Max's credentials to ISS, there is no account found to auth the user. Max is not in the DSLocal DB and since ISS is a client, not a replica/domain server, it can't pass the authentication request up the chain.

Ok, that is theory number one. The second, is permissions. One bit of information you did not provide is where the folder Temp exists. Remember that the default folders in the home folder have restrictive permissions, granting only the home folder owner to access (Desktop, Documents, Downloads, Movies, Music, and Pictures have a POSIX permission of 700 (rwx------), preventing any other user from accessing (or traversing) the folder. If the Temp folder is inside one of these folders, then only the Edison Carter account can travers the parent folder to get to the Temp folder. Setting the permissions on the Temp folder will make no difference if the user ID can't pass through the parent folders.

Now, if Temp is created in the root of the home folder (/Users/Edison/Temp), then it should have standard Posix umask of 755. That should be adequate to allow users other than Edison to traverse and reach the shared folder Temp.

Ok, with luck that all made sense and I understand what you are trying to accomplish. Outside of that, there is always the chaos of auth_authority attributes and SMB auth. But I think your OS versions are before that.

Hope this is helpful.

Reid