tieto team mailing list archive

[Ballock <boleslaw.tokarski@xxxxxxxxx>]

Blueprint changed by Ballock:

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

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