You can make a difference in the Apple Support Community!

When you sign up with your Apple Account, you can provide valuable feedback to other community members by upvoting helpful replies and User Tips.

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Unable to access SMB shares using network account credentials

My environment is a home network with six Macintosh computers (the hardware isn't relevant). One machine runs macOS High Sierra Server as an OD master, and the five client Macs are all bound to this server, with one running High Sierra and the rest running Mojave. Everyone in the home logs onto his/her respective Mac using a network login account on the OD master. We have a couple of SMB file shares on the server, and everyone connects to those shares using their respective network login account credentials (i.e., server-based SMB shares are secured by adding users' network accounts from OD to the ACL). This works great, and has always worked great since I originally set it up clear back on Snow Leopard. Or was it Lion? Anyway...


What does NOT work--and has never worked--is if a user shares a directory on their client desktop Mac, and assigns someone's network account credentials to the ACL. When this is done, the specified user's network credentials appear to be accepted (authenticated), but they are denied access to the share with the error, "You do not have permission to access this server." This happens even with the Login Option set to "Allow network users to log in at login window" option set, and the option for All Users chosen.


Here's an example. On my wife's iMac (computer name "iss") she has a shared folder called "Temp". She has added Read/Write permission for the user Edison Carter, which is a local account on her iMac, as well as for the user Max Headroom, which is a network account in OD on our High Sierra Server. Here's a shot from sharing Preferences Panel.



When I attempt to connecting to the file share from my desktop iMac, when prompted for credentials if I specify the account credentials for the account local to my wife's iMac Edison Carter (ecarter), I can connect and access the folder with no difficulty. However, if I specify the network account from OD Max Headroom (maxheadroom), I see this.



I've tried embedding the username/password in a string "smb://username:password@iss..." in the Connect to server dialog and I've tried specifying things with the mount command in Terminal. I found an article that recommended that I make sure NTLMv2 was enabled in OD (it is). As I said previously, I think it's authenticating the username and password correctly because if I specify a bad password or username, the credential prompt dialog "shakes me off" as expected with a bad username/password combo and I don't get the above error.


Again, these are all Macs, all either High Sierra, Mojave, or Catalina. There are no Windows machines involved, and no Active Directory, the is purely Apple's Open Directory implementation with High Sierra Server.


This problem has driven me nuts for years. I've always had to work around it by either putting shared data in a share on the server (where network account credentials seem to work just fine with file shares), or else share the folder on a client Mac use the credentials of an account with local admin rights (which is clearly non-optimal).


I would appreciate any suggestions anyone may have. Surely, I must be overlooking something obvious but I'm ****** if I can figure out what.

Mac mini, macOS 10.13

Posted on Jan 7, 2023 3:05 PM

Reply

Similar questions

12 replies

Jan 8, 2023 11:44 AM in response to original_jeff

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

Jan 10, 2023 6:42 PM in response to Strontium90

OK, time for some full disclosure here...


My day job for the last 30 years has been as a system administrator. For the last 25 of those years, I've been supporting Windows computers in Active Directory domains. For about the last 10 years, I've given up using Windows computers at home and switched totally and completely to Apple computers in an Open Directory domain. Though I've had formal training and practical experience with Windows/AD, my Apple/OD experience has come exclusively from tinkering at home, and trying to extrapolate bits of the Apple/OD ecosystem to what I know about the Windows/AD ecosystem.


In the Windows/AD world, I'm used to having one or two servers hosting copies of the Active Directory. These are typically referred to as Domain Controllers. All the other computers that participate in the domain security are either member servers, or clients. However, neither member servers nor clients host a copy of the AD. Both types of machines connect and bind to the domain by authenticating domain computer accounts to the AD, and users can log into both types of machines by authenticating domain user accounts to the AD. When member servers and clients need to authenticate a user, they examine the credentials to determine if they are a local account or a domain account (i.e., specified as either <localhost>\<username> or <domain>\<username>, or one of a couple of variations on those themes). Local accounts are authenticated against the local account database, whereas domain account are passed to the nearest Domain Controller for authentication.


So I guess my first question is: is that effectively the same model for the OD Macs? I have been assuming all along that it is.


Now, when I establish a file share on either a Windows/AD member server or a client (no local copy of AD), I can secure it with an ACL that contains local accounts, domain accounts, or a combination of both. When a user on another client computer attempts to connect to the file share on either the member server or the client computer, the user initiating the connection can specify his credentials. If those credentials are specified as a network account, the member server or client hosting the file share passes the credentials to the nearest Domain Controller which authenticates them and passes back an access token. At that point, the member server or client allows the user access to the file share.


So I guess my second question is: is that effectively NOT the same model for the OD Macs? I have been assuming all along that it is, but that's clearly not the behavior I'm experiencing and if I'm understanding what you're writing, that is in fact not the case for OD Macs.


My final question would be, if there is such as thing as "best practice" for a case like this, what's the "best"/"easiest"/"most straight-forward" approach to getting a behavior for my OD Macs that loosely approximates that of the AD Windows machine? Installing server and putting an OD replica on everything seems a bit heavy-duty. From the screenshot you provided, it would seem like either the Standalone or the Connected to another directory server options would be correct, but it isn't clear to me (A) which option, and (B) if either option is even supported anymore given that I'm running High Sierra as my OD master. (I'm still on High Sierra because, frankly, we're still heavy users of the DCHP, DNS, OD, Contacts, Calendar, and VPN server services, and I still rely on the GUI server manager tool.)


Let me also add how much I appreciate all the time and effort you've put into responding to me. This is a valuable learning opportunity for me and I very much appreciate it!

Jan 11, 2023 6:20 AM in response to original_jeff

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



Jan 11, 2023 4:47 PM in response to Strontium90

The four steps you outlined for the Hight Server and the eight steps for the Mojave client are essentially consistent with my environment. I even changed my shared folder to be /Users/Shared/Data (with 777) like yours, just to eliminate any possible problem with sharing a folder in the root of the filesystem.


Now, on the Mojave client, the sudo ktutil list returns lines like the following. None of them contain the name of the High Sierra OD master.


cifs/LKDC:SHA1.CEC0DA59F67726AD1C3488C47A153C04ACFFE51A@LKDC:SHA1.CEC0DA59F67726AD1C3488C47A153C04ACFFE51A


I'm unaccustomed to reading the keys in a keytab file, so I'm uncertain if the above is correct, but they don't seem to match what you suggest they should say, because none of them reference the High Sierra Server OD Master. In fact, if I run the same command on the High Sierra Server (hostname "constitution"), I see a mixture of lines, some like this:


cifs/LKDC:SHA1.1B5260B16D501D35089950396D63539FC508968A@LKDC:SHA1.1B5260B16D501D35089950396D63539FC508968A


But some look like you suggest:


cifs/constitution.mydomain.com@CONSTITUTION.MYDOMAIN.COM


In fact, I looked on three of bound Mojave clients in my home, and none of the keytab files on any of them contained keys with references to the OD Master server. They all contained only keys that started with "LKDC".


When I run dscl . -list /Groups I see nine sharepoint.group.# groups, sequentially numbered 1 thru 9.


Running dscl . -read /Groups/com.apple.sharepoint.group.# for group 9 correctly identifies my shared folder, and yes, the NestedGroups value ends in 0000000C. 


And yes, running dscl . -list /Groups GeneratedUID for the NestedGroup ID for group 9 confirms that it matches to Everyone.


I see you've posted a link to a video, so I'm off to study it for any additional clues—although I'm curious to know if that keytab file on the Mojave clients are correct, given that it has no keys that reference the High Sierra Server OD Master.


—Jeff

Jan 12, 2023 7:45 AM in response to original_jeff

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

Jan 8, 2023 9:46 AM in response to Strontium90

Reid,


Thanks for taking the time to provide such a thorough reply. Let me respond to a couple of things in your post.


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


Yes... but to clarify that last point: I can log on to the client with the network (OD) user credentials at the login window on the client. When I do, and I open the Users & Groups preferences panel, I see the network (OD) user correctly listed under Current User as a "Network User" (in this case, Max Headroom). Here's a screen shot.



Also, when I'm attempting to connect to the file share on the client computer from another client computer, and I specify the network (OD) user credentials (Max Headroom), it appears to accept the credentials--it doesn't do the shake-off thing that the prompt dialog does if you input invalid credentials, or an incorrect password. IOW, it looks to me like the Max Headroom credentials are accepted and authenticated, just like the local account (Edison Carter). It's just that in the case of local Edison Carter account, clicking OK open a finder window display the shared folder, but for the network Max Headroom account, clicking OK opens the error dialog.


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.


Ouch. How certain are you of this? I'm asking because, based on my experiences, that seems counterintuitive. 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! That... just doesn't seem right to me. In my experience with Active Directory (and yes, I realize AD and OD are different animals), you don't need to make every machine a member server with a copy of AD in order to share resources using network credentials. Is this really the way it has to be done using OD?


No shot at Reid, but can any other readers out there verify this?


Final point:


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.


Good point. Shame on me for not being more clear! In this specific case, the shared folder, Temp, is in the root of the filesystem, ie., /Temp. The POSIX permissions are 777 (rwxrwxrwx), so there should be absolutely no reason for it to be inaccessible.


Thanks again for your post.


--Jeff


Jan 8, 2023 4:54 PM in response to Strontium90

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



Jan 11, 2023 5:32 PM in response to Strontium90

Ooh! Ooh! A clue!


I was more or less step-by-step in sync with you all through the video, right down to performing the same DNS checks with nslookup, and everything seemed right, UNTIL...


At 10:35, after binding the client Mojave-two to your domain, you used Directory Utility to do an LDAP query for the computer objects in the domain, and clearly saw both the High Sierra OD Master (high.carbontechnology.com$) and the Mojave client (Mojave-two$). I don't see any of my supposedly bound clients! There ought to be five! Here's my server:



And yet, on all of my Mojave clients (the screenshot below is from one of them named "iss"), if I look the Users & Groups preferences panel, I see this:



...which I always took to mean a successful binding (green light... correct OD Master... successful?). Also, if I look in the Directory Utility, select LDAP, and click Edit (the pencil icon), I see this:



...which I always took as further evidence of a successful binding.


I'm going to go back and finish watching the rest of the video, but I'm hoping this is all sufficient evidence that NONE of my clients are in actuality properly bound to the OD Master, and enough clue that you can help me figure out what the bindings appear to be happening, but actually aren't.


--Jeff



Jan 11, 2023 6:19 PM in response to original_jeff

OK, for Reid and anyone else following along, here's how this turned out.


My High Sierra OD Master was properly configured. All of my Mojave clients were properly configured to use my High Sierra OD Master as a Network Account Server. This means the OD Master server was correctly set up, and my clients were correctly set up, so that any network account could be used to log in to any client. From my example above, this means the user Max Headroom could log into any Mojave client computer using his network account credentials. He didn't have to have a local account or a profile pre-configured on the clients. This was evidenced by the fact that the Users & Groups preferences panel, Login Options screen showed a little green dot next to the name of my OD Master server:



Also, when I went into the Directory Utility, selected LDAP and clicked Edit, under options I saw a line item that also referred to my OD Master server:



However, in spite of all this, none of my clients were actually bound to the OD Master!


The first clue that this was the case was when when I listed the keytab on each client with sudo ktutil list and NONE of the keys had a reference to the OD Master server. The second clue was when I used the Directory Utility to browse the Computer--uh, is it called an "OU" in OD, as it is in AD?--and I saw only my OD Master, and NONE of my supposedly bound clients.



So at this point, I went back into the LDAP service on a client, clicked Edit, and under options, I selected the existing configuration for my OD Master server and clicked Edit. On the Connection tab, I clicked the Bind button, provided the requested credentials, and completed the Bind process.



After I did this, three things happened. First, the Bind button disappeared from the Connection tab. Second, the keytab contained additional new keys that referred to the OD Master server. Third, the machines began appearing in the Computers OU in OD (notice the addition of iss$ and discovery$ below).



So, I think that's it! That's what was wrong, and that's how I fixed it. I suppose the only remaining question is why this happened in the first place. It must be that the processes of assigning a Network Account Server, and Binding to the OD Domain are actually two separate processes. I must have assigned a Network Account Server and assumed that the act of doing so also bound the client to the domain. It would never have occurred to me that these two concepts were separate because I don't think there's an analog in AD... I'm not aware that its possible to have a Windows machine that can authenticate network accounts to log to a client, without also having that client bound to the domain. Perhaps someone else can comment on this.


Reid, my friend, I can't thank you enough. You put a LOT of time and brain power into helping me solve this and I really appreciate it. Your video tutorial was absolutely top notch, massively professional, and when I saw you reference Carbon Technology I suddenly remembered that I think it was some of your video tutorials on YouTube that helped me with parts of my original setup years and years ago.


Thank you VERY MUCH. Would you happen to have a PayPal account? I'd love to, uh... "buy you a beer". Or perhaps there's some other way I can express my gratitude?


--Jeff

Jan 7, 2023 6:47 PM in response to original_jeff

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





Unable to access SMB shares using network account credentials

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.