ASCII Smiley Face Daniel Dickinson Mini Headshot
The C Shore
Daniel Dickinson's Website - Experimental

Debian LDAP Overview

Using an LDAP Server

Objectives

DanielDickinson 2005-08-02: This is my reworking of the Debian Wiki LDAPAuthentication pages to hopefully be more detailed and coherent. The plan is to have clear, easy to understand instructions on installing and configuring an LDAP server. At this time, stable is 'Debian 3.1 'Sarge'

Assumptions

  • An effort has been made to modularize the system. That is you can pick and choose which parts you wish to implement. You should be able to ignore the bits on DNS and Samba, for example, and still have useful instructions on setting up LDAP Authentication for users
  • The LDAP server will contain all non-system users (i.e. a UID >= 1000)
    • Rationale: System groups are managed by Debian package install scripts using adduser which means packages installed after ldap would not create their required users in the ldap directory
  • The LDAP server will contain all non-system groups (i.e. a GID >= 1000)
    • Rationale: As with UID. The original author said GID >= 100, however I think that has changed since Woody as my Sarge systems have system users above 100
  • The LDAP server will contain all other hosts, networks, services, and /etc data
    • Rationale: This may prove useful in large environments, and in any case ensures completeness of the database
    • This document collection will include information on how to use, or not use, all the other /etc data
  • The only special users in LDAP will be the LDAP admin user and the Samba user admin, with no additional "proxy" users
    • Rationale: This makes life simpler
  • The LDAP special users shall use SSHA crypt
    • Rationale: This is probably the most secure option for password storage for LDAP special users
  • Samba data will also be stored using LDAP
    • Rationale: This centralizes all user authentication (both *nix and windows) and allows for shared Linux/Windows users and groups
  • The LDAP PAM module will be used for authentication, authorization, password changes, and updating /etc/passwd-type information (e.g. chfn and chsh)
    • Rationale: Most applications are PAM-aware, so using PAM means that most apps that need to authenticate/authorize can be made LDAP-aware simply by making PAM LDAP-aware
    • NB: When using Samba passwd is deprecated and a Samba-aware alternative preferred (see SmbLdapTools)
  • Only root will have access to shadow passwords via NSS
    • Rationale: Security.
  • All POSIX passwords shall use MD5 digest hashing
    • Rationale: Security
  • Apache web authentication will be done using LDAP
    • Rationale: If desired regular users could also be Apache users, and even if not, it means that user authentication can be centrally administered
  • DNS will be served via LDAP
    • Rationale: We can. Also in large environments LDAP can be replicated and failover introduced (this is not described in these documents however)
  • The network address book will be ldap-hosted
    • Rationale: The users already in the LDAP directory only need some addressbook fields added to be address book entries as well as user authentication entries
  • SSHLDAPSetup will not be covered here
    • Rationale: SSH authentication is best done using public/private keys
  • Simple authentication is used
    • Rationale: Getting encrypted LDAP communications happening is another major component to make mistakes on, therefore it is left until the end. All the examples not in LDAPSecurity assume simple authentication
Previous: LDAP Top: LDAP Next: OpenLDAPSetup