I have just one problem left that prevent me to migrate from ibm tivoli to
389 ldap. The format of the birthdate
i have generated a date AAAAMMJJHHMMSS with this format but 389 still refuse
to add it must i encode this
also in base64 to be able to use this format ? i have used this trick to add
a space value to a attribute
the syntax of birthdate is generralizetime
#!ERROR [LDAP: error code 21 - birthdate: value #0 invalid per syntax ]
Hello, I been using linux for years and I got my family to use
linux(forcibly hehe)and they love it. Well I am in college I recently
took a class that uses Windows Active Directory, and I was wondering if
there was something equilvent to linux. I heard the 389 prjoect was
somewhat close to that, I have questions like can make roaming profile
for users, can I configure window clients, and so on. Though I kinda
want to get your guys opinion how you guys started with 389. Like
should I buy book based on LDAP, should I take some class related to
that, or relay on the internet to find all information. Thank you for
I'm writing this mail to report a strange behavior in 389-ds when
configured as MultiMasterReplication.
The scenario is very simple an application use it as authentication
base, the access to ldap server is regulated by a software load balancer
with two nodes.
The strange thing I noticed is every 48 hour the server must be killed
and restarted beacause doesn't respond to any request but the port and
the process are still alive, some times MMR stops due to an not existing
conflict in some entry
But today comes the disastrous thing over, MMR doesn't work anymore.
Checking the error log on first node was reported a strange thing
> [17/Feb/2010:13:11:45 +0100] NSMMReplicationPlugin - Replication agreement for agmt="cn=srvprd-l011v->srvprd-l012v" (172:389) could not be updated. For replication to take place, please enable the suffix and restart the server
> [17/Feb/2010:13:13:25 +0100] NSMMReplicationPlugin - Total update aborted: Replication agreement for "agmt="cn=srvprd-l011v->srvprd-l012v" (172:389)" can not be updated while the replica is disabled
> [17/Feb/2010:13:13:25 +0100] NSMMReplicationPlugin - (If the suffix is disabled you must enable it then restart the server for replication to take place).
> [17/Feb/2010:13:14:50 +0100] NSMMReplicationPlugin - conn=30964 op=3 repl="ou=ext,o=MYroot": Begin incremental protocol
> [17/Feb/2010:13:14:50 +0100] NSMMReplicationPlugin - conn=30964 op=3 replica="unknown": Unable to acquire replica: error: no such replica
> [17/Feb/2010:13:14:50 +0100] NSMMReplicationPlugin - conn=30964 op=3 repl="ou=ext,o=MYroot": StartNSDS50ReplicationRequest: response=6 rc=0
> [17/Feb/2010:13:16:27 +0100] NSMMReplicationPlugin - Total update aborted: Replication agreement for "agmt="cn=srvprd-l011v->srvprd-l012v" (172:389)" can not be updated while the replica is disabled
> [17/Feb/2010:13:16:27 +0100] NSMMReplicationPlugin - (If the suffix is disabled you must enable it then restart the server for replication to take place).
But either the replica and the suffix are already enabled !!!! The first
thing I do is to restart the istance but print this
srvprd-l011v... 389-Directory/1.2.5 B2010.012.2033
[17/Feb/2010:13:32:47 +0100] - 389-Directory/1.2.5 B2010.012.2033 starting up
[17/Feb/2010:13:32:47 +0100] NSMMReplicationPlugin - _replica_init_from_config: failed to create csn generator for replica (cn=replica,cn=\22ou=ext,o=MYroot\22,cn=mapping tree, cn=config)
[17/Feb/2010:13:32:47 +0100] - replica_destroy
[17/Feb/2010:13:32:47 +0100] NSMMReplicationPlugin - Unable to configure replica ou=esterni,o=siae: failed to create csn generator for replica (cn=replica,cn=\22ou=ext,o=MYroot\22,cn=mapping tree, cn=config)
[17/Feb/2010:13:32:47 +0100] NSMMReplicationPlugin - changelog program - _cl5CheckGuardian: found old style of guardian file: bdb/4.3/libreplication-plugin
[17/Feb/2010:13:32:47 +0100] NSMMReplicationPlugin - changelog program - _cl5DBOpen: file d0bbdd82-1dd111b2-a05ca5d6-b0600000_4b699709000000010000.db4 has no matching replica; removing
[17/Feb/2010:13:32:47 +0100] NSMMReplicationPlugin - changelog program - _cl5DBOpen: failed to remove (�ҷ�fU�) file; libdb error - 2 (No such file or directory)
[17/Feb/2010:13:32:47 +0100] NSMMReplicationPlugin - changelog program - _cl5DBOpen: opened 0 existing databases in /var/lib/dirsrv/slapd-srvprd-l011v/changelogdb
[17/Feb/2010:13:32:47 +0100] NSMMReplicationPlugin - Found replication agreement named "cn=srvprd-l011v->srvprd-l012v, cn=replica, cn="ou=ext,o=MYroot", cn=mapping tree, cn=config".
[17/Feb/2010:13:32:47 +0100] NSMMReplicationPlugin - The replication agreement named "cn=srvprd-l011v->srvprd-l012v, cn=replica, cn="ou=ext,o=MYroot", cn=mapping tree, cn=config" could not be correctly parsed. No replication will occur with this replica.
[17/Feb/2010:13:32:47 +0100] NSMMReplicationPlugin - agmtlist_config_init: found 0 replication agreements in DIT
[17/Feb/2010:13:32:47 +0100] - slapd started. Listening on All Interfaces port 389 for LDAP requests
Due to business continuity I did restore the MMR as soon as possible and
I must did it removing replicas and changelog to recreate it from the
What Can I do to being MMR more reliable???
I have a quick question. I am using Fedora 12 and just installed 389
Directory Server yesterday.
I followed the instruction on the yum installation guide,
- yum install 389-ds
I am not sure why it installed 389 DS 1.2.3 instead of 1.2.5. I tried "yum
upgrade" but no luck.
I assume the reason is probably I am pointing at a wrong yum repository.
Can someone please provide me with the address to the yum repository that
has 389 DS 1.2.5?
Hello, all. I read in a post from 2006 that 389 does not support
referential integrity for memberuid. That would seem like a great
inconvenience. Has that been changed or is it still impossible? Is
there any chance of it changing? I suppose we are a little spoiled in
our environment in that uids are globally unique. I can see how this
could be a problem when there are non-unique uids but, since referential
integrity can be configured to take specific attributes, I was hoping we
could enforce it in our case :-( Thanks - John
Hello, all. I'm having a miserable time getting CUPS to work with
Directory Server for group authentication. I think it is more
fundamental than CUPS. When I do getent group <groupname> to a local
group, the result is populated with members. However, if I do it for an
LDAP group, the group is returned but with no members. What would cause
such behavior? Do I need something other than default NSS mappings?
I am running CentOS Directory Server 8.1 on CentOS 5.4. The client is
running Debian Lenny. Thanks - John
Perhaps some of you have gone down this path before and can offer some
helpful suggestions. I need to convert a group of servers to LDAP
authentication. Most of the user accounts on these systems have
consistent uids and gids across all the servers. There are a few
exceptions but the people who need to access the servers on a daily
basis should all have the same account uid on every machine.
My questions are:
1. Can you disable local authentication for all users except root
once LDAP authentication is in place?
2. If there are some users who only need access to a small number of
servers, how would you handle that situation?
3. When adding new users, do you create them a private group to avoid
id: cannot find name for group ID 5001
Any other tips, tricks, or gotchas are most welcome!
Guys I' ve seen this warning on the 8.1 Administration Guide:
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
In my scenario I have many OUs under the AD synchronized subtree eg
ou=dep1,dc=example,dc=com , ou=dep2,dc=example,dc=com , etc. I tried to
synchronize the whole subtree dc=example,dc=com to the respective tree
on DS but this fails due to schema incompatibilities. So I created one
sync agreement per OU and it seems to be working as expected in my test
environment. What that warning above is all about? What could possibly
go wrong if you use multiple sync agreements. How can there be entry
conflicts if each synchronized subtree is different from the other?
Another issue I have is that when users are disabled on the AD they are
still active on the DS. An obvious workaround is to change the password
of the disabled user so he can not use his account on AD but it would be
nice if their is a solution to avoid this. Any ideas?
We have what appears to be a single replication operation holding up all
subsequent replication changes. We had a user who was added to our
Active Directory with an incorrect name. The record was then synced down
to our 389 DS server/FreeIPA. When the problem was discovered, it
appears that someone attempted to change the records on both the AD and
Directory Server between replication attempts. We are now stuck in a
loop, where the Directory Server is trying to send the rename operation
to the Active Directory, but it keeps failing due to receiving a
referral (presumably because the rename operation has already occurred
manually, but not sure). To make things worse, it appears that any
subsequent changes are stuck waiting for this transaction to complete.
How can I rectify a referral operation from my AD server. I assume that
because I have only one LDAP connection to my AD servers that a referral
will never work properly. How can I get around this issue? Is there a
way to revoke this one change and have the Directory begin processing