Replication with SSLCLIENTAUTH: server sent no certificate
by Eugen Lamers
I'm trying to setup a replication with a certificate based authentication between supplier and consumer. The certificates in the certdb at /etc/dirsrv/slapd-XXX contain the very same CA with which the respective server certificates in the certdbs have been signed. The certificates all have the 'u' flag, and the CA has the C and T flag.
The replication (on the supplier) has been setup such that TLS and certificate based authentication is used, see extract from the replication agreement object:
objectclass: nsds5ReplicationAgreement
nsds5replicahost: <consumer-hostname>
nsds5replicaport: 389
nsds5replicatransportinfo: TLS
nsds5replicabindmethod: SSLCLIENTAUTH
Trying to initialize the consumer raises this error in the error-log of the supplier (the host sending the starttls connection request):
Replication bind with EXTERNAL auth failed: LDAP error 48 (Inappropriate authentication) (missing client certificate)
The certificate that the server should have sent can, however, be used with the ldap commandline tools as ldapsearch. In this case a wireshark trace clearly shows that the client sends the certificate during the TLS handshake, while in the above case it doesn't.
The TLS handshake defines that the client has to send an "empty certificate" if it does not have a certificate that has been issued by a CA offered by the server during the handshake. I can't see a reason for the client to think the condition isn't met. The certificate with which the server (supplier) is setup is the only one available.
Is it possible that the server does not know which certificate it has to use for authentication with the consumer server? And if so, how do I make the server know?
The 389-ds in use is the version 1.4.1.6~git0.5ac5a8aad. The problem was the same with 1.4.0.3.
Thanks,
Eugen
2 years, 3 months
ERR - slapi_ldap_bind - Could not send bind request for id [(anon)] authentication mechanism [EXTERNAL]: error -1 (Can't contact LDAP server), system error 0 (no error), network error 0
by Graham Leggett
Hi all,
We have a long standing 389ds master LDAP server that was found to be unable to contact it’s slaves. Most specifically, the slaves show nothing in their logs about any kind of connection, while the master is logging this:
[12/Nov/2019:21:39:47.212715697 +0000] - ERR - slapi_ldap_bind - Could not send bind request for id [(anon)] authentication mechanism [EXTERNAL]: error -1 (Can't contact LDAP server), system error 0 (no error), network error 0 (Unknown error, host “ldap01:636”)
Key is "system error 0 (no error)”, which leaves us stumped. The error is obviously “success”.
Has anyone seen this kind of thing before?
This is 389ds running on CentOS7 as follows:
389-ds-base-1.3.9.1-10.el7.x86_64
Regards,
Graham
—
2 years, 6 months
Problem browsing LDAP with Outlook
by Chris Bryant
When configuring Microsoft Outlook (not Outlook Express) to access an LDAP directory, there is an option to 'Enable Browsing (requires server support)'. If this option is chosen and the directory server supports it, then you should be able to open the LDAP address book and page up and down through the results. I have been unable to get this working properly with 389 DS.
When I try to browse from Outlook against the 389 DS directory, I am able to see the first page of results perfectly. However, if I move to the next page, only the first object returned will have any attributes included, and all of the rest of the objects in the page will have no attributes. I have a test perl script that duplicates this functionality as well.
I can get this to work properly with an older version of Netscape Directory Server, and I can get it working with OpenDS. Since 389 DS advertises support for the controls that are required for this to work, just like the other two servers, then I would expect it to work there also.
Has anyone out there gotten this to work with 389 DS? If so, can you share if there was anything special that you needed to do to get this to work? I'm trying to determine if this is a bug in the server, or if I'm just missing something in the configuration.
Thanks,
Chris
USA.NET
You Run Your Business. We'll Run Your Email.
This message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information of USA.NET, Inc. Any unauthorized review, use, copying, disclosure, or distribution is prohibited. If you are not the intended recipient, please immediately contact the sender by reply email and delete all copies of the original message.
2 years, 9 months
MemberOf group restrictions to a client system (server and client running CentOS 7)
by Janet Houser
Hi,
I'm new to 389-ds and last week downloaded and installed the software.
I have a running instance of the server, and I've added TLS/SSL. I've configured a CentOS 7 client to be able to query
the server using TLS/SSL, and all appears working.
I've created users and groups on the 389-ds server successfully. For each user and group, I've enabled posix attributes and my client
can see the unix users and groups using the "getent password" or "getent group" commands.
Now, here's where I'm getting tripped up..........
I need to limit which users have access to which systems. I've been trying to do this via memberOf group limitations.
I found the following online resource (https://thornelabs.net/2013/01/28/aix-restrict-server-login-via-ldap-grou...)
which is close enough to CentOS that the initial commands worked.
I enabled the MemberOf plugin and changed the attributes per the link, and restarted the system.
I created a test group (that I didn't enable a posix GID) and tried to add a single user via:
Right click on group -- > click Properties --> then Members --> click Add --> Search for user --> click Add.
When I try to go this route (which worked before enabling the memberOf plugin) it worked. Now it seems I get the error:
"Cannot save to directory server.
netscape.ldap.LDAPException: error resiult(65): Object class violation"
And the messages file throws the error (/var/log/dirsrv/slapd-<instancename>/errors:
"Entry "uid=test,ou=People,dc=int,dc=com" -- attribute "memberOf" not allowed
[17/Feb/2016:11:22:58 -0700] memberof-plugin - memberof_postop_modify: failed to add dn (cn=testgroup,ou=Groups,dc=int,dc=com) to target. Error (65)"
So it seems my server isn't quite using the memberOf plugin properly, but I'm not sure what else to enable. I'll have to solve this issue before
I even try to filter login access via groups on my client system.
I should mention that if I go under the advanced tab for one of the groups I created, I can add the the attribute "uniquemember", but I'm not sure what I
should set the "value" to be.
I've tried creating new users to see if I could set their "uniquemember" attributes, but no luck. It seems that I don't have the ability to set this attribute
on individual users, only groups.
This might not be the right road to head down when trying to restrict access to servers via groups, so I'm open to any suggestions.
Any suggestions would be appreciated.
2 years, 9 months
winsync password problems
by Alberto Viana
Hi Guys,
389-Directory/1.4.3.2
The password sync from 389 to windows(2012) is not working:
# dsconf RNP repl-winsync-agmt create --suffix=dc=rnp,dc=local
--host=gti-df-dc01 --port=636 --conn-protocol=LDAPS
--bind-dn="CN=my_win_account" --bind-passwd=password
--win-subtree=dc=my,dc=domain --ds-subtree=dc=my,dc=domain --win-domain=RNP
--sync-users=on --sync-groups=on --init AD-DF-DC01
Double checked everything including the user permissions on windows AD side
, also checked the windows log and passync log, could not found anything
related (at least the 389 trying to update my user's password or any error)
From windows to 389 works fine.
Attaching the log (in replication debug mode)
Don't know what else to look
Thanks.
3 years, 2 months
Sequence rollover; local offset updated
by Christophe Trefois
First off, apologies for double posting to here and ipa mailing list, but we are getting a bit uneasy, and also the issue seems to come from the code in 389-ds directly, so this seems more appropriate.
We are using ipa-server ipa-server-4.6.5-11.el7.centos.3.x86_64 with 389-ds-base-1.3.9.1-10.el7.x86_64 on CentOS 7.7.
Since couple days some of our replicas are coming with "csngen_new_csn - Sequence rollover; local offset updated." messages in the slapd erorr logs.
We use the python "ipa_check_consistency" and replication seems to be fine.
We checked all replicas, and they are all in time sync with ntp (updated) with no visible offset.
is this anything to worry about, and how can we make those messages to stop appearing?
3 years, 3 months
healthcheck problems
by Alberto Viana
Hi Guys,
In 389 version 1.4.2.4 healthcheck works fine:
~# dsconf RNP healthcheck
Enter password for cn=Directory Manager on ldaps://localhost:
Beginning lint report, this could take a while ...
Checking Backends ...
Checking Config ...
Checking Encryption ...
Checking ReferentialIntegrityPlugin ...
Healthcheck complete!
And seems that function was moved to dsctl
but in 1.4.2.5 I got this error:
~# dsctl RNP healthcheck
Beginning lint report, this could take a while ...
Checking Backends ...
Checking Config ...
Checking Encryption ...
Checking FSChecks ...
Checking ReferentialIntegrityPlugin ...
Checking MonitorDiskSpace ...
Checking Replica ...
Checking Changelog5 ...
Checking DSEldif ...
Error: [Errno 2] No such file or directory:
'/etc/dirsrv/slapd-{instance_name}/dse.ldif'
Is that a bug?
Thanks
Alberto Viana
3 years, 3 months
Re: 389-admin
by Giovanni Baruzzi
Dear Ilia,
I have similar problems.
I am working under CentOS 7 and I would like to gather experience with the new Cockpit, but I found no packages and no information.
How can we install it?
The search of EPEL repositories was unfruitful..
Thanks,
Best Regards,
Mit freundlichen Grüßen,
Giovanni
3 years, 4 months
389-admin
by Илья
Hello! Planning to move from Centos 6 to Centos 8, but can not find any
389-Admin server packages. Are they at least exist? or Admin server is
EOL project and there is another approach for 389 server management. I
hardly can find any latest info about this question.
Regards, Ilya.
3 years, 4 months
Announcing 389 Directory Server 1.4.1.14
by Mark Reynolds
389 Directory Server 1.4.1.14
The 389 Directory Server team is proud to announce 389-ds-base version
1.4.1.14
Fedora packages are available on Fedora 30.
https://koji.fedoraproject.org/koji/taskinfo?taskID=40932992
<https://koji.fedoraproject.org/koji/taskinfo?taskID=40932992> - Fedora 30
Bodhi
https://bodhi.fedoraproject.org/updates/FEDORA-2020-abba3cea93
<https://bodhi.fedoraproject.org/updates/FEDORA-2020-abba3cea93> - Fedora 30
The new packages and versions are:
* 389-ds-base-1.4.1.14-1
Source tarballs are available for download at Download
389-ds-base Source
<https://releases.pagure.org/389-ds-base/389-ds-base-1.4.1.14.tar.bz2>
Highlights in 1.4.1.14
* Bug fixes
Installation and Upgrade
See Download <https://www.port389.org/docs/389ds/download.html> for
information about setting up your yum repositories.
To install the server use *dnf install 389-ds-base*
To install the Cockpit UI plugin use *dnf install cockpit-389-ds*
After rpm install completes, run *dscreate interactive*
For upgrades, simply install the package. There are no further
steps required.
There are no upgrade steps besides installing the new rpms
See Install_Guide
<https://www.port389.org/docs/389ds/howto/howto-install-389.html> for
more information about the initial installation and setup
See Source <https://www.port389.org/docs/389ds/development/source.html>
for information about source tarballs and SCM (git) access.
New UI Progress (Cockpit plugin)
The new UI is fully functional. There are still parts that need to be
converted to ReactJS, but every feature is available.
Configuration Tab
Functional
Written in ReactJS
Server Tab Yes No (coming soon)
Security Tab Yes Yes
Database Tab Yes Yes
Replication Tab Yes Yes
Schema Tab Yes Yes
Plugin Tab Yes Yes
Monitor Tab Yes Yes
Feedback
We are very interested in your feedback!
Please provide feedback and comments to the 389-users mailing list:
https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproject...
If you find a bug, or would like to see a new feature, file it in our
Pagure project: https://pagure.io/389-ds-base
* Bump version to 1.4.1.14
* Issue 50727 - correct mistaken options in filter validation patch
* Issue 50727 - change syntax validate by default in 1.4.2
* Issue 49254 - Fix compiler failures and warnings
* Issue 50349 - additional fix: filter schema check must handle subtypes
* Issue 50836 - Port Schema UI tab to React
* Issue 50842 - Decrease 389-console Cockpit component size
* Issue 50790 - Add result text when filter is invalid
* Issue 50834 - Incorrectly setting the NSS default SSL version max
* Issue 50829 - Disk monitoring rotated log cleanup
causes heap-use-after-free
* Issue 50709 - (cont) Several memory leaks reported by Valgrind for
389-ds 1.3.9.1-10
* Issue 50599 - Fix memory leak when removing db region files
* Issue 49395 - Set the default TLS version min to TLS1.2
* Issue 50818 - dsconf pwdpolicy get error
* Issue 50599 - Remove db region files prior to db recovery
* Issue 50816 - dsconf allows the root password to be set to nothing
--
389 Directory Server Development Team
3 years, 4 months