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

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

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

Linha 39:

Linha 56:

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

objectClass: olcSchemaConfig

Linha 57:

Linha 74:

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

changetype: modify

Linha 74:

Linha 91:

# 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

ldapmodify -Y external -H ldapi:/// <<EOF

ldapmodify -Y external -H ldapi:// <<EOF

dn: cn=module{0},cn=config

changetype: modify

Linha 85:

Linha 102:

# 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

objectClass: olcPPolicyConfig

Linha 91:

Linha 108:

olcPPolicyHashCleartext: TRUE

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