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.
Hi, I am having a problem with LDAP multi-master environment. I am trying to initialize a new hub (first one crashed so this is a new build with same hostname).
When I exported the LDIF file from master and imported to hub there were no errors. I then created a replication agreement from master to hub. When I try to send updates, I get error on hub error log: csngen limit exceeded value 129888, limit 86400.
Is there a way to reset the skew or "force" the replication?
Paul M. Whitney
I have a requirement to disable inactive users after 90 days. I did read
http://directory.fedoraproject.org/wiki/Account_Policy_Design but I am not
sure whether this is a design proposal or the actual implementation.
My DS version is :
rpm -qa | grep 389
[root@386-100-16 dirsrv]# ldapsearch -x -D "cn=Directory manager" -w
Password -b "cn=config" -s base lastLoginTime
# extended LDIF
# base <cn=config> with scope baseObject
# filter: (objectclass=*)
# requesting: lastLoginTime
# search result
result: 0 Success
# numResponses: 2
# numEntries: 1
[root@386-100-16 dirsrv]# grep -i lastlogintime
holds login state in user entries (GeneralizedTime syntax)
2.16.840.1.1137126.96.36.199.1.35 NAME 'lastLoginTime'
I am not sure how to implement this though, please advice.
I know this is not a strictly 389 DS related question. I did
set idle_timelimit 60 in my /etc/ldap.conf client file but connections
stay running and do not time out. Is there any setting I need to add on the
server side ?
My Full Ldap file at /etc/ldap.conf
I'm facing a problem with windows users whose password contains the spanish accented "n" (ñ). Neither the ldap directory or the password sync service complain at all , but the user is unable to auth in 389ds (latest version both 389-ds and windows pass sync). I've browsed the forums and disabled the 7bit-check plugin, but that does not seem to work either. Here's what I've found in the audit logs (please note the unhashed password entry):
Windows user password: funci0nA
modifiersName: cn=directory manager
However, with accented "n":
Windows user password: cañadelomo
modifiersName: cn=directory manager
Why the difference when the spanish char is used, does it trigger something else in the sync process?
J u an Carlos Camargo Carrillo
957-211157 , 650932877
I'm trying to add a new server, and will need to use SSL, of course.
But all the instructions tell how to generate a self-signed CA, but
we've got real signed certs on the other servers, and so I'm trying to
generate a CSR for the new one.
Generating one from the 389-console is only giving me a 1024-bit key,
and 2048 is required.
I see that running the cert request from the command line is not the
preferred option, but how else can I change the parameters for the cert
Our instance of 389 (version 188.8.131.52 running on Centos 5.7) has recently begun
exhibiting problems with account locking.
Locking (or inactivating if you prefer) an account, either by using the 389
console, or the ns-inactivate.pl script works initially and the user object
displays the correct attributes...
nsrole "cn=nsdisabledrole,dc=..." "cn=nsmanageddisabledrole,dc=..."
and an ldapsearch confirms the existence of the nsaccountlock attribute.
However, after some period of time has elapsed (haven't quite narrowed down
exactly when it occurs) the nsaccountlock attribute is no longer present,
meaning the account is no longer locked.
About two weeks ago, I removed all entries from nsManagedDisabledRole and
restarted dirsrv, then inactivated approximately 16 accounts. As of Thursday
last week they were all still as expected with the nsaccountlock attribute
present. As of this morning (Monday) none of the accounts have the
nsaccountlock attribute present. The modifytimestamp for the user object
remains unchanged, which would indicate an issue with the management of the
virtual nsaccountlock attribute.
Does anyone have any idea what might be causing this? Replication is not an
issue as we only have a single server. There is an AD sync agreement active, but
it's my understanding that 389 cannot sync account locking with Active Directory.
Is the management of the virtual attribute nsaccountlock logged at all? Is
there a specific log level (either in access log or error log) that will give a
clue as to what is happening?
Thanks in advance,
I think I have succeded in setting up 389ds on Centos 6.2. Now I would
like to integrate samba with 389. Is there any documentation available
that explains how to do it?
I didn't know how to title this mail. I think this should be a feature
request in Track when I want to discuss this here first.
I have 389DS with 150 DBs with an structure similar to this:
Each one of this subtrees are in separate DBs because I have subtree
replication between the 150 branches of the companies.
80% of the objects are in the ou=HeadQuarters. I've noticed that the
performance is definetely better when I use base ou=Headquarters in my
I have indexes on each DB but I think that the problem is that 389DS
doesn't have a master index or something to improve the searchs in
scenarios like mine.
May be the solution is to implemen another replication code that
doesn't required separate DBs for subtree replication.
Shall I file a ticket? Or there is a solution now?
for pam config always read the man page:
$ man pam_ldap
the most interesting part in pam.conf is:
login auth requisite pam_authtok_get.so.1
login auth required pam_dhkeys.so.1
login auth required pam_unix_cred.so.1
login auth binding pam_unix_auth.so.1 server_policy
login auth required pam_ldap.so.1
for ssh add a additional section where you replace 'login' with 'other'.
The search limit configuration in 389 DS is similar to the SunDS 5.x server.
at least a "getent passwd <ldapusername>" should return the entry. Perhaps you should configure on the DS389 VLV's with the Solaris /usr/lib/ldap/idsconfig script. If you adapt the DS version check, this script works also for 389DS.
Am 03.05.12, schrieb Rafael Hinojosa <rhinojos(a)haverford.edu>:
> 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 Client.
> 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 and groups.
> 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 greatly appreciated.
> Thank you for your time,
> Rafael A. Hinojosa
> Technical Support Analyst
> Core Technologies - Instructional & Information Technology Services
> Haverford College - 370 Lancaster Ave. - Haverford, PA 19041-1392
> Office : (610) 896-1312
> Direct : (610) 772-1593
> Fax : (610) 896-1429