Skip to content
d3vi1 edited this page Oct 30, 2017 · 7 revisions

Welcome to the freeipa-macosx-support wiki!

Ideas

Rename to FreeIPA-darwin-support. macosx is not really current and the os had multiple names in the past years: NeXTStep, OpenStep, Rhapsody, Mac OS X Server, Mac OS X, OS X, macOS, iOS, tvOS, watchOS, etc. The only common denominator since the initial commercial release has been Darwin. Not to mention that it's the actual name for the Operating System and the commercial names listed above apply to Darwin distributions made by Apple and it's predecessors.

Needed Items

In order to create the ODConfigTemplate, we need the following information from IPA:

  • Kerberos realms: api.env.realm, but also ldapsearch "(cn=*)" -Y GSSAPI -s base -b DN[api.env.container_realm_domains,,api.env.basedn] associatedDomain
  • IPA Domain: api.env.domain
  • IPA LDAP Servers and their IP addresses: ldapsearch "(cn=*)" cn -s one -b [api.env.container_masters,api.env.basedn] -Y GSSAPI
  • IPA LDAP read-write replicas and their IP addresses: ldapsearch "(cn=*)" cn -s base -b [api.env.container_masters,api.env.basedn] -Y GSSAPI
  • IPA LDAP read-only replicas and their IP addresses: ldapsearch "(cn=*)" cn -s base -b [api.env.container_masters,api.env.basedn] -Y GSSAPI
  • IPA LDAP Base DN: api.env.basedn
  • IPA KADM Servers and their IP addresses: ldapsearch "(&(cn=KPASSWD)(ipaConfigString=enabledService))" -s one -b [api.env.container_masters,api.env.basedn] -Y GSSAPI
  • IPA KDC Servers and their IP addresses: ldapsearch "(&(cn=KDC)(ipaConfigString=enabledService))" -s one -b [api.env.container_masters,api.env.basedn] -Y GSSAPI
  • Container for User Accounts: DN[api.env.container_user, api.env.basedn]
  • Container for User Groups: DN[api.env.container_group, api.env.basedn]
  • Container for Computer Accounts: DN[api.env.container_host, api.env.basedn]
  • Container for Computer Groups: DN[api.env.container_hostgroup, api.env.basedn]
  • Container for CA (cn=CACert, cn=ipa, cn=etc) : ?!?
  • Container for macOS Config: we will export an api.env.container_darwinODConfig (or something similar)
  • Container for the Automount Map: api.env.container_automount
  • Container for the Automount: api.env.container_automount
  • Container for Machines (I don't exactly know what this is): ?!?
  • ObjectClasses for User Accounts: ?!?
  • ObjectClasses for Groups: ?!?

Tasks that require some IPA/IPA API expertise

  • We need to register in order watch for modifications to the above properties. We need this because we have to regenerate the ODConfigTemplate when something changes (new server, hostname changed, container DN change, etc.).
  • We further need to depend on the activation of the Samba specific LDAP entries provided by IPA. So, when this plugin gets activated, the Samba entries get automatically enabled.

Tasks that need testing

I seem to remember when I did my setup that I had troubles with SSL because the LDAP Server certificate requested a mandatory OCSP/CRL validation but the Dogtag VA wasn't brought up. It might not be an issue anymore, but it requires investigation.

Tasks that take us out of IPA

  • Connect to Avahi in order to announce the LDAP servers on mDNS. Pyzeroconf seems to be adequate and it seems to support both Avahi and mDNSResponder. This is needed for the discovery of the IPA Server. It should be packaged separately as an plugin, but we should depend on it.
  • Generate Property Lists from the ODConfig dictionaries. There is a plistlib that can help us out, but because we only need to encode and not decode, and because extra dependencies are frowned upon, we might get away by implementing our own minimal plist encoder. We also need to base64-encode those but I assume that it's already covered by the standard Py libs.

Requirements from IPA. We somehow need to verify that we are compliant here

  • Anonymous & unencrypted binds to the DN(api.env.container_darwinODConfig,api.env.basedn) of the LDAP server in order to get the templates initially. If this presents an issue, we can create a new DN that hosts solely the ODConfig and the CA Certificate which directs the client to another DN over SSL, but this is not as elegant as it could be.
  • Activation of the PLAIN SASL authentication method over SSL.
  • The CRL URL or the OCSP responder should be up and running. If you're using the internal CA, that means that the dogtag VA should be started. If you're using an external CA, you should have access to it.