FeministWiki:LDAP Schema

From FeministWiki
Revision as of 19:57, 23 July 2019 by Technician (talk | contribs) (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...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

The member database of the FeministWiki is stored via LDAP. The basic structure looks like this:

    - 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
    - ...
    objectClass: groupOfNames
    cn: members
    member: username
    member: username2
    member: ...


  • 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.

Custom objectClass

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

# Entry to add, with e.g. 'ldapadd' tool
dn: cn=feministwiki,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: feministwiki
olcAttributeTypes: {0}(
   NAME 'fwRecoveryMail'
   DESC 'FeministWiki password recovery mail'
   EQUALITY caseIgnoreMatch
olcObjectClasses: {1}(
   NAME 'fwMember'
   DESC 'FeministWiki member'
   SUP inetOrgPerson
   MAY ( fwRecoveryMail ) )

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:

# Modifications to be made, e.g. 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

# 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