Issue with schema replication
by Moisés Barba Pérez
Hi,
I'm upgrading one 389DS machine from 1.2.5 to 1.2.10.7 and I have found a
problem when replicate the schema from another 1.2.5 DS machine.
I had created an attribute like this:
attributeTypes: (
<OIDXXXXXXX>
NAME 'xxxxx'
DESC 'yyyyy'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024}
SINGLE-VALUE
)
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
[1.3.6.1.4.1.1466.115.121.1.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.
Regards,
Moses.
11 years, 11 months
Cannot Initialize Hub
by Paul Whitney
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
paul.whitney(a)me.com
11 years, 11 months
Disable Inactive Users After 90 days
by Ali Jawad
Hi
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
389-admin-console-1.1.8-1.el5
389-ds-base-1.2.9.9-1.el5
389-dsgw-1.1.7-2.el5
389-console-1.1.7-3.el5
389-adminutil-1.1.14-1.el5
389-admin-1.1.23-1.el5
389-admin-console-doc-1.1.8-1.el5
389-ds-1.2.1-1.el5
389-ds-base-libs-1.2.9.9-1.el5
389-ds-console-1.2.6-1.el5
389-ds-console-doc-1.2.6-1.el5
I got
[root@386-100-16 dirsrv]# ldapsearch -x -D "cn=Directory manager" -w
Password -b "cn=config" -s base lastLoginTime
# extended LDIF
#
# LDAPv3
# base <cn=config> with scope baseObject
# filter: (objectclass=*)
# requesting: lastLoginTime
#
# config
dn: cn=config
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
and
[root@386-100-16 dirsrv]# grep -i lastlogintime
/etc/dirsrv/slapd-386-100-16/schema/*
/etc/dirsrv/slapd-386-100-16/schema/60acctpolicy.ldif:## lastLoginTime
holds login state in user entries (GeneralizedTime syntax)
/etc/dirsrv/slapd-386-100-16/schema/60acctpolicy.ldif:attributeTypes: (
2.16.840.1.113719.1.1.4.1.35 NAME 'lastLoginTime'
I am not sure how to implement this though, please advice.
Regards
11 years, 11 months
idle_timelimit 60
by Ali Jawad
Hi
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
bind_policy soft
URI ldap://xx.xx.xx.xx
BASE dc=xxxxxxx,dc=local
TLS_CACERTDIR /etc/openldap/cacerts
pam_password clear
pam_lookup_policy yes
idle_timelimit 60
Regards
11 years, 11 months
Problem with passwords and spanish characters
by Juan Carlos Camargo
Hi there,
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
time: 20120508080147
dn: uid=*******************
changetype: modify
replace: userPassword
userPassword: {SSHA}z8Ns6yOIY5N8JiZA7N53DWUCm6QCdBV083dXbA==
-
replace: modifiersName
modifiersName: cn=directory manager
-
replace: modifyTimestamp
modifyTimestamp: 20120508060323Z
-
replace: unhashed#user#password
unhashed#user#password: funci0nA
-
replace: entryusn
entryusn: 203032
However, with accented "n":
Windows user password: cañadelomo
time: 20120508080345
dn: uid=*****************
changetype: modify
replace: userPassword
userPassword: {SSHA}gD/DhJXnFiRsXl2KIooVPaSwG+1K9VjU8yxZ5Q==
-
replace: modifiersName
modifiersName: cn=directory manager
-
replace: modifyTimestamp
modifyTimestamp: 20120508060521Z
-
replace: unhashed#user#password
unhashed#user#password:: Y2HxYWRlbG9tbw==
-
replace: entryusn
entryusn: 203037
-
Why the difference when the spanish char is used, does it trigger something else in the sync process?
Regards!
--
J u an Carlos Camargo Carrillo
957-211157 , 650932877
11 years, 11 months
How to change certificate options using 389-console ?
by Addison Laurent
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
request?
Thanks,
Addison
11 years, 11 months
Problems with nsaccountlock attribute
by David Baird
Hi All,
Our instance of 389 (version 1.2.8.1 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=..."
nsroledn "cn=nsManagedDisabledRole,dc=..."
nsaccountlock "true"
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,
David.
11 years, 11 months
389 and Samba integration on Centos 6
by Alberto Suárez
Hello:
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?
Thank you!
Alberto Suárez.
11 years, 11 months
Master index (?!) feature request?
by Diego Woitasen
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:
dc=company,dc=com
ou=Headquarters,dc=company,dc=com
ou=Branch1,dc=company,dc=com
ou=Branch2,dc=company,dc=com
.
.
.
ou=Branch150,dc=company,dc=com
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
applications.
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?
Regards,
Diego
--
Diego Woitasen
11 years, 11 months
Re: [389-users] Solaris client, behavior differences?
by Carsten Grzemba
Hi,
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.
Regards,
Carsten
Am 03.05.12, schrieb Rafael Hinojosa <rhinojos(a)haverford.edu>:
> Hi,
>
> 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,
>
>
> --Raf
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
>
> 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
> rhinojos(a)haverford.edu
>
>
>
>
>
>
>
11 years, 11 months
