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.
We recently upgraded from Centos 5.4 389-ds Version 1.1.2 to Centos 6.7
389-ds version 1.2.11
The setup has a single master, hub and 5 replicas. For some reason we are
experiencing replication delays of upto 40 secs between hub and replicas.
This did not occur in the old setup. At the time access logs showed an
average of 1000 MOD operations per minute.
Some of our configured parameters:
The systems resources on the Hub (CPU/memory/disk) look fine, so it must be
389-ds resources either on the hub or the replicas that must be causing the
delay. Where should I be looking?
Our build system detects syntax error in
String found where operator expected at
/usr/src/tmp/389-ds-base-buildroot/usr/sbin/ns-accountstatus.pl line 34,
near "STDERR " [-i] [-g seconds]\n\n""
(Do you need to predeclare STDERR?)
syntax error at
/usr/src/tmp/389-ds-base-buildroot/usr/sbin/ns-accountstatus.pl line 34,
See attached patch to fix it.
Small note: ldap/admin/src/scripts/db2index.in use Bash4 syntax
construction (|&), but use interpreter /bin/sh
Not all Linux distributives have /bin/sh as symlink to /bin/bash4
A question about how to best go about doing access control on db-linked directories. Given the below 2-directory setup (Dir1 has a db link set up to Dir2, and vice versa), is the shown ACI setup possible/advisable? If not, what’s the best way to make it work?:
aci:(targetattr ="*")(version 3.0;acl “Admins Group";allow (all) (groupdn = "ldap:///cn=admins,dc=example,dc=com");)
I ask because section 2.3.6. Database Links and Access Control Evaluation, of the RHDS Admin Guide says:
"ACIs must be located with any groups they use. If the groups are dynamic, all users in the group must be located with the ACI and the group. If the group is static, it may refer to remote users."
I’m afraid the phrasing is a little opaque to my understanding. Does it mean that “Admin Groups” act on Dir2 is not allowed to refer to cn=admins,dc=example,dc=com on Dir1?
If so, then what is the best way of maintaining groups centrally but allowing them to be used on remote directories?
Say Alice only has access to Dir1, she can issue a search to ou=projects because of the DB link from Dir1 —> Dir2. When the aci on ou=projects is processed, which user is used? uid=alice or the proxy user of the db link? Will the aci work at all in this case?
Thanks a lot,
Senior Programmer Analyst
Information Technology | Engage. Envision. Enable.
The University of British Columbia
trevor.fong(a)ubc.ca<mailto:email@example.com> | 1-604-827-5247<tel:604-827-5247> | it.ubc.ca<http://it.ubc.ca>
I am new to 389-console and have the following questions:
If 389-console connects the first time to an admin server or
a directory server the appropriate JARs will be downloaded
to the console locally. On the server they are stored under
These JARs are included in both packages 389-admin-console
and 389-ds-console, respectively.
Under RHEL 6 and CentOS 6 these packages can be downloaded
from the EPEL channel, but under RHEL 7 and CentOS 7
from the EPEL-TEST channel only.
Are there any plans to make the RHEL 7 packages available
in the EPEL channel soon? My customer restricts use of
I appreciate your help!
Thanks and best regards,
I have tried to set up a replication agreement on a 389ds master to send updates to a 389ds slave. The master is configure to use client certs for authentication.
The 389ds master fails each time it attempts to contact the slave with the following message, and tcpdump shows no traffic flowing over the wire:
[30/Mar/2016:17:19:19 +0000] setup_ol_tls_conn - failed: unable to create new TLS context
[30/Mar/2016:17:19:19 +0000] slapi_ldap_bind - Error: could not configure the server for cert auth - error -1 - make sure the server is correctly configured for SSL/TLS
[30/Mar/2016:17:19:19 +0000] NSMMReplicationPlugin - agmt="cn=Agreement ldap.example.com" (ldap:636): Replication bind with EXTERNAL auth failed: LDAP error 0 (Success) ()
The server is correctly configured for SSL/TLS, and I am able to bind to both the master and the slave over SSL port 636.
The replication agreement looks as follows:
dn: cn=Agreement ldap.example.com,cn=replica,cn=dc\3Dexample\,dc\3Dcom,cn=mapping tree,cn=config
cn: Agreement ldap.example.com
description: Replication agreement to ldap.example.com
nsDS5ReplicaBindDN: cn=Replication Manager,cn=config
nsds5replicaLastInitStatus: 255 Replication error acquiring replica: unknown
nsds5replicaLastUpdateStatus: 255 Replication error acquiring replica: unkno
wn error - Unable to acquire replica
Is there anything I can do to coax a useful error message out of the master server? "LDAP error 0 (Success)” tells me this is a bug of some kind, as why would it fail saying success?
This is 389ds on Ubuntu 14.04:
ii 389-ds-base 184.108.40.206-0ubuntu1 amd64 389 Directory Server suite - server
I have an old directory server running Sun One Java System Directory Service. Yesterday I created top dcobject - dc=christianbook,dc=com, however, I don't know what the best way is to import data from my old Sun Directory Server to 389 Directory Server. It appears the object structure is different. Below is an example of my old dcobject:
aci: (target ="ldap:///dc=christianbook,dc=com")(targetattr !="userPassword")(version 3.0;acl "Anonymous read-search access";allow (read, search, compare)(userdn = "ldap:///anyone");)
aci: (target="ldap:///dc=christianbook,dc=com") (targetattr = "*")(version 3.0; acl "allow all Admin group"; allow(all) groupdn = "ldap:///cn=Directory Administrators,ou=Groups,dc=christianbook,dc=com";)
aci: (targetattr = "cn||uid||uidNumber||gidNumber||homeDirectory||shadowLastChange||shadowMin||shadowMax||shadowWarning||shadowInactive||shadowExpire||shadowFlag||memberUid")(version 3.0; acl LDAP_Naming_Services_deny_write_access; deny (write) userdn = "ldap:///self";)
aci: (target="ldap:///dc=christianbook,dc=com")(targetattr="userPassword")(version 3.0; acl LDAP_Naming_Services_proxy_password_read; allow (compare,search) userdn = "ldap:///cn=proxyagent,ou=profile,dc=christianbook,dc=com";)
This is another object in my old Sun Directory Server:
What is the best way to convert or import from my old Sun Directory Server to new one?
I installed a new version of 389:
And I'm getting these warnings:
[30/Mar/2016:10:47:39 -0300] - SSL alert: Found unsecure configuration:
nsSSL3: on; We strongly recommend to disable nsSSL3 in
[30/Mar/2016:10:47:39 -0300] - SSL alert: Configured range: min: TLS1.0,
max: TLS1.2; but both nsSSL3 and nsTLS1 are on. Respect the supported range.
I already disabled nsSSL2 and nsSSL3:
and confirmed that my server is only accepting TLS connections
Also tried to delete nsssl3ciphers:
But it comes back.
Why I'm still getting these warnings even after to disable nsSSL2 and
Today I installed the 389 Directory Server and Directory Console. However, the console keeps crashing and dumping core. However, it failed to write core dump, leaving a log file into root directory.
The first time when it dumps core:
1. Launch the 389-console
3. Select Directory Server Instance, in my case, its userauth1, open it
4. Choose Configuration Tab, expand data
5. Right click on it, choose New Suffix
6. Type in New Suffix name: dc=test2,dc=com
7. Type in Database name: test2
8. Click OK.
Then it dumps core. I re-launch the console, but I cannot find the newly added suffix.
So I decide to add it again, but the console spit out error that "suffix already exists". Console does not display the newly added suffix, however, it thinks it does exist.
I repeated adding another new suffix with a different name. It works without core dump.
I repeated adding/deleting new suffix a few more times. It appears core dump happens either when adding or deleting root suffix, randomly.
I need help to figure out
1) How do I delete the root suffix that cannot be displayed by the console?
2) How do I make console stable.
The java package, java-1.6.0-openjdk-220.127.116.11-18.104.22.168.el6_7.x86_64, is installed and used on my CentOS 6.7 x86_64 machine.
> The spinlocks of course just do their thing, and then we're much more
> reliant upon the hardware to provide fairness, and as we see, this may
> not be a safe bet.
> We also see in the third graph and fifth graphs that the first core
> performed badly compared to the others. I do not know why, but it needs
> Relating to this though, although I don't have other plots, but I did do
> quite a lot of benchmarking with the prototype benchmark app, and I
> seemed to find on some machines that some cores *always* did badly, and
> for *all* lock types. I have a weak suspicion it reflects internal
> memory access arrangements in the core itself. However, this was on VMs
> - although they were all dedicated hardware, so I had no neighbours on
> the box - so it could just be Xen doing strange things.
Even though it's a VM, numactl -H may still show something relevant.
BerkeleyDB did adaptive locking, using a spinlock before falling back to a
heavier weight system mutex. In practice we always found that spinlocks are
only a win within a single CPU socket; as soon as you have cross-socket
contention they're horrible.
The other obvious contributor to system balance is interrupt steering. Most
kernels seem to have irqbalance working by default these days, but you may
still wind up with a particular core getting more than a fair share of
interrupts sent to it. Again, not something you can directly tweak inside a VM
with any meaningful effect. Aside from that, it's not always beneficial to do
what irqbalance does. Sometimes you get much better system throughput by
sacrificing a core, sending all interrupts to it, leaving all the remaining
cores for the application. Fewer context switches on the remaining cores,
which leads to much higher efficiency.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/