SSL connection with 'startTLS' problem
by Karel Lang AFD
Hi guys,
please anyone could help me to decode error in access log?
Problem desr.:
I need to make Ricoh C3001 printer authenticate x 389 DS.
The printer stubbornly tries to start TLS inside SSL connection (if i
read the log file correct?) and the authentication fails, because 389
doesn't know what to make off it (i think) see:
The server uses ldaps:// method of connection on 636 port (with
selfsigned certificates).
[20/Oct/2014:18:31:50 +0200] conn=38 fd=70 slot=70 SSL connection from
192.168.2.139 to 192.168.2.245
[20/Oct/2014:18:31:50 +0200] conn=38 SSL 256-bit AES
[20/Oct/2014:18:31:50 +0200] conn=38 op=0 EXT
oid="1.3.6.1.4.1.1466.20037" name="startTLS"
[20/Oct/2014:18:31:50 +0200] conn=38 op=0 RESULT err=1 tag=120
nentries=0 etime=0
[20/Oct/2014:18:31:50 +0200] conn=38 op=1 BIND dn="RICOH2-SB$"
method=128 version=3
[20/Oct/2014:18:31:50 +0200] conn=38 op=1 RESULT err=53 tag=97
nentries=0 etime=0
[20/Oct/2014:18:31:51 +0200] conn=38 op=2 UNBIND
[20/Oct/2014:18:31:51 +0200] conn=38 op=2 fd=70 closed - U1
The 'err=53' means "server is unwilling to perform" and i see same
message in the printer logs
also, you can see the printer starts 'extended operation':
EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS"
which i think it should not? (because it is already SSL conn from start?)
different encryption (same result):
[root@srv-022 slapd-srv-022]# cat access | grep conn=48
[20/Oct/2014:18:35:56 +0200] conn=48 fd=68 slot=68 SSL connection from
192.168.2.139 to 192.168.2.245
[20/Oct/2014:18:35:57 +0200] conn=48 SSL 128-bit RC4
[20/Oct/2014:18:35:57 +0200] conn=48 op=0 EXT
oid="1.3.6.1.4.1.1466.20037" name="startTLS"
[20/Oct/2014:18:35:57 +0200] conn=48 op=0 RESULT err=1 tag=120
nentries=0 etime=1
[20/Oct/2014:18:35:57 +0200] conn=48 op=1 BIND dn="RICOH2-SB$"
method=128 version=3
[20/Oct/2014:18:35:57 +0200] conn=48 op=1 RESULT err=53 tag=97
nentries=0 etime=0
[20/Oct/2014:18:35:57 +0200] conn=48 op=2 UNBIND
[20/Oct/2014:18:35:57 +0200] conn=48 op=2 fd=68 closed - U1
Please note the different encryption i tried to use - for eg. 128-bit
RC4 and 256-bit AES etc, but all produces same result.
The printer has choice for usinge of ssl:
ssl 2.0 (set to 'yes)
ssl 3.0 (set to 'yes')
tls (i set this option to "NO" - but made no difference and result is
still same)
Also, the printer has only 2options:
1.
use SSL/TLS - if i check this, port 636 is automatically used
2.
dont use SSL/TLS - if i check this option, port 389 is used
Not much else to pick on (ofc there is other LDAP things to fill up like
hostname etc.)
I think this looks like client problem? Or do you think i can try to
tune up something on the server side? - anybody had experienced similar
troubles?
--
*Karel Lang*
8 years, 7 months
Error code 51 and replication errors
by Shilen Patel
Hi,
I'm running 1.2.11.32. I have 6 replicas (two of which are read-only). I ran into an issue where a DELETE operation failed on a server with error code 51 (ldap busy).
[21/Oct/2014:23:44:44 -0400] conn=78160 op=39510 RESULT err=51 tag=107 nentries=0 etime=3 csn=5447282c000300050000
The application retried the delete several times for a couple of hours (while the server wasn't getting any other requests) and the result was always the same (err=51). Each time that happened, the error log had the following:
[21/Oct/2014:23:44:44 -0400] - Retry count exceeded in delete
My first question is, what would cause a problem like this?
I simply restarted that directory and then the update succeeded. However, when the update went to the other 5 servers, they failed in the same way and the same error was logged in their log files. But the update wasn't retried. It was just skipped and future updates via replication succeeded on those 5 servers.
My second question is, what's the best way to monitor for these types of replication errors? In this case, nsds5replicaLastUpdateStatus did not indicate a problem. If I had not been looking at the error file on those 5 hosts, I'm wondering how I would have known that a delete failed to replicate to them. If the answer is to just have something monitoring the error log files, are there specific search strings to look for to separate out updates that have failed and won't be retried from other errors (e.g. temporary connection issues)? Just curious if there is a best practice here.
Thanks!
- Shilen
8 years, 7 months
Searching for userCertificate
by Graham Leggett
Hi all,
I am trying to research how it might be possible to do a directory search for an exact match on a digital certificate storing in userCertificate. Most specifically, I want to do a simple lookup based on a binary match of the cert, its not enough to do the combination of DN and serial number.
Does anyone know whether a simple search will work with 389ds or if there are any gotchas to look out for? Some googling would suggest that openldap can’t do it, I was wondering if 389ds had the same problem.
Regards,
Graham
—
8 years, 7 months
Re: [389-users] Searching for userCertificate
by Howard Chu
> Date: Tue, 21 Oct 2014 13:29:32 +0200
> From: Graham Leggett <minfrin(a)sharp.fm>
> Hi all,
>
> I am trying to research how it might be possible to do a directory search
for an exact match on a digital certificate storing in userCertificate. Most
specifically, I want to do a simple lookup based on a binary match of the
cert, its not enough to do the combination of DN and serial number.
>
> Does anyone know whether a simple search will work with 389ds or if there
are any gotchas to look out for? Some googling would suggest that openldap
can’t do it, I was wondering if 389ds had the same problem.
The userCertificate attribute is defined in RFC4523 with a specific syntax,
and only supports the certificateExactMatch matching rule. OpenLDAP implements
this RFC, along with the rest of the LDAPv3 spec.
In the past, before the certificateExactMatch matching rule was defined
(LDAPv2 days), it was common practice to change the core.schema definition of
userCertificate to use octetString syntax, and the corresponding
octetStringMatch equality matching rule. You can still do this in OpenLDAP,
although it obviously breaks compatibility with the standards.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
8 years, 7 months
SASL configuration
by Dhiraj Deshpande
Hi folks,
Need to configure sasl mecanism so that i can use DIGEST-MD5 mechanism with
my autofs configuration. With PLAIN it is working fine but need to use
DIGEST-MD5. Where i can specify.
[root@ibm001 ~]# cat /etc/autofs_ldap_auth.conf
<?xml version="1.0" ?>
<!--
This files contains a single entry with multiple attributes tied to it.
See autofs_ldap_auth.conf(5) for more information.
-->
<autofs_ldap_sasl_conf
usetls="no"
tlsrequired="no"
authrequired="yes"
authtype="DIGEST-MD5"
user="proxyuser"
secret="XXX"
/>
--
Thanks & Regards
Dhiraj S. Deshpande
8 years, 7 months
Announcing 389 Directory Server version 1.3.2.24
by 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
<http://www.port389.org/binaries/389-ds-base-1.3.2.24.tar.bz2>
Highlights in 1.3.2.24
* Various bugs were fixed.
Installation and Upgrade
See Download <http://www.port389.org/docs/389ds/download.html> 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
<http://www.port389.org/docs/389ds/legacy/install-guide.html> for more
information about the initial installation, setup, and upgrade
See Source <http://www.port389.org/docs/389ds/development/source.html>
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
8 years, 7 months
Announcing 389 Directory Server version 1.3.3.5
by 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
<http://www.port389.org/binaries/389-ds-base-1.3.3.5.tar.bz2>
Highlights in 1.3.3.5
* Several bugs are fixed.
Installation and Upgrade
See Download <http://www.port389.org/docs/389ds/download.html> 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
<http://www.port389.org/docs/389ds/legacy/install-guide.html> for more
information about the initial installation, setup, and upgrade
See Source <http://www.port389.org/docs/389ds/development/source.html>
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
8 years, 7 months
custom object classes and attributes
by 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
8 years, 7 months
Regarding patch availability for RHBA-2014:1623-1
by 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
8 years, 7 months