FeministWiki:LDAP Schema: Difference between revisions
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...") |
(No difference)
|
Revision as of 18:57, 23 July 2019
The member database of the FeministWiki is stored via LDAP. 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) anduid
(user ID) fields both contain the username. This is because some software is preconfigured to look atuid
, while most look atcn
. - 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}( 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. 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 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