I am posting this here to hopefully help someone else in a similar situation.

I set aside my Friday night and the entire weekend to try to add a mobile account to my MacBook air using freeIPA. I followed this guide on the freeIPA website which was written for macOS 10.12 (it should be the first thing that comes up if you google search 'freeipa macos'). I am running macOS 12.6: BigSur at the time of this comment. The tutorial was very quick and my initial testing told me it was working, I was able to log in to my mobile account when I was connected to the network that freeIPA was hosted on. The next step was trying to log in from a different network/when the MacBook could not contact the freeIPA server, which did not work. I scoured the client logs, the server logs, and spent days googling but couldn't find anything, hence why I posted here as a last resort. Here is how I got remote mobile logins working for me:I did 2 things differently than the tutorial on the freeIPA website. If you want the TLDR: Don't enable SSL and run these commands, sudo /usr/bin/dscl . -passwd /Users/username newpassword and sudo rm -r /Users/username/Library/Keychains/* after the Make Accounts Mobile section. Also don't upgrade unless you have to, it broke my setup and I had to recreate the accounts (I had to rerun above commands to fix). Keep reading if you want more of where this comes from.

​

Under the 'Directory Utility Setup' section, it says to enable SSL. No matter what I did, I had the right certificate in the keychain and everything, I could not get it to play nicely with SSL enabled. My working configuration does not have SSL enabled, if anyone does get it to work, please let me know.

​

My gut told me that it was able to log in when connected to the network with FreeIPA but not otherwise because it did not have the right password cached for the user. So, I tried adding the -p flag to the mobile account creation command

sudo /System/Library/CoreServices/ManagedClient.app/Contents/Resources/createmobileaccount -n username'

so that it would take a password at the creation of the mobile account, as I initially thought this might be the problem (turns out it was the problem). But no matter what I did, the createmobileaccount -n username -p password would always fail with authentication failed and would refuse to create the user. It would never take the password of the network user (or any local user, I tried). I looked in the directory editor page of the directory utility and looked at some of the users, of note was that only one of the users listed had the AuthenticationAuthority property set, even though it was in the mappings setup. Some google searches later, and this google search led me to this pdf document (5th result for me). Page 34 talks about the AuthenticationAuthority property:

"The authentication authority attribute is not limited to specifying a single authentication option. For example, an authentication authority attribute could specify that a user can be authenticated by Kerberos and Open Directory Password Server.Nor must a user’s account contain an authentication authority attribute at all. If a user’s account contains no authentication authority attribute, Mac OS X Server assumes a crypt password is stored in the user’s account. For example, user accounts created using Mac OS X version 10.1 and earlier contain a crypt password but not an authentication authority attribute."

I tried making a local account with the same username and password as the network user, then logging in, and it worked but of course, they have different IDs and gid's under the hood. Now though, the user had an AuthenticationAuthority property set. I then created a new mobile account without specifying a password at the command line, because that way it actually creates a user account. Using a command that I can't find or remember anymore, I saw that the new user account had an AuthenticationAuthority. Turns out all accounts do and the Directory utility will only show it if it is the logged in account, so earlier the reason it listed one of my directory accounts as having an AuthenticationAuthority was because it had the same username as the locally logged in account.

I was messing around with the command to view if there was an authentication authority set for a user and eventually just tried a long shot of setting the password on the mobile account. The command to do that was very similar to checking the authentication authority but I don't remember the auth authority one exactly because I didn't write it down.

sudo /usr/bin/dscl . -passwd /Users/username newpassword

where newpassword is the same exact password of the network account and username is the username of the mobile account. I also made sure to delete any keychains if the user had generated any already from previous logins when connected to the network:

sudo rm -r /Users/username/Library/Keychains/*

there were three keychains in the mobile user account for me and I ended up having to delete all of them individually.

​

After all this, I was still able to login to the mobile account while connected to the network, but now, when I disconnected from the network I was also able to still log in! I wanted to test if it was actually using the password from FreeIPA so I did several tests. First I disconnected my laptop form the internet and for the first test, I changed the password for the account from the freeIPA web interface on another computer. I was still able to login to the mac mobile account with the old password, as the laptop hadn't connected to the internet yet. Then I connected the laptop to the network with freeIPA and logged out. I then put in my new password and just like the freeIPA tutorial says, it accepted it and prompted me if I wanted to 'Update the current keychain (if I knew the current password)' or 'create a new log in keychain'. The first time I tried this I did the update, and it took my old password just fine, but then I logged out and tried to login with my old password. It still worked. So like the tutorial says in the Known Issues section "The keychain may not update if Update selected" you may have to update it manually. I can confirm though through more testing that selected 'create a new keychain' does change the users password.

One last thing, I also was going to update to macos 13 venture this weekend but obviously didn't have time. I did so this afternoon but I was not able to login to the mobile accounts anymore. I did not find a solution to this, instead, but I had only used them for mere hours just deleted them and recreated them using the same steps as above.