FeministWiki:LDAP Schema: diferenças entre revisões

(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...")
 
 
(Há 4 edições intermédias do mesmo utilizador que não estão a ser apresentadas)
Linha 1: Linha 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
Linha 34: Linha 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 ===


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 <code>ldapadd</code> 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
Linha 57: Linha 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 to make the following changes to the default LDAP permissions:
 
* Members should be able to change their own display name (<code>sn</code>) and e-mail address (<code>mail</code>).
* The read-only user should be able to find users via the combination of their username and recovery mail address (<code>fwRecoveryMail</code>), but not actually see their recovery mail addresses.  (The password reset mechanism uses this.)
* Members should not be able to see who a member was added by (the <code>manager</code> field).
 
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
Linha 65: Linha 88:
  olcAccess: {2}to attrs=sn,mail by self write
  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
  olcAccess: {3}to attrs=fwRecoveryMail by self write by dn.exact="cn=readonly,dc=feministwiki,dc=org" search
olcAccess: {4}to attrs=manager by self read
  -
  -


=== Password hashing ===
Note that <code>olcAccess</code> entries are evaluated in order, and the first match takes effect.  This can affect performance.  In the statement above, we start inserting entries from index 2, because indexes 0 and 1 already have some meaningful default entries.
 
=== Password policy ===


To make sure passwords are stored with the <code>{SSHA}</code> scheme rather than plain text, the <code>ppolicy</code> "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
To make sure passwords are stored with the <code>{SSHA}</code> scheme rather than plain text, the <code>ppolicy</code> "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
Linha 74: Linha 100:


  # 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
Linha 85: Linha 111:
   
   
  # 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
Linha 91: Linha 117:
  olcPPolicyHashCleartext: TRUE
  olcPPolicyHashCleartext: TRUE
  EOF
  EOF
Further, <code>ppolicy</code> is used to enable brute-force protection.  For this, we need to add an entry of the object class <code>pwdPolicy</code> to the directory, add attributes related to brute-force protection, and then set it as the default password policy:
# Add an OU for password policies
ldapadd -xy ~/pwd/ldap <<EOF
dn: ou=pwdPolicies,dc=feministwiki,dc=org
objectClass: organizationalUnit
ou: pwdPolicies
EOF
# Add the pwdPolicy object
ldapadd -xy ~/pwd/ldap <<EOF
dn: cn=default,ou=pwdPolicies,dc=feministwiki,dc=org
objectClass: applicationProcess
objectClass: pwdPolicy
cn: default
pwdAttribute: userPassword
pwdLockout: TRUE
pwdLockoutDuration: 3600
pwdMaxFailure: 5
EOF
# Set it as the default password policy
ldapmodify -Y external -H ldapi:// <<EOF
dn: olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config
changetype: modify
add: olcPPolicyDefault
olcPPolicyDefault: cn=default,ou=pwdPolicies,dc=feministwiki,dc=org
EOF
With these settings, five consecutive authentication failures with a username will lock the account for an hour.
=== 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