FeministWiki:LDAP Schema: Difference between revisions

 
(9 intermediate revisions by the same user not shown)
Line 38: 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.
=== Tips on the usage of ldap commands ===
Commands such as ldapsearch, ldapmodify, etc. require authentication.  The correct method depends on whether you want to interact with the configuration database found in {{C|/etc/ldap/slapd.d}}, or the actual data database found in {{C|/var/lib/ldap}}.
For configuration, use {{C|-Y external -H ldapi://}} to connect directly with root permissions, so no actual LDAP domain login is needed.
For data, use {{C|-xy ~/pwd/ldap}} to use the LDAP domain admin password.  The file {{C|~/.ldaprc}} should contain the following, so you don't have to specify the domain admin explicitly every time:
BINDDN cn=admin,dc=feministwiki,dc=org


=== Read-only user ===
=== Read-only user ===
Line 43: Line 53:
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 60:
  cn: readonly
  cn: readonly
  description: Read-only user
  description: Read-only user
userPassword: $(cat ~/pwd/ldap-readonly)
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 67:
=== Custom objectClass ===
=== Custom objectClass ===


The following LDIF statement may be passed to <code>ldapadd</code> 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 84:
     STRUCTURAL
     STRUCTURAL
     MAY ( fwRecoveryMail ) )
     MAY ( fwRecoveryMail ) )
EOF


=== Attribute permissions ===
=== Attribute permissions ===
Line 80: Line 94:
* 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 103:
  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 99: Line 113:
In short, the steps go as follows (these commands ''should'' work verbatim):
In short, the steps go as follows (these commands ''should'' work verbatim):


  # Add the ppolicy schema
  # Only needed on old versions of slapd, to 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
Line 117: Line 131:
  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
pwdFailureCountInterval: 3600
pwdLockoutDuration: 3600
pwdMaxFailure: 30
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, 30 consecutive authentication failures with a username will lock the account for an hour.  Login failures are also cleared after an hour, meaning it's possible to try 30 passwords per hour, which won't get an attacker far.


=== Time of last login ===
=== Time of last login ===
Line 122: Line 168:
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