> 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 
> 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: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!!!).

>> 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?

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

Reply via email to