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:
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 220.127.116.11~git0.5ac5a8aad. The problem was the same with 18.104.22.168.
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:
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.
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.
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.
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
--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
It's my first message on this list thanks in advance for your answers.
I've configured a 389ds instance with ipv6 address and it's working
great with it.
I need for this instance to be reachable via ipv4 also but despite
hours of research on the web and the archive of the list, I couldn't
find any good help or how-to to setup 389ds to listen on both ipv4 and
I can't find a parameter specifying the listening interfaces.
Has anyone faced this kind of setup and managed to make it work?
Can 389ds work this way?
we have set up a multi master replication (two peers, SIMPLE authentication) and added a global password policy to cn=config. We included the passwordMustChange attribute to cn=config, which led to the fact that the server process could not authenticate to the replication manager of the peer host. We solved it by removing the generated attribute passwordExpirationTime.
How is it usually handled to include something like passwordExp in the global policy at cn=config without preventing something like replication from working:
1. Apply a user based policy (w/o passwordExp) to the user-like object "replication manager", or
2. Place the user-like objects like "replication manager" to the DIT (not cn=config) and apply a subtree based policy (w/o passwordExp) to the subtree containing the object, or
3. avoid setting pwdExp and pwdMustChange to a global policy at cn=config, or
4. something else?
I have single master/replica setup and information is flowing. After the sync I had 2 issues. First issue is within the console. After syncing from the 8.2 master to the 9.1 replica I can no longer access any of the items in the server group on the replica.. Clicking on Administration server or the dirsrv instance gives an error. "Failed to install a local copy of redhat-ds-8.2.jar or one of its supporting files. Please ensure that the appropriate console package is installed on the administration server. redhat-ds-8.2jar not found at http://dir.mycomp.org:9830/". So not sure if I need to find the redhat-ds-8.2.jar file on the master and install it on the replica, run setup-ds-admin.pl -u or if this is normal behavior for the replica?
The second issue are schema issues. Initially I copied the /etc/dirsrv/slapd-inst/schema/99user.ldif file over from the master to the replica and it took care of most of the schema errors. However I am still getting the following error:
[25/Feb/2020:08:38:15 -0500] NSACLPlugin - __aclp__init_targetattr: targetattr "ssn" does not exist in schema. Please add attributeTypes "ssn" to schema if necessary.
[25/Feb/2020:08:38:15 -0500] NSACLPlugin - ACL PARSE ERR(rv=-5): (targetattr = "ssn
[25/Feb/2020:08:38:15 -0500] NSACLPlugin - Error: This ((targetattr != "ssn || userPassword") (version 3.0;acl "Directory Comparator";allow (read,compare,search)(userdn = "ldap:///uid=comparator,ou=Special Users,o=dir.mycomp.org");)) ACL will not be considered for evaluation because of syntax errors.
I have looked at the attributes in schema under the instance's configuration tab (within the master's console) but there isn't an ssn attribute that I can find. I see userPassword attribute. Not sure how to proceed from here.
OK, I've got 389-ds all installed and performed the install test.
Now what? How do I get all of the required information concerning my LAN
into the 389-DS server? Is here a document or tutorial on how to do this?
First, i am a noob to ldap and directory server. I have been at this for
30+ days in various scenarios to move off of directory server 8.2 to 11. In
my latest iteration I am just trying to step through the major upgrades
os/ds one at time to get to my end result.
I am trying to replicate databases from directory server 8.2 to 9. I have
followed the redhat documentation but still struggling. On the consumer, I
am getting the error message,
slapi_ldap_bind - error: could not bind id [cn=replication
manager,cn=config] mech [SIMPLE]: error 48 (inappropriate authentication)
errno 0 (Success)
I have changed the password do it wouldn't be too simple. Made sure that
supplier dn is cn=replication manager,cn=config as well as simple bind
userid. How can I check if security and what type is on supplier?