My colleague and I are working on migrating from Sun One Directory Server
to 389 Directory Server. We have successfully configured 389 Directory
Server on Centos 5.7. We've been able to successfully setup Multi-Master
Replication and have joined (or at least it appears to) a Solaris 10
Here is a quick breakdown of what we're observing...
Solaris 10 host, as a 389 Client...
... can perform ldapsearch (using both directory manager & proxyagent
bindDNs). It will return all entries (when using directory manager as the
bindDN) or a limited amount (2000, when search using proxyagent bindDN), as
specified by the configuration.
... using ldaplist requires an escaped wild card to list most of the DB,
again I'm assuming it is inheriting the proxyagent limits.
... executing "getent passwd" or "getent group" returns ONLY the local
users & groups.
Solaris 10 host, as a Sun One Client...
... using ldapsearch exhibits the same behavior.
... using ldaplist requires no wild card, we can simply execute "ldaplist
passwd" and get, surprisingly, all entries in the DB.
... can execute "getent passwd" or "getent group" and see all LDAP users
Is this normal or have we screwed up some config somewhere?
We have yet to move on to tackling the PAM stack since we're trying to see
if this config is viable.
At the moment, as a local user on this 389 Client, we cannot su to another
LDAP user. It just says sorry, /var/adm/messages just reads "su :
[auth.crit] 'su <USER>' failed for <LOCAL USER> on..."
We can su to another LDAP user as root w/o the need to specify a passwd,
which I'm assuming is the only reason that works.
My colleague is going to work on finding a viable PAM config. Any clues,
leads, or references you can provide us for either anomalies would be
Thank you for your time,
Rafael A. Hinojosa
Technical Support Analyst
Core Technologies - Instructional & Information Technology
Haverford College - 370 Lancaster Ave. - Haverford, PA 19041-1392
Office : (610) 896-1312
Direct : (610) 772-1593
Fax : (610) 896-1429
I have several questions about syntax and attributes, hope you can help me.
- Why the attribute mail in DS is case sensitive?? Is there any problem
changing it to non case sensitive? If there is no problem, how can I modify
- I have a problem whit the syntax of the nsViewFilter attribute, the value
of the attribute is: (ou=*ou=D. PERIÓDICO,o=xxxxx,dc=xxxx,dc=xxxx). I guess
the problem is the character "Ó" but if it is possible to create the ou
with special characters, should be possible create a nsViewFilter with
special characters to??? (389DS 1.2.5)
- I have read about the attribute nsslapd-allidsthreshold and its use in
older versions. I have 389DS 1.2.5, have I to use it or it is deprecated???
I have search this parameters in my ldap servers and someones have it, and
others don't, maybe this behaviour is because of actualizations of the DS
but I would like to know if in 1.2.5 is needed or if i can delete it.
Thank you in advance.
I'm wondering if this is a bug in the logging of CMP operations. What we have empirically determined is the right thing is happening but the log is not indicating a CMP of a member attribute against a specific DN which is NOT any of the DNs in the log snippet below. The dn="" is the area of concern on the CMP operation. If you're interested, we are using the pam ldap client on RHEL6 to generate this behavior.
DS is 184.108.40.206 on RHEL5
[01/May/2012:10:55:52 -0400] conn=143810 op=0 BIND dn="uid=compserv-unix-nss,ou=Specials,dc=cmu,dc=edu" method=128 version=3
[01/May/2012:10:55:52 -0400] conn=143810 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=compserv-unix-nss,ou=specials,dc=cmu,dc=edu"
[01/May/2012:10:55:52 -0400] conn=143810 op=1 SRCH base="dc=cmu,dc=edu" scope=2 filter="(uid=gettes)" attrs="host authorizedService shadowExpire shadowFlag shadowInactive shadowLastChange shadowMax shadowMin shadowWarning uidNumber"
[01/May/2012:10:55:52 -0400] conn=143810 op=1 RESULT err=0 tag=101 nentries=1 etime=0
[01/May/2012:10:55:52 -0400] conn=143810 op=2 CMP dn="" attr="member"
[01/May/2012:10:55:52 -0400] conn=143810 op=2 RESULT err=5 tag=111 nentries=0 etime=0
[01/May/2012:10:55:52 -0400] conn=143810 op=3 UNBIND
I think I made a mistake but not sure what.
I successfully installed the Server Certs and CA certs generated from my
dogtag CA. I set all the necessary parameters. I confirmed that the
New Certificates were installed and restarted the directory server. Now
I get the error message in /var/log/dirsrv/slapd-SonshineServer/errors
[30/Apr/2012:21:57:16 -0500] - SSL alert: Security Initialization:
Unable to authenticate (Netscape Portable Runtime error -8192 - An I/O
error occurred during security authorization.)
[30/Apr/2012:21:57:16 -0500] - ERROR: SSL Initialization Failed.
Any ideas on what I can do to fix the problem would be greatly
appreciated. I'm on F15 and updated my 389 packages to the following:
Hello, all. We would like to enforce unique cn for groupofuniquenames
only and only under a specific part of the DIT.
I'll illustrate with:
So we want to enforce unique CNs on groups under Internal but not under
External and only CNs on groups (because our current DN based uniqueness
constraint on CN means we can't create multiple password policy
nscontainer objects under Internal).
If we configure set nsslapd-pluginarg1 to
"O=Internal,DC=mycompany,DC=com", we enforce uniqueness in that
container but for all objects.
Although we haven't tried it (lest we create a bigger problem than we
already have!), I believe it we set nsslapd-pluginarg1 to
markerObjectClass=O and nsslapd-pluginarg2 to
requiredObjectClass=groupofuniquenames, it will enforce CN uniqueness on
groups but will do so both in Internal AND External. Is that correct?
So is it possible to combine them somehow to achieve what we want?
Thanks - John