I have been attempting to setup FreeIPA using Rocky Linux 9.4 and have joined Windows 11, Ubuntu 22.04, and Rocky Linux 9.4 Clients. Everything seems to work correctly. I am having issues trying to join MacOS Sanoma to the Domain/REALM but regardless of what I do I can’t get the MacOS to authenticate or login with FreeIPA user accounts. The MacOS clients are enrolled in FreeIPA and I have manually configured the systems config files based on this article which seems like the most recent on the Internet. FreeIPA - Linux Guide and Hints
Does anyone have MacOS Sonoma working with FreeIPA?
Can anyone point me to a working configuration guide?
I am the maintainer of that website. My mac, running Sonoma, has no issues authenticating with my FreeIPA domain.
What exactly are you getting stuck on? Did you follow the steps thoroughly, including for “Ventura and likely newer”? Have you tried to look at the logs or run the necessary directory utility commands to troubleshoot your issue? killall -USR1 DirectoryService should put it into debug mode to generate logs for you to read in the Console app or in /var/log and /Library/Logs.
I have tried steps for Ventura and newer. I have also tried the command above and I get a message saying “No running processes belonging to you were found.” It’s really strange, I can do kinit with any user from the IPA domain and I get a valid ticket. I also get prompted when I need to change passwords and it works perfectly. When I search the directory tab on Directory Editor tab in the Directory Utility I can see the users from the domain without it being authenticated. When I try authenticate by clicking on the lock no credentials I enter are accepted. I keep getting this error “Credentials could not be verified, user name and password is invalid (5000)”. I’m not sure if the Base DN is correct. Should I be using the format (dc=server,dc=company,dc=net) or (dc=company, dc=net) Is there a way to configure the client with the dsconfigad tool?
This shows that kerberos is working. Unfortunately kerberos working does not mean the LDAP portion will work right away.
The base dn will match what your realm name is. E.g., dn=angelsofclockwork,dc=net would be mine. If you are able to see your users and groups in the directory utility, then your base dn has been configured correctly.
FreeIPA is not active directory, so that command will not work.
This might have something to do with securetoken. Typically this is established when the user first logs in at the login screen (this includes users from an LDAP and in this case FreeIPA) or when you are creating a mobile account. If you’re not able to login as an IPA user at the login screen or create the mobile account, the logs could tell you why (see log stream --process opendirectoryd). Looking at the logs would also indicate something about securetoken. It may be worth a look.
You could try to run sysadminctl -adminUser "..." -adminPassword "..." -secureTokenOn "ipauser" -password "ipapassword" and see if that helps too. I was not required to run this on my mac (it’s not in my root history). I believe this was established for me when using createmobileaccount.
I have tried the log stream --process opendirectoryd and it works really well. You were correct when you said I would see securetoken failures’. I am also seeing a lot of issues related to DNS resolution. I have removed all DNS servers in my test network except for IPA’s built-in DNS server to eliminate the other BIND servers from the problem while troubleshooting. I seem to be getting errors related to the directory BIND. could you confirm what format your security tab looks like? Is “Use authentication when connecting” enabled? Under the Distinguished Name are you pointing to an admin user or your own account to read the directory? in DN I have used the following format (uid=asmith,cn=users,cn=accounts,dc=fathom,dc=org) It accepts the account and password but I can’t read the directory and it says not authenticated on the lock icon.
I also tried your other suggestion and it says "No event, “secureTokenOn “asmith” -password “ipauserpassword””.
My security tab is completely empty. I do not have a DN set.
Perhaps this will work instead. Replace <ipa_user> with your IPA user name and <local_admin_account> with the name of the local admin user on your mac. It’ll ask for passwords interactively.
I’m not sure if these are red herrings, but they imply that the kerberos ticket at /etc/krb5.keytab is not valid. Two things I would verify is the permissions and that you can kinit with the keytab and perform an ldapsearch.
The reason the permissions came to mind is that I didn’t document the proper permissions for Ventura and higher.
What I would suggest is if you are still struggling to start completely over. You can do this by clearing out all network servers in users & groups, cleaning the krb5.conf file, and rebooting. The keytab can stay if it is valid.
I’ve found that sometimes starting clean is the best option to solving some of these problems. See below where I perform a clean macOS install with IPA authentication.
I went through my guide on a macOS VM to verify if there is a missing step somewhere.
[label@ipa01 ~]$ ipa host-add macvm.angelsofclockwork.net --force
----------------------------------------
Added host "macvm.angelsofclockwork.net"
----------------------------------------
Host name: macvm.angelsofclockwork.net
Principal name: host/macvm.angelsofclockwork.net@ANGELSOFCLOCKWORK.NET
Principal alias: host/macvm.angelsofclockwork.net@ANGELSOFCLOCKWORK.NET
Password: False
Member of host-groups: allhosts
Indirect Member of netgroup: allhosts
Keytab: False
Managed by: macvm.angelsofclockwork.net
[label@ipa01 ~]$ ipa-getkeytab -s ipa01.angelsofclockwork.net -p host/macvm.angelsofclockwork.net -k /tmp/krb5.keytab
Keytab successfully retrieved and stored in: /tmp/krb5.keytab
[label@ipa01 ~]$ chown label:label /tmp/krb5.keytab
[label@ipa01 ~]$
Bringing over the keytab, configuring kerberos, and testing. (Instead of 600, I use 640 and root:_keytabusers, I believe I forgot to document this properly)
I left PAM configured with the defaults for now. We’re just trying to login as an IPA user.
Adding one of my IPA servers to the users & groups settings. This shows green, so it’s connected.
I open the directory utility and click the “lock”. I click LDAP, click the pencil. Here I set the mappings to rfc2307 and put in my base DN. Here I purposely use cn=accounts,… because I have a compat tree and don’t want that to be used.
Clicked edit, went to search & mappings, and made the relevant changes. Also verified the search policy.
I go ahead and log out and at this point, I try to login with my IPA user for the first time. It takes a moment, but I am eventually given the beginning setup screen.
At this point, I need to create the mobile account, and make the account an admin. I also want to make sure my IPA user is allowed to perform system updates (this requires the use of sysadminctl like earlier - I don’t do this on my own mac, but I am showing it as an example).
I think I found an error with the encryption types when I use the ktutil command and I read the /etc/krb5.keytab file. It says there are two unknown encryption types.
So I ran this as suggested but I get the following error saying the user ipa_user can’t be found even though I manually do a kinit as the ipa_user and get a ticket.
macos:~ root# klist
Credentials cache: API:4A5BA7A1-6ABD-486D-9F3C-E9A72DCFD99A
Principal: asmith@COMPANYNAME.ORG
Issued Expires Principal
Jun 24 13:23:14 2024 Jun 25 12:27:46 2024 krbtgt/COMPANYNAME.ORG@COMPANYNAME.ORG
macos:~ root# /usr/sbin/sysadminctl -secureTokenOn asmith -password - -adminUser localadmin -adminPassword -
Enter password for localadmin :
2024-06-24 13:24:28.570 sysadminctl[1605:39484] Unknown user asmith
I had already added the ca.crt but tried deleting and adding it again. It adds it but then I need to manually open Keychain access and set it to a trusted certificate.
macos:~ root# sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /etc/ipa/ca.crt
SecTrustSettingsSetTrustSettings: The authorization was denied since no user interaction was possible.
This means the directory utility is unable to sync or perform searches in IPA’s directory. So the user does not exist on the system. This is likely due to a misconfiguration.
The “compat” (compatibility) tree is exactly as it sounds. It’s an entirely separate tree that is generated automagically from current users and groups in cn=accounts that is more or less for “legacy” clients that do not understand rfc2307bis. However, this tree does not provide all users and groups right away, meaning they only show up requested on a search. This is why I avoid using it on mac clients.
Ok so I managed to get everything working now by doing the following.
The issue you’re encountering is due to the presence of unknown encryption types in the Kerberos keytab. These unknown encryption types (with identifiers 19 and 20) correspond to encryption types that might not be recognized by your current Kerberos setup. Here’s a step-by-step guide to fix this issue:
Step 1: Identify the Unknown Encryption Types
Kerberos encryption types are defined by specific numbers. In your output:
unknown (19) typically corresponds to AES256-CTS-HMAC-SHA384-192 (supported by newer Kerberos implementations).
unknown (20) typically corresponds to AES128-CTS-HMAC-SHA256-128 (also supported by newer implementations).
Since these types are unknown, it suggests that your Kerberos implementation or the libraries in use do not recognize or support these newer encryption types.
Step 2: Update Kerberos Libraries
Ensure that your Kerberos libraries on the MacOS system are up to date. You can update the libraries using Homebrew if it is installed.
brew update
brew upgrade krb5
Alternatively, ensure that your MacOS system is updated to the latest version, as this can also update the underlying libraries.
Step 3: Regenerate the Keytab File
If updating the libraries does not resolve the issue, you may need to regenerate the keytab file on your FreeIPA server, ensuring it uses supported encryption types.
Login to your FreeIPA server:
ssh adminuser@freeipa-server.companyname.org
Regenerate the keytab file:
Use the following command to generate a new keytab file with specific encryption types.
So I found the above fix using Open AI. Now I have a different issue. When I reboot I am unable to login as the network account even though it’s still listed in /Users/asmith. The only way I am able to get the login working again is to run “kinit host/macos.companyname.org@COMPANYNAME.ORG” so that the host gets a Kerberos ticket. Once I have run this command as the local user and I log out and back in as the network account I am able to work as expected until I log out. I have no idea why this is happening since the account is a network account and an admin user and the IPA server is available even when I can’t log back in. Do you have any idea what could be causing this?
I tried OpenAI again to see if there were any pointers regarding the need to login with a local account to obtain a new Kerberos ticket before each network login and it said the following.
The issue where you need to manually run kinit each time before logging in suggests that the Kerberos ticket is not being automatically acquired or renewed during the login process. This typically indicates a configuration issue with how Kerberos is being handled during the MacOS login.
Here are several steps you can take to ensure that Kerberos tickets are properly managed during login:
### Step 1: Ensure SSSD is Configured Properly
If you are using SSSD (System Security Services Daemon) to manage authentication, ensure it is configured correctly.
1. **Install SSSD (if not already installed)**:
```bash
brew install sssd
Configure SSSD:
Edit the /etc/sssd/sssd.conf file to include the Kerberos domain and other settings:
By following these steps, you should be able to configure the system to automatically obtain and renew Kerberos tickets during the login process, resolving the need to manually run kinit before each login.
The problem with the above recommendations is that there is no sssd package in homebrew and there is no sssd directory on the MacOS OS.
Did you purposely add the extra enctypes to the keytab? As far as I know, types 19 and 20 shouldn’t come up unless you asked for it in ipa-getkeytab.
You shouldn’t have to do this. Ensure you have /etc/krb5.conf configured correctly.
SSSD is part of Linux distributions (EL, Fedora, Ubuntu) and is not part of macOS nor built for it. Mac’s use the directory utility and other software.
