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 + + 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. - 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. + * 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 -- Mailing list: https://launchpad.net/~tieto Post to : [email protected] Unsubscribe : https://launchpad.net/~tieto More help : https://help.launchpad.net/ListHelp
