tieto team mailing list archive

[Bryan Quigley <gQuigs@xxxxxxxxx>]

Blueprint changed by Bryan Quigley:

Whiteboard changed:
  Issues to test:
  What to do if AD is very slow to login.   Timeout is currently around 1 minute.   PAM Stack timeout vs SSSD.  (If it can access AD, it will try even on bad links) - Workitem: Ballock
  Expiring passwords -
  
  Utilities to join to a domain:
  msktutil -
  realmd/adcli -
  - filed https://bugs.freedesktop.org/show_bug.cgi?id=71910 to fix a couple of issues
  + AD: realmd discovers and joins the domain correctly when run from an already-installed system.
  - realmd tries to run 'update-rc.d sssd enable', but the sssd package comes with upstart init, so this doesn't apply. Anyway, as services in Debian-based are enabled automatically by default, there's no need to enable it at all.
  - realmd installs appropriate packages based on the type of directory service found. Therefore, running it as part of a postinstall script (to get the user dialogs) is problematic.
  + realmd acquires a valid Kerberos keytab for the machine, thus utilizing the full potential of machine accounts. This allows to enable SSO services from the machine like in https://wiki.ubuntu.com/Enterprise/Authentication/KerberosServices
  - we need to make sure that realmd/adcli correctly handles machine password expiry. Unlike msktutils's manpage, adcli does not say much about it.
  edubuntu-server-client -
  
  Test above clients with Free IPA - timo
  Test above clients with Zentyal domain - Bryan
  Test above clients with AD domain - Ballock
- 
- Move likewise-open to Universe. -
  
  realmd co-op with gnome-control-center for trusty
  - is only meant for individual users being able to login to a domain, not to set up the machine https://bugzilla.gnome.org/show_bug.cgi?id=697910
  - needs g-c-c > 3.8.1, probably will be backported to our fork for trusty
  
  Touch base with stephan on plans for edubuntu - Timo
  - ubiquity is a frontend for d-i, so adding domain join support there means fixing user-setup first
  - user-setup is run before installing the system on disk, but changes are applied in finish-install phase
  - validating user input at that point is "hard/impossible"
    * a minimal check would be to use ldap to set the password of the specified machine in AD, but that may not work if the machine account is not there at all.
    * otherwise, we would need an udeb with adcli and perhaps realmd too. This might require a significant amount of hacking, as it depends on ldap and kerberos libraries, which do not have their respective udebs.
  - we could join the domain at full user-setup phase (not the udeb part), but that would make a perhaps unnecessary interruption in the installation process.
  - user-setup-udeb could ask *if* the user will want to join AD/directory at the later phase. The full-blown user-setup would use a regular realmd/adcli binary for joining
  
  Notes from Ballock: There is an option to ask the joiner user/password
  at udeb phase and make late user-setup verify that and come back to the
  user to retype the user/password. However, I am against this method, as
  the debconf answer might be logged to /var/log/installer.log and would
  end up in the debconf database that would be afterwards readable till
  the machine dies. Although, once successfully joined, full user-setup is
  be able to clear it from the regular debconf database, the install-time
  database remains on drive.
  
  tjaalton: Fedora's current anaconda has a first-boot setup phase where
  the domain join is handled, so our equivalent of this is the finish-
  install phase which should work fine for this, no need to do everything
  in the first phase.

-- 
Make ActiveDirectory Trusty
https://blueprints.launchpad.net/ubuntu/+spec/client-1311-activedirectory