Warning Livedoc is no longer being updated and will be deprecated shortly. Please refer to https://documentation.tjhsst.edu.

Integrated Authentication

From Livedoc - The Documentation Repository
Revision as of 12:05, 30 July 2008 by William Yang (talk | contribs) (Filling it out. Should be good for now.)
Jump to: navigation, search


As part of the effort to move to a unified user information and password system, effectively eliminating the need for multiple computer accounts (at least in terms of passwords), all Linux and UNIX systems are now using an LDAP/Kerberos scheme to authenticate using Windows accounts.
POSIX attributes (e.g. uid, gid, POSIX logon username) are currently manually imported by a script.



See NSS LDAP for details and configuration.


Microsoft Active Directory supports authentication using the Kerberos protocol. The Kerberos realm is LOCAL.TJHSST.EDU. For the system to authenticate to Kerberos, we use pam_krb5 (see below). For GSSAPI authentication, a cross-realm one-way trust allows us to issue CSL.TJHSST.EDU system keytabs and have them work with both CSL and LOCAL.TJHSST.EDU Kerberos principals.


  • See an existing system for an /etc/krb5.conf that can be installed on a new system. Note that on Solaris systems, krb5.conf should be installed in /etc/krb5/ with a symlink to usual location of /etc/krb5.conf.
  • auth_to_local rules are used to allow GSSAPI authentication to work for both TJ Kerberos realms regardless of what the configured default_realm is.
  • A PAM minimum_uid is set in krb5.conf to ensure that system users don't try Kerberos, ever.
  • On Solaris, a kpasswd_protocol directive is added for each realm since Solaris defaults to using an RPC implementation for kpasswd, which is not compatible with most other non-Sun kpasswd implementations.



  • CSL workstations currently use pam_krb5 from http://www.eyrie.org/~eagle/software/pam-krb5/.
  • Solaris systems currently use pam_krb5 from the above website, but locally patched to properly implement use_authtok behavior and also to implement functionality for afs_tokens and afs_tokens_nopag options so AFS tokens can be handled in the PAM auth stack with pam_krb5 (see pam_afs2 below). This is useful to implement multi-realm auth as currently dtlogin does not appear to function with an AFS token-getting module placed in session, and xscreensaver also calls only the auth stack (so now tokens are refeshed upon screen unlock).
  • Configuration note: all systems are currently configured with two pam_krb5 instances in the PAM auth stack to allow for multi-realm auth. CSL.TJHSST.EDU should be attempted first as it is our local Kerberos realm which does not lock out accounts after multiple incorrect tries, where as LOCAL.TJHSST.EDU does implement account lockout.


This module is no longer primarily used; its code was patched into the pam_krb5 used on Solaris (see above). It is still used in the sshd-gssapi PAM session stack on Solaris as the PAM auth stack is not processed if GSSAPI is used for SSH.

  • PAM module that can set up a PAG and run a program to get AFS tokens. This module can run either in auth or session (we prefer auth so that things that don't process PAM-session like scp will also get tokens).

See Also