Authentication services in Ubuntu

Bolesław Tokarski boleslaw.tokarski at tieto.com
Tue Jun 4 08:02:09 UTC 2013


Hello,


On 06/03/2013 09:06 PM, Timo Aaltonen wrote:
>> We could also do some investigations on realmd from Fedora/RedHat which
>> is their tool for joining a Directory service. I believe it's not just
>> for MS AD. Realmd has not been packaged for .deb yet, I believe. And I
>> am not sure how RedHat-specific it is.
> It's on raring & saucy at least (0.12-0ubuntu1), but not on Debian.

Ok, then I guess I can start checking how the thing works on 
raring/saucy. Would use that on Debian too. Recently I had some use of 
your SSSD packages on Wheezy too :)


>> Then the remaining thing is the configuration helper. Perhaps we could
>> fork RedHat's system-auth-config?
> If that'd work with the installer.. but I doubt it. Adding support for
> this in user-setup shouldn't be too hard, just use the UI/ideas from
> authconfig as a starting point..
>
> Or maybe I'm hoping too much to be able to just preseed a few values and
> it'd all be automatic from there on, and provide the gui bits for
> joining a realm manually :)

Personally I prefer post-installation join. I am using a generic 
installation of Ubuntu with just LVM and optional encryption and set the 
config questions to some defaults like the 'ubuntu' hostname. While the 
system boots for the first time my CFEngine agent contacts our policy 
server, gets the proper hostname for the machine, installs sssd, 
configures authentication and does a lot of other stuff.

You need to configure a last-resort local user anyway, so it does not 
matter that the config is run after installation from userspace+sudo.

Making the directory join and configuration an install-time question 
presents a number of challenges:
  - the full-blown OS is not yet running, you can't rely on some features
  - if the questions are supposed to be in a udeb package, the 
environment is even more restricted
  - we'd have no use of RedHat's tool, basically we'd need to implement 
our own

Alternatively, we could use an early udeb that just passes the fields to 
a regular deb that would execute the join in its postinst; or even as a 
first boot action. That however means that if the user makes a typo, it 
will only get feedback once the installation gets to the joining phase. 
Or perhaps we can add all the joining libraries (ldap, kerberos) to d-i? 
I'd say too much hassle.

>> Even if we decided that we do not need to care about "legacy" LDAP
>> authentication, I would propose to fix the Ubuntu packages in the same
>> way the Debian packages are done - by not requiring ldap-auth-config. I
>> have just checked the Ubuntu maintainer of the libpam-ldap and it seems
>> to be "Ubuntu Core Developers
>> <mailto:ubuntu-devel-discuss at lists.ubuntu.com>" with an email to this
>> list. So, can we make it happen?
> ldap-auth-config is an ubuntu specific package, which seems to be
> basically unmaintained for some time now. Then again I don't see why
> libpam/nss-ldap should be touched, if we're going to use lib*-sss.. the
> obsolete package(s) could be dropped once the new stuff is working.
I'd say to drop the changes made against Debian. Aside for the 
separation that Debian does with regards to ldap.conf files (for nss and 
pam, it doesn't seem right to me), I'd say drop the diffs.

Cheers,
Ballock




More information about the Ubuntu-devel-discuss mailing list