FeministWiki:LDAP Schema: Difference between revisions

    From FeministWiki
    (Created page with "The member database of the FeministWiki is stored via LDAP. The basic structure looks like this: dc=feministwiki,dc=org ou=members - cn=''username'' objectCl...")
     
    No edit summary
    Line 1: Line 1:
    The member database of the FeministWiki is stored via LDAP.  The basic structure looks like this:
    The member database of the FeministWiki is stored via LDAP.  This page explains some details about the setup.
     
    === Structure ===
     
    The basic structure looks like this:


      dc=feministwiki,dc=org
      dc=feministwiki,dc=org
    Line 34: Line 38:
    * The <code>fwRecoveryMail</code> field may hold a mail address that will be used for password reset requests.  It's different from the primary mail address because that one may be the member's FeministWiki address, which they can't access if they've lost their password.
    * The <code>fwRecoveryMail</code> field may hold a mail address that will be used for password reset requests.  It's different from the primary mail address because that one may be the member's FeministWiki address, which they can't access if they've lost their password.
    * The <code>manager</code> contains the DN (distinguished name) of the member who added the member.  It may be empty for special member accounts like "Administrator" or the "Deleted" pseudo-account.
    * The <code>manager</code> contains the DN (distinguished name) of the member who added the member.  It may be empty for special member accounts like "Administrator" or the "Deleted" pseudo-account.
    === Read-only user ===
    For security purposes, it's a good idea to have a "read-only" user for LDAP read operations, instead of using the admin for everything.
    # Addition to be made via 'ldapadd'
    dn: cn=readonly,dc=feministwiki,dc=org
    objectClass: simpleSecurityObject
    objectClass: organizationalRole
    cn: readonly
    description: Read-only user
    No fiddling with access control is needed, since read-only access is the default.


    === Custom objectClass ===
    === Custom objectClass ===
    Line 39: Line 56:
    The following LDIF statement may be passed to 'ldapadd' to create the <code>fwMember</code> object class.
    The following LDIF statement may be passed to 'ldapadd' to create the <code>fwMember</code> object class.


      # Entry to add, with e.g. 'ldapadd' tool
      # Addition to be made via 'ldapadd'
      dn: cn=feministwiki,cn=schema,cn=config
      dn: cn=feministwiki,cn=schema,cn=config
      objectClass: olcSchemaConfig
      objectClass: olcSchemaConfig
    Line 57: Line 74:
    === Attribute permissions ===
    === Attribute permissions ===


    We want members to be able to change some of their own settings without requiring privilege escalation.  Additionally, we want the "readonly" dummy user to be able to find users via the combination of their username and recovery mail address(The password reset mechanism uses this.) The following LDIF statement may be passed to 'ldapmodify' to make the necessary access control changes:
    We want members to be able to change some of their own settings without requiring privilege escalation.  We also want the read-only user to be able to find users via the combination of their username and recovery mail address (the password reset mechanism uses this) but not actually see recovery mail addresses.  The following LDIF statement may be passed to 'ldapmodify' to make the necessary access control changes:


      # Modifications to be made, e.g. via 'ldapmodify'
      # Modification to be made via 'ldapmodify'
      dn: olcDatabase={1}mdb,cn=config
      dn: olcDatabase={1}mdb,cn=config
      changetype: modify
      changetype: modify
    Line 74: Line 91:


      # Add the ppolicy schema
      # Add the ppolicy schema
      ldapadd -Y external -H ldapi:/// < /etc/ldap/schema/ppolicy.ldif
      ldapadd -Y external -H ldapi:// < /etc/ldap/schema/ppolicy.ldif
       
       
      # Enable the ppolicy dynamic module
      # Enable the ppolicy dynamic module
      ldapmodify -Y external -H ldapi:/// <<EOF
      ldapmodify -Y external -H ldapi:// <<EOF
      dn: cn=module{0},cn=config
      dn: cn=module{0},cn=config
      changetype: modify
      changetype: modify
    Line 85: Line 102:
       
       
      # Add the ppolicy overlay with olcPPolicyHashCleartext set to TRUE
      # Add the ppolicy overlay with olcPPolicyHashCleartext set to TRUE
      ldapadd -Y external -H ldapi:/// <<EOF
      ldapadd -Y external -H ldapi:// <<EOF
      dn: olcOverlay=ppolicy,olcDatabase={1}mdb,cn=config
      dn: olcOverlay=ppolicy,olcDatabase={1}mdb,cn=config
      objectClass: olcPPolicyConfig
      objectClass: olcPPolicyConfig
    Line 91: Line 108:
      olcPPolicyHashCleartext: TRUE
      olcPPolicyHashCleartext: TRUE
      EOF
      EOF
    === Time of last login ===
    The <code>lastbind</code> module of OpenLDAP keeps track of when a user last logged in.
    Load the module:
    # Modification to be made via 'ldapmodify'
    dn: cn=module{0},cn=config
    changetype: modify
    add: olcModuleLoad
    olcModuleLoad: lastbind
    And enable the overlay:
    # Addition to be made via 'ldapadd'
    dn: olcOverlay=lastbind,olcDatabase={1}mdb,cn=config
    objectClass: olcLastBindConfig
    olcOverlay: lastbind
    olcLastBindPrecision: 60

    Revision as of 18:59, 21 December 2019

    The member database of the FeministWiki is stored via LDAP. This page explains some details about the setup.

    Structure

    The basic structure looks like this:

    dc=feministwiki,dc=org
      ou=members
        - cn=username
          objectClass: fwMember
          cn: username
          uid: username
          sn: Display name
          userPassword: {SSHA}saltedhash
          mail: username@feministwiki.org
          fwRecoveryMail: user@example.org
        - cn=username2
          objectClass: fwMembe
          cn: username2
          uid: username2
          sn: Display name
          userPassword: {SSHA}saltedhash2
          mail: username2@feministwiki.org
          manager: cn=username,ou=members,dc=feministwiki,dc=org
        - ...
      ou=groups
        cn=members
        objectClass: groupOfNames
        cn: members
        member: username
        member: username2
        member: ...
    

    Notes:

    • The cn (common name) and uid (user ID) fields both contain the username. This is because some software is preconfigured to look at uid, while most look at cn.
    • The sn (surname) field is used to hold a display name that may be different from the username. The field is filled with the username by default.
    • The mail field holds the primary mail address for communication with the member. It's filled with the FeministWiki mail address of the member by default, but can be changed freely.
    • The fwRecoveryMail field may hold a mail address that will be used for password reset requests. It's different from the primary mail address because that one may be the member's FeministWiki address, which they can't access if they've lost their password.
    • The manager contains the DN (distinguished name) of the member who added the member. It may be empty for special member accounts like "Administrator" or the "Deleted" pseudo-account.

    Read-only user

    For security purposes, it's a good idea to have a "read-only" user for LDAP read operations, instead of using the admin for everything.

    # Addition to be made via 'ldapadd'
    dn: cn=readonly,dc=feministwiki,dc=org
    objectClass: simpleSecurityObject
    objectClass: organizationalRole
    cn: readonly
    description: Read-only user
    

    No fiddling with access control is needed, since read-only access is the default.

    Custom objectClass

    The following LDIF statement may be passed to 'ldapadd' to create the fwMember object class.

    # Addition to be made via 'ldapadd'
    dn: cn=feministwiki,cn=schema,cn=config
    objectClass: olcSchemaConfig
    cn: feministwiki
    olcAttributeTypes: {0}( 1.3.6.1.4.1.42.2.27.99.1.1
       NAME 'fwRecoveryMail'
       DESC 'FeministWiki password recovery mail'
       EQUALITY caseIgnoreMatch
       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    olcObjectClasses: {1}( 1.3.6.1.4.1.42.2.27.99.2.1
       NAME 'fwMember'
       DESC 'FeministWiki member'
       SUP inetOrgPerson
       STRUCTURAL
       MAY ( fwRecoveryMail ) )
    

    Attribute permissions

    We want members to be able to change some of their own settings without requiring privilege escalation. We also want the read-only user to be able to find users via the combination of their username and recovery mail address (the password reset mechanism uses this) but not actually see recovery mail addresses. The following LDIF statement may be passed to 'ldapmodify' to make the necessary access control changes:

    # Modification to be made via 'ldapmodify'
    dn: olcDatabase={1}mdb,cn=config
    changetype: modify
    add: olcAccess
    olcAccess: {2}to attrs=sn,mail by self write
    olcAccess: {3}to attrs=fwRecoveryMail by self write by dn.exact="cn=readonly,dc=feministwiki,dc=org" search
    -
    

    Password hashing

    To make sure passwords are stored with the {SSHA} scheme rather than plain text, the ppolicy "password policy overlay" is used. ZYTRAX has a very nice book about LDAP which documents how to enable this: http://www.zytrax.com/books/ldap/ch6/ppolicy.html

    In short, the steps go as follows (these commands should work verbatim):

    # Add the ppolicy schema
    ldapadd -Y external -H ldapi:// < /etc/ldap/schema/ppolicy.ldif
    
    # Enable the ppolicy dynamic module
    ldapmodify -Y external -H ldapi:// <<EOF
    dn: cn=module{0},cn=config
    changetype: modify
    add: olcModuleLoad
    olcModuleLoad: ppolicy
    EOF
    
    # Add the ppolicy overlay with olcPPolicyHashCleartext set to TRUE
    ldapadd -Y external -H ldapi:// <<EOF
    dn: olcOverlay=ppolicy,olcDatabase={1}mdb,cn=config
    objectClass: olcPPolicyConfig
    olcOverlay: ppolicy
    olcPPolicyHashCleartext: TRUE
    EOF
    

    Time of last login

    The lastbind module of OpenLDAP keeps track of when a user last logged in.

    Load the module:

    # Modification to be made via 'ldapmodify'
    dn: cn=module{0},cn=config
    changetype: modify
    add: olcModuleLoad
    olcModuleLoad: lastbind
    

    And enable the overlay:

    # Addition to be made via 'ldapadd'
    dn: olcOverlay=lastbind,olcDatabase={1}mdb,cn=config
    objectClass: olcLastBindConfig
    olcOverlay: lastbind
    olcLastBindPrecision: 60