"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:ad...@example.org <http://example.org>
AuthAuthority: ;Kerberosv5;;ad...@example.org
<mailto:ad...@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
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
