[Freeipa-users] Apple OpenDirectory Integration

["Răzvan Corneliu C.R. VILT"]

> On 4 feb. 2016, at 12:16, Rob Crittenden <rcritten at redhat.com> wrote:
> This is very cool and excellent work!

Thanks. I've done most of the R&D 1 year ago for a client that has a medium Mac-only network. Since a year passed, I wanted to share my results in order make sure that the information won't be lost or obsoleted. Furthermore, FreeIPA is a wonderful piece of software that is making the life of admins around the world easier and due to BYOD policies Macs should get more love.

> Currently the FreeIPA wiki points to http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8 for instructions on configuring MacOS. Are these sufficient to match what you've accomplished?

Nope, what I've accomplished is different. I've managed to get OS X clients to register to the IPA server like it's an Open Directory Server. No command line interaction on the clients at all. No need for manual keytabs or manual file editing or PAM modules or Apple scripts. Just click join in the System Preferences -> Users Preferences Pane.

>> A 389 Directory Server plugin that generates altSecurityIdentities and
>> AuthAuthority values automatically for an objectClass=apple-account.
>> This would automatically present the following entries (user admin used
>> as an example):
>> --
>> altSecurityIdentitites: Kerberos:admin at EXAMPLE.ORG <http://example.org>
>> AuthAuthority: ;Kerberosv5;;admin at EXAMPLE.ORG
>> <mailto:admin at example.org>;EXAMPLE.ORG <http://example.org>;
>> --
>> 
> 
> Is this generally static data set once during user-creation? If so them the framework can manage it w/o requiring a 389-ds plugin which means it would be far easier to do.

It's static data. It's a concatenation of multiple strings: a hard-coded one, the uid and the realm. It only changes if you rename the user account. It is used to route the authn phase to the Kerberos account (no PAM configuration!!!).

> 
>> A better way to specify homes for users. Not everyone uses automount and
>> automount maps (although OS X can use them). We need to be able to
>> specify not the assumably mounted home directory, but the protocol (afp,
>> nfs, cifs, etc.), server and share/directory. Furthermore, most Mac
>> Admins will have a heart-attack if they see an auto-mounted
>> /home/$username instead of the usual /Users/$username.
> 
> Not sure what you mean. Do you mean having a way to map it by client type? You may be able to do it by having client-type-based automount maps.

OK. So on Linux you do an automount map for the file server with the homes and state that the user home directory is in /home/$userName

On Windows, you give the home folder as \\server\share\folder, but assume that the protocol is SMB/CIFS.

On Mac OS X, you give the protocol, the server and the share\folder. You could use automount, but I've never seen any OS X admin do that. Mainly because you loose the roaming ability (they call it file synchronization). Mac OS X can use roaming profiles just like Windows. They don't have to be mounted except at logon time which is important for road-warriors. Since most Macs are laptops, the road-warrior scenario is assumed. Otherwise, you just get local homes.


>> Is anyone from Red Hat willing to pick this up? It would be a nice
>> addition. If so, I am offering to do the testing and fine-tuning for all
>> post-Tiger releases. I can also share virtual machines for server and
>> client configuration.
> 
> I'd open one or more RFE tickets on https://fedorahosted.org/freeipa/newticket

One was already opened (https://fedorahosted.org/freeipa/ticket/4813) and I'm in CC. Since nothing happened for 1 year after my offer to document it, I've decided to start this thread.

>> The Apple schemas are included in Apple's GPL code-drops for OpenLDAP if
>> anyone is wondering about licensing. We don't need the full schemas
>> because we can map most stuff to our own schema and it works brilliantly.
> 
> It is probably best to stick with the Apple schema otherwise there could be pain later if something changes, requiring additional mapping.

I wouldn't encourage it for two reasons:
1) The Apple schema is designed to be remapped to any other schema. That's the point of cn=config. That's what I did. It describes the attribute mappings to internal data structures. I've identified a minimal number of apple-schema items that have no direct mapping to freeIPA datastructures and documented them in the two schema expansions in the email.
2) Using the Apple schema without remapping would duplicate a most of the data and would make account maintenance and LDAP Browsing more difficult in the future. Since Apple is flexible about the schema, why shouldn't we use that?