Alexander suggested using ipa-advise plugin for the job: https://bugzilla.redhat.com/show_bug.cgi?id=1167994#c1

We would like to encourage any OS-X user/developer to help us with this use case!

No OS X development is necessary. I recently migrated an OS X Open Directory to CentOS 7 + FreeIPA. Mac OS X requires 3 aspects:

1) An LDAP announced through DNS-SD/mDNS.[[BR]]
2) A PLIST File in the LDAP letting it know the mappings of the schema of that particular LDAP to it's own needs. A few more config options in the LDAP such as the krb5.conf file that the clients need to have on the systems.[[BR]]
3) A Kerberos Realm or a Password Server Realm.

The Password Server interface is simple and clearly documented by Apple in the DSPasswordServerPlugin and the Linux Password Server project (LPWS). None of those are usable for FreeIPA, but they document the syntax of the simple protocol.
The PLIST file can be automatically generated.

What you can get easily:

• Authentication and Authorization
• Kerberos Single Sign On
• CA Certificate distributed to all the stations
• NSS-like provisioning of maps (auto mounts, users, groups, hosts)
• Joining the FreeIPA Realm

What requires some serious development

• PasswordServer functionality. You basically loose the ability to use non-kerberised logins to OS X servers (and file sharing in clients) that are joined in the FreeIPA domain. PasswordServer allows for a lot of SASL authentication methods such as CRAM-MD5, DIGEST-MD5, MSCHAP, NTML to be used by all the members of a domain. PasswordServer keeps the password hashes and the plain text password locally for all accounts and synchronizes the information between OD Servers. In pre-Lion versions it's an authdb file that contains the recoverable passwords and from Lion onwards it is kept in a separate OpenLDAP directory, that is only accessible through LDAPI sockets by the local PasswordServer.
• Getting OS X to request a certificate from the PKI part of the IPA.
• MCX (Apple's own Group Policy like extensions). Basically, you can store them in the LDAP, but you need to write a lot of UI to create them and I don't think that it's worth the effort initially.

I wrote the complete documentation on the migration steps needed and will attach it to the ticket if there is interest (after cleaning it up a bit to protect the client).
The documentation includes migrating Mail, Web, OpenDirectory, SMB, AFP, Calendar and Contacts from OS X. It does not include the data migration steps which were taken.

And configuration profiles are not the best idea. They are more like restriction policies and provisioning (wifi, certificates, apps), they don't cover the Identity part of IPA. Yes, you can deploy the CA through profiles, but that's all the overlap in functionality.

Proper enrollment is the way to go. OS X uses Kerberos and LDAP. FreeIPA uses Kerberos and LDAP. OS X gets the CA information from LDAP. FreeIPA publishes CA information to the LDAP. Anyone see the pattern here?

I don't think that adding ou=macosxodconfig,cn=config,dc=example,dc=com to the LDAP is complicated. It just needs an XML Plist in the description that we can easily generate.

d3vi1's comments on the list on how to set it up in details: https://www.redhat.com/archives/freeipa-users/2016-February/msg00059.html

Moving for re-triage.

This ticket is out of scope of 4.4.0 release. Moving to 4.4.1. Note that 4.4.1 needs to be triaged, therefore not everything will be implemented.

moving out tickets not implemented in 4.4.1

4.4.2 is a stabilization milestone. If this bug is important stabilization bug then please put it to NEEDS TRIAGE milestone for retriage.

I've been looking for macOS integration options for a while, is someone still working on this? I've stumbled across a python script that turns plists into profiles for deployment (https://github.com/timsutton/mcxToProfile) which might be usable to take a plist XML template, fill it with IPA parameters and use mcxToProfile to create a profile out of it.

Say you have a macOS client, you could either make ipa-client-install work on macOS, or register the computer in the WebUI and download/send the profile to the client.

On the client, it would then apply the settings from the profile and you'd have a working auth setup.

Alternatively, a native dsplug and dsaplug could be created for native integration allowing much deeper integration and automation.

It is on my plan for this summer. I have a partial plugin implementation which I plan to turn into a proper IPA CLI. Other tasks took priority, sorry.

It is on my plan for this summer. I have a partial plugin implementation which I plan to turn into a proper IPA CLI.

That's great to hear! Any chance it's in a public repository somewhere?

Other tasks took priority, sorry.

No worries! It's cool enough to know other people are working on this.

No, it is not in a usable form.

I'm also very happy to assist with testing. This sounds oh so much more scalable than the method described in https://annvix.com/using_freeipa_for_user_authentication#Mac_OS_X_10.7.2F10.8

I've been battling with the manual methods (now more clearly documented at https://www.freeipa.org/page/HowTo/Setup_FreeIPA_Services_for_Mac_OS_X_10.12) for several days and am still failing to make the LDAP GSSAPI/krb bits work effectively. I'm going round and round with can the host keytab be harnessed for the main bind and how to pass it effectively if it can indeed be used. @abbra Any updates from your end, or ways that others could collaborate on this?
Appreciate the efforts so far!

Sadly I lack the knowledge to contribute solutions to these problems but I would like to add my vote for FreeIPA to significantly improve their support for Mac clients.

As should be obvious to all but the most bigoted anti-Mac persons, Apple Macs do now have a significant representation in businesses. (IBM alone have well over 100,000 of them for goodness sake!) Whilst many businesses will be able to adequately support these using gasp! Active Directory, and whilst one might suspect this is these days Apple's preferred solution the whole point of FreeIPA one could argue is to be an alternative to AD. If FreeIPA only adequately supports Linux clients then it is missing the point.

I can certainly attest that I have seen several businesses and government departments that wish to avoid Microsoft servers and hence also AD but still need to support all the usual client platforms. Since FreeIPA does not currently deliver on this and nor does OpenLDAP this increasingly might mean SAMBA4 AD.

Whilst improving support for Windows clients is a separate topic, it should be possible for the FreeIPA project to do a lot better for Macs with a lot less effort. Basically it involves as a starting point doing what has been done by some here in particular as mentioned by @d3vi1 above.

I would suggest that since Macs are a well documented case and a common enough case that to have a simple tick box to include Apple schema related options and to auto-generate mappings and to auto-generate things like ou=macosxodconfig,cn=config,dc=example,dc=com entries would be a relatively trivial exercise. It should not impact on existing Linux/FreeBSD client connectivity.

Again as mentioned by @d3vi1 a further much needed step would be to implement the equivalent of Apple's Password Server. This I can imagine would be a bigger project despite again available documentation and even some example code in the Linux world at https://code.google.com/archive/p/lpws/ see also https://www.blueboxmoon.com/wordpress/moving-apples-passwordserver-to-linux/

As things stand it is a shame that FreeIPA does much well but lets itself down on the client support side.

Note: Any approach that involves manually configuring the clients as per https://www.freeipa.org/page/HowTo/Setup_FreeIPA_Services_for_Mac_OS_X_10.12 is clearly wrong. You should do it once on the server rather than multiple times on each of many clients. In this I again support @d3vi1

At the moment I might be looking at the ridiculous situation of using the existing FreeIPA at our company and establishing a trust to a new SAMBA4 AD for Windows and Mac clients.

PS. I can understand the need for prioritising things and that when this issue was raised originally over two years ago Macs were also less common but hopefully we can all agree more than enough time has now passed and this issue needs active consideration.

TLDR: I'm ready to help, if anyone can guide me through the FreeIPA source code. There are just things that need changing.

1) generate the cn=config given information that is already available in LDAP (such as the replicas) and information that might be available in the LDAP as well as outside such as the kerberos config.
2) Using a plugin to automatically generate some entries for each account (such as the authAuthority). The CoS plugin might do the job nicely.
3) Insert additional schema and ACIs. That would most probably be the IPA libraries specifig to the setup and upgrade parts.
4) Add a plugin to automatically publish via Avahi the correct DNS-SD entries when the LDAP server is started on both mDNS and the main DNS zone (which might be hosted in IPA). Avahi is capable of publishing on both mDNS and normal DNS.

Python is not a a native language for me, but I have no problem writing the patch if I don't have to spend a week understanding the interdependencies between the different software components and modules (389-ds, IPA, Dogtag, etc.). If anyone can tell where to insert the code, I can do it and you have my email.

I am still using FreeIPA at multiple customer sites, am current in it's usage and have the computers to experiment with everything from Tiger-PPC and Leopard-PPC64 to the latest x86_64 macOS Betas in both virtual and bare-metal form. I also have a complete repository of NextSTEP/OpenStep/Rhapsody/Mac OS X/OS X/macOS releases.

LPWS:
Regarding the LPWS, porting it to IPA would not be difficult, but it's current design is deficient. I personally would favor rewriting it in python and that's something that is not needed urgently.

The only authentication methods that you might want to publish through it are NTLM, CRAM-MD5 and DIGEST-MD5. Everything else is pretty much covered correctly even without it by Kerberos. If you have a Mac-only environment you don't actually need it since Macs correctly use Kerberos. If you have a Mac server registered in FreeIPA and publish SMB from it, you have a small problem with Windows if you don't offer NTLM methods. The good thing about NTLM is that it's easy to implement since we already have the hashes in LDAP.

Another use of the PasswordServer is the role mapping in OS X. FreeIPA roles are different in concept from Mac roles. A schema and GUI extension might be able to solve that, but it's extensive work. Specifically, you would need to assign the isAdmin role to specific groups, users, hosts combinations.

And the last use of the PasswordServer is password changing. The easiest approach, if FreeIPA supports it, is to map it to RFC3062.

Personal off-topic rant that shouldn't be included here:
If I was Red Hat, I'd go not only after macOS but also after legacy UNIX (AIX/Solaris/etc.). You can't believe how much corporations are spending on this and the perception of FreeIPA (for the ones that heard about it) is that it's a solution that works only for RHEL. And it can easily be the gold standard for Linux/UNIX.

Radius (for WiFi/802.1x/VPNs/etc.) and Samba are also poorly represented by FreeIPA. Imagine I want to setup a VPN server on a machine using IPSEC+L2TP (standard operation for the past 10 years), I need to go through pppd -> mschap -> winbind -> FreeIPA. That's a problem if it's a different server with the same LDAP DB. Two samba instances using the same LDAP DB means that they share the same SID and that requires knowing SAMBA well enough.

Having Kerberized authentication in Samba for OS X clients without an AD using LDAP is also complicated. Forgive me, but SMB2/SMB3 is now the de-facto standard for all the client operating systems (macOS and Windows). Needs some work.

Red Hat products can be at the core of the deal if they come up with a ZFS equivalent (with L2ARC like behavior and NFSv4 ACLs, for heaves sake, it's 2017) and an IPA that can handle all UNIX-like operating systems. Does anyone at Red Hat need a wishlist-roadmap? I can give one based on my experiences at Telecom, Energy and Financial institutions.

Phew...

Let me note that Solaris/AIX/HP/ux/whatever ALREADY work. The freeIPA team just doesn't provide the configuration and documentation any more because it was far too difficult to do so to a satisfactory level. The *nix OS vendors are much better prepared to handle helping their users configure authentication against a remote LDAP and/or Kerberos server.

CRAM-MD5 and DIGEST-MD5 which require storing passwords in the clear which will never happen in IPA. NTLM is rather terrible too though sometimes a necessary evil for compatibility.

IIRC if an IPA object has the sambaSamAccount objectclass then NT and LM hashes will be generated automatically.

@d3vi1 I pushed my skeleton for a plugin to https://github.com/abbra/freeipa-macosx-support. This is based on the deskprofile plugin you can find there as well, to support FleetCommander, so we know it is possible to maintain a third party plugin to core FreeIPA without much trouble.

Right now this code is only supporting python2 installation (e.g. before FreeiP 4.6) just because it only installs files into a location for python2, but that is easy to change as the code itself would be in a single python module.

You are welcome to fork this repo and provide updates. Let us move development of the module to Github and use this ticket for tracking purposes.

ACK && Forked. Busy weekend ahead!

Wow looks like I have managed to kick off a storm of activity. :)

Here's hoping we get a working solution.

@d3vi1 yes the number one need for a Password Server module is to facilitate password changing by Mac users. Password Server authentication for non-kerberised services would obviously also be beneficial. I am less concerned about being able to define admin roles 'in the Mac way'. The fact we are all here looking at FreeIPA implies we have given up on Apple servers and I therefore have long switched to a simple group membership to define users allowed to administer various services. Still the goal should be to first do the basics i.e. LDAP extension for Macs and Password Server and ultimately try and achieve everything a Mac environment would expect including roles.

Allegedly Apple open-sourced their OpenDirectory changes back to Heimdal, OpenLDAP etc. projects, it is surprising no-one has taken that to make at least OpenLDAP in to a full-blown 100% compatible OpenDirectory replacement as of yet. See also https://opensource.apple.com/source/OpenDirectory/ and https://opensource.apple.com/source/passwordserver_sasl/ In fact these days with Apple's total lack of apparent interest in server aspects you would have expected them to make it a lot easier to run a Mac environment with pure open source. Again perhaps this relates to my prior comment about Apple tacitly preferring (genuine) AD.

On a different but related topic, here we are talking about enhancing FreeIPA to be an OpenDirectory replacement in addition to 'standard' LDAP+Kerberos. The logical follow-on would be for FreeIPA to also become a 'drop-in' replacement for AD ala SAMBA4 but without needing a SAMBA4 AD setup. I would not expect 100% AD capability but something equivalent to SAMBA4 would be a great start i.e. authentication, GPO support and ability to do trusts.

We made deliberate decision to not duplicate work done as Samba AD development in FreeIPA. There is simply no need to spend effort on the same. Instead we concentrated on making sure Samba AD can talk trust to FreeIPA. This is certainly true for Heimdal-enabled Samba AD. For MIT Kerberos-enabled Samba AD there is still one bug left that prevents proper interoperability with FreeIPA. It is on our radar and is planned to work on.

Please do not use this ticket to discuss things outside macOS support. No need for that. You did also not kick off activity here -- macOS support plugin was in my 'todo' list for quite some time already, so I just shared the code that I had laying around in hope it can be used by @d3vi1.

Finally, lack of interest from Apple side is something that Apple should be addressing if they feel a need for that. There is still no clear documentation available about their setup and requirements towards LDAP schema for macosxconfig subtree. All you could do is to look up into released source code. As nobody did that before, it looks like no much incentive is there for those who can do it.

@abbra Your points about SAMBA AD are well taken. Your tip about SAMBA and Heimdal is appreciated.

@d3vi1 as I see it merely having an ou=macosxodconfig,cn=config,dc=example,dc=com and related records for advertising replicas and kerberos is sufficient. However there is also the option of using cn=schema,cn=config,dc=example,dc=com to store the entire Apple schema. Do you have any views on this?

@abbra While your points make sense, a lot of users and administrators would like to use something else, but don't have the technical skill or knowledge to integrate existing codebases. In that regard, they are much like Windows administrators, they often don't actually know their systems beyond the interfaces presented by the vendor. The need is there, but they can't help beyond asking and testing because of a specialisation differential.

In general, implementing basic functionality first is probably the most important. I have done some research into the ObjC part of the directory services plugins on the macOS side. It's actually possible to create a fully working 'FreeIPA' or 'IdM' Directory Services plugin that interacts with the OS. This way, you won't actually need the PasswordServer etc. since configuration and communication will be handled by the FreeIPA/IdM directory services plugin. The OS just calls that plugin to handle the extras where the communication behind that can just be plain REST API calls, kerberos and LDAP. No need for AD simulation either since the plugin takes care of that. AD itself is a plugin, as is Apple's own OD Server access.

While simply generating a barebones configuration profile will definitely help with initial integration, an OD plugin will probably survive OS updates and deeper integration much better. Combining the two would probably be the golden ticket.

I'd like to point out that any contribution that advances this area is welcome. I hope there is an understanding that current FreeIPA team has limited capacity to solve all issues on all fronts. Support of macOS is not on the high priority list for many reasons but most importantly because there are other higher priority tasks. I understand the frustration this may cause to macOS users and administrators but there is nothing I can do to get more resources in this area.

Implementing macOS side as a native Directory Services plugin requires an attention from someone familiar with macOS development environment and resources to maintain this code going forward. If somebody is able to provide these, I'm all for it. However, I do not see any real movement towards that, unfortunately.

Let us concentrate this ticket to the actual technical discussion. Rehashing arguments for providing macOS support is just going in cycles.

@johnkeates Whilst it is indeed possible to create directory service plugins to install on the Mac to add custom support at the Mac end and as examples this is used by Centrify and Thursby Admit I personally dislike this approach. Not only do such tools tend I would suggest to be more likely to break with Apple OS updates but I have even seen instances of them introducing incompatibilities for other network software running on the Mac that is trying to authenticate. You are welcome to develop this for your own use but I would prefer a server based solution. Another issue is that Mac management systems typically only support using OD or AD for automating setup. (For OD you can include appropriately configured LDAP servers like we are discussing here.) So if you wanting to automate building configured Macs this is another issue.

I completely agree that it should not fall on to the FreeIPA project to deliver native code for macOS, but regarding the DS plugin, I intended to develop one more geared towards the SSSD type of integration. Not replacing system functions but expanding on existing integrations. The problem is that not all functionality can be replicated using only server-side additions, especially those provided by the standard ipa-client package and sssd. This is of course mostly 'extra' functionality, and not required for basic operation.

I currently enroll macOS clients by using a combination of saltstack and preconfigured IPA profiles, while certain things could be automated more with the password server and OD schemes in the LDAP tree, some simpler things are not all that hard to do on the client side. Take AD integration for example, while basic joining just works, there are options to set mobile account creation vs. local or network, use supplied UNC paths vs. locally translated paths, set the default shell, remap LDAP fields in case the AD schema has modifications or additional fields, specific target AD servers can be set as well as keeping auto discovery, and basic administrative assignment by listing AD groups.

Taking those and implementing it on the IPA side will work up to a point. A profile can only change what controls are available, which means the LDAPv3 plugin instead of the AD plugin. The LDAPv3 has not a lot of settings, and is mostly intended for mapping. Other settings like kerberos etc. can be made using a profile, and there is some room for custom commands, but that's about it.

I think that if we want a robust implementation (which we probably do want), the first step might not actually be adding mac-specific things to the LDAP tree, but starting out with the machine account automation and profile XML generation. It is practically the MVP as it will allow semi-automatic enrolments. Getting a python based IPA CLI working on macOS could fully automate it, and since python is available by default it should not require too much porting to get it to work, but this is getting in to implementation space.

I'd like to help, I have a fair amount of macOS knowledge, sysadmin experience, but I am currently mostly active in Software Engineering and DevOps. Should we create a Wiki page or use a GitHub tracker to keep pagure clean?

As I suggested earlier, we can use https://github.com/abbra/freeipa-macosx-support/issues for this.

Hi Guys,

Let's move the chatting away from the ticket towards email and/or https://github.com/d3vi1/freeipa-macosx-support.
Anyone interested should send me an email (you have my address in GitHub and the email thread mentioned above). I'll setup a mailing list or just start a simple email thread.
We'll create a pull request to abbra once we have enough for a beta release. Until now, I've managed to transform the plists to native python dicts. On Saturday, if time is sufficient, I'll try to identify how to get the needed variables (Realm, friendly name, replicas, KDCs, etc.).

Cheers,
Răzvan

@jelockwood @d3vi1 can one of you briefly explain what is the role of the Apple Password server and why is it needed ? Something that does DIGST-MD5 should just be burned on the stake, so I would like to know exactly what requires it and why, when you already have a kdc+kpasswd service.

Think of it as a server for SASL. Back when SSL was expensive in both computing terms and financial, most services were unencrypted and they just used different authentication techniques such as DIGEST and CRAM. Since Kerberos isn’t usually available to internet facing services, they came up with the PasswordServer. It also offers additional services, but this is the main one. You would have LDAP on one server and IMAP on another, and using the password server plugin you could do any authentication method you can think of.
In the LDAP you have the authenticationAuthority attribute which dictates what is available (PasswordServer, Kerberos, iCloud, NT, etc.)

By not using it you loose two things: authentication to unencrypted macOS hosted services. Password changing using the macOS UI.

Posted from the phone, so I can’t go into more details.

Are you aware of any documentation about this password server from Apple, or source code drops from them ?

Original implementation at snow leopard level, but nothing changed since DSPasswordServerPlugin

A blog entry from a dude that ported it to Linux. The link for the abandoned LPWS is in the blog entry.

A new attempt called passwdd at implementing it in linux started from LPWS

This is where the DSPlugin for IPA would come in handy as PasswordServer isn't needed for AD, yet password changes in AD work, because the changing routines are implemented in the AD plugin and macOS just calls whatever plugin is currently used, thus bypassing the need for PasswordServer. On the other hand, this would (as discussed earlier) require macOS native code to be supplied and maintained and that is just not something we should shove towards the IPA project.

If the password changing methods can be supported in a secure way, I think it would make for a good addition, if not, the IPA WebUI is fine for password changes and a user could simply log out and back in. Additionally, the user would have to change their Keychain password manually since that is not automated if you change the password externally, just like FileVault passwords would need manual updates. Implementing PasswordServer password changes fixes that.

@johnkeates I got that point, no need to keep re-hashing it. What I wouild likje is a spec though.
@d3vi1 thanks for the source code pointers, is there any technical doc at all around this service ?

Before proceeding, grab a coffee... It's going to be a while. And I think that with this I've completely exhausted my OpenDirectory integration knowhow.

Regarding technical doc: not that I'm aware of. The LDAP glue for it is documented with links/references to the extent that I've found them in this email. The only other things that I've found are in the Mac OS X Directory Services Apple Training Guide. There's a lot of stuff over there about the usage and behavior at the 10.5 (out of 10.13) version level. Almost nothing has changed in the protocols, only in the implementation.

I've covered everything I could find about altSecurityIdentities and authAuthority as well as the relationship between NFSHomeDirectory and AppleHomeDirectory.

If you read the email from above, in the authAuthority for PasswordServer link, you also get a short description of the password server made directly by Apple. Interacting with it can be made through a telnet session as it is an interactive protocol.

Personally, I don't think the password server is needed at this stage. It only offers obsoleted SASL methods, an isAdminAccount property, as well as password changing. I'd like to proceed without it at this point and point the accounts solely towards KRB5. macOS is perfectly capable of changing an expired password also over Kerberos.

Let's go at this stage for the task that covers 90% of the functionality which is ODConfig. I've had a couple of hours and I've converted the PLists into readable and formatted python dictionaries in my fork. I've also setup a wiki over there and I am looking for some API information if you can share/guide me.

It’s also worth noting that the PasswordServer used an actual file up until and including 10.6 Snow Leopard for storing the data. It can be accessed for migration purpose using the code below:

//
//  main.m
//  PasswordServerPlugin
//
//  Created by Alex Georoceanu on 13/11/2014 for Răzvan Vilt.
//  Submitted by Răzvan Vilt to FreeIPA in public terms
//   on 28/10/2017
//  This should compile cleanly in the
//  DSPasswordSeverPlugin directory on any mac.
//  You can use it after migrating the accounts to FreeIPA,
//  to disable some of them and to set the password to the
//  previous value.
//

#import <Foundation/Foundation.h>
#import "AuthDBFile.h"

int main (int argc, const char * argv[])
{
    // Get the Snow Leopard AuthServer DB.
    AuthDBFile *file = [[AuthDBFile alloc] initWithFile:"/some/path/to/authservermain"];
    [file nextSlot];

    PWFileHeader *Header = malloc(sizeof(PWFileHeader));
    [file getHeader:Header];

    PWFileEntry *pw = malloc(sizeof(PWFileEntry));
    for (int i=1; i< (Header->deepestSlotUsed+1);i++) {
        [file getPasswordRec:i putItHere: pw unObfuscate:TRUE];
        //Use this to format the samba password hashes as LDIF
        printf("dn: uid=%s,cn=users,dc=example,dc=org\nchangetype: modify\nadd: sambaNTPassword\nsambaNTPassword: %s\n\n", pw->usernameStr,pw->digest[0].digest );

        //Use this to disable the account
        if (pw->access.isDisabled==1){
            printf("ipa user-disable %s\n", pw->usernameStr);
        }

        //Use this to set the password in LDIF format and add a random PwdLastSet.
        printf("echo dn: uid=%s,cn=users,dc=example,dc=org; echo changetype: modify; echo add: userPassword; echo userpassword: `slappasswd -s \"%s\"`; echo -; echo add: sambaPwdLastSet; sambaPwdLastSet: 1417356004;echo\n", pw->usernameStr, pw->passwordStr);

        if (pw->usernameStr[0]!=0) {
        if (pw->extraAccess.isComputerAccount!=1){
            printf("%s %s\n", pw->usernameStr, pw->passwordStr);
        }
    }
/*        for (int j=0; j < 10; j++) {
            if (pw->digest[j].method[0] != 0) {
                NSLog(@"username: %s hashtype: %s hash: %s\n", pw->usernameStr, pw->digest[j].method, pw->digest[j].digest);
            }
        }*/

    }

    //NSLog (@"Validation returns: %d", [file validateFiles]);
    return 0;
}

Starting from Lion (10.7) Server, the Password Server DB is stored in the OpenLDAP cn=authdata DN that is only accessible over LDAPI. My guess is that they went this way in order to use the OpenLDAP replication which is more reliable.

Basically PasswordServer revolves around providing an interactive TCP/IP and SASL-Authenticated session for working with the data below. If you are curious, these is the information that the Password Server provides in an actual OpenDirectory running at my home on the latest macOS High Sierra. In the content you get the AccessFeatures, Authentication Methods, Weak Authentication Methods, User accounts (that I’ve censored and replaced with „someuser”), Public Key and Password Hashes for some of the authentication methods.

# This should show everything that is contained in the password server (including DB)
imac:~ root# mkpassdb -dump
Access Features:
usingHistory=0 canModifyPasswordforSelf=1 usingExpirationDate=0 usingHardExpirationDate=0 requiresAlpha=0 requiresNumeric=0 expirationDateGMT=18446744073709551615 hardExpireDateGMT=18446744073709551615 maxMinutesUntilChangePassword=0 maxMinutesUntilDisabled=0 maxMinutesOfNonUse=0 maxFailedLoginAttempts=0 minChars=0 maxChars=0 passwordCannotBeName=0 requiresMixedCase=0 requiresSymbol=0 newPasswordRequired=0 minutesUntilFailedLoginReset=0 notGuessablePattern=0
Weak Authentication Methods:
SMB-NT
SMB-LAN-MANAGER
CRYPT
APOP

Public Key: 1024 65537 126156735362834922652669667510124737971525265977003458292838259662475941942339637701783031842665637489899899968013535474647377427038990743911664412758698759306606987798849786426049586039725915353359580583450027978985802381494661566820916379229460639580871881869418576860074704243214464804408968770344748232621 root@imac.myDomain.name.tld


slot: 0xd0e9f4d4b0e111e2b1fa00254ba69508        diradmin    04/29/2013 06:31:09 PM
slot: 0xcb5f80ac64434de8a8fe343d8d91cf40     _krb_krbtgt    01/01/1970 01:59:59 AM
slot: 0xb05bf6388ee444bb9d25766b75e0bf3b   _krb_changepw    01/01/1970 01:59:59 AM
slot: 0x482cce130a1f4d28ab2c79e65c8da74e     _krb_kadmin    01/01/1970 01:59:59 AM
slot: 0xb68e88865bac45358c6630fd2eed0716   _krb_kerberos    01/01/1970 01:59:59 AM
slot: 0x7dc0c4f6b7ec45f28755fed52d220f53  _krb_anonymous    01/01/1970 01:59:59 AM
slot: 0xd8aea44eb0e111e2b8e300254ba69508 imac.myDomain.name.tld$    04/29/2013 06:31:22 PM
slot: 0x1a4cbe54b0e211e2b8e300254ba69508        someuser    04/29/2013 06:33:12 PM
slot: 0x4d0a2912b0e211e2b8e300254ba69508        someuser    04/29/2013 06:34:37 PM
slot: 0xfc98a596b10711e291a400254ba69508          razvan    04/29/2013 11:04:23 PM
slot: 0x03f1b404b10811e291a400254ba69508        someuser    04/29/2013 11:04:35 PM
slot: 0x094e2a04b10811e291a400254ba69508        someuser    04/29/2013 11:04:44 PM
slot: 0x1e01d3f6b10811e291a400254ba69508        someuser    04/29/2013 11:05:19 PM
slot: 0x23eddb5cb10811e291a400254ba69508        someuser    04/29/2013 11:05:29 PM
slot: 0xbe619d20e9f411e2bf2f00254ba69508        someuser    07/11/2013 09:41:02 AM
slot: 0x06ffd286e9f511e2bf2f00254ba69508        someuser    07/11/2013 09:42:16 AM
slot: 0xa5ba55ce1c0211e3a22800254ba69508        someuser    09/13/2013 02:25:45 AM
slot: 0x547abdec1c0311e3a22800254ba69508        someuser    09/13/2013 02:30:39 AM
slot: 0x15d3aff09d2b11e3b22600254ba69508        someuser    02/24/2014 10:10:14 AM
slot: 0x43b8c1169f0211e3b22600254ba69508        someuser    02/26/2014 06:23:03 PM
slot: 0x4537d46ac6cf11e3b1fd00254ba69508 vpn_85ce8219e9e1   04/18/2014 10:58:47 AM
slot: 0x83259252289611e4bb0c00254ba69508        someuser    08/20/2014 09:19:24 PM
slot: 0x2ae494848ad511e4ae4d00254ba69508  razvan-laptop$    12/23/2014 08:54:48 PM
slot: 0xe5bab4128b3b11e4ae4d00254ba69508        someuser    12/24/2014 09:10:10 AM
slot: 0x413f61708b3c11e4ae4d00254ba69508        someuser    12/24/2014 09:12:45 AM
slot: 0x1d11b2029b5f11e48e8b00254ba69508      oldLaptop$    01/13/2015 10:02:34 PM
slot: 0x9b99b766039511e5b6f5c42c030d4c6f        someuser    05/26/2015 01:54:40 PM
slot: 0x88c2f7e83b4311e5a8fdc42c030d4c6f        someuser    08/05/2015 10:28:15 AM
slot: 0x468e65767f3e11e5ad53c42c030d4c6f        someuser    10/30/2015 09:41:55 PM
slot: 0x54c74e3c821811e5ad53c42c030d4c6f        someuser    11/03/2015 12:47:52 PM

imac:~ root# mkpassdb -dump 0xfc98a596b10711e291a400254ba69508

slot: 0xfc98a596b10711e291a400254ba69508          razvan    04/29/2013 11:04:23 PM
Last password change:   10/11/2017 05:21:55 AM
Last login:     10/28/2017 10:25:36 AM
Failed login count: 0
Disable reason:     none
Hash-only bit:      0
Last Transaction ID:    0
Transaction requires kerberos:  0
Record is dead: 0
Record is not to be replicated: 0

Access Features:
isDisabled=0 isAdminUser=1 newPasswordRequired=0 usingHistory=0 canModifyPasswordforSelf=1 usingExpirationDate=0 usingHardExpirationDate=0 requiresAlpha=0 requiresNumeric=0 expirationDateGMT=18446744073709551615 hardExpireDateGMT=18446744073709551615 maxMinutesUntilChangePassword=0 maxMinutesUntilDisabled=0 maxMinutesOfNonUse=0 maxFailedLoginAttempts=0 minChars=0 maxChars=0 passwordCannotBeName=0 validAfter=18446744073709551615 requiresMixedCase=0 requiresSymbol=0 notGuessablePattern=0 isSessionKeyAgent=0 isComputerAccount=0 adminClass=0 adminNoChangePasswords=0 adminNoSetPolicies=0 adminNoCreate=0 adminNoDelete=0 adminNoClearState=0 adminNoPromoteAdmins=0

Group(s) for Administration: unrestricted

digest 0:   method: *cmusaslsecretSMBNT
        digest length: 16
        digest: ABCDEF0123456789ABCDEF0123456789

digest 1:   <empty>
digest 2:   method: *cmusaslsecretDIGEST-MD5
        digest length: 16
        digest: ABCDEF0123456789ABCDEF0123456789

digest 3:   method: *cmusaslsecretCRAM-MD5
        digest length: 32
        digest: ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789

digest 4:   method: KerberosRealmName
        digest: IMAC.myDomain.name.tld

digest 5:   method: KerberosPrincName
        digest: razvan

digest 6:   <empty>
digest 7:   method: *cmusaslsecretDIGEST-UMD5


digest 8:   <empty>
digest 9:   <empty>
slot checksum:  ABCDEF0123456789ABCDEF0123456789

I have not moved on yet to trying the plugins on Git provided by @abbra and @d3vi1 which I believe are not yet finished but now that our FreeIPA system is 'stable' I have tried following the 'standard' instructions for connecting a Mac to FreeIPA as per https://www.freeipa.org/page/HowTo/Setup_FreeIPA_Services_for_Mac_OS_X_10.12

(I am testing with Sierra 10.12.6)

I have got as far as Kerberos' kinit & klist working, and also got dscacheutil -q user -a name username working. If I do sudo /System/Library/CoreServices/ManagedClient.app/Contents/Resources/createmobileaccount -v -n username this also runs with no errors and the mobile account is added to System Preferences and the home directory created in /Users.

Unfortunately when I try logging in to the resulting 'mobile' account I get the following error -

Unable to create mobile account.
There was a problem creating your mobile account.

I also get this same error if instead of using the above createmobileuser command I try logging in as a new mobile user directly via the login window.

I did find this post https://www.jamf.com/jamf-nation/discussions/13822/unable-to-create-mobile-account and the first time I tried the suggestion of deleting three sqlindex files it did work and allow logging in as a mobile user but I have not been able to repeat this success.

Anyone got any ideas?

Ok managed to fix my own problem. The FreeIPA documentation only lists mapping the following fields

You however also need the following

Changing GeneratedUID as follows also seems to help

Update: Arggh! It works the first time but then seems to go back to failing subsequent logins - even though the account has now been created on the Mac.

Hi,

I use an IPA domain since at least 2 years and the user and group management for some desktop Mac’s are done using this CentOS 7 IPA domain, but still not for notebooks because the current integration is only fully valid for the FreeBSD subsystem but not for Cocoa and Carbon since at least 10.9 (maybe already not for Core Service). E.g. for the Finder is not (as for any normal Unix application) the UID and the GID of a filesystem object the primary ID, it is the GeneratedUID of the user and of the group. I can still see that if I press ⌘I on e.g. my home directory and look at bottom in the access rights. The user will shown but for the group it shows permanently „loading…“. An „ls -la“ in a Terminal shows all properly (FreeBSD subsystem).

But now to some facts. Long time the How-To for using FreeIPA with MacOS X 10.7/10.8 was the only information on the FreeIPA sites to MacOS X integration. Now this is replaced by an How-To for MaxOS X 10.12 but unfortunately is this not based on the former 10.7/10.8 How-To instead on older ones for 10.6 and earlier. You can see that in the part "Kerberos Setup“. Since 10.7 this should not be done by /etc/krb5.conf any more.
One bug or cut&paste typo in the 10.12 How-To did you already found (GeneratedUID => ipaUniqueID) but the comparable mapping for groups are missing and there are some inacceptable and IMO also not necessary security changes described. Also is this the only How-To which also changes /etc/pam.d/passwd. All How-To’s changes /etc/pam.d/authorization, some additionally /etc/pam.d/screensaver but /etc/pam.d/passwd I have never seen before and also not changed on my systems. BTW, this changes will be lost with each „major“ upgrade (e.g. from 10.11 to 10.12). You can still logon but „klist“ shows nothing. Another problem is the described import of the SSL certificate of the IPA server. In the described way the trust can also be lost during such upgrade and to logon is possible. The better way is the command line, e.g. using this shell script (Enroll-step1-Cert.sh) as root:

cd /etc
mkdir ipa
cd ipa
curl -OL http://ipa-server/ipa/config/ca.crt
security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain ca.crt

Another mistake is IMO in the most or all How-To’s. Don’t map HomeDirectory, map only the NFSHomeDirectory! This was maybe right for pre 10.7 and is perhaps also still right if NFSHomeDirectory points to a network share. But if the home directory should be automatically created during first logon with all skeleton files and subdirectories and the right language as for a local account then map only NFSHomeDirectory as described!
The next thing which I miss in both How-Tos’s is the creation of an LDAP user as described in the FreeIP How-To’s for LDAP clients. The older 10.7/10.8 How-To was based on CentOS 7.0 and so also on IPA 3.x but CentOS 7.1 and higher is based on IPA 4.x and there is any anonymous LDAP access very limited and not sufficient for an Open Directory client!

I’m not sure if these commands:

chown root:wheel /etc/krb5.keytab
chmod 0600 /etc/krb5.keytab

are still correct because on my systems it looks in this way:

-rw-r-----  1 root  _keytabusers  2302  8 Okt 12:27 /etc/krb5.keytab

and because _keytabusers is a special internal group a mode of 640 is more logical. Now back to LDAP attribute mapping.

What I’m really wonder is that the 10.12 How-To did not restrict the SASL methods. Normal the following must be configured since many MacOS X releases:

    module options = Dict {
        ldap = Dict {
            Denied SASL Methods = Array {
                DIGEST-MD5
                CRAM-MD5
                NTLM
                GSSAPI
            }
        }
    }

but maybe this is done here automatically. Perhaps by the other order: System Preferences > Users & Groups > Login Options before Directory Utility. Normally you must edit the per Directory Utility created .plist file in /Library/Preferences/OpenDirectory/Configurations/LDAPv3/ using

/usr/libexec/PlistBuddy -c "add ':module options:ldap:Denied SASL Methods:' string CRAM-MD5“ <IPA server>.plist

etc.
Here my mappings which are working but not for group membership because since at least MacOS X 10.9 group membership will be managed by GeneratedUID (MemberGUID) in Finder an Co.

    mappings = Dict {
        recordtypes = Dict {
            dsRecTypeStandard:Users = Dict {
                attributetypes = Dict {
                    dsAttrTypeStandard:NFSHomeDirectory = Dict {
                        native = #/Users/$uid$
                    }
                    dsAttrTypeStandard:FirstName = Dict {
                        native = givenName
                    }
                    dsAttrTypeStandard:LastName = Dict {
                        native = sn
                    }
                    dsAttrTypeStandard:GeneratedUID = Dict {
                        native = ipaUniqueID
                    }
                    dsAttrTypeStandard:RecordName = Dict {
                        native = uid
                    }
                    dsAttrTypeStandard:UniqueID = Dict {
                        native = uidNumber
                    }
                    dsAttrTypeStandard:RealName = Dict {
                        native = cn
                    }
                    dsAttrTypeStandard:PrimaryGroupID = Dict {
                        native = gidNumber
                    }
                    dsAttrTypeStandard:UserShell = Dict {
                        native = loginShell
                    }
                    dsAttrTypeStandard:AuthenticationAuthority = Dict {
                        native = #;Kerberosv5;;$krbPrincipalName$;MY.REALM.DE
                    }
                }
                info = Dict {
                    Object Classes = Array {
                        inetOrgPerson
                    }
                    Search Base = cn=users,cn=accounts,dc=...,dc=de
                    Group Object Classes = OR
                }
            }
            dsRecTypeStandard:Groups = Dict {
                attributetypes = Dict {
                    dsAttrTypeStandard:GeneratedUID = Dict {
                        native = ipaUniqueID
                    }
                    dsAttrTypeStandard:RecordName = Dict {
                        native = cn
                    }
                    dsAttrTypeStandard:PrimaryGroupID = Dict {
                        native = gidNumber
                    }
                    dsAttrTypeStandard:Member = Dict {
                        native = member
                    }
                    dsAttrTypeStandard:Comment = Dict {
                        native = description
                    }
                }
                info = Dict {
                    Object Classes = Array {
                        posixgroup
                    }
                    Search Base = cn=groups,cn=accounts,dc=...,dc=de
                    Group Object Classes = OR
                }
            }
        }
        function = ldap:translate_recordtype
        template = LDAPv3
        attributes = Array {
            objectClass
        }
    }
    trusttype = authenticated

And the LDAP bind is done authenticated using a special LDAP sysaccount (see https://www.freeipa.org/page/HowTo/LDAP).

@abbra & @d3vi1
IMO the simplest way would be to use the compat tree and generate the missing attributes as group-memberguid by the Schema Compatibility Plugin as already done there for clients which supports only RFC 2307 schema and not the RFC 2307bis schema. But either some expert from this plug-in does that or gives us an explanation what is currently happens there e.g. for groups:

dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config
cn: groups
createTimestamp: 20150726130601Z
creatorsName: cn=directory manager
modifiersName: cn=Directory Manager
modifyTimestamp: 20171008191935Z
objectClass: top
objectClass: extensibleObject
schema-compat-container-group: cn=compat, dc=...dc=de
schema-compat-container-rdn: cn=groups
schema-compat-entry-attribute: gidNumber=%{gidNumber}
schema-compat-entry-attribute: %ifeq("ipaanchoruuid","%{ipaanchoruuid}","objectclass=ipaOverrideTarget","")
schema-compat-entry-attribute: memberUid=%deref_r("member","uid")
schema-compat-entry-attribute: ipaanchoruuid=%{ipaanchoruuid}
schema-compat-entry-attribute: objectclass=posixGroup
schema-compat-entry-attribute: memberUid=%{memberUid}
schema-compat-entry-attribute: %ifeq("ipauniqueid","%{ipauniqueid}","objectclass=ipaOverrideTarget","")
schema-compat-entry-attribute: %ifeq("ipauniqueid","%{ipauniqueid}","ipaanchoruuid=:IPA:….de:%{ipauniqueid}","")
schema-compat-entry-attribute: objectclass=ipaexternalgroup
schema-compat-entry-attribute: ipaexternalmember=%deref_r("member","ipaexternalmember")
schema-compat-entry-rdn: cn=%{cn}
schema-compat-ignore-subtree: cn=dna,cn=ipa,cn=etc,dc=...dc=de
schema-compat-ignore-subtree: cn=topology,cn=ipa,cn=etc,dc=...dc=de
schema-compat-restrict-subtree: dc=...dc=de
schema-compat-restrict-subtree: cn=Schema Compatibility,cn=plugins,cn=config
schema-compat-search-base: cn=groups, cn=accounts, dc=...dc=de
schema-compat-search-filter: objectclass=posixGroup

Especially the ifeq lines, because
1. IMO should %ifeq("ipauniqueid","%{ipauniqueid}“ always true or is there a site effect if in base the attribute is not set then NULL == NULL returns false?
2. Why is „objectclass=ipaOverrideTarget“ added if ipaanchoruuid is equal ipaanchoruuid and also if ipauniqueid is equal ipauniqueid?
3. Why is ipaanchoruuid set to the value of the base (when is this be set?) and later it will be set to "ipaanchoruuid=:IPA:….de:%{ipauniqueid}“?

Maybe the doc of the plugin is not complete. Who can give us a deeper description what is happen here? I will not simple copy it without understanding it.
We need at least something like

schema-compat-entry-attribute: apple-group-memberguid=%deref_r("member","ipauniqueid“)

There would be IMO also a possibility to generate the full apple-user, apple-group and apple-computer class objects via this plugin instead to implement a fully new one. But for computer there would be the question: is the compat tree writeable? A full functionally join creates the computer object.

Br,
Silvio

@sw4fas

Thank you for taking the time to reply. Yes your right the 'official' article is full of errors.

I have tried some of your suggestions but still at best not getting any further than I had reached i.e. I can get the first login of a user to work and to generate a mobile account with the home directory on the laptop but subsequent logins fail as I reported.

As far as I can see however Kerberos is working fine. Regarding your comment about the official document being wrong with regards the chown and chmod commands you are partially right and they are partially wrong. Their commands should be being applied to /etc/krb5.conf and not /etc/krb5.keytab in fact if things are working properly you do not need to manually create a keytab file as binding to the LDAP/Kerberos server once you have a valid krb5.conf will result in a keytab file being created automatically and with the correct ownership and permissions.

Kinit and Klist work fine for me repeatedly.

My biggest problem is that I cannot get a secure binding to work from the Mac for LDAP. I can only get unauthenticated binding to work. I also seem to have discovered a bug in Apple's software here. If you untick the 'Use authentication when connecting' option in Directory Utility it does alter the LDAP config file to say 'trusttype = anonymous' but it leaves the 'trustaccount = "someone"' still set and as a result DOES still try to do an authenticated bind which of course still fails. I find I have to do 'defaults delete /Library/Preferences/OpenDirectory/Configuration/LDAPv3/myserver.mydomain.com.plist trustaccount' to fix that. (I am running Sierra 10.12.6)

I have tried using for the authenticated bind both an account in cn=users,cn=accounts,dc=mydomain,dc=com and in cn=sysaccounts,cn=etc,dc=mydomain,dc=com neither worked.

The account in sysaccounts was created as per the instructions you pointed me to although with a different username chosen.

At this stage I am not using SSL for this on the Mac but have installed and trusted the rootCA from the FreeIPA system. As I recall even a non-authenticated bind with SSL also fails.

I get the impression you have got further than me and do have authenticated binding working. Do you also have mobile accounts working including after the first login? Can you give any more details of how you achieved this?

So far I would rate the Linux support of FreeIPA as good, the features e.g. DNS, PKI as good but the Mac support as an utter failure and completely unusable. This is these days inexcusable as Macs are no longer a rarity. One would expect a lot better from a supposed professional organisation like RedHat.

UPDATE:
I had tried as mentioned two different accounts for testing authenticated binds from the Mac to the FreeIPA system and these had not worked for this purpose although they worked for example for Apache. However I just got our FreeIPA administrator to try his master admin account from FreeIPA and it seems that account is working for binding, even better this looks like it might have fixed second and later logins for mobile accounts as well. He is now going to look at what permissions issue might be present on FreeIPA. Progress!

@jelockwood

I'm not sure what you try, but an automatic join is not possible in my environment, because for that you must extend the IPA LDAP first. Which should be done by the plugin on Git provided by @abbra and @d3vi1 if it is ready to use. This plugin is otherwise IMO based on https://www.redhat.com/archives/freeipa-users/2016-February/msg00059.html (link was already provided by @abbra 2 years ago in this thread).

Did you or you IPA domain admin added such Apple specific configuration to your IPA LDAP? Otherwise you can not join, you must use LDAPv3 with own mapping. The LDAP system account will be specified on the third tab of the LDAP configuration (Security - but I expect you know this)).
Otherwise has this LDAP system account only read rights. If you will join a system then the used account must have the add computer role in IPA. If that really works then you are right and no local Kerberos configuration and key tab is needed because in this case
1. the Kerberos config will be provided by the apple-configuration LDAP object provided by the LDAP server to join
2. the computer object & account and also the corresponding key tab is created by the join, transferred to the client and IMO than included into /Library/Preferences/OpenDirectory/Configuration/LDAPv3/myserver.mydomain.com.plist and not as separate file but I'm not sure. To check that I must have an Active Directory, join a Mac to that and check then the resulting plist file ;-)
If a computer is really joined (automatically with the Join button) then the Computer Account credentials will be used for LDAP queries and no additional account must be specified in security tab for binding.

That kinit works is fine but this is the FreeBSD personality. As I wrote since 10.7 the guides to integrate a Mac Client in a Open LDAP or FreIPA environment says that /Library/Preferences/edu.mit.Kerberos should be used instead /etc/krb5.conf.

Now to Mobile Accounts: as I wrote I have currently only desktop Mac's "joined" and so a "Mobile Account" was not really needed. Today I have checked it with a newly created IPA account (because I use local and no network Homes I was not sure what happens in such case). I simple following https://support.apple.com/kb/PH25671?locale=en_US and it works.

Maybe should we check your myserver.mydomain.com.plist if you have still problems.

Ok some further progress @sw4fas and a new road block.

With our live FreeIPA system I have a set of config files in particular a hand built /etc/krb5.conf and a plist for OpenDirectory which I can pre-install on a Mac. The OpenDirectory plist is configured to use authenticated binding and map fields and I have worked out a script to automate adding the matching password to the System Keychain for the binding.

With this I can have a Mac automatically built and get the login screen to allow using network accounts to login and create a mobile account, once logged in a user can use System Preferences to change their password and this works and is synced back to FreeIPA - presumably via Kerberos.

What does not work is if the users password has been reset and requires them to change their password immediately at the login screen, they get the expected dialog but attempts to enter a new password always fail. I am presuming this is because no Kerberos ticket has been created at this stage and without Password Server there is no fallback method.

I have moved on to trying @d3vi1 approach of adding the Apple schema and related settings to FreeIPA so that in theory you do not need to add pre-built config files on the client Mac. I have worked out how to use ldapadd to add the ldif files and now get cn=config showing up when I use an LDAP browser. However some problems still remain here. Firstly Snip2 section from @d3vi1 article just does not work for me, it complains that authAuthority is not defined. Other articles for OpenLDAP suggest this might be due to a need to install a samba schema but due to the significant differences between OpenLDAP and FreeIPA I do not think it is as simple as importing a samba schema.

If I can get either cn=config to work or for someone to provide a working plugin that generates/populates it as per https://github.com/abbra/freeipa-macosx-support I am willing to work with my colleagues to try and get a working PasswordServer implemented based on https://github.com/mmpestorich/passwdd/wiki/Overview

By this I mean if I can get help so that as per @d3vi1 article it is possible for an unconfigured Mac to bind to FreeIPA and automatically configure itself via cn=config then we - my company can move on to getting PasswordServer ported.

PS. Mobile accounts mean the user account is created locally on the users computer and the home directory is stored on the users computer and password changes are synced to the directory server, network accounts mean the account is only on the directory server and the home directory is on a file server, Portable Home Directory accounts are like Mobile accounts but the home directory is synced between the users computer and the file server. Portable Home Directories are not supported in Sierra or later.

@sw4fas and @jelockwood

So we are also running into some issues with FreeIPA and local mobile accounts on 10.13.3 (High Sierra).

Can one of you confirm that you have the following working? Connecting a 10.13.3 or higher device to FreeIPA server, logging into the user account, able to convert the user to an Admin and then use the Apple defined button to create mobile account. (we have this confirmed and working) however if we disconnect from the network, no longer having access to FreeIPA and try to login to the device with the Mobile user account it always gives the password shake. Mobile users are not Mobile, the user account is created, the home directory is on the unit however there is no way for the user to Login. We have used the standard instructions for setup, however the IPA servers are currently running the 3.x versions and not 4.x. If someone can verify this is working, then we can take the info to our infrastructure engineers for requesting upgrades on the IPA servers.

Oddly of course, this all worked fine in Sierra but broke soon as High Sierra was released.

@d3vi1 can you comment on if your method is still functional in MacOS 10.14 and current versions of FreeIPA? We've been using the official guidance on the FreeIPA wiki for years and have nothing but issues and were thinking about building a test lab to test your method.

Also, it sounds like you do consulting work, would you be interested in implementing the necessary functionality into FreeIPA as a paid project? It seems that there was discussion of a FreeIPA plugin for this purpose that never took off.

macOS Catalina now requires integrity protection disabled to modify the LDAP configuration plist, and therefore change the SASL configuration.

I'm not sure how this will affect systems that are upgraded, as the system I'm attempting to bind is a new install.

@adambishop
Thanks for the information, however I have pretty much given up on using FreeIPA with Macs. I managed to get a Mac bound with all the needed field mappings and pretty much everything except one item working. This involved copying a Kerberos config file, copying a pre-built LDAP config file during a Mac build process.

A user could login and successfully change their password via System Preferences -> Users & Groups.

The one thing that would not work was if their user account had the password reset with the need to immediately change it on login. Because at the login screen they have not yet logged in they have not yet acquired a Kerberos ticket and hence cannot change their password via Kerberos. FreeIPA of course does not include Apples Password Server, as a result they get stuck at their login screen.

The process also of having to copy pre-built files is also undesirable although it might work even with Catalina since my build process modifies the drive from a different boot environment using DeployStudio.

Really the FreeIPA team need to do at a minimum the inclusion as standard of a Mac compatible LDAP schema, I could not get the OpenLDAP one to work with FreeIPA. Ideally they would also port Apple's Password Server which is free open source code.

Oops! Apple have removed the OpenLDAP and Password Server code from their open source site. Hopefully someone still has it.