Old

[JerryHaltom] Working on reorganization of page and formulization of ideas at NetworkAuthentication/Client

Introduction

There are many different kinds of network authentication in use today and Ubuntu should be easily configured to use any of these out of the box but without asking any questions in the default install. In order to accomplish this there should be a single utility similar to Fedora's authconfig that interfaces with package-specific configuration scripts. To complement this, an authentication server metapackage can be provided that sets up an LDAP+Kerberos installation.

Rationale

Ubuntu should easily integrate into existing network infrastructure including authentication and authorization. There is a lot of demand for easy configuration of the many different authentication methods including LDAP, Active Directory, Kerberos and NIS.http://www.ubuntuforums.org/showthread.php?t=191858&highlight=enterprise

Scope and Use Cases

The goal for Edgy Eft should support authentication of clients to existing networks, and deploying servers to authenticate against.

The initial implementation should support the following use cases:

  • The system administrator has a lab of machines to install. He uses the authconfig-like utility to create a file with a set of settings. He uses the file to deploy the settings to all the machines in the computer lab.
  • The system administrator wants to use both NIS (for legacy purposes) and his new Active Directory setup for authentication and authorization. He enters the relevant configuration for each of the methods.
  • The system administrator has a lab of machines to install, and wants to use an Ubuntu server to authenticate against. He installs the server package, which on installation asks the administrator information about the domain to setup.

Implementation Plan

[Time estimates are just that, estimates. They are based on an educated guess of implementation difficulty, but without having reviewed the code.]

  • Client
    • Use Fedora's "authconfig" for specific ideas and to determine details of what files need to be changed for each method.
      • Most of the changes done by "authconfig" are distribution neutral as they modify upstream configuration files.
      • PAM configuration is the only Fedora-specific aspect and that is easily adaptable to /etc/pam.d/common-*
    • Break down the 4700-line "authinfo.c" into package-specific configure scripts to fit within Ubuntu policy.
      • base-files needs a tool to modify nsswitch.conf and nsswitch.conf needs changed to be managed by maintainer scripts and not be listed in conffiles. (1 day)
      • libpam-runtime needs a script for modifying /etc/pam.d/common-*. (1 week)
      • samba needs a script for setting up winbind authentication in /etc/samba/smb.conf. (unsure, probably half a week to a week)
      • libpam-smbpass needs a script for modifying /etc/pam_smb.conf (absolutely trivial, 2 hours)
      • krb5-config and krb4-config need a script for /etc/krb5.conf and /etc/krb.conf (similar to the script for samba, so if we have the samba script, 1 day)
      • libhesiod0 needs a script for modifying /etc/hesiod.conf (trivial, 2 hours)
      • libnss-ldap needs a script for modifying /etc/libnss-ldap.conf (similar to /etc/openldap/ldap.conf, fairly simple, 4 hours)
      • libldap2 needs a script for modifying /etc/openldap/ldap.conf (fairly simple, 4 hours)
      • nis needs a script for modifying /etc/yp.conf (trivial, 2 hours)
    • Make sure the packages needed for an authentication method are installed on the system by checking for missing packages and notifying the user of the problem and how to fix it.
    • All the necessary packages are already in main.
    • No questions to configure the authentication method should be asked when installing with Ubuntu's default priority for debconf.

    • The client authentication method should be configurable in the usual System->Administration menu

Data Preservation and Migration

Some packages currently package their configuration as conffiles and those packages will need to be changed to use maintainer scripts. Please see Debian policy for the explanation of the difference between conffiles and configuration files.

Obviously scripts should be written to conform to the Ubuntu guidelines of not overwriting user modifications in configuration file. By restricting the scripts to making simple and well-defined changes it should be possible to insert and remove the appropriate changes without losing user changes. "authconfig" currently manages this quite well and similar techniques can be used in the scripts.

Packages Affected

  • base-files
  • libpam-runtime
  • libpam-smbpass
  • libnss-ldap
  • samba
  • krb5-config
  • krb4-config
  • libhesiod0
  • libldap2
  • nis
  • slapd

User Interface Requirements

  • Client-side
    • The various pieces should be configurable through the usual "dpkg-reconfigure" where appropriate, and a higher-level package should provide a unified place to set all the relevant authentication and user information settings. The higher-level package should do this through calling dpkg-reconfigure on the relevant packages and making sure a graphical frontend is used. An interface similar to Windows' "Join this domain" should preferably be created.

Outstanding Issues

None.

Additional Remarks

For edgy+1 Fedora Directory Server should be evaluated. Currently it would require significant packaging work to ship in edgy, even for universe

For edgy+1, it may be possible in the installer to touch the whole network on ports such as 389 (LDAP) to detect NIS servers. If DHCP detects a 192.168.x.y/24 subnet, then it is feasible to test 192.168.x.* on these ports. Upon asking for a user name, the installer could ask if one of the detected LDAP, AD, Kerberos, or NIS servers should be used; and who the administrator is. This would require exceptions to the 'no questions asked' installer policy.

LDAP, Active Directory, Kerberos, and NIS can backbone VPN authentication. A VPN spec for IPSEC, PPTP, or TLS should be drawn up; in the mean time, be mindful of these and don't use anything inherently incompatible.

[BenjaminMontgomery] We need a python binding for the kerberos libraries. I've started working on one, you can get it via bazaar at http://www.montynet.org/bazaar/python-krb5. I've been using what I have so far to create a prototype Gnome applet to manage kerberos credentials. I haven't spent a lot of time looking at Fedora Directory Server, but there are very few maintained tools out there to manage an LDAP+Kerberos SSO setup.

[EdwardMurrell] There's a GNOME utility called gktools for handling Kerberos tickets, written in C, adapted from the gnome-kerberos tools from redhat. This is avaliable at http://asgaard.homelinux.org/code/gktools/ It needs a bit of polishing, but is about 95% complete.

[EdwardMurrell] Rather than scanning all the possible ports in the current range, it would be much better to use the DNS service listings to find LDAP and Kerberos servers, as well as the Kerberos domain. From there, it should be possible to map things like the default search suffix for the LDAP servers (unless the admin has done something stupid).

I'm not sure how it differs from Fedora's auth tool but I found sadms (http://sadms.sourceforge.net/) mentioned in another wiki post on integration with Active Directory. Also, does this supercede the spec listed here: https://wiki.edubuntu.org/ActiveDirectoryIntegration?highlight=%28directory%29%7C%28active%29 ?

[JelmerVernooij] Is there really any need to worry about Kerberos 4 configuration? There is no reason at all to be setting up new Kerberos4 environments and there are some security concerns over it. At some point Kerberos 4 support will be removed from the Kerberos packages (there has already been talk about doing so for the Heimdal kerberos packages in Debian).

[ToniHeinonen] I think it's best to upgrade to Samba 2.0.23 (edgy is in feature freeze and it seems to ship 2.0.22). That's the first version where winbind works like XP workstations, ie. it uses the AD/Kereros stuff instead of NT4 RPC for a lot of things. I'm not sure, but I believe in this version Winbind also gets a Kerberos TGT for you, so you get the Kerberos SSO stuff with pam_winbind (and you don't have to use pam_krb5).

[JerryHaltom] [NetworkAuthentication/ScratchPad] I'm braindumping here.

[MagnusRunesson] It would be nice if Administration->Users and Groups(usersadmin) worked agains ldap/kerberos/nis. There are some pythobnbindings in debian unstable python-kerberos package.

[SimonARuiz] As an end user with no technical experience this (usersadmin against the network directory) is the only bit that I can understand and provide comment on. This should not be default, or it should ask before implementing (and I know we want to keep the number of questions on install limited). In my work situation, a large school corporation (and likely most places with a big enough corporate network), we only want interaction to modify the directory through one "approved" channel, and users should not be able to modify ANYTHING on the Active Directory without going through that channel. Just my $0.02.

Notes from IRC

  • Move all server stuff to own spec Partly done see: NetworkAuthentication/Client

  • Add notes about ajmitch's code

  • Add notes about new Suse stuff
  • Investigate other distros (Mandriva, Xandros, etc.)
  • Seperate out AD auth vs FDS/OpenLDAP auth
  • List ubuntu-directory team
  • Link to bugs

CategorySpec

NetworkAuthentication/Old (last edited 2008-08-06 16:17:43 by localhost)