[Freeipa-users] Apple OpenDirectory Integration

[Rob Crittenden]

"Răzvan Corneliu C.R. VILT" wrote:
> Hi Guys,
>
> I've done a small scale demo of using FreeIPA instead of an Open
> Directory Server to serve Apple OS X clients. This is based on my
> experiences from one year ago (Ticket #4813). I've also attached some
> screenshots.

This is very cool and excellent work!

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?

> *Here's what works:*
>
>   * Host sees the IPA Server
>   * Host is able to register to the IPA server
>   * Host creates a computer account (needs a bit of help here)
>   * Host sets it's own random password (including kerberosPrincipalKey
>     and kerberosExtraData)
>   * Host can see the users and other computers in the LDAP
>   * Host can use TLS registration with FreeIPA's own root certificate as
>     found in cn=CACert,cn=ipa,cn=etc
>   * Host can use just Kerberos for authentication and doesn't need an
>     Apple Password Server
>
>
> *Here's what needs to be done to get there:*
>
>   * Create a cn=config,$baseDN entry (attached example ldif). This can
>     be created automatically based on a template.
>   * Create and ACI that gives anonymous read access to cn=config,$baseDN
>     (SNIP #3)
>   * Modify an existing ACI to give altSecurityIdentities and description
>     to anonymous/public consumption (SNIP #4)
>   * Extend the schema to include apple-configuration (SNIP #1)
>   * Extend the schema to include apple-user (should be renamed to
>     apple-account since it applies also to hosts) (SNIP #2)
>   * Add PLAIN to the supported SASL mechanisms (I don't know why it's
>     missing anyway because it's restricted to TLS by default). For me,
>     without further investigation of the reasons, I had to also disable
>     CRAM-MD5 and DIGEST-MD5 on the 389 DS.
>   * Make sure (if you upgraded from a v3) that you have OCSP and/or CRL
>     working
>   * Add an _ldap._tcp entry in avahi and/or server the LDAP server via
>     DHCP and/or serve the search domain via DHCP and make the DNS-SD
>     service entries for it.
>
>
> *Here's what's missing from FreeIPA:*
>
> 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>;
> --
> AuthAuthority is interesting because it supports not only basic LDAP
> authentication, but also Kerberos, Netlogon and Apple Password Server
> and you can specify multiple authentication authorities (including an
> Active Directory).

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.

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

> *Here's what's missing from OS X:*
> A way to request OS X to do GSS-TSIG registration to the DNS. We may
> have an MCX method to do that, but I haven't investigated. NSUpdate is
> available and has support for gss-tsig. I think that for Active
> Directory it does this automatically, and if so, we should be able to
> reproduce it.
>
> A way to specify that the fqdn argument should actually be an FQDN. We
> might have to write a 389 DS plugin to take the CN without the final "$"
> and add the domain name after it.
>
> SUDO Map support. Currently, the only way to specify if an account has
> sudo rights is to make it an admin. This makes it clear that without
> Password Server support (partly implemented in the LPWS project), the
> usage scenarios are limited to normal users and SSO to servers. OTOH, OS
> X only knows admin and non-admin accounts, so it's not that bad.
>
> *Steps to produce my demo install before the patches below:*
> ipa-server-install -r EXAMPLE.ORG <http://example.org> -n example.org
> <http://example.org> -p deadbeef -a deadbeef -P
> deadbeef --hostname=ipa.example.org <http://ipa.example.org>
> --ip-address=172.16.23.138 --ssh-trust-dns -U --setup-dns --no-forwarders
>
> 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

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

rob