On Thu, 04 Feb 2016, "Răzvan Corneliu C.R. VILT" wrote:

On 4 feb. 2016, at 12:16, Rob Crittenden <rcrit...@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
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:ad...@example.org <http://example.org>
AuthAuthority: ;Kerberosv5;;ad...@example.org
<mailto:ad...@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

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

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

Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to