Powerful Open Source LDAP

From Port389

This page contains the roadmap and some recent release history for the 389 project.

Contents

History

History contains the history of the project, and what features were added when.

Next Steps

Version 1.2.11

  • Support multiple Simple Paged Result searches in a single connection Simple_Paged_Results_Design
  • Support SASL/PLAIN
  • logconv.pl improvements
  • Support for Berkeley DB version 5
  • Improved support for transactions and backend transaction plugins
    • DNA and USN use backend transaction plugins
    • all plugins except replication, cos, roles, and views use backend transaction plugins
  • Allow internal operations triggered by external operations (referential integrity, memberof, etc.) to use modifiersName/creatorsName from original external operation
    • Added a new config attribute nsslapd-plugin-binddn-tracking to cn=config. It is off by default. If set to on, the server will update a set of new operational attributes: internalModifiersname & internalCreatorsname. These attributes will store the DN of the plugin that made the update, while modifiersname/creatorsname will now be the bind dn that initiated the original external operation.
  • Windows Sync API version 2 Windows_Sync_Plugin_API
  • Ability to disable replication agreements
    • nsds5ReplicaEnabled - if this is set to "off" in the replication agreement entry, the agreement will be disabled
  • CLEANRUV improvements Howto:CLEANRUV
    • New CLEANALLRUV and RELEASERUV tasks
  • Disk monitoring Disk_Monitoring
    • Can enable monitoring of disk usage, particularly for databases and log files, with warnings upon reaching certain thresholds of disk usage
  • Allow setup to work with IPv6

Version 1.3

The following features are planned for 389 Directory Server 1.3.

  • Auto-generated SLAPI reference
    • generate plugin programmers reference from code + comments (e.g. doxygen)

Future

  • AD integration alignment - (in order for RHDS to be used as an identity store for read only Active Directory cross forest trust we need to implement a number of features:
    • Present AD DIT style read-only view of the data stored in the DS part of the tree
      • AD clients see a DIT that looks like an AD DIT, *nix and regular LDAPv3 clients see the usual tree
    • ranged attribute values - e.g. for large static groups - MS supports attrname;M-N where M and N are numbers expressing the range
    • Need ability to specify and ordering for attribute values or the ability to retrieve attributes values in a certain order - control? attr subtype?
      • This may be needed less if the painful tool (Microsoft Managment console) is not used.
  • Schema
  • Security
    • Option to turn off SASL mechanisms
    • Password Policy
      • Make the DS password policy pluggable - be able to support plugins such as cracklib
    • Restrict directory manager bind by host/IP address
    • Get rid of certmap.conf - use SASL mapping (cert auth is really just SASL/EXTERNAL)
  • Improve RFC correctness with respect to the new LDAP RFCs (RFC4511 etc.)
  • Support GUIDs in ACIs to reference entries
    • confirm group filter functionality in 1.2 supports this
  • improve replication conflict handling
    • current handling of conflicts can confuse searches such as KDC. perhaps create separate part of the tree to store conflict entries.
  • Data Compression
    • command line db2ldif/ldif2db can read write to pipe, so you can do db2ldif -n userRoot -a - | gzip > file.ldif.gz
    • ability to import/export compressed files via the task interface
    • ability to store/retrieve compressed attribute values (think large CRLs)
    • ability to request either a compressed value or uncompressed
    • possibly use attr subtypes e.g. ldapsearch .... certRevList;x-gzip
    • need to be able to use compressed values in replication too, especially for replica init
    • bdb may have support for compression
  • Allow authentication without an entry
    • If just using the directory server for authentication, want to allow the directory server to authenticate identities
    • This is mostly applicable for non-password based auth, or cases where the directory server is not the credential store
    • For example, cert based auth; SASL auth (GSSAPI, other cases where you pass off the auth decision to sasl), PAM pass through, other types of pass through auth
    • In this case, you want to allow the auth even if there is no user entry
    • this probably wouldn't work for simple auth (no user entry to retrieve userPassword from)
    • Need to be able to use access control, resource limits, groups/roles, CoS, with these user identities
  • Roles with explicit scoping
    • Ability to define roles/CoS that apply to scopes other than the container subtree
    • e.g. have a roleSubtree or cosSubtree attribute
  • CoS define attribute values based on regex match/substitution
    • For example, be able to define homeDirectory based on uid
    • cosAttribute: uid
    • cosDestinationAttribute: homeDirectory
    • cosRegex: s,(.+),/home/\1,
  • Log compression - compress logs when rotating
  • Log robustness - don't stop working when log volume fills up
  • WinSync attribute mapping configuration
    • support attributes other than hardcoded list
    • be able to split/join attributes
    • be able to define regex match/substitution for attribute value mappings
  • Plug-in support for languages other than C
    • python, Java, perl
  • Support for subtree and one level searches rooted at "" (i.e. null suffix support)
  • Bi-directonally linked attributes similar to memberOf (about a dozen).
  • Atomic and consistent updates for links. This might imply transactions, or some other interesting solution, but everything must be atomic so that the bi-directional links are created in one step and never get out of synch.
  • Dynamic group expansion
    • Define a dynamic group, and have the member/uniqueMember attribute of this group automatically be populated by the server
    • clients can then just search for member like with a regular static posix group
  • Configuration replication
    • we already replicate schema changes, and configuration stored in the tree (aci, roles, CoS, etc.)
    • typical use case is when adding indexes to a master, you want those indexes replicated to all consumers
    • there are many other types of configuration we might want to replicate - new databases, suffixes, sasl maps, plugin config, etc.
  • logconv.pl enhancements
    • switch to hide unindexed searches in verbose mode
  • regular expressions in ACIs
    • for example, allow a user to add or modify a value just in case the new value matches the regex. Or the group or dn of the user matches the regex...
Retrieved from "http://directory.fedoraproject.org/wiki/Roadmap"
Account