COM-FSM > SIS Documentation > Integration > LDAP Integration

LDAP Integration

Page last modified 05:47, 16 Jul 2013 by kgirrard
    Table of contents
      1. 1.1. Overview
    1. 2. Accounts
      1. 2.1. Services
    2. 3. Groups
    3. 4.  The LDAP Account


    Account information can be integrated with an external LDAP database to allow accounts defined within the SIS to provide authentication for e-mail, wi-fi, or other LDAP-aware services. Integration with LDAP is not required for operation of the SIS, however. Some account management functions (e.g. deleting an account) can only be performed on the LDAP Account form, but this shouldn't be taken to imply that LDAP is required or in use.


    Each person defined in the database can have one or more accounts associated with them. Each account has a unique login name, and may be used for access to it's own combination of services. Content at the top of the form is used for UNIX accounts or directory information:


    Field UNIX Directory Description
    Password Y   A new password for this account is specified here, and will be required when creating a new account
    Expires Y   Date the current password expires; some services will observe password expiration (not allowing an account to be used after a specific date)
    Group Y   Default group for this account; used mostly for UNIX accounts
    Shell Y   UNIX shell for account; the default of "/sbin/nologin" creates a UNIX account that doesn't allow the user to log in to the host (e.g. with ssh or sftp); if the user needs access (including for management of a web site) this will need changed to an actual shell (such as /bin/bash)
    Quota: Mail Y   Limit on IMAP storage (if in use)
    Quota: Home Y   Limit on UNIX storage in user's home directory (if enforced)
    Used/Host/IP     Data on account usage can be collected to update these fields to provide information on when the account was last used.
    Title   Y Position title
    Department   Y Department affiliation
    Office   Y Office location (e.g. building and room number)
    Phone   Y Telephone number
    Campus   Y Campus where this person is located
    GECOS Override Y Y Account Name override if the person's name doesn't apply to this account, or they wish to have a different form of their name used; the GECOS field is normally populated with only First and Last name; this name is used for outgoing mail, as well as any directory entry
    Home Page   Y URL of this account's home page
    User ID Y   System-assigned ID number (also known in UNIX as uid)
    The use of each field is determined by the LDAP objectClass associated with each service (see below) and how that class is implemented within LDAP.php (the server-side implementation of the LDAP interface). In the above table the UNIX and Directory columns correspond to the posixAccount and inetOrgPerson) LDAP Object classes, respectively. 


    Support for specific uses of the LDAP databse is organized around Services. The service definition is where most aspects of the LDAP integration are brought together, from an LDAP objectClass that defines what type of information should be included in the associated LDAP record,LDAPServiceSample.png to other characteristics such as what type of password should be used (called a Hash), and whether an e-mail address should be managed as part of the service.

    In addtion to the service code and description for an LDAP Service, these records include:

    The Organizational Unit where this data will appear in the LDAP database, with the configured Base DN appended; records in the example would be placed under ou=ITS,dc=comfsm,dc=fm
    The method used to encrypt passwords for this service; to use any Hash type it must be enabled on the LDAP Hash form.
    Indicates whether new accounts should have this service added by default, when they are created on the LDAP Account form
    The security level associated with this service; services with limited access have a numerically larger security levels
    This controls the type of information gathered and added to the LDAP record when it's placed in the database; these are defined on the LDAP Object form but, more importantly, must be coded for in the server-side interface (LDAP.php)
    Address Type
    If an e-mail address should be automatically created and managed for the person when an account with this service is present, it's type should be specified here; these accounts appear on the Person form; note that these e-mail address records are not strongly linked to information in an LDAP record, and are managed on a per-person basis in the SIS database, not on a per-account basis like LDAP accounts
    E-Mail Domain
    The domain name that should be used to construct an e-mail address, when an Address Type is specified


    Having LDAP Groups associated with an account offers controls for any LDAP-aware application that understands the posixGroup object class. Access to this documentation, for example, is limited to users with the sis.users group association. The LDAP Account form allows editing of group data for individual accounts; this same information can edited from the perspective of the group on the Group Members form. 

    The LDAP Account

    Each defined, active LDAP account will have one or more services specified, depending on what each account is to be used for. The accounts will all share common data from the LDAP Account form, including a password, but can supply information to multiple LDAP-aware applications.

    Powered by MindTouch Core