Make ActiveDirectory Trusty
We should have a recommended way to easily add a machine to an AD domain (other common scenarios as well. Ex: Zentyal). It should "just work". Password expiration (¬ifications), changing AD passwords, lightdm set to allow logins when joined. We may also want to consider: dropping/upgrades from likewise-open, GUI for joining domain.
Could this get scheduled for Thursday?
Blueprint information
- Status:
- Not started
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- New
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
Whiteboard
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:/
+ 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:/
- 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-
Test above clients with Free IPA - timo
Test above clients with Zentyal domain - Bryan
Test above clients with AD domain - Ballock
realmd co-op with gnome-control-
- is only meant for individual users being able to login to a domain, not to set up the machine https:/
- 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/
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.
Work Items
Work items:
Demote likewise-open (bug reported https:/
