FeministWiki:LDAP Schema: differenze tra le versioni
(2 versioni intermedie di uno stesso utente non sono mostrate) | |||
Riga 43: | Riga 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. | ||
# | # 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 | ||
Riga 49: | Riga 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. | ||
Riga 54: | Riga 56: | ||
=== Custom objectClass === | === Custom objectClass === | ||
The following | The following command creates the <code>fwMember</code> object class. | ||
ldapadd -Y external -H ldapi:// <<EOF | |||
dn: cn=feministwiki,cn=schema,cn=config | dn: cn=feministwiki,cn=schema,cn=config | ||
objectClass: olcSchemaConfig | objectClass: olcSchemaConfig | ||
Riga 71: | Riga 73: | ||
STRUCTURAL | STRUCTURAL | ||
MAY ( fwRecoveryMail ) ) | MAY ( fwRecoveryMail ) ) | ||
EOF | |||
=== Attribute permissions === | === Attribute permissions === | ||
Riga 80: | Riga 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 | The following command makes the necessary access control changes: | ||
ldapmodify -Y external -H ldapi:// <<EOF | |||
dn: olcDatabase={1}mdb,cn=config | dn: olcDatabase={1}mdb,cn=config | ||
changetype: modify | changetype: modify | ||
Riga 89: | Riga 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. | ||
Riga 136: | Riga 139: | ||
pwdLockout: TRUE | pwdLockout: TRUE | ||
pwdLockoutDuration: 3600 | pwdLockoutDuration: 3600 | ||
pwdMaxFailure: | pwdMaxFailure: 10 | ||
pwdFailureCountInterval: 3600 | |||
EOF | EOF | ||
Riga 147: | Riga 151: | ||
EOF | EOF | ||
With these settings, | 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 === | ||
Riga 153: | Riga 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 | |||
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 | |||
# Enable the overlay | |||
ldapadd -Y external -H ldapi:// <<EOF | |||
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 |
Versione attuale delle 21:35, 2 apr 2020
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 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.
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.
# Add read-only user ldapadd -xy ~/pwd/ldap <<EOF dn: cn=readonly,dc=feministwiki,dc=org objectClass: simpleSecurityObject objectClass: organizationalRole cn: readonly description: Read-only user EOF
No fiddling with access control is needed, since read-only access is the default.
Custom objectClass
The following command creates the fwMember
object class.
ldapadd -Y external -H ldapi:// <<EOF 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 ) ) EOF
Attribute permissions
We want to make the following changes to the default LDAP permissions:
- Members should be able to change their own display name (
sn
) and e-mail address (mail
). - The read-only user should be able to find users via the combination of their username and recovery mail address (
fwRecoveryMail
), 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
manager
field).
The following command makes the necessary access control changes:
ldapmodify -Y external -H ldapi:// <<EOF 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 olcAccess: {4}to attrs=manager by self read EOF
Note that olcAccess
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 {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
Further, ppolicy
is used to enable brute-force protection. For this, we need to add an entry of the object class pwdPolicy
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
The lastbind
module of OpenLDAP keeps track of when a user last logged in.
# Load the module ldapmodify -Y external -H ldapi:// <<EOF dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: lastbind EOF
# Enable the overlay ldapadd -Y external -H ldapi:// <<EOF dn: olcOverlay=lastbind,olcDatabase={1}mdb,cn=config objectClass: olcLastBindConfig olcOverlay: lastbind olcLastBindPrecision: 60 EOF