Fedora directory users - Apr 2009 - RE: Proposed new features for 1.3

Would like to see additional monitoring flexibility for snmp - when configuring
multiple ds instances with same port on single multihomed host monitoring
information is agregated by port in the monitoring not by instance and port.

Please provide more information on deprecation of certmap.conf.  Need
flexibility to not rely on dn in cert mapping to anything in directory and rely
on successful tls mutual authentication and truststore configuration.

Script to provide index analysis based on data in  the directory to provide the
following info:
Search performance efficiency of index and index type based on return limits,
and scanidslistlimit.

Compressed ldif(gzip) capability for export, import, and initialization usage.


Dave Partridge
Sent from my Windows Mobile® phone.

-----Original Message-----
From: Rich Megginson <rmeggins@redhat.com>
Sent: Thursday, April 09, 2009 7:23 PM
To: General discussion list for the Fedora Directory server project.
<fedora-directory-users@redhat.com>
Subject: Re: [Fedora-directory-users] Proposed new features for 1.3

Andrey Ivanov wrote:
> I continue with my list
Thanks - I''ve added many of these to the list - questions
below.
>
> * the server should be able to return the members of dynamic groups 
> "on the fly" as if it were real members, the membership attribute
> should be configurable - uniqueMember, member or another
I put this on the Future list:
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

>
> * support of other virtual attributes generated "on the fly"
Can you explain this a little more?
>
> * pam passthrough plug-in should take into account at least the 
> account activation/desactivation (bug *470684* 
> <https://bugzilla.redhat.com/show_bug.cgi?id=470684> ). There is a 
> comment about some additional useful features it in th README file of 
> this plug-in :
> We need to worry about account expiration or lockout e.g. the
user''s
> credentials are valid but the user has been locked out of his/her
> account, or the password has expired, or something like that. Some of
>
>
> this can be handled by LDAP e.g. returning password policy control
> values when the password has expired.
>
>
> * a way to synchronise the configuration of indexes (each time we add 
> an index on one of the replicated servers we need to make it manually 
> on all the others) and some other parameters in "cn=config"
between
> the replicated servers  (a little like the "configuration"
partition
> in active directory), the schema changes are already replicated which 
> is very good
I''m calling this feature "Configuration replication" - I
think it could
be useful for other sorts of configuration.
>
> * enforced attribute syntax validation
Already on the list - Syntax validation checking
>
> * re-verify and validate conformance of the syntaxes, case sensitivity 
> and their matching rules to RFC 
>
(https://www.redhat.com/archives/fedora-directory-users/2008-July/msg00041.html)
>
Already on the list
> * unix socket autobind still does not seem to work (ldapi) - 
>
https://www.redhat.com/archives/fedora-directory-users/2009-February/msg00112.html.
> It could be very useful for various maintenance scripts running on the 
> server.
We tested this with 1.2.0 and it seems to work.  You tested a build from 
source?  Did you use --enable-autobind with configure?  Did you restart 
the server after configuring your autobind and sasl
mapping?
>
> * verification of the server from the viewpoint of memory leaks. Th 
> size of the memory used by the server grows with time (normally we 
> don''t restart the sevrr during several months, so i can follow the
stats)
We regularly run the server test suite with valgrind enabled.  I''m not 
aware of any per connection or per operation leaks.  What exactly are 
you seeing?
>
> * logconv.pl - very useful script, add some more options/ adjustments 
> (for example, a switch to hide unindexed searches in verbose mode). We 
> use it as logwatch.
>
> * a perl script to show the replication statistics (there is one for 
> the we page generation statistics, something more basic, text-only 
> would be very welcome) in text mode - to receiveth reports by mail 
> once per day like logwatch for example
What sort of information are you looking for?  ldapsearch can provide 
most of the useful information.
>
> * regular expressions in ACIs (i know, it is very difficult to do, so 
> maybe somewhere in the timescale of the version 10.0 ? :)) - for 
> example, allow a user to add or modify a value just in case the new 
> value mathes the regex. Or the group or dn of the user matches the 
> regex...
You can do some of that currently with targetattrfilters - see 
*http://tinyurl.com/3yo88r

We added support in 1.2.0 to allow you to specify group membership with 
LDAP search specifications, which does allow some wildcarding, so that 
might help too.
*
>
> * simplify the creation of new syntaxes and their validation/ 
> enforcement (version 11.0? :))
Can you elaborate?
>
> * virtual views allowing to map not only the trees but also the 
> attributes (''cn'' instead of ''uid'' in a
subtree, for example)
Can you elaborate?
>
> * enable regex in certmap.conf for mapping the CNs of the certificates 
> during the certificate authentification of users
This is on the list as
Get rid of certmap.conf - use SASL mapping (cert auth is really just 
SASL/EXTERNAL)
The sasl mapping code uses regular expressions
>
>
>
>
> Other than that i just want to emphasize the great job you are doing 
> adding new features and especially the fantastic reactivity in fixing 
> some critical server bugs (usually it takes only one or two days to 
> have the necessary diff in bugzilla!)
>
> Thank you and please continue the development of this directory server!
And thank you for your suggestions.
>
>
>  
>
>
>
>
>         Thanks - I''ve added these notes to
>         http://directory.fedoraproject.org/wiki/Roadmap#Version_1.3
>
>         Anyone else?  C''mon - surely you have an opinion about a
new
>         feature.
>
>
>             Thanks for all your hard work on this!
>
>  
>
> ------------------------------------------------------------------------
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>   









This e-mail and any attachment is intended for the above name recipient(s) only
and may contain confidential or privileged information.  If you are not an
intended recipient, please notify the sender and delete the message.  Failure to
maintain the confidentiality of this e-mail and any attachment may subject you
to penalties under applicable law.


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for
the sole use of the intended recipient(s) and may contain confidential and
privileged information or otherwise be protected by law. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy all
copies of the original message.

David Partridge wrote:
> Would like to see additional monitoring flexibility for snmp - when
configuring multiple ds instances with same port on single multihomed host
monitoring information is agregated by port in the monitoring not by instance
and port.
>
> Please provide more information on deprecation of certmap.conf.
We would instead use the SASL mapping functionality to map the subjectDN 
in the cert to a DN that the DS knows about.  The SASL mapping code is 
much more powerful and flexible than the certmap.conf code.
*http://tinyurl.com/cqe42v
*
> Need flexibility to not rely on dn in cert mapping to anything in directory
and rely on successful tls mutual authentication and truststore configuration.
>   
I''m not sure I understand - do you want the ability to do cert auth 
without having to have a real entry in the directory server that 
corresponds to the subjectDN?
> Script to provide index analysis based on data in  the directory to provide
the following info:
> Search performance efficiency of index and index type based on return
limits, and scanidslistlimit.
>
> Compressed ldif(gzip) capability for export, import, and initialization
usage.
>   
Ok - Thanks - this is all good stuff.
>
> Dave Partridge
> Sent from my Windows Mobile® phone.
>
> -----Original Message-----
> From: Rich Megginson <rmeggins@redhat.com>
> Sent: Thursday, April 09, 2009 7:23 PM
> To: General discussion list for the Fedora Directory server project.
<fedora-directory-users@redhat.com>
> Subject: Re: [Fedora-directory-users] Proposed new features for 1.3
>
> Andrey Ivanov wrote:
>   
>> I continue with my list
>>     
> Thanks - I''ve added many of these to the list - questions below.
>   
>> * the server should be able to return the members of dynamic groups 
>> "on the fly" as if it were real members, the membership
attribute
>> should be configurable - uniqueMember, member or another
>>     
> I put this on the Future list:
> 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
>
>
>   
>> * support of other virtual attributes generated "on the fly"
>>     
> Can you explain this a little more?
>   
>> * pam passthrough plug-in should take into account at least the 
>> account activation/desactivation (bug *470684* 
>> <https://bugzilla.redhat.com/show_bug.cgi?id=470684> ). There is
a
>> comment about some additional useful features it in th README file of 
>> this plug-in :
>> We need to worry about account expiration or lockout e.g. the
user''s
>> credentials are valid but the user has been locked out of his/her
>> account, or the password has expired, or something like that. Some of
>>
>>
>> this can be handled by LDAP e.g. returning password policy control
>> values when the password has expired.
>>
>>
>> * a way to synchronise the configuration of indexes (each time we add 
>> an index on one of the replicated servers we need to make it manually 
>> on all the others) and some other parameters in "cn=config"
between
>> the replicated servers  (a little like the "configuration"
partition
>> in active directory), the schema changes are already replicated which 
>> is very good
>>     
> I''m calling this feature "Configuration replication" - I
think it could
> be useful for other sorts of configuration.
>   
>> * enforced attribute syntax validation
>>     
> Already on the list - Syntax validation checking
>   
>> * re-verify and validate conformance of the syntaxes, case sensitivity 
>> and their matching rules to RFC 
>>
(https://www.redhat.com/archives/fedora-directory-users/2008-July/msg00041.html)
>>
>>     
> Already on the list
>   
>> * unix socket autobind still does not seem to work (ldapi) - 
>>
https://www.redhat.com/archives/fedora-directory-users/2009-February/msg00112.html.
>> It could be very useful for various maintenance scripts running on the 
>> server.
>>     
> We tested this with 1.2.0 and it seems to work.  You tested a build from 
> source?  Did you use --enable-autobind with configure?  Did you restart 
> the server after configuring your autobind and sasl mapping?
>   
>> * verification of the server from the viewpoint of memory leaks. Th 
>> size of the memory used by the server grows with time (normally we 
>> don''t restart the sevrr during several months, so i can follow
the stats)
>>     
> We regularly run the server test suite with valgrind enabled.  I''m
not
> aware of any per connection or per operation leaks.  What exactly are 
> you seeing?
>   
>> * logconv.pl - very useful script, add some more options/ adjustments 
>> (for example, a switch to hide unindexed searches in verbose mode). We 
>> use it as logwatch.
>>
>> * a perl script to show the replication statistics (there is one for 
>> the we page generation statistics, something more basic, text-only 
>> would be very welcome) in text mode - to receiveth reports by mail 
>> once per day like logwatch for example
>>     
> What sort of information are you looking for?  ldapsearch can provide 
> most of the useful information.
>   
>> * regular expressions in ACIs (i know, it is very difficult to do, so 
>> maybe somewhere in the timescale of the version 10.0 ? :)) - for 
>> example, allow a user to add or modify a value just in case the new 
>> value mathes the regex. Or the group or dn of the user matches the 
>> regex...
>>     
> You can do some of that currently with targetattrfilters - see 
> *http://tinyurl.com/3yo88r
>
> We added support in 1.2.0 to allow you to specify group membership with 
> LDAP search specifications, which does allow some wildcarding, so that 
> might help too.
> *
>   
>> * simplify the creation of new syntaxes and their validation/ 
>> enforcement (version 11.0? :))
>>     
> Can you elaborate?
>   
>> * virtual views allowing to map not only the trees but also the 
>> attributes (''cn'' instead of ''uid''
in a subtree, for example)
>>     
> Can you elaborate?
>   
>> * enable regex in certmap.conf for mapping the CNs of the certificates 
>> during the certificate authentification of users
>>     
> This is on the list as
> Get rid of certmap.conf - use SASL mapping (cert auth is really just 
> SASL/EXTERNAL)
> The sasl mapping code uses regular expressions
>   
>>
>>
>> Other than that i just want to emphasize the great job you are doing 
>> adding new features and especially the fantastic reactivity in fixing 
>> some critical server bugs (usually it takes only one or two days to 
>> have the necessary diff in bugzilla!)
>>
>> Thank you and please continue the development of this directory server!
>>     
> And thank you for your suggestions.
>   
>>  
>>
>>
>>
>>
>>         Thanks - I''ve added these notes to
>>         http://directory.fedoraproject.org/wiki/Roadmap#Version_1.3
>>
>>         Anyone else?  C''mon - surely you have an opinion about
a new
>>         feature.
>>
>>
>>             Thanks for all your hard work on this!
>>
>>  
>>
>>
------------------------------------------------------------------------
>>
>> --
>> Fedora-directory-users mailing list
>> Fedora-directory-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>   
>>     
>
>
>
>
>
>
>
>
>
>
> This e-mail and any attachment is intended for the above name recipient(s)
only and may contain confidential or privileged information.  If you are not an
intended recipient, please notify the sender and delete the message.  Failure to
maintain the confidentiality of this e-mail and any attachment may subject you
to penalties under applicable law.
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential and
privileged information or otherwise be protected by law. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy all
copies of the original message.
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

Use case example for certmap.conf for end user:

Customer has desire to share Enterprise Directory information across WAN
for contact information sharing, but has requirement for strong
authentication using PKI.  PKI trust is a PKI Mesh utilizing cross
certification.  Users information in Directory Server One (DS1) are
associated with users issued certificates from PKI One (PKI1).  Users
information in Directory Server Two (DS2) are associated with users
issued certificates from PKI Two (PKI2).

DS1 has no awareness or cross population of entries with DS2, but PKI1
is cross certified with PKI2 and trusted by both populations.  Users
associated with PKI1 have a business requirement to strongly
authenticate with DS2 to locate and collaborate with population of users
in DS2, but have no entry in DS2 and vice versa.  By removing current
capability to strongly authenticate based on TLS configuration but have
NO DN in DS you are removing capability to use SASL External in a cross
certified PKI environment.  User of the product will be forced to use
SASL GSSAPI that causes other security issues or requirements to setup
all of these Kerberos trust and ticketing handling that should not be
required, difficult to sustain and place external dependencies on usage
of the DS product in a federated environment as described.

If directory is utilized as something OTHER than repository for people
similar challenges will present themselves when certificates are issued
for devices, roles, and groups.  Examples include but are not limited to
VOIP device address book capabilities such as CISCO VOIP phones or call
managers, Potentially for extending security capability in hosts that
have host based certificates that may require use of the directory for
backend business processes were Certificate trust and regular expression
checks of DN utilized for the TLS session may be sufficient to utilize
for ACI binding rules.

David M. Partridge
Tangible Software Inc.
dpartridge@tangiblesoftware.com
 
> -----Original Message-----
> From: Rich Megginson [mailto:rmeggins@redhat.com]
> Sent: Thursday, April 09, 2009 11:47 PM
> To: General discussion list for the Fedora Directory server project.
> Subject: Re: [Fedora-directory-users] Proposed new features for 1.3
> 
> David Partridge wrote:
> > Would like to see additional monitoring flexibility for snmp - when
> configuring multiple ds instances with same port on single multihomed
host
> monitoring information is agregated by port in the monitoring not by
> instance and port.
> >
> > Please provide more information on deprecation of certmap.conf.
> We would instead use the SASL mapping functionality to map the
subjectDN
> in the cert to a DN that the DS knows about.  The SASL mapping code is
> much more powerful and flexible than the certmap.conf code.
> *http://tinyurl.com/cqe42v
> *
> > Need flexibility to not rely on dn in cert mapping to anything in
> directory and rely on successful tls mutual authentication and
truststore
> configuration.
> >
> I''m not sure I understand - do you want the ability to do cert
auth
> without having to have a real entry in the directory server that
> corresponds to the subjectDN?
> > Script to provide index analysis based on data in  the directory to
> provide the following info:
> > Search performance efficiency of index and index type based on
return
> limits, and scanidslistlimit.
> >
> > Compressed ldif(gzip) capability for export, import, and
initialization
> usage.
> >
> Ok - Thanks - this is all good stuff.
> >
> > Dave Partridge
> > Sent from my Windows Mobile(r) phone.
> >
> > -----Original Message-----
> > From: Rich Megginson <rmeggins@redhat.com>
> > Sent: Thursday, April 09, 2009 7:23 PM
> > To: General discussion list for the Fedora Directory server project.
> <fedora-directory-users@redhat.com>
> > Subject: Re: [Fedora-directory-users] Proposed new features for 1.3
> >
> > Andrey Ivanov wrote:
> >
> >> I continue with my list
> >>
> > Thanks - I''ve added many of these to the list - questions
below.
> >
> >> * the server should be able to return the members of dynamic
groups
> >> "on the fly" as if it were real members, the membership
attribute
> >> should be configurable - uniqueMember, member or another
> >>
> > I put this on the Future list:
> > 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
> >
> >
> >
> >> * support of other virtual attributes generated "on the
fly"
> >>
> > Can you explain this a little more?
> >
> >> * pam passthrough plug-in should take into account at least the
> >> account activation/desactivation (bug *470684*
> >> <https://bugzilla.redhat.com/show_bug.cgi?id=470684> ).
There is a
> >> comment about some additional useful features it in th README file
of
> >> this plug-in :
> >> We need to worry about account expiration or lockout e.g. the
user''s
> >> credentials are valid but the user has been locked out of his/her
> >> account, or the password has expired, or something like that. Some
of
> >>
> >>
> >> this can be handled by LDAP e.g. returning password policy control
> >> values when the password has expired.
> >>
> >>
> >> * a way to synchronise the configuration of indexes (each time we
add
> >> an index on one of the replicated servers we need to make it
manually
> >> on all the others) and some other parameters in
"cn=config" between
> >> the replicated servers  (a little like the
"configuration"
partition
> >> in active directory), the schema changes are already replicated
which
> >> is very good
> >>
> > I''m calling this feature "Configuration
replication" - I think it
could
> > be useful for other sorts of configuration.
> >
> >> * enforced attribute syntax validation
> >>
> > Already on the list - Syntax validation checking
> >
> >> * re-verify and validate conformance of the syntaxes, case
sensitivity
> >> and their matching rules to RFC
> >> (https://www.redhat.com/archives/fedora-directory-users/2008-
> July/msg00041.html)
> >>
> >>
> > Already on the list
> >
> >> * unix socket autobind still does not seem to work (ldapi) -
> >> https://www.redhat.com/archives/fedora-directory-users/2009-
> February/msg00112.html.
> >> It could be very useful for various maintenance scripts running on
the
> >> server.
> >>
> > We tested this with 1.2.0 and it seems to work.  You tested a build
from
> > source?  Did you use --enable-autobind with configure?  Did you
restart
> > the server after configuring your autobind and sasl mapping?
> >
> >> * verification of the server from the viewpoint of memory leaks.
Th
> >> size of the memory used by the server grows with time (normally we
> >> don''t restart the sevrr during several months, so i can
follow the
> stats)
> >>
> > We regularly run the server test suite with valgrind enabled. 
I''m
not
> > aware of any per connection or per operation leaks.  What exactly
are
> > you seeing?
> >
> >> * logconv.pl - very useful script, add some more options/
adjustments
> >> (for example, a switch to hide unindexed searches in verbose
mode).
We
> >> use it as logwatch.
> >>
> >> * a perl script to show the replication statistics (there is one
for
> >> the we page generation statistics, something more basic, text-only
> >> would be very welcome) in text mode - to receiveth reports by mail
> >> once per day like logwatch for example
> >>
> > What sort of information are you looking for?  ldapsearch can
provide
> > most of the useful information.
> >
> >> * regular expressions in ACIs (i know, it is very difficult to do,
so
> >> maybe somewhere in the timescale of the version 10.0 ? :)) - for
> >> example, allow a user to add or modify a value just in case the
new
> >> value mathes the regex. Or the group or dn of the user matches the
> >> regex...
> >>
> > You can do some of that currently with targetattrfilters - see
> > *http://tinyurl.com/3yo88r
> >
> > We added support in 1.2.0 to allow you to specify group membership
with
> > LDAP search specifications, which does allow some wildcarding, so
that
> > might help too.
> > *
> >
> >> * simplify the creation of new syntaxes and their validation/
> >> enforcement (version 11.0? :))
> >>
> > Can you elaborate?
> >
> >> * virtual views allowing to map not only the trees but also the
> >> attributes (''cn'' instead of
''uid'' in a subtree, for example)
> >>
> > Can you elaborate?
> >
> >> * enable regex in certmap.conf for mapping the CNs of the
certificates
> >> during the certificate authentification of users
> >>
> > This is on the list as
> > Get rid of certmap.conf - use SASL mapping (cert auth is really just
> > SASL/EXTERNAL)
> > The sasl mapping code uses regular expressions
> >
> >>
> >>
> >> Other than that i just want to emphasize the great job you are
doing
> >> adding new features and especially the fantastic reactivity in
fixing
> >> some critical server bugs (usually it takes only one or two days
to
> >> have the necessary diff in bugzilla!)
> >>
> >> Thank you and please continue the development of this directory
server!
> >>
> > And thank you for your suggestions.
> >
> >>
> >>
> >>
> >>
> >>
> >>         Thanks - I''ve added these notes to
> >>        
http://directory.fedoraproject.org/wiki/Roadmap#Version_1.3
> >>
> >>         Anyone else?  C''mon - surely you have an opinion
about a
new
> >>         feature.
> >>
> >>
> >>             Thanks for all your hard work on this!
> >>
> >>
> >>
> >>
-----------------------------------------------------------------------
> -
> >>
> >> --
> >> Fedora-directory-users mailing list
> >> Fedora-directory-users@redhat.com
> >> https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >>
> >>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > This e-mail and any attachment is intended for the above name
> recipient(s) only and may contain confidential or privileged
information.
> If you are not an intended recipient, please notify the sender and
delete
> the message.  Failure to maintain the confidentiality of this e-mail
and
> any attachment may subject you to penalties under applicable law.
> >
> >
> > CONFIDENTIALITY NOTICE: This e-mail message, including any
attachments,
> is for the sole use of the intended recipient(s) and may contain
> confidential and privileged information or otherwise be protected by
law.
> Any unauthorized review, use, disclosure or distribution is
prohibited. If
> you are not the intended recipient, please contact the sender by reply
e-
> mail and destroy all copies of the original message.
> >
> > --
> > Fedora-directory-users mailing list
> > Fedora-directory-users@redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >
> 









This e-mail and any attachment is intended for the above name recipient(s) only
and may contain confidential or privileged information.  If you are not an
intended recipient, please notify the sender and delete the message.  Failure to
maintain the confidentiality of this e-mail and any attachment may subject you
to penalties under applicable law.


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for
the sole use of the intended recipient(s) and may contain confidential and
privileged information or otherwise be protected by law. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy all
copies of the original message.

David Partridge wrote:
> Would like to see additional monitoring flexibility for snmp - when
configuring multiple ds instances with same port on single multihomed host
monitoring information is agregated by port in the monitoring not by instance
and port.
>
> Please provide more information on deprecation of certmap.conf.  Need
flexibility to not rely on dn in cert mapping to anything in directory and rely
on successful tls mutual authentication and truststore configuration.
>
> Script to provide index analysis based on data in  the directory to provide
the following info:
> Search performance efficiency of index and index type based on return
limits, and scanidslistlimit.
>
> Compressed ldif(gzip) capability for export, import, and initialization
usage.
>   
A follow up to this - directory server can import from stdin and export 
to stdout, so you can do this:
db2ldif -n userRoot -a - | gzip > db.ldif.gz
and
gunzip -c db.ldif.gz | ldif2db -n userRoot -i -

For initialization usage, I guess that would mean online init (or remote 
bulk load using ldapmodify -B).  In that case, since the data is BER 
encoded already, it would be better to investigate attribute value 
compression, as discussed elsewhere in this thread.
>
> Dave Partridge
> Sent from my Windows Mobile® phone.
>
> -----Original Message-----
> From: Rich Megginson <rmeggins@redhat.com>
> Sent: Thursday, April 09, 2009 7:23 PM
> To: General discussion list for the Fedora Directory server project.
<fedora-directory-users@redhat.com>
> Subject: Re: [Fedora-directory-users] Proposed new features for 1.3
>
> Andrey Ivanov wrote:
>   
>> I continue with my list
>>     
> Thanks - I''ve added many of these to the list - questions below.
>   
>> * the server should be able to return the members of dynamic groups 
>> "on the fly" as if it were real members, the membership
attribute
>> should be configurable - uniqueMember, member or another
>>     
> I put this on the Future list:
> 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
>
>
>   
>> * support of other virtual attributes generated "on the fly"
>>     
> Can you explain this a little more?
>   
>> * pam passthrough plug-in should take into account at least the 
>> account activation/desactivation (bug *470684* 
>> <https://bugzilla.redhat.com/show_bug.cgi?id=470684> ). There is
a
>> comment about some additional useful features it in th README file of 
>> this plug-in :
>> We need to worry about account expiration or lockout e.g. the
user''s
>> credentials are valid but the user has been locked out of his/her
>> account, or the password has expired, or something like that. Some of
>>
>>
>> this can be handled by LDAP e.g. returning password policy control
>> values when the password has expired.
>>
>>
>> * a way to synchronise the configuration of indexes (each time we add 
>> an index on one of the replicated servers we need to make it manually 
>> on all the others) and some other parameters in "cn=config"
between
>> the replicated servers  (a little like the "configuration"
partition
>> in active directory), the schema changes are already replicated which 
>> is very good
>>     
> I''m calling this feature "Configuration replication" - I
think it could
> be useful for other sorts of configuration.
>   
>> * enforced attribute syntax validation
>>     
> Already on the list - Syntax validation checking
>   
>> * re-verify and validate conformance of the syntaxes, case sensitivity 
>> and their matching rules to RFC 
>>
(https://www.redhat.com/archives/fedora-directory-users/2008-July/msg00041.html)
>>
>>     
> Already on the list
>   
>> * unix socket autobind still does not seem to work (ldapi) - 
>>
https://www.redhat.com/archives/fedora-directory-users/2009-February/msg00112.html.
>> It could be very useful for various maintenance scripts running on the 
>> server.
>>     
> We tested this with 1.2.0 and it seems to work.  You tested a build from 
> source?  Did you use --enable-autobind with configure?  Did you restart 
> the server after configuring your autobind and sasl mapping?
>   
>> * verification of the server from the viewpoint of memory leaks. Th 
>> size of the memory used by the server grows with time (normally we 
>> don''t restart the sevrr during several months, so i can follow
the stats)
>>     
> We regularly run the server test suite with valgrind enabled.  I''m
not
> aware of any per connection or per operation leaks.  What exactly are 
> you seeing?
>   
>> * logconv.pl - very useful script, add some more options/ adjustments 
>> (for example, a switch to hide unindexed searches in verbose mode). We 
>> use it as logwatch.
>>
>> * a perl script to show the replication statistics (there is one for 
>> the we page generation statistics, something more basic, text-only 
>> would be very welcome) in text mode - to receiveth reports by mail 
>> once per day like logwatch for example
>>     
> What sort of information are you looking for?  ldapsearch can provide 
> most of the useful information.
>   
>> * regular expressions in ACIs (i know, it is very difficult to do, so 
>> maybe somewhere in the timescale of the version 10.0 ? :)) - for 
>> example, allow a user to add or modify a value just in case the new 
>> value mathes the regex. Or the group or dn of the user matches the 
>> regex...
>>     
> You can do some of that currently with targetattrfilters - see 
> *http://tinyurl.com/3yo88r
>
> We added support in 1.2.0 to allow you to specify group membership with 
> LDAP search specifications, which does allow some wildcarding, so that 
> might help too.
> *
>   
>> * simplify the creation of new syntaxes and their validation/ 
>> enforcement (version 11.0? :))
>>     
> Can you elaborate?
>   
>> * virtual views allowing to map not only the trees but also the 
>> attributes (''cn'' instead of ''uid''
in a subtree, for example)
>>     
> Can you elaborate?
>   
>> * enable regex in certmap.conf for mapping the CNs of the certificates 
>> during the certificate authentification of users
>>     
> This is on the list as
> Get rid of certmap.conf - use SASL mapping (cert auth is really just 
> SASL/EXTERNAL)
> The sasl mapping code uses regular expressions
>   
>>
>>
>> Other than that i just want to emphasize the great job you are doing 
>> adding new features and especially the fantastic reactivity in fixing 
>> some critical server bugs (usually it takes only one or two days to 
>> have the necessary diff in bugzilla!)
>>
>> Thank you and please continue the development of this directory server!
>>     
> And thank you for your suggestions.
>   
>>  
>>
>>
>>
>>
>>         Thanks - I''ve added these notes to
>>         http://directory.fedoraproject.org/wiki/Roadmap#Version_1.3
>>
>>         Anyone else?  C''mon - surely you have an opinion about
a new
>>         feature.
>>
>>
>>             Thanks for all your hard work on this!
>>
>>  
>>
>>
------------------------------------------------------------------------
>>
>> --
>> Fedora-directory-users mailing list
>> Fedora-directory-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>   
>>     
>
>
>
>
>
>
>
>
>
>
> This e-mail and any attachment is intended for the above name recipient(s)
only and may contain confidential or privileged information.  If you are not an
intended recipient, please notify the sender and delete the message.  Failure to
maintain the confidentiality of this e-mail and any attachment may subject you
to penalties under applicable law.
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential and
privileged information or otherwise be protected by law. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy all
copies of the original message.
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

David Partridge wrote:
> Use case example for certmap.conf for end user:
>
> Customer has desire to share Enterprise Directory information across WAN
> for contact information sharing, but has requirement for strong
> authentication using PKI.  PKI trust is a PKI Mesh utilizing cross
> certification.  Users information in Directory Server One (DS1) are
> associated with users issued certificates from PKI One (PKI1).  Users
> information in Directory Server Two (DS2) are associated with users
> issued certificates from PKI Two (PKI2).
>
> DS1 has no awareness or cross population of entries with DS2, but PKI1
> is cross certified with PKI2 and trusted by both populations.  Users
> associated with PKI1 have a business requirement to strongly
> authenticate with DS2 to locate and collaborate with population of users
> in DS2, but have no entry in DS2 and vice versa.  By removing current
> capability to strongly authenticate based on TLS configuration but have
> NO DN in DS you are removing capability to use SASL External in a cross
> certified PKI environment.  User of the product will be forced to use
> SASL GSSAPI that causes other security issues or requirements to setup
> all of these Kerberos trust and ticketing handling that should not be
> required, difficult to sustain and place external dependencies on usage
> of the DS product in a federated environment as described.
>
> If directory is utilized as something OTHER than repository for people
> similar challenges will present themselves when certificates are issued
> for devices, roles, and groups.  Examples include but are not limited to
> VOIP device address book capabilities such as CISCO VOIP phones or call
> managers, Potentially for extending security capability in hosts that
> have host based certificates that may require use of the directory for
> backend business processes were Certificate trust and regular expression
> checks of DN utilized for the TLS session may be sufficient to utilize
> for ACI binding rules.
>   
So you want to allow a user from DS1 to authenticate to DS2, without 
having a user entry in DS2.  Then use access control, bind resource 
limits, groups, roles, CoS, etc. without having a real user entry.  I 
think that would be useful for auth in general, not just cert based 
auth.  It comes up often in SASL/GSSAPI auth (wanting to use Kerberos 
auth without having to have a user entry), and is necessary to support 
the types of devices you mention.

One of the things that cert based auth does now is to retrieve the 
userCertificate from the user''s entry and compare it against the cert 
presented in the auth request.  But that (verifyCert) can be turned off 
now.  Would you want the ability to compare the cert presented for auth 
against the known cert for that identity?
> David M. Partridge
> Tangible Software Inc.
> dpartridge@tangiblesoftware.com
>  
>   
>> -----Original Message-----
>> From: Rich Megginson [mailto:rmeggins@redhat.com]
>> Sent: Thursday, April 09, 2009 11:47 PM
>> To: General discussion list for the Fedora Directory server project.
>> Subject: Re: [Fedora-directory-users] Proposed new features for 1.3
>>
>> David Partridge wrote:
>>     
>>> Would like to see additional monitoring flexibility for snmp - when
>>>       
>> configuring multiple ds instances with same port on single multihomed
>>     
> host
>   
>> monitoring information is agregated by port in the monitoring not by
>> instance and port.
>>     
>>> Please provide more information on deprecation of certmap.conf.
>>>       
>> We would instead use the SASL mapping functionality to map the
>>     
> subjectDN
>   
>> in the cert to a DN that the DS knows about.  The SASL mapping code is
>> much more powerful and flexible than the certmap.conf code.
>> *http://tinyurl.com/cqe42v
>> *
>>     
>>> Need flexibility to not rely on dn in cert mapping to anything in
>>>       
>> directory and rely on successful tls mutual authentication and
>>     
> truststore
>   
>> configuration.
>>     
>> I''m not sure I understand - do you want the ability to do cert
auth
>> without having to have a real entry in the directory server that
>> corresponds to the subjectDN?
>>     
>>> Script to provide index analysis based on data in  the directory to
>>>       
>> provide the following info:
>>     
>>> Search performance efficiency of index and index type based on
>>>       
> return
>   
>> limits, and scanidslistlimit.
>>     
>>> Compressed ldif(gzip) capability for export, import, and
>>>       
> initialization
>   
>> usage.
>>     
>> Ok - Thanks - this is all good stuff.
>>     
>>> Dave Partridge
>>> Sent from my Windows Mobile(r) phone.
>>>
>>> -----Original Message-----
>>> From: Rich Megginson <rmeggins@redhat.com>
>>> Sent: Thursday, April 09, 2009 7:23 PM
>>> To: General discussion list for the Fedora Directory server
project.
>>>       
>> <fedora-directory-users@redhat.com>
>>     
>>> Subject: Re: [Fedora-directory-users] Proposed new features for 1.3
>>>
>>> Andrey Ivanov wrote:
>>>
>>>       
>>>> I continue with my list
>>>>
>>>>         
>>> Thanks - I''ve added many of these to the list - questions
below.
>>>
>>>       
>>>> * the server should be able to return the members of dynamic
groups
>>>> "on the fly" as if it were real members, the
membership attribute
>>>> should be configurable - uniqueMember, member or another
>>>>
>>>>         
>>> I put this on the Future list:
>>> 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
>>>
>>>
>>>
>>>       
>>>> * support of other virtual attributes generated "on the
fly"
>>>>
>>>>         
>>> Can you explain this a little more?
>>>
>>>       
>>>> * pam passthrough plug-in should take into account at least the
>>>> account activation/desactivation (bug *470684*
>>>> <https://bugzilla.redhat.com/show_bug.cgi?id=470684> ).
There is a
>>>> comment about some additional useful features it in th README
file
>>>>         
> of
>   
>>>> this plug-in :
>>>> We need to worry about account expiration or lockout e.g. the
>>>>         
> user''s
>   
>>>> credentials are valid but the user has been locked out of
his/her
>>>> account, or the password has expired, or something like that.
Some
>>>>         
> of
>   
>>>> this can be handled by LDAP e.g. returning password policy
control
>>>> values when the password has expired.
>>>>
>>>>
>>>> * a way to synchronise the configuration of indexes (each time
we
>>>>         
> add
>   
>>>> an index on one of the replicated servers we need to make it
>>>>         
> manually
>   
>>>> on all the others) and some other parameters in
"cn=config" between
>>>> the replicated servers  (a little like the
"configuration"
>>>>         
> partition
>   
>>>> in active directory), the schema changes are already replicated
>>>>         
> which
>   
>>>> is very good
>>>>
>>>>         
>>> I''m calling this feature "Configuration
replication" - I think it
>>>       
> could
>   
>>> be useful for other sorts of configuration.
>>>
>>>       
>>>> * enforced attribute syntax validation
>>>>
>>>>         
>>> Already on the list - Syntax validation checking
>>>
>>>       
>>>> * re-verify and validate conformance of the syntaxes, case
>>>>         
> sensitivity
>   
>>>> and their matching rules to RFC
>>>> (https://www.redhat.com/archives/fedora-directory-users/2008-
>>>>         
>> July/msg00041.html)
>>     
>>>>         
>>> Already on the list
>>>
>>>       
>>>> * unix socket autobind still does not seem to work (ldapi) -
>>>> https://www.redhat.com/archives/fedora-directory-users/2009-
>>>>         
>> February/msg00112.html.
>>     
>>>> It could be very useful for various maintenance scripts running
on
>>>>         
> the
>   
>>>> server.
>>>>
>>>>         
>>> We tested this with 1.2.0 and it seems to work.  You tested a build
>>>       
> from
>   
>>> source?  Did you use --enable-autobind with configure?  Did you
>>>       
> restart
>   
>>> the server after configuring your autobind and sasl mapping?
>>>
>>>       
>>>> * verification of the server from the viewpoint of memory
leaks. Th
>>>> size of the memory used by the server grows with time (normally
we
>>>> don''t restart the sevrr during several months, so i
can follow the
>>>>         
>> stats)
>>     
>>> We regularly run the server test suite with valgrind enabled. 
I''m
>>>       
> not
>   
>>> aware of any per connection or per operation leaks.  What exactly
>>>       
> are
>   
>>> you seeing?
>>>
>>>       
>>>> * logconv.pl - very useful script, add some more options/
>>>>         
> adjustments
>   
>>>> (for example, a switch to hide unindexed searches in verbose
mode).
>>>>         
> We
>   
>>>> use it as logwatch.
>>>>
>>>> * a perl script to show the replication statistics (there is
one
>>>>         
> for
>   
>>>> the we page generation statistics, something more basic,
text-only
>>>> would be very welcome) in text mode - to receiveth reports by
mail
>>>> once per day like logwatch for example
>>>>
>>>>         
>>> What sort of information are you looking for?  ldapsearch can
>>>       
> provide
>   
>>> most of the useful information.
>>>
>>>       
>>>> * regular expressions in ACIs (i know, it is very difficult to
do,
>>>>         
> so
>   
>>>> maybe somewhere in the timescale of the version 10.0 ? :)) -
for
>>>> example, allow a user to add or modify a value just in case the
new
>>>> value mathes the regex. Or the group or dn of the user matches
the
>>>> regex...
>>>>
>>>>         
>>> You can do some of that currently with targetattrfilters - see
>>> *http://tinyurl.com/3yo88r
>>>
>>> We added support in 1.2.0 to allow you to specify group membership
>>>       
> with
>   
>>> LDAP search specifications, which does allow some wildcarding, so
>>>       
> that
>   
>>> might help too.
>>> *
>>>
>>>       
>>>> * simplify the creation of new syntaxes and their validation/
>>>> enforcement (version 11.0? :))
>>>>
>>>>         
>>> Can you elaborate?
>>>
>>>       
>>>> * virtual views allowing to map not only the trees but also the
>>>> attributes (''cn'' instead of
''uid'' in a subtree, for example)
>>>>
>>>>         
>>> Can you elaborate?
>>>
>>>       
>>>> * enable regex in certmap.conf for mapping the CNs of the
>>>>         
> certificates
>   
>>>> during the certificate authentification of users
>>>>
>>>>         
>>> This is on the list as
>>> Get rid of certmap.conf - use SASL mapping (cert auth is really
just
>>> SASL/EXTERNAL)
>>> The sasl mapping code uses regular expressions
>>>
>>>       
>>>> Other than that i just want to emphasize the great job you are
>>>>         
> doing
>   
>>>> adding new features and especially the fantastic reactivity in
>>>>         
> fixing
>   
>>>> some critical server bugs (usually it takes only one or two
days to
>>>> have the necessary diff in bugzilla!)
>>>>
>>>> Thank you and please continue the development of this directory
>>>>         
> server!
>   
>>> And thank you for your suggestions.
>>>
>>>       
>>>>
>>>>
>>>>
>>>>         Thanks - I''ve added these notes to
>>>>        
http://directory.fedoraproject.org/wiki/Roadmap#Version_1.3
>>>>
>>>>         Anyone else?  C''mon - surely you have an
opinion about a
>>>>         
> new
>   
>>>>         feature.
>>>>
>>>>
>>>>             Thanks for all your hard work on this!
>>>>
>>>>
>>>>
>>>>
>>>>         
> -----------------------------------------------------------------------
>   
>> -
>>     
>>>> --
>>>> Fedora-directory-users mailing list
>>>> Fedora-directory-users@redhat.com
>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>
>>>>
>>>>         
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> This e-mail and any attachment is intended for the above name
>>>       
>> recipient(s) only and may contain confidential or privileged
>>     
> information.
>   
>> If you are not an intended recipient, please notify the sender and
>>     
> delete
>   
>> the message.  Failure to maintain the confidentiality of this e-mail
>>     
> and
>   
>> any attachment may subject you to penalties under applicable law.
>>     
>>> CONFIDENTIALITY NOTICE: This e-mail message, including any
>>>       
> attachments,
>   
>> is for the sole use of the intended recipient(s) and may contain
>> confidential and privileged information or otherwise be protected by
>>     
> law.
>   
>> Any unauthorized review, use, disclosure or distribution is
>>     
> prohibited. If
>   
>> you are not the intended recipient, please contact the sender by reply
>>     
> e-
>   
>> mail and destroy all copies of the original message.
>>     
>>> --
>>> Fedora-directory-users mailing list
>>> Fedora-directory-users@redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>
>>>       
>
>
>
>
>
>
>
>
>
>
> This e-mail and any attachment is intended for the above name recipient(s)
only and may contain confidential or privileged information.  If you are not an
intended recipient, please notify the sender and delete the message.  Failure to
maintain the confidentiality of this e-mail and any attachment may subject you
to penalties under applicable law.
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential and
privileged information or otherwise be protected by law. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy all
copies of the original message.
>
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

Agreed, BUT how do I do this with features of Task Invocation Via LDAP
if it is not part of the core product?

David M. Partridge
Tangible Software Inc.
Sr. Security Engineer
2010 Corporate Ridge
Suite 620
McLean, Virginia 22102
Office     800-913-9901 x 3001
Mobile   571-286-9628
Fax        703-288-1226
dpartridge@tangiblesoftware.com
 
> -----Original Message-----
> From: Rich Megginson [mailto:rmeggins@redhat.com]
> Sent: Friday, April 10, 2009 9:29 AM
> To: General discussion list for the Fedora Directory server project.
> Subject: Re: [Fedora-directory-users] Proposed new features for 1.3
> 
> David Partridge wrote:
> > Would like to see additional monitoring flexibility for snmp - when
> configuring multiple ds instances with same port on single multihomed
host
> monitoring information is agregated by port in the monitoring not by
> instance and port.
> >
> > Please provide more information on deprecation of certmap.conf.
Need
> flexibility to not rely on dn in cert mapping to anything in directory
and
> rely on successful tls mutual authentication and truststore
configuration.
> >
> > Script to provide index analysis based on data in  the directory to
> provide the following info:
> > Search performance efficiency of index and index type based on
return
> limits, and scanidslistlimit.
> >
> > Compressed ldif(gzip) capability for export, import, and
initialization
> usage.
> >
> A follow up to this - directory server can import from stdin and
export
> to stdout, so you can do this:
> db2ldif -n userRoot -a - | gzip > db.ldif.gz
> and
> gunzip -c db.ldif.gz | ldif2db -n userRoot -i -
> 
> For initialization usage, I guess that would mean online init (or
remote
> bulk load using ldapmodify -B).  In that case, since the data is BER
> encoded already, it would be better to investigate attribute value
> compression, as discussed elsewhere in this thread.
> >
> > Dave Partridge
> > Sent from my Windows Mobile(r) phone.
> >
> > -----Original Message-----
> > From: Rich Megginson <rmeggins@redhat.com>
> > Sent: Thursday, April 09, 2009 7:23 PM
> > To: General discussion list for the Fedora Directory server project.
> <fedora-directory-users@redhat.com>
> > Subject: Re: [Fedora-directory-users] Proposed new features for 1.3
> >
> > Andrey Ivanov wrote:
> >
> >> I continue with my list
> >>
> > Thanks - I''ve added many of these to the list - questions
below.
> >
> >> * the server should be able to return the members of dynamic
groups
> >> "on the fly" as if it were real members, the membership
attribute
> >> should be configurable - uniqueMember, member or another
> >>
> > I put this on the Future list:
> > 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
> >
> >
> >
> >> * support of other virtual attributes generated "on the
fly"
> >>
> > Can you explain this a little more?
> >
> >> * pam passthrough plug-in should take into account at least the
> >> account activation/desactivation (bug *470684*
> >> <https://bugzilla.redhat.com/show_bug.cgi?id=470684> ).
There is a
> >> comment about some additional useful features it in th README file
of
> >> this plug-in :
> >> We need to worry about account expiration or lockout e.g. the
user''s
> >> credentials are valid but the user has been locked out of his/her
> >> account, or the password has expired, or something like that. Some
of
> >>
> >>
> >> this can be handled by LDAP e.g. returning password policy control
> >> values when the password has expired.
> >>
> >>
> >> * a way to synchronise the configuration of indexes (each time we
add
> >> an index on one of the replicated servers we need to make it
manually
> >> on all the others) and some other parameters in
"cn=config" between
> >> the replicated servers  (a little like the
"configuration"
partition
> >> in active directory), the schema changes are already replicated
which
> >> is very good
> >>
> > I''m calling this feature "Configuration
replication" - I think it
could
> > be useful for other sorts of configuration.
> >
> >> * enforced attribute syntax validation
> >>
> > Already on the list - Syntax validation checking
> >
> >> * re-verify and validate conformance of the syntaxes, case
sensitivity
> >> and their matching rules to RFC
> >> (https://www.redhat.com/archives/fedora-directory-users/2008-
> July/msg00041.html)
> >>
> >>
> > Already on the list
> >
> >> * unix socket autobind still does not seem to work (ldapi) -
> >> https://www.redhat.com/archives/fedora-directory-users/2009-
> February/msg00112.html.
> >> It could be very useful for various maintenance scripts running on
the
> >> server.
> >>
> > We tested this with 1.2.0 and it seems to work.  You tested a build
from
> > source?  Did you use --enable-autobind with configure?  Did you
restart
> > the server after configuring your autobind and sasl mapping?
> >
> >> * verification of the server from the viewpoint of memory leaks.
Th
> >> size of the memory used by the server grows with time (normally we
> >> don''t restart the sevrr during several months, so i can
follow the
> stats)
> >>
> > We regularly run the server test suite with valgrind enabled. 
I''m
not
> > aware of any per connection or per operation leaks.  What exactly
are
> > you seeing?
> >
> >> * logconv.pl - very useful script, add some more options/
adjustments
> >> (for example, a switch to hide unindexed searches in verbose
mode).
We
> >> use it as logwatch.
> >>
> >> * a perl script to show the replication statistics (there is one
for
> >> the we page generation statistics, something more basic, text-only
> >> would be very welcome) in text mode - to receiveth reports by mail
> >> once per day like logwatch for example
> >>
> > What sort of information are you looking for?  ldapsearch can
provide
> > most of the useful information.
> >
> >> * regular expressions in ACIs (i know, it is very difficult to do,
so
> >> maybe somewhere in the timescale of the version 10.0 ? :)) - for
> >> example, allow a user to add or modify a value just in case the
new
> >> value mathes the regex. Or the group or dn of the user matches the
> >> regex...
> >>
> > You can do some of that currently with targetattrfilters - see
> > *http://tinyurl.com/3yo88r
> >
> > We added support in 1.2.0 to allow you to specify group membership
with
> > LDAP search specifications, which does allow some wildcarding, so
that
> > might help too.
> > *
> >
> >> * simplify the creation of new syntaxes and their validation/
> >> enforcement (version 11.0? :))
> >>
> > Can you elaborate?
> >
> >> * virtual views allowing to map not only the trees but also the
> >> attributes (''cn'' instead of
''uid'' in a subtree, for example)
> >>
> > Can you elaborate?
> >
> >> * enable regex in certmap.conf for mapping the CNs of the
certificates
> >> during the certificate authentification of users
> >>
> > This is on the list as
> > Get rid of certmap.conf - use SASL mapping (cert auth is really just
> > SASL/EXTERNAL)
> > The sasl mapping code uses regular expressions
> >
> >>
> >>
> >> Other than that i just want to emphasize the great job you are
doing
> >> adding new features and especially the fantastic reactivity in
fixing
> >> some critical server bugs (usually it takes only one or two days
to
> >> have the necessary diff in bugzilla!)
> >>
> >> Thank you and please continue the development of this directory
server!
> >>
> > And thank you for your suggestions.
> >
> >>
> >>
> >>
> >>
> >>
> >>         Thanks - I''ve added these notes to
> >>        
http://directory.fedoraproject.org/wiki/Roadmap#Version_1.3
> >>
> >>         Anyone else?  C''mon - surely you have an opinion
about a
new
> >>         feature.
> >>
> >>
> >>             Thanks for all your hard work on this!
> >>
> >>
> >>
> >>
-----------------------------------------------------------------------
> -
> >>
> >> --
> >> Fedora-directory-users mailing list
> >> Fedora-directory-users@redhat.com
> >> https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >>
> >>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > This e-mail and any attachment is intended for the above name
> recipient(s) only and may contain confidential or privileged
information.
> If you are not an intended recipient, please notify the sender and
delete
> the message.  Failure to maintain the confidentiality of this e-mail
and
> any attachment may subject you to penalties under applicable law.
> >
> >
> > CONFIDENTIALITY NOTICE: This e-mail message, including any
attachments,
> is for the sole use of the intended recipient(s) and may contain
> confidential and privileged information or otherwise be protected by
law.
> Any unauthorized review, use, disclosure or distribution is
prohibited. If
> you are not the intended recipient, please contact the sender by reply
e-
> mail and destroy all copies of the original message.
> >
> > --
> > Fedora-directory-users mailing list
> > Fedora-directory-users@redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >
> 









This e-mail and any attachment is intended for the above name recipient(s) only
and may contain confidential or privileged information.  If you are not an
intended recipient, please notify the sender and delete the message.  Failure to
maintain the confidentiality of this e-mail and any attachment may subject you
to penalties under applicable law.


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for
the sole use of the intended recipient(s) and may contain confidential and
privileged information or otherwise be protected by law. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy all
copies of the original message.

David Partridge wrote:
> Agreed, BUT how do I do this with features of Task Invocation Via LDAP
> if it is not part of the core product?
>   
Right.  The gzip/gunzip needs to be in the server itself to do
that.
> David M. Partridge
> Tangible Software Inc.
> Sr. Security Engineer
> 2010 Corporate Ridge
> Suite 620
> McLean, Virginia 22102
> Office     800-913-9901 x 3001
> Mobile   571-286-9628
> Fax        703-288-1226
> dpartridge@tangiblesoftware.com
>  
>
>   
>> -----Original Message-----
>> From: Rich Megginson [mailto:rmeggins@redhat.com]
>> Sent: Friday, April 10, 2009 9:29 AM
>> To: General discussion list for the Fedora Directory server project.
>> Subject: Re: [Fedora-directory-users] Proposed new features for 1.3
>>
>> David Partridge wrote:
>>     
>>> Would like to see additional monitoring flexibility for snmp - when
>>>       
>> configuring multiple ds instances with same port on single multihomed
>>     
> host
>   
>> monitoring information is agregated by port in the monitoring not by
>> instance and port.
>>     
>>> Please provide more information on deprecation of certmap.conf.
>>>       
> Need
>   
>> flexibility to not rely on dn in cert mapping to anything in directory
>>     
> and
>   
>> rely on successful tls mutual authentication and truststore
>>     
> configuration.
>   
>>> Script to provide index analysis based on data in  the directory to
>>>       
>> provide the following info:
>>     
>>> Search performance efficiency of index and index type based on
>>>       
> return
>   
>> limits, and scanidslistlimit.
>>     
>>> Compressed ldif(gzip) capability for export, import, and
>>>       
> initialization
>   
>> usage.
>>     
>> A follow up to this - directory server can import from stdin and
>>     
> export
>   
>> to stdout, so you can do this:
>> db2ldif -n userRoot -a - | gzip > db.ldif.gz
>> and
>> gunzip -c db.ldif.gz | ldif2db -n userRoot -i -
>>
>> For initialization usage, I guess that would mean online init (or
>>     
> remote
>   
>> bulk load using ldapmodify -B).  In that case, since the data is BER
>> encoded already, it would be better to investigate attribute value
>> compression, as discussed elsewhere in this thread.
>>     
>>> Dave Partridge
>>> Sent from my Windows Mobile(r) phone.
>>>
>>> -----Original Message-----
>>> From: Rich Megginson <rmeggins@redhat.com>
>>> Sent: Thursday, April 09, 2009 7:23 PM
>>> To: General discussion list for the Fedora Directory server
project.
>>>       
>> <fedora-directory-users@redhat.com>
>>     
>>> Subject: Re: [Fedora-directory-users] Proposed new features for 1.3
>>>
>>> Andrey Ivanov wrote:
>>>
>>>       
>>>> I continue with my list
>>>>
>>>>         
>>> Thanks - I''ve added many of these to the list - questions
below.
>>>
>>>       
>>>> * the server should be able to return the members of dynamic
groups
>>>> "on the fly" as if it were real members, the
membership attribute
>>>> should be configurable - uniqueMember, member or another
>>>>
>>>>         
>>> I put this on the Future list:
>>> 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
>>>
>>>
>>>
>>>       
>>>> * support of other virtual attributes generated "on the
fly"
>>>>
>>>>         
>>> Can you explain this a little more?
>>>
>>>       
>>>> * pam passthrough plug-in should take into account at least the
>>>> account activation/desactivation (bug *470684*
>>>> <https://bugzilla.redhat.com/show_bug.cgi?id=470684> ).
There is a
>>>> comment about some additional useful features it in th README
file
>>>>         
> of
>   
>>>> this plug-in :
>>>> We need to worry about account expiration or lockout e.g. the
>>>>         
> user''s
>   
>>>> credentials are valid but the user has been locked out of
his/her
>>>> account, or the password has expired, or something like that.
Some
>>>>         
> of
>   
>>>> this can be handled by LDAP e.g. returning password policy
control
>>>> values when the password has expired.
>>>>
>>>>
>>>> * a way to synchronise the configuration of indexes (each time
we
>>>>         
> add
>   
>>>> an index on one of the replicated servers we need to make it
>>>>         
> manually
>   
>>>> on all the others) and some other parameters in
"cn=config" between
>>>> the replicated servers  (a little like the
"configuration"
>>>>         
> partition
>   
>>>> in active directory), the schema changes are already replicated
>>>>         
> which
>   
>>>> is very good
>>>>
>>>>         
>>> I''m calling this feature "Configuration
replication" - I think it
>>>       
> could
>   
>>> be useful for other sorts of configuration.
>>>
>>>       
>>>> * enforced attribute syntax validation
>>>>
>>>>         
>>> Already on the list - Syntax validation checking
>>>
>>>       
>>>> * re-verify and validate conformance of the syntaxes, case
>>>>         
> sensitivity
>   
>>>> and their matching rules to RFC
>>>> (https://www.redhat.com/archives/fedora-directory-users/2008-
>>>>         
>> July/msg00041.html)
>>     
>>>>         
>>> Already on the list
>>>
>>>       
>>>> * unix socket autobind still does not seem to work (ldapi) -
>>>> https://www.redhat.com/archives/fedora-directory-users/2009-
>>>>         
>> February/msg00112.html.
>>     
>>>> It could be very useful for various maintenance scripts running
on
>>>>         
> the
>   
>>>> server.
>>>>
>>>>         
>>> We tested this with 1.2.0 and it seems to work.  You tested a build
>>>       
> from
>   
>>> source?  Did you use --enable-autobind with configure?  Did you
>>>       
> restart
>   
>>> the server after configuring your autobind and sasl mapping?
>>>
>>>       
>>>> * verification of the server from the viewpoint of memory
leaks. Th
>>>> size of the memory used by the server grows with time (normally
we
>>>> don''t restart the sevrr during several months, so i
can follow the
>>>>         
>> stats)
>>     
>>> We regularly run the server test suite with valgrind enabled. 
I''m
>>>       
> not
>   
>>> aware of any per connection or per operation leaks.  What exactly
>>>       
> are
>   
>>> you seeing?
>>>
>>>       
>>>> * logconv.pl - very useful script, add some more options/
>>>>         
> adjustments
>   
>>>> (for example, a switch to hide unindexed searches in verbose
mode).
>>>>         
> We
>   
>>>> use it as logwatch.
>>>>
>>>> * a perl script to show the replication statistics (there is
one
>>>>         
> for
>   
>>>> the we page generation statistics, something more basic,
text-only
>>>> would be very welcome) in text mode - to receiveth reports by
mail
>>>> once per day like logwatch for example
>>>>
>>>>         
>>> What sort of information are you looking for?  ldapsearch can
>>>       
> provide
>   
>>> most of the useful information.
>>>
>>>       
>>>> * regular expressions in ACIs (i know, it is very difficult to
do,
>>>>         
> so
>   
>>>> maybe somewhere in the timescale of the version 10.0 ? :)) -
for
>>>> example, allow a user to add or modify a value just in case the
new
>>>> value mathes the regex. Or the group or dn of the user matches
the
>>>> regex...
>>>>
>>>>         
>>> You can do some of that currently with targetattrfilters - see
>>> *http://tinyurl.com/3yo88r
>>>
>>> We added support in 1.2.0 to allow you to specify group membership
>>>       
> with
>   
>>> LDAP search specifications, which does allow some wildcarding, so
>>>       
> that
>   
>>> might help too.
>>> *
>>>
>>>       
>>>> * simplify the creation of new syntaxes and their validation/
>>>> enforcement (version 11.0? :))
>>>>
>>>>         
>>> Can you elaborate?
>>>
>>>       
>>>> * virtual views allowing to map not only the trees but also the
>>>> attributes (''cn'' instead of
''uid'' in a subtree, for example)
>>>>
>>>>         
>>> Can you elaborate?
>>>
>>>       
>>>> * enable regex in certmap.conf for mapping the CNs of the
>>>>         
> certificates
>   
>>>> during the certificate authentification of users
>>>>
>>>>         
>>> This is on the list as
>>> Get rid of certmap.conf - use SASL mapping (cert auth is really
just
>>> SASL/EXTERNAL)
>>> The sasl mapping code uses regular expressions
>>>
>>>       
>>>> Other than that i just want to emphasize the great job you are
>>>>         
> doing
>   
>>>> adding new features and especially the fantastic reactivity in
>>>>         
> fixing
>   
>>>> some critical server bugs (usually it takes only one or two
days to
>>>> have the necessary diff in bugzilla!)
>>>>
>>>> Thank you and please continue the development of this directory
>>>>         
> server!
>   
>>> And thank you for your suggestions.
>>>
>>>       
>>>>
>>>>
>>>>
>>>>         Thanks - I''ve added these notes to
>>>>        
http://directory.fedoraproject.org/wiki/Roadmap#Version_1.3
>>>>
>>>>         Anyone else?  C''mon - surely you have an
opinion about a
>>>>         
> new
>   
>>>>         feature.
>>>>
>>>>
>>>>             Thanks for all your hard work on this!
>>>>
>>>>
>>>>
>>>>
>>>>         
> -----------------------------------------------------------------------
>   
>> -
>>     
>>>> --
>>>> Fedora-directory-users mailing list
>>>> Fedora-directory-users@redhat.com
>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>
>>>>
>>>>         
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> This e-mail and any attachment is intended for the above name
>>>       
>> recipient(s) only and may contain confidential or privileged
>>     
> information.
>   
>> If you are not an intended recipient, please notify the sender and
>>     
> delete
>   
>> the message.  Failure to maintain the confidentiality of this e-mail
>>     
> and
>   
>> any attachment may subject you to penalties under applicable law.
>>     
>>> CONFIDENTIALITY NOTICE: This e-mail message, including any
>>>       
> attachments,
>   
>> is for the sole use of the intended recipient(s) and may contain
>> confidential and privileged information or otherwise be protected by
>>     
> law.
>   
>> Any unauthorized review, use, disclosure or distribution is
>>     
> prohibited. If
>   
>> you are not the intended recipient, please contact the sender by reply
>>     
> e-
>   
>> mail and destroy all copies of the original message.
>>     
>>> --
>>> Fedora-directory-users mailing list
>>> Fedora-directory-users@redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>
>>>       
>
>
>
>
>
>
>
>
>
>
> This e-mail and any attachment is intended for the above name recipient(s)
only and may contain confidential or privileged information.  If you are not an
intended recipient, please notify the sender and delete the message.  Failure to
maintain the confidentiality of this e-mail and any attachment may subject you
to penalties under applicable law.
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential and
privileged information or otherwise be protected by law. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy all
copies of the original message.
>
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

David M. Partridge
Tangible Software Inc.
Sr. Security Engineer
2010 Corporate Ridge
Suite 620
McLean, Virginia 22102
Office     800-913-9901 x 3001
Mobile   571-286-9628
Fax        703-288-1226
dpartridge@tangiblesoftware.com
 
> -----Original Message-----
> From: Rich Megginson [mailto:rmeggins@redhat.com]
> Sent: Friday, April 10, 2009 10:40 AM
> To: General discussion list for the Fedora Directory server project.
> Subject: Re: [Fedora-directory-users] Proposed new features for 1.3
> 
> David Partridge wrote:
> > Use case example for certmap.conf for end user:
> >
> > Customer has desire to share Enterprise Directory information across
WAN
> > for contact information sharing, but has requirement for strong
> > authentication using PKI.  PKI trust is a PKI Mesh utilizing cross
> > certification.  Users information in Directory Server One (DS1) are
> > associated with users issued certificates from PKI One (PKI1).
Users
> > information in Directory Server Two (DS2) are associated with users
> > issued certificates from PKI Two (PKI2).
> >
> > DS1 has no awareness or cross population of entries with DS2, but
PKI1
> > is cross certified with PKI2 and trusted by both populations.  Users
> > associated with PKI1 have a business requirement to strongly
> > authenticate with DS2 to locate and collaborate with population of
users
> > in DS2, but have no entry in DS2 and vice versa.  By removing
current
> > capability to strongly authenticate based on TLS configuration but
have
> > NO DN in DS you are removing capability to use SASL External in a
cross
> > certified PKI environment.  User of the product will be forced to
use
> > SASL GSSAPI that causes other security issues or requirements to
setup
> > all of these Kerberos trust and ticketing handling that should not
be
> > required, difficult to sustain and place external dependencies on
usage
> > of the DS product in a federated environment as described.
> >
> > If directory is utilized as something OTHER than repository for
people
> > similar challenges will present themselves when certificates are
issued
> > for devices, roles, and groups.  Examples include but are not
limited to
> > VOIP device address book capabilities such as CISCO VOIP phones or
call
> > managers, Potentially for extending security capability in hosts
that
> > have host based certificates that may require use of the directory
for
> > backend business processes were Certificate trust and regular
expression
> > checks of DN utilized for the TLS session may be sufficient to
utilize
> > for ACI binding rules.
> >
> 
> So you want to allow a user from DS1 to authenticate to DS2, without
> having a user entry in DS2.  Then use access control, bind resource
> limits, groups, roles, CoS, etc. without having a real user entry.  I
> think that would be useful for auth in general, not just cert based
> auth.  It comes up often in SASL/GSSAPI auth (wanting to use Kerberos
> auth without having to have a user entry), and is necessary to support
> the types of devices you mention.
[David Partridge] 
DS1 and DS2 for clarity are only containers of information for users to
consume. A user may have data in neither, one or both DS, but has PKI
credentials that are trusted by neither, one or both DS.  If trusted the
user should be authenticated via TLS using mutual authentication using
PKI. If not trusted user is turned away by TLS mutual authentication.

Authentication and access control are two separate and distinct
processes.  

If user is not authenticated why should I allow them to get to the point
of exposing internal directory resources to evaluate access control,
bind resource limits, groups, roles, CoS, etc.  Believe I had this
conversation with Bob Lord long time ago when we discovered a previous
security issue.

If user is authenticated capabilities of DN mapping with sophisticated
access control, bind resource limits, groups, roles, CoS, etc. continue
to be valuable for providing different privileges and capabilities. But
the ability should not be absolute to requiring a DN in the directory
NOR would I want to try to build rules based on every PKI end user DN
that may have a chain of trust that is acceptable based on adding to NSS
Truststore.  There will be some cases that the fact that they
authenticated regardless of SASL mechanism should be able to provide
''SOME'' access.
> 
> One of the things that cert based auth does now is to retrieve the
> userCertificate from the user''s entry and compare it against the
cert
> presented in the auth request.  But that (verifyCert) can be turned
off
> now.  Would you want the ability to compare the cert presented for
auth
> against the known cert for that identity?
[David Partridge] Depends - For our use cases identity certificates [
digital signature, nonrepudiation key usage] are NEVER published or
stored outside of PKI CA infrastructure (will let the Dogtag team
explain reasons).  Therefore the certificate used for SSL will NEVER be
a match to the certificate attribute in the directory which is merely
one or more email encryption certificates [key encipherment key usage]
that corresponds to mail attribute in directory.

If directory was for PKI CA infrastructure matching the certificate
binary value may be useful, but unnecessary if implementation of PKI
done correctly.  Matching binary contradicts why the PKI exists in the
first place.  In most cases PKI exists so you do not need prior
knowledge of the end user of the certificate to know that the
individual/system met identity vetting requirements and is the only
individual/system that possessed private key to make it do what it does.

> > David M. Partridge
> > Tangible Software Inc.
> > dpartridge@tangiblesoftware.com
> >
> >
> >> -----Original Message-----
> >> From: Rich Megginson [mailto:rmeggins@redhat.com]
> >> Sent: Thursday, April 09, 2009 11:47 PM
> >> To: General discussion list for the Fedora Directory server
project.
> >> Subject: Re: [Fedora-directory-users] Proposed new features for
1.3
> >>
> >> David Partridge wrote:
> >>
> >>> Would like to see additional monitoring flexibility for snmp -
when
> >>>
> >> configuring multiple ds instances with same port on single
multihomed
> >>
> > host
> >
> >> monitoring information is agregated by port in the monitoring not
by
> >> instance and port.
> >>
> >>> Please provide more information on deprecation of
certmap.conf.
> >>>
> >> We would instead use the SASL mapping functionality to map the
> >>
> > subjectDN
> >
> >> in the cert to a DN that the DS knows about.  The SASL mapping
code
is
> >> much more powerful and flexible than the certmap.conf code.
> >> *http://tinyurl.com/cqe42v
> >> *
> >>
> >>> Need flexibility to not rely on dn in cert mapping to anything
in
> >>>
> >> directory and rely on successful tls mutual authentication and
> >>
> > truststore
> >
> >> configuration.
> >>
> >> I''m not sure I understand - do you want the ability to do
cert auth
> >> without having to have a real entry in the directory server that
> >> corresponds to the subjectDN?
> >>
> >>> Script to provide index analysis based on data in  the
directory
to
> >>>
> >> provide the following info:
> >>
> >>> Search performance efficiency of index and index type based on
> >>>
> > return
> >
> >> limits, and scanidslistlimit.
> >>
> >>> Compressed ldif(gzip) capability for export, import, and
> >>>
> > initialization
> >
> >> usage.
> >>
> >> Ok - Thanks - this is all good stuff.
> >>
> >>> Dave Partridge
> >>> Sent from my Windows Mobile(r) phone.
> >>>
> >>> -----Original Message-----
> >>> From: Rich Megginson <rmeggins@redhat.com>
> >>> Sent: Thursday, April 09, 2009 7:23 PM
> >>> To: General discussion list for the Fedora Directory server
project.
> >>>
> >> <fedora-directory-users@redhat.com>
> >>
> >>> Subject: Re: [Fedora-directory-users] Proposed new features
for
1.3
> >>>
> >>> Andrey Ivanov wrote:
> >>>
> >>>
> >>>> I continue with my list
> >>>>
> >>>>
> >>> Thanks - I''ve added many of these to the list -
questions below.
> >>>
> >>>
> >>>> * the server should be able to return the members of
dynamic
groups
> >>>> "on the fly" as if it were real members, the
membership attribute
> >>>> should be configurable - uniqueMember, member or another
> >>>>
> >>>>
> >>> I put this on the Future list:
> >>> 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
> >>>
> >>>
> >>>
> >>>
> >>>> * support of other virtual attributes generated "on
the fly"
> >>>>
> >>>>
> >>> Can you explain this a little more?
> >>>
> >>>
> >>>> * pam passthrough plug-in should take into account at
least the
> >>>> account activation/desactivation (bug *470684*
> >>>> <https://bugzilla.redhat.com/show_bug.cgi?id=470684>
). There is
a
> >>>> comment about some additional useful features it in th
README
file
> >>>>
> > of
> >
> >>>> this plug-in :
> >>>> We need to worry about account expiration or lockout e.g.
the
> >>>>
> > user''s
> >
> >>>> credentials are valid but the user has been locked out of
his/her
> >>>> account, or the password has expired, or something like
that.
Some
> >>>>
> > of
> >
> >>>> this can be handled by LDAP e.g. returning password policy
control
> >>>> values when the password has expired.
> >>>>
> >>>>
> >>>> * a way to synchronise the configuration of indexes (each
time we
> >>>>
> > add
> >
> >>>> an index on one of the replicated servers we need to make
it
> >>>>
> > manually
> >
> >>>> on all the others) and some other parameters in
"cn=config"
between
> >>>> the replicated servers  (a little like the
"configuration"
> >>>>
> > partition
> >
> >>>> in active directory), the schema changes are already
replicated
> >>>>
> > which
> >
> >>>> is very good
> >>>>
> >>>>
> >>> I''m calling this feature "Configuration
replication" - I think it
> >>>
> > could
> >
> >>> be useful for other sorts of configuration.
> >>>
> >>>
> >>>> * enforced attribute syntax validation
> >>>>
> >>>>
> >>> Already on the list - Syntax validation checking
> >>>
> >>>
> >>>> * re-verify and validate conformance of the syntaxes, case
> >>>>
> > sensitivity
> >
> >>>> and their matching rules to RFC
> >>>>
(https://www.redhat.com/archives/fedora-directory-users/2008-
> >>>>
> >> July/msg00041.html)
> >>
> >>>>
> >>> Already on the list
> >>>
> >>>
> >>>> * unix socket autobind still does not seem to work (ldapi)
-
> >>>>
https://www.redhat.com/archives/fedora-directory-users/2009-
> >>>>
> >> February/msg00112.html.
> >>
> >>>> It could be very useful for various maintenance scripts
running
on
> >>>>
> > the
> >
> >>>> server.
> >>>>
> >>>>
> >>> We tested this with 1.2.0 and it seems to work.  You tested a
build
> >>>
> > from
> >
> >>> source?  Did you use --enable-autobind with configure?  Did
you
> >>>
> > restart
> >
> >>> the server after configuring your autobind and sasl mapping?
> >>>
> >>>
> >>>> * verification of the server from the viewpoint of memory
leaks.
Th
> >>>> size of the memory used by the server grows with time
(normally
we
> >>>> don''t restart the sevrr during several months, so
i can follow
the
> >>>>
> >> stats)
> >>
> >>> We regularly run the server test suite with valgrind enabled. 
I''m
> >>>
> > not
> >
> >>> aware of any per connection or per operation leaks.  What
exactly
> >>>
> > are
> >
> >>> you seeing?
> >>>
> >>>
> >>>> * logconv.pl - very useful script, add some more options/
> >>>>
> > adjustments
> >
> >>>> (for example, a switch to hide unindexed searches in
verbose
mode).
> >>>>
> > We
> >
> >>>> use it as logwatch.
> >>>>
> >>>> * a perl script to show the replication statistics (there
is one
> >>>>
> > for
> >
> >>>> the we page generation statistics, something more basic,
text-only
> >>>> would be very welcome) in text mode - to receiveth reports
by
mail
> >>>> once per day like logwatch for example
> >>>>
> >>>>
> >>> What sort of information are you looking for?  ldapsearch can
> >>>
> > provide
> >
> >>> most of the useful information.
> >>>
> >>>
> >>>> * regular expressions in ACIs (i know, it is very
difficult to
do,
> >>>>
> > so
> >
> >>>> maybe somewhere in the timescale of the version 10.0 ? :))
- for
> >>>> example, allow a user to add or modify a value just in
case the
new
> >>>> value mathes the regex. Or the group or dn of the user
matches
the
> >>>> regex...
> >>>>
> >>>>
> >>> You can do some of that currently with targetattrfilters - see
> >>> *http://tinyurl.com/3yo88r
> >>>
> >>> We added support in 1.2.0 to allow you to specify group
membership
> >>>
> > with
> >
> >>> LDAP search specifications, which does allow some wildcarding,
so
> >>>
> > that
> >
> >>> might help too.
> >>> *
> >>>
> >>>
> >>>> * simplify the creation of new syntaxes and their
validation/
> >>>> enforcement (version 11.0? :))
> >>>>
> >>>>
> >>> Can you elaborate?
> >>>
> >>>
> >>>> * virtual views allowing to map not only the trees but
also the
> >>>> attributes (''cn'' instead of
''uid'' in a subtree, for example)
> >>>>
> >>>>
> >>> Can you elaborate?
> >>>
> >>>
> >>>> * enable regex in certmap.conf for mapping the CNs of the
> >>>>
> > certificates
> >
> >>>> during the certificate authentification of users
> >>>>
> >>>>
> >>> This is on the list as
> >>> Get rid of certmap.conf - use SASL mapping (cert auth is
really
just
> >>> SASL/EXTERNAL)
> >>> The sasl mapping code uses regular expressions
> >>>
> >>>
> >>>> Other than that i just want to emphasize the great job you
are
> >>>>
> > doing
> >
> >>>> adding new features and especially the fantastic
reactivity in
> >>>>
> > fixing
> >
> >>>> some critical server bugs (usually it takes only one or
two days
to
> >>>> have the necessary diff in bugzilla!)
> >>>>
> >>>> Thank you and please continue the development of this
directory
> >>>>
> > server!
> >
> >>> And thank you for your suggestions.
> >>>
> >>>
> >>>>
> >>>>
> >>>>
> >>>>         Thanks - I''ve added these notes to
> >>>>
http://directory.fedoraproject.org/wiki/Roadmap#Version_1.3
> >>>>
> >>>>         Anyone else?  C''mon - surely you have an
opinion about a
> >>>>
> > new
> >
> >>>>         feature.
> >>>>
> >>>>
> >>>>             Thanks for all your hard work on this!
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >
-----------------------------------------------------------------------
> >
> >> -
> >>
> >>>> --
> >>>> Fedora-directory-users mailing list
> >>>> Fedora-directory-users@redhat.com
> >>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> This e-mail and any attachment is intended for the above name
> >>>
> >> recipient(s) only and may contain confidential or privileged
> >>
> > information.
> >
> >> If you are not an intended recipient, please notify the sender and
> >>
> > delete
> >
> >> the message.  Failure to maintain the confidentiality of this
e-mail
> >>
> > and
> >
> >> any attachment may subject you to penalties under applicable law.
> >>
> >>> CONFIDENTIALITY NOTICE: This e-mail message, including any
> >>>
> > attachments,
> >
> >> is for the sole use of the intended recipient(s) and may contain
> >> confidential and privileged information or otherwise be protected
by
> >>
> > law.
> >
> >> Any unauthorized review, use, disclosure or distribution is
> >>
> > prohibited. If
> >
> >> you are not the intended recipient, please contact the sender by
reply
> >>
> > e-
> >
> >> mail and destroy all copies of the original message.
> >>
> >>> --
> >>> Fedora-directory-users mailing list
> >>> Fedora-directory-users@redhat.com
> >>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >>>
> >>>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > This e-mail and any attachment is intended for the above name
> recipient(s) only and may contain confidential or privileged
information.
> If you are not an intended recipient, please notify the sender and
delete
> the message.  Failure to maintain the confidentiality of this e-mail
and
> any attachment may subject you to penalties under applicable law.
> >
> >
> > CONFIDENTIALITY NOTICE: This e-mail message, including any
attachments,
> is for the sole use of the intended recipient(s) and may contain
> confidential and privileged information or otherwise be protected by
law.
> Any unauthorized review, use, disclosure or distribution is
prohibited. If
> you are not the intended recipient, please contact the sender by reply
e-
> mail and destroy all copies of the original message.
> >
> >
> > --
> > Fedora-directory-users mailing list
> > Fedora-directory-users@redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >









This e-mail and any attachment is intended for the above name recipient(s) only
and may contain confidential or privileged information.  If you are not an
intended recipient, please notify the sender and delete the message.  Failure to
maintain the confidentiality of this e-mail and any attachment may subject you
to penalties under applicable law.


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for
the sole use of the intended recipient(s) and may contain confidential and
privileged information or otherwise be protected by law. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy all
copies of the original message.

David Partridge wrote:
> David M. Partridge
> Tangible Software Inc.
> Sr. Security Engineer
> 2010 Corporate Ridge
> Suite 620
> McLean, Virginia 22102
> Office     800-913-9901 x 3001
> Mobile   571-286-9628
> Fax        703-288-1226
> dpartridge@tangiblesoftware.com
>  
>
>   
>> -----Original Message-----
>> From: Rich Megginson [mailto:rmeggins@redhat.com]
>> Sent: Friday, April 10, 2009 10:40 AM
>> To: General discussion list for the Fedora Directory server project.
>> Subject: Re: [Fedora-directory-users] Proposed new features for 1.3
>>
>> David Partridge wrote:
>>     
>>> Use case example for certmap.conf for end user:
>>>
>>> Customer has desire to share Enterprise Directory information
across
>>>       
> WAN
>   
>>> for contact information sharing, but has requirement for strong
>>> authentication using PKI.  PKI trust is a PKI Mesh utilizing cross
>>> certification.  Users information in Directory Server One (DS1) are
>>> associated with users issued certificates from PKI One (PKI1).
>>>       
> Users
>   
>>> information in Directory Server Two (DS2) are associated with users
>>> issued certificates from PKI Two (PKI2).
>>>
>>> DS1 has no awareness or cross population of entries with DS2, but
>>>       
> PKI1
>   
>>> is cross certified with PKI2 and trusted by both populations. 
Users
>>> associated with PKI1 have a business requirement to strongly
>>> authenticate with DS2 to locate and collaborate with population of
>>>       
> users
>   
>>> in DS2, but have no entry in DS2 and vice versa.  By removing
>>>       
> current
>   
>>> capability to strongly authenticate based on TLS configuration but
>>>       
> have
>   
>>> NO DN in DS you are removing capability to use SASL External in a
>>>       
> cross
>   
>>> certified PKI environment.  User of the product will be forced to
>>>       
> use
>   
>>> SASL GSSAPI that causes other security issues or requirements to
>>>       
> setup
>   
>>> all of these Kerberos trust and ticketing handling that should not
>>>       
> be
>   
>>> required, difficult to sustain and place external dependencies on
>>>       
> usage
>   
>>> of the DS product in a federated environment as described.
>>>
>>> If directory is utilized as something OTHER than repository for
>>>       
> people
>   
>>> similar challenges will present themselves when certificates are
>>>       
> issued
>   
>>> for devices, roles, and groups.  Examples include but are not
>>>       
> limited to
>   
>>> VOIP device address book capabilities such as CISCO VOIP phones or
>>>       
> call
>   
>>> managers, Potentially for extending security capability in hosts
>>>       
> that
>   
>>> have host based certificates that may require use of the directory
>>>       
> for
>   
>>> backend business processes were Certificate trust and regular
>>>       
> expression
>   
>>> checks of DN utilized for the TLS session may be sufficient to
>>>       
> utilize
>   
>>> for ACI binding rules.
>>>
>>>       
>> So you want to allow a user from DS1 to authenticate to DS2, without
>> having a user entry in DS2.  Then use access control, bind resource
>> limits, groups, roles, CoS, etc. without having a real user entry.  I
>> think that would be useful for auth in general, not just cert based
>> auth.  It comes up often in SASL/GSSAPI auth (wanting to use Kerberos
>> auth without having to have a user entry), and is necessary to support
>> the types of devices you mention.
>>     
>
> [David Partridge] 
> DS1 and DS2 for clarity are only containers of information for users to
> consume. A user may have data in neither, one or both DS, but has PKI
> credentials that are trusted by neither, one or both DS.  If trusted the
> user should be authenticated via TLS using mutual authentication using
> PKI. If not trusted user is turned away by TLS mutual authentication.
>   
Ok.  So just in general allow authentication if user doesn''t
exist.
> Authentication and access control are two separate and distinct
> processes.  
>
> If user is not authenticated why should I allow them to get to the point
> of exposing internal directory resources to evaluate access control,
> bind resource limits, groups, roles, CoS, etc.  Believe I had this
> conversation with Bob Lord long time ago when we discovered a previous
> security issue.
>   
Sure.  Unauthenticated users should not be allowed to consume resources 
or discover information.  We have some roadmap items to disallow and 
lockdown anonymous users even more than we do today.
> If user is authenticated capabilities of DN mapping with sophisticated
> access control, bind resource limits, groups, roles, CoS, etc. continue
> to be valuable for providing different privileges and capabilities. But
> the ability should not be absolute to requiring a DN in the directory
> NOR would I want to try to build rules based on every PKI end user DN
> that may have a chain of trust that is acceptable based on adding to NSS
> Truststore.  There will be some cases that the fact that they
> authenticated regardless of SASL mechanism should be able to provide
> ''SOME'' access.
>   
Ok.  Right - I want to allow those capabilities without requiring a DN 
in the directory.
>   
>> One of the things that cert based auth does now is to retrieve the
>> userCertificate from the user''s entry and compare it against
the cert
>> presented in the auth request.  But that (verifyCert) can be turned
>>     
> off
>   
>> now.  Would you want the ability to compare the cert presented for
>>     
> auth
>   
>> against the known cert for that identity?
>>     
>
> [David Partridge] Depends - For our use cases identity certificates [
> digital signature, nonrepudiation key usage] are NEVER published or
> stored outside of PKI CA infrastructure (will let the Dogtag team
> explain reasons).  Therefore the certificate used for SSL will NEVER be
> a match to the certificate attribute in the directory which is merely
> one or more email encryption certificates [key encipherment key usage]
> that corresponds to mail attribute in directory.
>
> If directory was for PKI CA infrastructure matching the certificate
> binary value may be useful, but unnecessary if implementation of PKI
> done correctly.  Matching binary contradicts why the PKI exists in the
> first place.  In most cases PKI exists so you do not need prior
> knowledge of the end user of the certificate to know that the
> individual/system met identity vetting requirements and is the only
> individual/system that possessed private key to make it do what it does.
>   
Ok.
>
>   
>>> David M. Partridge
>>> Tangible Software Inc.
>>> dpartridge@tangiblesoftware.com
>>>
>>>
>>>       
>>>> -----Original Message-----
>>>> From: Rich Megginson [mailto:rmeggins@redhat.com]
>>>> Sent: Thursday, April 09, 2009 11:47 PM
>>>> To: General discussion list for the Fedora Directory server
>>>>         
> project.
>   
>>>> Subject: Re: [Fedora-directory-users] Proposed new features for
1.3
>>>>
>>>> David Partridge wrote:
>>>>
>>>>         
>>>>> Would like to see additional monitoring flexibility for
snmp -
>>>>>           
> when
>   
>>>> configuring multiple ds instances with same port on single
>>>>         
> multihomed
>   
>>> host
>>>
>>>       
>>>> monitoring information is agregated by port in the monitoring
not
>>>>         
> by
>   
>>>> instance and port.
>>>>
>>>>         
>>>>> Please provide more information on deprecation of
certmap.conf.
>>>>>
>>>>>           
>>>> We would instead use the SASL mapping functionality to map the
>>>>
>>>>         
>>> subjectDN
>>>
>>>       
>>>> in the cert to a DN that the DS knows about.  The SASL mapping
code
>>>>         
> is
>   
>>>> much more powerful and flexible than the certmap.conf code.
>>>> *http://tinyurl.com/cqe42v
>>>> *
>>>>
>>>>         
>>>>> Need flexibility to not rely on dn in cert mapping to
anything in
>>>>>
>>>>>           
>>>> directory and rely on successful tls mutual authentication and
>>>>
>>>>         
>>> truststore
>>>
>>>       
>>>> configuration.
>>>>
>>>> I''m not sure I understand - do you want the ability to
do cert auth
>>>> without having to have a real entry in the directory server
that
>>>> corresponds to the subjectDN?
>>>>
>>>>         
>>>>> Script to provide index analysis based on data in  the
directory
>>>>>           
> to
>   
>>>> provide the following info:
>>>>
>>>>         
>>>>> Search performance efficiency of index and index type based
on
>>>>>
>>>>>           
>>> return
>>>
>>>       
>>>> limits, and scanidslistlimit.
>>>>
>>>>         
>>>>> Compressed ldif(gzip) capability for export, import, and
>>>>>
>>>>>           
>>> initialization
>>>
>>>       
>>>> usage.
>>>>
>>>> Ok - Thanks - this is all good stuff.
>>>>
>>>>         
>>>>> Dave Partridge
>>>>> Sent from my Windows Mobile(r) phone.
>>>>>
>>>>> -----Original Message-----
>>>>> From: Rich Megginson <rmeggins@redhat.com>
>>>>> Sent: Thursday, April 09, 2009 7:23 PM
>>>>> To: General discussion list for the Fedora Directory server
>>>>>           
> project.
>   
>>>> <fedora-directory-users@redhat.com>
>>>>
>>>>         
>>>>> Subject: Re: [Fedora-directory-users] Proposed new features
for
>>>>>           
> 1.3
>   
>>>>> Andrey Ivanov wrote:
>>>>>
>>>>>
>>>>>           
>>>>>> I continue with my list
>>>>>>
>>>>>>
>>>>>>             
>>>>> Thanks - I''ve added many of these to the list -
questions below.
>>>>>
>>>>>
>>>>>           
>>>>>> * the server should be able to return the members of
dynamic
>>>>>>             
> groups
>   
>>>>>> "on the fly" as if it were real members, the
membership attribute
>>>>>> should be configurable - uniqueMember, member or
another
>>>>>>
>>>>>>
>>>>>>             
>>>>> I put this on the Future list:
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>           
>>>>>> * support of other virtual attributes generated
"on the fly"
>>>>>>
>>>>>>
>>>>>>             
>>>>> Can you explain this a little more?
>>>>>
>>>>>
>>>>>           
>>>>>> * pam passthrough plug-in should take into account at
least the
>>>>>> account activation/desactivation (bug *470684*
>>>>>>
<https://bugzilla.redhat.com/show_bug.cgi?id=470684> ). There is
>>>>>>             
> a
>   
>>>>>> comment about some additional useful features it in th
README
>>>>>>             
> file
>   
>>> of
>>>
>>>       
>>>>>> this plug-in :
>>>>>> We need to worry about account expiration or lockout
e.g. the
>>>>>>
>>>>>>             
>>> user''s
>>>
>>>       
>>>>>> credentials are valid but the user has been locked out
of his/her
>>>>>> account, or the password has expired, or something like
that.
>>>>>>             
> Some
>   
>>> of
>>>
>>>       
>>>>>> this can be handled by LDAP e.g. returning password
policy
>>>>>>             
> control
>   
>>>>>> values when the password has expired.
>>>>>>
>>>>>>
>>>>>> * a way to synchronise the configuration of indexes
(each time we
>>>>>>
>>>>>>             
>>> add
>>>
>>>       
>>>>>> an index on one of the replicated servers we need to
make it
>>>>>>
>>>>>>             
>>> manually
>>>
>>>       
>>>>>> on all the others) and some other parameters in
"cn=config"
>>>>>>             
> between
>   
>>>>>> the replicated servers  (a little like the
"configuration"
>>>>>>
>>>>>>             
>>> partition
>>>
>>>       
>>>>>> in active directory), the schema changes are already
replicated
>>>>>>
>>>>>>             
>>> which
>>>
>>>       
>>>>>> is very good
>>>>>>
>>>>>>
>>>>>>             
>>>>> I''m calling this feature "Configuration
replication" - I think it
>>>>>
>>>>>           
>>> could
>>>
>>>       
>>>>> be useful for other sorts of configuration.
>>>>>
>>>>>
>>>>>           
>>>>>> * enforced attribute syntax validation
>>>>>>
>>>>>>
>>>>>>             
>>>>> Already on the list - Syntax validation checking
>>>>>
>>>>>
>>>>>           
>>>>>> * re-verify and validate conformance of the syntaxes,
case
>>>>>>
>>>>>>             
>>> sensitivity
>>>
>>>       
>>>>>> and their matching rules to RFC
>>>>>>
(https://www.redhat.com/archives/fedora-directory-users/2008-
>>>>>>
>>>>>>             
>>>> July/msg00041.html)
>>>>
>>>>         
>>>>> Already on the list
>>>>>
>>>>>
>>>>>           
>>>>>> * unix socket autobind still does not seem to work
(ldapi) -
>>>>>>
https://www.redhat.com/archives/fedora-directory-users/2009-
>>>>>>
>>>>>>             
>>>> February/msg00112.html.
>>>>
>>>>         
>>>>>> It could be very useful for various maintenance scripts
running
>>>>>>             
> on
>   
>>> the
>>>
>>>       
>>>>>> server.
>>>>>>
>>>>>>
>>>>>>             
>>>>> We tested this with 1.2.0 and it seems to work.  You tested
a
>>>>>           
> build
>   
>>> from
>>>
>>>       
>>>>> source?  Did you use --enable-autobind with configure?  Did
you
>>>>>
>>>>>           
>>> restart
>>>
>>>       
>>>>> the server after configuring your autobind and sasl
mapping?
>>>>>
>>>>>
>>>>>           
>>>>>> * verification of the server from the viewpoint of
memory leaks.
>>>>>>             
> Th
>   
>>>>>> size of the memory used by the server grows with time
(normally
>>>>>>             
> we
>   
>>>>>> don''t restart the sevrr during several months,
so i can follow
>>>>>>             
> the
>   
>>>> stats)
>>>>
>>>>         
>>>>> We regularly run the server test suite with valgrind
enabled.  I''m
>>>>>
>>>>>           
>>> not
>>>
>>>       
>>>>> aware of any per connection or per operation leaks.  What
exactly
>>>>>
>>>>>           
>>> are
>>>
>>>       
>>>>> you seeing?
>>>>>
>>>>>
>>>>>           
>>>>>> * logconv.pl - very useful script, add some more
options/
>>>>>>
>>>>>>             
>>> adjustments
>>>
>>>       
>>>>>> (for example, a switch to hide unindexed searches in
verbose
>>>>>>             
> mode).
>   
>>> We
>>>
>>>       
>>>>>> use it as logwatch.
>>>>>>
>>>>>> * a perl script to show the replication statistics
(there is one
>>>>>>
>>>>>>             
>>> for
>>>
>>>       
>>>>>> the we page generation statistics, something more
basic,
>>>>>>             
> text-only
>   
>>>>>> would be very welcome) in text mode - to receiveth
reports by
>>>>>>             
> mail
>   
>>>>>> once per day like logwatch for example
>>>>>>
>>>>>>
>>>>>>             
>>>>> What sort of information are you looking for?  ldapsearch
can
>>>>>
>>>>>           
>>> provide
>>>
>>>       
>>>>> most of the useful information.
>>>>>
>>>>>
>>>>>           
>>>>>> * regular expressions in ACIs (i know, it is very
difficult to
>>>>>>             
> do,
>   
>>> so
>>>
>>>       
>>>>>> maybe somewhere in the timescale of the version 10.0 ?
:)) - for
>>>>>> example, allow a user to add or modify a value just in
case the
>>>>>>             
> new
>   
>>>>>> value mathes the regex. Or the group or dn of the user
matches
>>>>>>             
> the
>   
>>>>>> regex...
>>>>>>
>>>>>>
>>>>>>             
>>>>> You can do some of that currently with targetattrfilters -
see
>>>>> *http://tinyurl.com/3yo88r
>>>>>
>>>>> We added support in 1.2.0 to allow you to specify group
membership
>>>>>
>>>>>           
>>> with
>>>
>>>       
>>>>> LDAP search specifications, which does allow some
wildcarding, so
>>>>>
>>>>>           
>>> that
>>>
>>>       
>>>>> might help too.
>>>>> *
>>>>>
>>>>>
>>>>>           
>>>>>> * simplify the creation of new syntaxes and their
validation/
>>>>>> enforcement (version 11.0? :))
>>>>>>
>>>>>>
>>>>>>             
>>>>> Can you elaborate?
>>>>>
>>>>>
>>>>>           
>>>>>> * virtual views allowing to map not only the trees but
also the
>>>>>> attributes (''cn'' instead of
''uid'' in a subtree, for example)
>>>>>>
>>>>>>
>>>>>>             
>>>>> Can you elaborate?
>>>>>
>>>>>
>>>>>           
>>>>>> * enable regex in certmap.conf for mapping the CNs of
the
>>>>>>
>>>>>>             
>>> certificates
>>>
>>>       
>>>>>> during the certificate authentification of users
>>>>>>
>>>>>>
>>>>>>             
>>>>> This is on the list as
>>>>> Get rid of certmap.conf - use SASL mapping (cert auth is
really
>>>>>           
> just
>   
>>>>> SASL/EXTERNAL)
>>>>> The sasl mapping code uses regular expressions
>>>>>
>>>>>
>>>>>           
>>>>>> Other than that i just want to emphasize the great job
you are
>>>>>>
>>>>>>             
>>> doing
>>>
>>>       
>>>>>> adding new features and especially the fantastic
reactivity in
>>>>>>
>>>>>>             
>>> fixing
>>>
>>>       
>>>>>> some critical server bugs (usually it takes only one or
two days
>>>>>>             
> to
>   
>>>>>> have the necessary diff in bugzilla!)
>>>>>>
>>>>>> Thank you and please continue the development of this
directory
>>>>>>
>>>>>>             
>>> server!
>>>
>>>       
>>>>> And thank you for your suggestions.
>>>>>
>>>>>
>>>>>           
>>>>>>
>>>>>>         Thanks - I''ve added these notes to
>>>>>>
>>>>>>             
> http://directory.fedoraproject.org/wiki/Roadmap#Version_1.3
>   
>>>>>>         Anyone else?  C''mon - surely you have
an opinion about a
>>>>>>
>>>>>>             
>>> new
>>>
>>>       
>>>>>>         feature.
>>>>>>
>>>>>>
>>>>>>             Thanks for all your hard work on this!
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
> -----------------------------------------------------------------------
>   
>>>> -
>>>>
>>>>         
>>>>>> --
>>>>>> Fedora-directory-users mailing list
>>>>>> Fedora-directory-users@redhat.com
>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> This e-mail and any attachment is intended for the above
name
>>>>>
>>>>>           
>>>> recipient(s) only and may contain confidential or privileged
>>>>
>>>>         
>>> information.
>>>
>>>       
>>>> If you are not an intended recipient, please notify the sender
and
>>>>
>>>>         
>>> delete
>>>
>>>       
>>>> the message.  Failure to maintain the confidentiality of this
>>>>         
> e-mail
>   
>>> and
>>>
>>>       
>>>> any attachment may subject you to penalties under applicable
law.
>>>>
>>>>         
>>>>> CONFIDENTIALITY NOTICE: This e-mail message, including any
>>>>>
>>>>>           
>>> attachments,
>>>
>>>       
>>>> is for the sole use of the intended recipient(s) and may
contain
>>>> confidential and privileged information or otherwise be
protected
>>>>         
> by
>   
>>> law.
>>>
>>>       
>>>> Any unauthorized review, use, disclosure or distribution is
>>>>
>>>>         
>>> prohibited. If
>>>
>>>       
>>>> you are not the intended recipient, please contact the sender
by
>>>>         
> reply
>   
>>> e-
>>>
>>>       
>>>> mail and destroy all copies of the original message.
>>>>
>>>>         
>>>>> --
>>>>> Fedora-directory-users mailing list
>>>>> Fedora-directory-users@redhat.com
>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>
>>>>>
>>>>>           
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> This e-mail and any attachment is intended for the above name
>>>       
>> recipient(s) only and may contain confidential or privileged
>>     
> information.
>   
>> If you are not an intended recipient, please notify the sender and
>>     
> delete
>   
>> the message.  Failure to maintain the confidentiality of this e-mail
>>     
> and
>   
>> any attachment may subject you to penalties under applicable law.
>>     
>>> CONFIDENTIALITY NOTICE: This e-mail message, including any
>>>       
> attachments,
>   
>> is for the sole use of the intended recipient(s) and may contain
>> confidential and privileged information or otherwise be protected by
>>     
> law.
>   
>> Any unauthorized review, use, disclosure or distribution is
>>     
> prohibited. If
>   
>> you are not the intended recipient, please contact the sender by reply
>>     
> e-
>   
>> mail and destroy all copies of the original message.
>>     
>>> --
>>> Fedora-directory-users mailing list
>>> Fedora-directory-users@redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>
>>>       
>
>
>
>
>
>
>
>
>
>
> This e-mail and any attachment is intended for the above name recipient(s)
only and may contain confidential or privileged information.  If you are not an
intended recipient, please notify the sender and delete the message.  Failure to
maintain the confidentiality of this e-mail and any attachment may subject you
to penalties under applicable law.
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential and
privileged information or otherwise be protected by law. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy all
copies of the original message.
>
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>