Hi, I figured I would ask the question here before proceeding with a RFE.
I searched TRAC and couldn't locate any relevant tickets.
I'd like to have 389 compress rotated log files to save significant amounts of disk space. Additionally, logconv.pl and other relevant tools would need to be modified to dynamically uncompress logfiles being processed (yes, I know I could gunzip -c and stuff like that but it would be easy to modify the tool to "do the right thing"). Is this a reasonable RFE or is it deemed "out of scope"?
I have a 389 DS server replication agreement whith an AD Server and when I
change the password in the windows side it replicates into 389 but via 389
console I can see this field "unhashed#user#password" in clear text.
How can I encrypt this field? Is it possible?
I tried the following configuration:
dn: cn=unhashed#user#password,cn=encrypted attributes,cn=userRoot,cn=ldbm
If I restart my server the field is gone.
The fact is that I need to avoid my admin to see the user´s password.
I have recently upgraded our 389 servers from pretty old versions that
were a mix and match of 389 release and CentOS released versions (all on
centos 5) to the latest (on centos6) (specific RPMs listed below).
I did this though a full ldif dump of the original server and imported
into a freshly installed new master server. Then I setup the
replication agreements with the 7 slave servers and everything was
After about a week I starting having a problem with the hubs servers
where all of them after (possibly exactly) 24 hours would start going
crazy on the disk IO (95-100% according to sysstat) of that server
making queries to ldap slow. The master server does not exhibit this
problem, it will run completely fine.
A simple restart of the dirsrv process corrects the issue and then it
will run for another 24 hours before repeating the issue.
The hardware running each node is somewhat different with varying disk
speeds underlying, but all exhibit the same behavior.
This happens the same on the 2 nodes that get relatively little traffic
and the 5 nodes that get a lot of traffic.
I was originally on the 389-ds-base release that shipped with CentOS6
and have changed to the version from the
repo, both do the same thing.
Any thoughts/suggestions on how to fix or further diagnose this? I've
had no luck with strace or error logs to find any issues. At this point
I've unfortunately had to resort to a cron job to restart all of my LDAP
I have 2 389 DS servers a 6 AD servers and i read this on red hat
documetation about windows replication:
"There can only be a single sync agreement between the Directory Server
environment and the Active Directory environment. Multiple sync agreements
to the same Active Directory domain can create entry conflicts."
Now I´m trying the following scenario:
server2 389(consumer) <- replication -> server1 389 <- replication ->
So in my master 389 server (server1) I have 3 agreements with 3 different
AD servers. It´s not clear if "Active Directory environment" means just one
Just to make clear that the 6 AD servers are in the same Active Directory
domain and all replicate information with each other. I have this number of
AD servers because they are located in different places(physically).
Can this scenario create entry conflitc? Am I suppose to sync with just one
We're trying to modify our already heavily modified version of fdstools to add
ntUser attributes to users. When we use it to create a new user (or add
ntUser attributes to and existing user) we end up with two new users in AD and
the cn: attribute of the user in 389 is modified to have CNF:<guid> added
which indicates a conflict in the database.
If we check the Enable NT User Attributes and create New NT Account in
389-console everything seems to work. We're not able to see what we're doing
differently. Except that perhaps 389-console is setting ntUniqueId, but I
didn't think it was supposed to do that, that the AD sync was supposed to
In fdstools we're setting ntUserDomainId, ntUserCreateNewAccount, and
ntUserDeleteAccount. Which seems to be all we need to do according to
Technical Manager 303-415-9701 x222
NWRA, Boulder Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
I have an 389 DS server 1.2.10 and I disabled/inactivated a user just for
test (via 389 console) but I could not find what attribute was modified
with this change. I need to know how to identify a disabled/inactivated
I did check the box that says User Must Change Password After Reset in Data
under configuration I also did set the same policy for specific users.
However, I am not being asked to change password on first logons through
ssh or direct console on server, the same is true when I do change the
password of a user "I guess this is what password reset means".
I am not using Fine Grain Password settings.
Any ideas ?
I'm upgrading one 389DS machine from 1.2.5 to 220.127.116.11 and I have found a
problem when replicate the schema from another 1.2.5 DS machine.
I had created an attribute like this:
and at replication time get this error:
[10/May/2012:14:35:31 +0200] attr_syntax_create - Error: the EQUALITY
matching rule [caseIgnoreIA5Match] is not compatible with the syntax
[18.104.22.168.4.1.1422.214.171.124.15] for the attribute [xxxxx]
Is there a default equality matching rule for this manual attributes???
Have I to modify the attribute with a equality matching rule for it in the
original 1.2.5 DS to be able to replicate??? Is it a problem between
versions??? If someone could help me i will appreciate it.