[Freeipa-users] Apple OpenDirectory Integration

[Alexander Bokovoy]

On Thu, 04 Feb 2016, "Răzvan Corneliu C.R. VILT" wrote:
>
>> 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!!!).
I wonder if we should use CoS plugin to get this data added to user
entries instead of storing it in every single user's LDAP entry -- the
only thing that is different is uid but the rest is the same, right?

>>
>>> 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.
If you don't provide any share details, what happens? Will Mac OS X
would fill-in the defaults based on the user name?

>> 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.
It mostly boils down to IPA developers not really having access to Mac
OS X devices. And load of other tickets to solve, of course.

>>> 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?
Good points. Remapping is better from our perspective too.

-- 
/ Alexander Bokovoy