Jump to content

FeministWiki:LDAP Schema: Difference between revisions

(5 intermediate revisions by the same user not shown)
Line 43: Line 43:
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.
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'
  # Add read-only user
ldapadd -xy ~/pwd/ldap <<EOF
  dn: cn=readonly,dc=feministwiki,dc=org
  dn: cn=readonly,dc=feministwiki,dc=org
  objectClass: simpleSecurityObject
  objectClass: simpleSecurityObject
Line 49: Line 50:
  cn: readonly
  cn: readonly
  description: Read-only user
  description: Read-only user
EOF


No fiddling with access control is needed, since read-only access is the default.
No fiddling with access control is needed, since read-only access is the default.
Line 54: Line 56:
=== Custom objectClass ===
=== Custom objectClass ===


The following LDIF statement may be passed to 'ldapadd' to create the <code>fwMember</code> object class.
The following command creates the <code>fwMember</code> object class.


  # Addition to be made via 'ldapadd'
  ldapadd -Y external -H ldapi:// <<EOF
  dn: cn=feministwiki,cn=schema,cn=config
  dn: cn=feministwiki,cn=schema,cn=config
  objectClass: olcSchemaConfig
  objectClass: olcSchemaConfig
Line 71: Line 73:
     STRUCTURAL
     STRUCTURAL
     MAY ( fwRecoveryMail ) )
     MAY ( fwRecoveryMail ) )
EOF


=== Attribute permissions ===
=== Attribute permissions ===
Line 80: Line 83:
* Members should not be able to see who a member was added by (the <code>manager</code> field).
* 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:
The following command makes the necessary access control changes:


  # Modification to be made via 'ldapmodify'
  ldapmodify -Y external -H ldapi:// <<EOF
  dn: olcDatabase={1}mdb,cn=config
  dn: olcDatabase={1}mdb,cn=config
  changetype: modify
  changetype: modify
Line 89: Line 92:
  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
  olcAccess: {4}to attrs=manager by self read
  -
  EOF


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.
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 hashing ===
=== 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
Line 117: Line 120:
  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: 10
pwdFailureCountInterval: 3600
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, ten consecutive authentication failures with a username will lock the account for an hour.  Login failures are also cleared after an hour.  This means it's possible to try ten passwords per hour during a brute-force attack, which won't get the attacker very far.


=== Time of last login ===
=== Time of last login ===
Line 122: Line 157:
The <code>lastbind</code> module of OpenLDAP keeps track of when a user last logged in.
The <code>lastbind</code> module of OpenLDAP keeps track of when a user last logged in.


Load the module:
# Load the module
 
  ldapmodify -Y external -H ldapi:// <<EOF
  # Modification to be made via 'ldapmodify'
  dn: cn=module{0},cn=config
  dn: cn=module{0},cn=config
  changetype: modify
  changetype: modify
  add: olcModuleLoad
  add: olcModuleLoad
  olcModuleLoad: lastbind
  olcModuleLoad: lastbind
EOF


And enable the overlay:
# Enable the overlay
   
  ldapadd -Y external -H ldapi:// <<EOF
# Addition to be made via 'ldapadd'
  dn: olcOverlay=lastbind,olcDatabase={1}mdb,cn=config
  dn: olcOverlay=lastbind,olcDatabase={1}mdb,cn=config
  objectClass: olcLastBindConfig
  objectClass: olcLastBindConfig
  olcOverlay: lastbind
  olcOverlay: lastbind
  olcLastBindPrecision: 60
  olcLastBindPrecision: 60
EOF