FeministWiki:LDAP Schema - Cronologia

Technician: /* Password policy */

2020-04-02T21:35:30Z

Password policy

← Older revision		Revision as of 21:35, 2 April 2020
Line 140:		Line 140:
	pwdLockoutDuration: 3600		pwdLockoutDuration: 3600
	pwdMaxFailure: 10		pwdMaxFailure: 10
			pwdFailureCountInterval: 3600
	EOF		EOF

Line 150:		Line 151:
	EOF		EOF

	With these settings, ~~five~~ consecutive authentication failures with a username will lock the account for an hour.		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 ===

Technician: /* Password policy */

2020-03-07T23:59:41Z

Password policy

← Older revision		Revision as of 23:59, 7 March 2020
Line 139:		Line 139:
	pwdLockout: TRUE		pwdLockout: TRUE
	pwdLockoutDuration: 3600		pwdLockoutDuration: 3600
	pwdMaxFailure: 5		pwdMaxFailure: 10
	EOF		EOF

Technician il 22:19, 29 feb 2020

2020-02-29T22:19:33Z

← Older revision		Revision as of 22:19, 29 February 2020
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 <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 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.
Line 153:		Line 156:
	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

Technician: /* Password policy */

2020-02-05T21:03:54Z

Password policy

← Older revision		Revision as of 21:03, 5 February 2020
Line 135:		Line 135:
	pwdAttribute: userPassword		pwdAttribute: userPassword
	pwdLockout: TRUE		pwdLockout: TRUE
	pwdLockoutDuration: ~~36000~~		pwdLockoutDuration: 3600
	pwdMaxFailure: 10		pwdMaxFailure: 5
	EOF		EOF

Line 147:		Line 147:
	EOF		EOF

	With these settings, ~~ten~~ consecutive authentication failures with a username will lock the account for ~~ten hours~~.		With these settings, five consecutive authentication failures with a username will lock the account for an hour.

	=== Time of last login ===		=== Time of last login ===

Technician: /* Password hashing */

2020-02-02T22:16:13Z

Password hashing

@@ Line 93: / Line 93: @@
 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
@@ Line 117: / Line 117: @@
   olcPPolicyHashCleartext: TRUE
   EOF
 === Time of last login ===

Technician: /* Custom objectClass */

2019-12-24T18:47:25Z

Custom objectClass

← Older revision		Revision as of 18:47, 24 December 2019
Line 54:		Line 54:
	=== 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.

	# Addition to be made via 'ldapadd'		# Addition to be made via 'ldapadd'

Technician: /* Attribute permissions */

2019-12-24T18:46:06Z

Attribute permissions

← Older revision		Revision as of 18:46, 24 December 2019
Line 74:		Line 74:
	=== Attribute permissions ===		=== Attribute permissions ===

	We want ~~members~~ to be able to change ~~some of~~ their own ~~settings without requiring privilege escalation~~. ~~We also want the~~ read-only user to be able to find users via the combination of their username and recovery mail address (~~the password reset mechanism uses this~~) but not actually see recovery mail addresses. 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:

	# Modification to be made via 'ldapmodify'		# Modification to be made via 'ldapmodify'
Line 82:		Line 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
	-		-

			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 hashing ===

Technician il 17:59, 21 dic 2019

2019-12-21T17:59:21Z

← Older revision		Revision as of 17:59, 21 December 2019
Line 1:		Line 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
Line 34:		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.

			=== 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 ===
Line 39:		Line 56:
	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 'ldapadd' 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
Line 57:		Line 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 members to be able to change some of their own settings without requiring privilege escalation. We also want the read-only user to be able to find users via the combination of their username and recovery mail address (the password reset mechanism uses this) but not actually see recovery mail addresses. 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
Line 74:		Line 91:

	# 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
Line 85:		Line 102:

	# 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
Line 91:		Line 108:
	olcPPolicyHashCleartext: TRUE		olcPPolicyHashCleartext: TRUE
	EOF		EOF

			=== 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

Technician: 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..."

2019-07-23T18:57:16Z

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..."

New page

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 <code>cn</code> (common name) and <code>uid</code> (user ID) fields both contain the username. This is because some software is preconfigured to look at <code>uid</code>, while most look at <code>cn</code>.
* The <code>sn</code> (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 <code>mail</code> 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 <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.

=== Custom objectClass ===

The following LDIF statement may be passed to 'ldapadd' to create the <code>fwMember</code> 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 <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

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