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.
I've been looking through the archives for information, but I haven't stumbled on a solution to my problem.
I'm running ds-389 (389-ds-base-22.214.171.124) on a centos 7 box (CentOS Linux release 7.2.1511). I have a centos OS client configured using SSL/TLS
which queries the LDAP server. Per a previous thread, I configured the memeberOf plugin and all seems to be working properly.
I have a php script that will run on the client and change the LDAP password for the user. The problem is, the script looks for the SSHA has
of the password when an ldapsearch is issued.
However, when I issue a general ldapsearch (anonymously) I don't get the userpassword field. I read in your archives that I might have
to be the "directory manager" user in order to see the hashed password. I've been playing around with the ldapsearch syntax, but I can't
quite get it right.
Anyway, my question is, can I set a flag in 389-ds that will display the hashed userpassword? I think that will solve my problem with the php script returning an error that it can't retrieve the old password.
we are running a small 389 DS cluster on two RHEL 7.4 machines. The version installed is the most recent in the Red Hat repositories, 126.96.36.199-19.el7_4. 389 DS is used as user storage for the Keycloak single sign-on system. It contains about 150k person objects.
To test the whole system, we are running load tests each night. These tests login 100 users per second in Keycloak for 15 minutes, which in turn authenticates the users against 389 DS. On our machines, this normally results in a very low CPU load by 389 DS, about 10-25%.
Up to now we used SSHA512 as password hashing algorithm. We now would like to switch to PBKDF2: As a first test, we changed the password of the user that Keycloak uses to bind to 389 DS to PBKDF2 hashing. In this configuration, we encountered a problem: When running the load tests, the system behaves normally for the first few minutes. After this, 389 DS CPU usage suddenly jumps to almost 800% on one of the servers (the machines have 8 CPUs) and authentications become very slow. This continues for the remaining runtime of the load test. When running the test again, 389 DS again behaves normally for the first few minutes, then CPU usage jumps to 800%.
When changing the password hash back to SSHA512, everything is fine again.
To me this looks like a bug in 389 DS. Please let me know what information to provide so you can investigate.
I hope to participate in Outreachy 2017 under Fedora in the project 389
Directory, mentored by William Brown.
I am fluent with the skills mentioned for the project. How should I start
the application process and my contributions to be a strong candidate for
I am running a multimaster master fractional replication (M1, M2 host) with memberof plugin excluded from replication, I am looking to add 1/2
dozen DS's to replication system but ALL will be read only ( master
-> slave replication cfg-one way replication) what will be my options
for cfg replication
-should I consider using M1 or M2 as master wich will replicate to each slave , so the master M2 will have 6 replcation agreements to each slave host -or -should I consider the cascading replication option one slave gets data from Master DS and from this slave next one replicates and so on ?
which one of this designs cfg replication solution will give the best performance?
I need to do ldapcompare in cn=encryption,cn=config and have no idea why I can’t:
root@ldap01:/home/ubuntu# ldapcompare -h localhost -D cn=root -wadmin cn=encryption,cn=config nsSSL2:off
Compare Result: Server is unwilling to perform (53)
Additional info: Operation on Directory Specific Entry not allowed
cn=root is the directory manager user.
What can I do to change this?
389-ds 188.8.131.52 - ubuntu
I have 2 server in multi master replication one of the DS server the log_archive dir is growing crazy, I need to be able to keep only the last 30 days log files, here is my cfg, what needs to be changed to accommodate the change?
nsslapd-accesslog: /var/log/..... /access
I'm a research student pursuing my Masters in IIIT-Hyderabad. I am keen on
working on the 389 Directory Server project for Outreachy.
I have prior experience in configuring, maintaining and managing systems in
an MHRD(Ministry of Human Resource Development, India) funded project. I
have completed the required course credits towards my degree and am working
on my Thesis currently. This would be great a opportunity for me to learn
and start contributing to the open source community at Fedora.
As I am a bit new to the community it would be nice if anyone could guide
me to a few useful resources to get me started. I started reading the
in our company we're working on project of migration multiple master-slave
synchronized OpenLDAP servers to multi-master 389 DS servers configuration.
We've been using OpenLDAP to store data of multiple applications such as
DNS servers (PowerDNS), DHCP servers, Mail servers (Postfix, Amavis)
etc..for at least 9 years.
We need to use custom LDAP schemas to store the data of these applications
in LDAP. These need to be converted from OpenLDAP format to RFC strict 389
DS convenient format which actually works great for most of them.
Unfortunately I didn't manage to use PowerDNS LDAP schema (
https://doc.powerdns.com/authoritative/backends/ldap.html) with 389 DS. As
I tried to google more information why this schema doesn't work with 389 DS
I found out it uses 'dnsdomain' schema which comes with OpenLDAP (
and was removed from 389 DS many years ago.
*Could you please give me some advice what can I do to make PowerDNS
backend work with 389 DS ?*
We're mid-sized company with many services using LDAP as their storage
backend and to migrate all of them to new LDAP servers is priority number
one. If there is no way to migrate PowerDNS LDAP data from OpenLDAP to 389
DS the whole project of migration to 389 DS would need to be reconsidered.
Nevertheless I don't understand why such a worldwide popular DNS server
which PowerDNS surely is couldn't be used with 389 DS LDAP implementation
which is also quite popular.
I'm in a situation where I will need to have my two existing version 184.108.40.206 B2015.345.187 servers, set up for multi-master replication, do multi-master replication with two additional 1.3 servers. Is there any known problem with this and is anyone doing it?