[389-users] Announcing 389 Directory Server version 1.3.2.24

2014-10-17 Thread Noriko Hosoi 


   389 Directory Server 1.3.2.24

The 389 Directory Server team is proud to announce 389-ds-base version 
1.3.2.24.


Fedora packages are available from the Fedora 20 repository.

The new packages and versions are:

 * 389-ds-base-1.3.2.24-1

A source tarball is available for download at Download Source 




 Highlights in 1.3.2.24

 * Various bugs were fixed.


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *yum install 389-ds* yum install 389-ds After install 
completes, run *setup-ds-admin.pl* to set up your directory 
server. setup-ds-admin.pl


To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run 
*setup-ds-admin.pl -u* to update your directory server/admin 
server/console information. setup-ds-admin.pl -u


See Install_Guide 
 for more 
information about the initial installation, setup, and upgrade


See Source  
for information about source tarballs and SCM (git) access.



 Feedback

We are very interested in your feedback!

Please provide feedback and comments to the 389-users mailing list: 
https://admin.fedoraproject.org/mailman/listinfo/389-users


If you find a bug, or would like to see a new feature, file it in our 
Trac instance: https://fedorahosted.org/389



 Detailed Changelog since 1.3.2.23

 * Ticket 47457 - default nsslapd-sasl-max-buffer-size should be 2MB
 * Ticket 47748 - Simultaneous adding a user and binding as the user
   could fail in the password policy check
 * Ticket 47750 - Creating a glue fails if one above level is a
   conflict or missing
 * Ticket 47834 - Tombstone_to_glue: if parents are also converted to
   glue, the target entry’s DN must be adjusted.
 * Ticket 47875 - dirsrv not running with old openldap
 * Ticket 47885 - deref plugin should not return references with noc
   access rights
 * Ticket 47885 - did not always return a response control
 * Ticket 47889 - DS crashed during ipa-server-install on test_ava_filter
 * Ticket 47897 - Need to move slapi_pblock_set(pb,
   SLAPI_MODRDN_EXISTING_ENTRY, original_entry->ep_entry) prior to
   original_entry overwritten
 * Ticket 47900 - Adding an entry with an invalid password as rootDN is
   incorrectly rejected
 * Ticket 47900 - Server fails to start if password admin is set
 * Ticket 47907 - ldclt: assertion failure with -e “add,counteach” -e
   “object=,rdn=uid:test[A=INCRNNOLOOP(0;24
 * Ticket 47918 - result of dna_dn_is_shared_config is incorrectly used
 * Ticket 47919 - ldbm_back_modify SLAPI_PLUGIN_BE_PRE_MODIFY_FN does
   not return even if one of the preop plugins fails.
 * Ticket 47920 - Encoding of SearchResultEntry is missing tag
 * Ticket 47922 - dynamically added macro aci is not evaluated on the fly

http://www.port389.org/docs/389ds/releases/release-1-3-2-24.html

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

[389-users] Announcing 389 Directory Server version 1.3.3.5

2014-10-17 Thread Noriko Hosoi 


   389 Directory Server 1.3.3.5

The 389 Directory Server team is proud to announce 389-ds-base version 
1.3.3.5.


Fedora packages are available from the Fedora 21 and Rawhide repositories.

The new packages and versions are:

 * 389-ds-base-1.3.3.5-1

A source tarball is available for download at Download Source 




 Highlights in 1.3.3.5

 * Several bugs are fixed.


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *yum install 389-ds* yum install 389-ds After install 
completes, run *setup-ds-admin.pl* to set up your directory 
server. setup-ds-admin.pl


To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run 
*setup-ds-admin.pl -u* to update your directory server/admin 
server/console information. setup-ds-admin.pl -u


See Install_Guide 
 for more 
information about the initial installation, setup, and upgrade


See Source  
for information about source tarballs and SCM (git) access.



 Feedback

We are very interested in your feedback!

Please provide feedback and comments to the 389-users mailing list: 
https://admin.fedoraproject.org/mailman/listinfo/389-users


If you find a bug, or would like to see a new feature, file it in our 
Trac instance: https://fedorahosted.org/389



 Detailed Changelog since 1.3.3.3

 * Ticket 47750 - Creating a glue fails if one above level is a
   conflict or missing
 * Ticket 47838 - harden the list of ciphers available by default (phase 2)
 * Ticket 47880 - provide enabled ciphers as search result
 * Ticket 47892 - Fix remaining compiler warnings
 * Ticket 47892 - coverity defects found in 1.3.3.x
 * Ticket 47897 - Need to move slapi_pblock_set(pb,
   SLAPI_MODRDN_EXISTING_ENTRY, original_entry->ep_entry) prior to
   original_entry overwritten
 * Ticket 47899 - Fix slapi_td_plugin_lock_init prototype
 * Ticket 47900 - Adding an entry with an invalid password as rootDN is
   incorrectly rejected
 * Ticket 47900 - Server fails to start if password admin is set
 * Ticket 47907 - ldclt: assertion failure with -e “add,counteach” -e
   “object=,rdn=uid:test[A=INCRNNOLOOP(0;24999;5)]”
 * Ticket 47908 - 389-ds 1.3.3.0 does not adjust cipher suite
   configuration on upgrade, breaks itself and pki-server
 * Ticket 47912 - Proper handling of “No original_tombstone for
   changenumber” errors
 * Ticket 47916 - plugin logging parameter only triggers result logging
 * Ticket 47918 - result of dna_dn_is_shared_config is incorrectly used
 * Ticket 47919 - ldbm_back_modify SLAPI_PLUGIN_BE_PRE_MODIFY_FN does
   not return even if one of the preop plugins fails.
 * Ticket 47920 - Encoding of SearchResultEntry is missing tag
 * Ticket 47922 - dynamically added macro aci is not evaluated on the fly

http://www.port389.org/docs/389ds/releases/release-1-3-3-5.html

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Regarding patch availability for RHBA-2014:1623-1

2014-10-17 Thread Rich Megginson 

On 10/17/2014 07:58 AM, Balaji P wrote:

Hi
While analyzing this problem we noticed this issue is released for 
RHEL in version 1.2.11.15 version.

Is it possible to deliver the fix in  1.2.8.2


The 389 team is not going to do this.


and 1.2.11.32 streams?


There isn't a 1.2.11.32 "stream".  There is a 389-ds-base-1.2.11 branch 
in the upstream git repository, and the fix is in this branch.



(or) Is there any patch available for this fix?


There are patches (plural, not singular) for this fix.  If you look at 
the git log for 389-ds-base-1.2.11 branch you will see several commits 
for ticket 47750.



Bug Fix Advisory - RHBA-2014:1623-1
--
Summary: 389-ds-base bug fix update
Updated 389-ds-base packages that fix one bug are now available for 
Red Hat Enterprise Linux 6.

*Description:*
The 389 Directory Server is an LDAPv3 compliant server. The base 
packages include the Lightweight Directory Access Protocol (LDAP) 
server and command-line utilities for server administration.

This update fixes the following bug:
* Bug fixes for replication conflict resolution (BZ#1080185) 
introduced a memory leak bug, which increased the size of the 
Directory Server. With this update, the memory leak code has been 
fixed, and the size of the Directory Servers in the replication 
topology is now stable under the stress. (BZ#1147479)
Users of 389-ds-base are advised to upgrade to these updated packages, 
which fix this bug. After installing this update, the 389 server 
service will be restarted automatically.

Thanks,
Balaji P


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

[389-users] custom object classes and attributes

2014-10-17 Thread Chase Miller 
Hello,

So I have a development ldap server up and running with all of my custom
object classes and attributes.  Now, is there a way to export these and
import them on my new production boxes, so I don't have to re-create all of
them.

Chase
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

[389-users] Regarding patch availability for RHBA-2014:1623-1

2014-10-17 Thread Balaji P 
Hi

While analyzing this problem we noticed this issue is released for RHEL in 
version 1.2.11.15 version.

Is it possible to deliver the fix in  1.2.8.2 and 1.2.11.32 streams?

(or) Is there any patch available for this fix?


Bug Fix Advisory - RHBA-2014:1623-1
--
Summary: 389-ds-base bug fix update

Updated 389-ds-base packages that fix one bug are now available for Red Hat 
Enterprise Linux 6.

Description:
The 389 Directory Server is an LDAPv3 compliant server. The base packages 
include the Lightweight Directory Access Protocol (LDAP) server and 
command-line utilities for server administration.

This update fixes the following bug:
* Bug fixes for replication conflict resolution (BZ#1080185) introduced a 
memory leak bug, which increased the size of the Directory Server. With this 
update, the memory leak code has been fixed, and the size of the Directory 
Servers in the replication topology is now stable under the stress. (BZ#1147479)

Users of 389-ds-base are advised to upgrade to these updated packages, which 
fix this bug. After installing this update, the 389 server service will be 
restarted automatically.

Thanks,
Balaji P

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] How relevant is Poodlebleed Bug to 389?

2014-10-17 Thread Rich Megginson 

On 10/17/2014 02:55 AM, Paul Tobias wrote:

You probably want to disable SSLv3 on the admin server too. Add the
following line to /etc/dirsrv/admin-serv/console.conf:
  NSSProtocol TLSv1.0,TLSv1.1

Documentation here:
https://git.fedorahosted.org/cgit/mod_nss.git/plain/docs/mod_nss.html

Regarding the directory server, I didn't find "nsTLS1" under
cn=encryption,cn=config,


It is not in dse.ldif by default, but if you do an ldapsearch you should 
see it.  It is on by default which is why it worked.


The recommendation is to

ldapmodify -x -D "cn=directory manager" -w 'password' <
but setting "nsSSL3: off" did the trick, the
openldap command line tools, the 389ds-console and sssd still works. (We
have "nsslapd-minssf: 128" in cn=config).

You can test like this:
  openssl s_client -connect hostname:389 -ssl3
  openssl s_client -connect hostname:636 -ssl3
  openssl s_client -connect hostname:9830 -ssl3

If the above commands says something like:
  140183413589832:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong
version number:s3_pkt.c:337:
  New, (NONE), Cipher is (NONE)
Then SSLv3 is disabled.

If the s_client output looks like this:
  New, TLSv1/SSLv3, Cipher is AES128-SHA
and it's waiting for input, then SSLv3 is enabled!

Have a nice day,
Paul

On 2014-10-15 20:20, Rich Megginson wrote:

On 10/15/2014 12:34 PM, Michael Gettes wrote:

Hi David (et al),

what is the right way to do this in the DS?  (i am on 1.2.11.32)

i see under cn=config there is cn=encryption and there are
nsSSL3Ciphers and nsSSLSupportCiphers (lots of these).  The
documentation just shows the simple on/off for SSL/TLS.

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_SSL-Setting_Security_Preferences.html
and
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnencryption-nsssl3ciphers
and
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnencryption-nsSSL2
and
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnencryption-nsSSL3
and
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnencryption-nsTLS1

You might be able to just set nsSSL2: off and nsSSL3: off and nsTLS1: on

For me, my admin server has SSL on but it is behind a firewall so I am
not concerned with adjusting it.

Thanks for pointers.

/mrg

On Oct 15, 2014, at 12:12 PM, David Boreham mailto:david_l...@boreham.org>> wrote:


On 10/15/2014 8:16 AM, Jan Tomasek wrote:

is http://poodlebleed.com/ related to 389? I think it is, this is
not implementation flaw in OpenSSL, this seems to be related to the
SSLv3 design.

From
http://askubuntu.com/questions/537196/how-do-i-patch-workaround-sslv3-poodle-vulnerability-cve-2014-3566
:


 Is it relevant for HTTPS only or also for IMAP/SMTP/OpenVPN and
 other protocols with SSL support?

The current attack vector as shown by the researchers works with
controlling the plaintext sent to the server using Javascript being
run on the victim's machine. This vector does not apply to non-HTTPS
scenarios without using a browser.

Also, normally an SSL client doesn't allow the session to be
downgraded to SSLv3 (having TLSv1+ seen in the handshake
capabilities), but browsers want to be very backward compatible and
the do. The combination with controlling plaintext and the specific
way a HTTP header is built up makes it exploitable.

Conclusion: disable SSLv3 for HTTPS *now*, disable SSLv3 for other
services in your next service window.



--
389 users mailing list
389-users@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/389-users



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] How relevant is Poodlebleed Bug to 389?

2014-10-17 Thread Paul Tobias 
You probably want to disable SSLv3 on the admin server too. Add the
following line to /etc/dirsrv/admin-serv/console.conf:
 NSSProtocol TLSv1.0,TLSv1.1

Documentation here:
https://git.fedorahosted.org/cgit/mod_nss.git/plain/docs/mod_nss.html

Regarding the directory server, I didn't find "nsTLS1" under
cn=encryption,cn=config, but setting "nsSSL3: off" did the trick, the
openldap command line tools, the 389ds-console and sssd still works. (We
have "nsslapd-minssf: 128" in cn=config).

You can test like this:
 openssl s_client -connect hostname:389 -ssl3
 openssl s_client -connect hostname:636 -ssl3
 openssl s_client -connect hostname:9830 -ssl3

If the above commands says something like:
 140183413589832:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong
version number:s3_pkt.c:337:
 New, (NONE), Cipher is (NONE)
Then SSLv3 is disabled.

If the s_client output looks like this:
 New, TLSv1/SSLv3, Cipher is AES128-SHA
and it's waiting for input, then SSLv3 is enabled!

Have a nice day,
Paul

On 2014-10-15 20:20, Rich Megginson wrote:
> On 10/15/2014 12:34 PM, Michael Gettes wrote:
>> Hi David (et al),
>>
>> what is the right way to do this in the DS?  (i am on 1.2.11.32)
>>
>> i see under cn=config there is cn=encryption and there are
>> nsSSL3Ciphers and nsSSLSupportCiphers (lots of these).  The
>> documentation just shows the simple on/off for SSL/TLS.
> 
> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_SSL-Setting_Security_Preferences.html
> and
> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnencryption-nsssl3ciphers
> and
> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnencryption-nsSSL2
> and
> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnencryption-nsSSL3
> and
> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnencryption-nsTLS1
> 
> You might be able to just set nsSSL2: off and nsSSL3: off and nsTLS1: on
>>
>> For me, my admin server has SSL on but it is behind a firewall so I am
>> not concerned with adjusting it.
>>
>> Thanks for pointers.
>>
>> /mrg
>>
>> On Oct 15, 2014, at 12:12 PM, David Boreham > > wrote:
>>
>>> On 10/15/2014 8:16 AM, Jan Tomasek wrote:
 is http://poodlebleed.com/ related to 389? I think it is, this is
 not implementation flaw in OpenSSL, this seems to be related to the
 SSLv3 design.
>>> From
>>> http://askubuntu.com/questions/537196/how-do-i-patch-workaround-sslv3-poodle-vulnerability-cve-2014-3566
>>> :
>>>
>>>
>>> Is it relevant for HTTPS only or also for IMAP/SMTP/OpenVPN and
>>> other protocols with SSL support?
>>>
>>> The current attack vector as shown by the researchers works with
>>> controlling the plaintext sent to the server using Javascript being
>>> run on the victim's machine. This vector does not apply to non-HTTPS
>>> scenarios without using a browser.
>>>
>>> Also, normally an SSL client doesn't allow the session to be
>>> downgraded to SSLv3 (having TLSv1+ seen in the handshake
>>> capabilities), but browsers want to be very backward compatible and
>>> the do. The combination with controlling plaintext and the specific
>>> way a HTTP header is built up makes it exploitable.
>>>
>>> Conclusion: disable SSLv3 for HTTPS *now*, disable SSLv3 for other
>>> services in your next service window.
>>>
>>>
>>>
>>> --
>>> 389 users mailing list
>>> 389-users@lists.fedoraproject.org
>>> 
>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>
>>
>>
>> --
>> 389 users mailing list
>> 389-users@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
> 
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users