Install 389 1.3.x on CentOS 6.3
by Moisés Barba Pérez
Hello,
I would like to upgrade our LDAP to the last stable versión in CentOS 6.3
but I have seen in the epel-389 repository that the last version is
1.2.10.26. Asking at IRC channel somebody said to me there is not support
of 1.3.x on el6. I undestand this is because the package 389-ds-base is now
part of RHEL6 but, why provide the 1.2.10.26 version in the epel-389 when
the last version in the el6 repo is 1.2.10.2 and don't provide 1.3.x? I
know I can get the srpm and rebuild the package but people who decides what
to install here want a stable version in a estable rpm, tested and aproved.
Do we have any chance to obtain a rpm tested in rhel/centOS for 1.3.x or
the only option is to use the last version in epel-389 repo?
Regards.
Moses.
11 years
passwordRetryCount not incrementing past 1
by Eric Gingras
Hi,
I have an issue with account lockout.
Setup:
2-node in MMR config
389-Directory/1.2.10.26 B2013.023.2027 (from fedorapeople repo)
RHEL 6.4 x86_64
What I did (as per docs), doing this as a subtree or local policy:
dn: cn=config
changetype: modify
replace: passwordIsGlobalPolicy
passwordIsGlobalPolicy: on
dn:
cn=cn\=nsPwPolicyEntry\,ou\=People\,dc\=<REMOVED>\,dc\=com,cn=nsPwPolicyContainer,ou=People,dc=<REMOVED>,dc=com
changetype: modify
replace: passwordExp
passwordExp: on
-
replace: passwordMaxAge
passwordMaxAge: 7862400
-
replace: passwordHistory
passwordHistory: on
-
replace: passwordInHistory
passwordInHistory: 3
-
replace: passwordCheckSyntax
passwordCheckSyntax: on
-
replace: passwordMinDigits
passwordMinDigits: 1
-
replace: passwordMinSpecials
passwordMinSpecials: 1
-
replace: passwordMinLowers
passwordMinLowers: 1
-
replace: passwordMinUppers
passwordMinUppers: 1
-
replace: passwordMinLength
passwordMinLength: 8
-
replace: passwordStorageScheme
passwordStorageScheme: SSHA512
-
replace: passwordLockout
passwordLockout: on
-
add: passwordMaxFailure
passwordMaxFailure: 3
-
add: passwordUnlock
passwordUnlock: off
I also need to track loginTime (no time-based lockout), again as per
doc:
dn: cn=Account Policy Plugin,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginEnabled
nsslapd-pluginEnabled: on
dn: cn=Account Policy Plugin,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginarg0
nsslapd-pluginarg0: cn=config,cn=Account Policy
Plugin,cn=plugins,cn=config
dn: cn=config,cn=Account Policy Plugin,cn=plugins,cn=config
changetype: modify
replace: alwaysrecordlogin
alwaysrecordlogin: yes
-
add: stateattrname
stateattrname: lastLoginTime
-
add: altstateattrname
altstateattrname: createTimestamp
-
add: specattrname
specattrname: acctPolicySubentry
-
add: limitattrname
limitattrname: accountInactivityLimit
Restarted:
service dirsrv restart both nodes
What I get (after purposely trying to bind with wrong pwd many times):
No lockout, passwordRetryCount stays at 1
dn: uid=<REMOVED>,ou=People,dc=<REMOVED>,dc=com
passwordRetryCount: 1
retryCountResetTime: 20130410130146Z
lastLoginTime: 20130409193943Z
passwordExpirationTime: 20130709182434Z
userPassword:: <REMOVED>
mail: <REMOVED>
sn: <REMOVED>
preferredLanguage: en
cn: <REMOVED>
uid: <REMOVED>
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
givenName: <REMOVED>
I'm freshly out of ideas, thanks for helping.
Eric
11 years
StartTLS error
by alexandre
Hi,
I'm having problem with my multi-master replication.
I have on 389DS server in multi-master replication with a Windows DC
(everything work fine).
I try to put another 389DS in multi-master replication over startTLS (just
to have redundancy).
When I do the consumer initialization i've got this error:
The consumer initializatiion has unsuccessfully completed. The error
received by the replica is: -11 - System error.
When I go to the /var/log/dirsrv/slapd-389ds/errors:
slapi_ldap_bind - Error: could not send startTLS request: error -11
(Connect error)
Just an indication, I went in "manage certificate" on both 389DS server and
I put the server cert and the CA cert, do I miss something ?
Thanks,
Alex
11 years
sync agreement problem
by Vesa Alho
Hi,
I'm having a problem with creating a sync agreement between two
identical 389ds installations (1.2.11.5). I'm a bit puzzled since I've
done this successfully before many times.
* Replication IDs are unique
* Both are Multiple Masters
* Both have same dc=domain,dc=com
* Schemas are identical
==> one difference from earlier setups is that SERVER1 and SERVER2 are
in different domains, but 389s base suffix is still identical
Any ideas?
SERVER1 (sync agreement here)
[10/Apr/2013:13:21:25 +0300] NSMMReplicationPlugin - agmt="cn=sync"
(ldap1:636): State: start -> ready_to_acquire_replica
[10/Apr/2013:13:21:25 +0300] NSMMReplicationPlugin - agmt="cn=sync"
(ldap1:636): Trying secure slapi_ldap_init_ext
[10/Apr/2013:13:21:25 +0300] NSMMReplicationPlugin - agmt="cn=sync"
(ldap1:636): binddn = cn=Directory Manager
[10/Apr/2013:13:21:25 +0300] NSMMReplicationPlugin - agmt="cn=sync"
(ldap1:636): No linger to cancel on the connection
[10/Apr/2013:13:21:26 +0300] NSMMReplicationPlugin - agmt="cn=sync"
(ldap1:636): Unable to acquire replica: there is no replicated area
"dc=domain,dc=com" on the consumer server. Replication is aborting.
[10/Apr/2013:13:21:26 +0300] NSMMReplicationPlugin - agmt="cn=sync"
(ldap1:636): Beginning linger on the connection
[10/Apr/2013:13:21:26 +0300] NSMMReplicationPlugin - agmt="cn=sync"
(ldap1:636): State: ready_to_acquire_replica -> stop_fatal_error
[10/Apr/2013:13:21:26 +0300] NSMMReplicationPlugin - agmt="cn=sync"
(ldap1:636): Incremental update failed and requires administrator action
[10/Apr/2013:13:21:26 +0300] NSMMReplicationPlugin - agmt="cn=sync"
(ldap1:636): State: stop_fatal_error -> stop_fatal_error
SERVER 2
[10/Apr/2013:10:21:27 +0000] NSMMReplicationPlugin - conn=90 op=3
Acquired consumer connection extension
[10/Apr/2013:10:21:27 +0000] NSMMReplicationPlugin - conn=90 op=3
repl="dc=domain,dc=com": Begin incremental protocol
[10/Apr/2013:10:21:27 +0000] NSMMReplicationPlugin - conn=90 op=3
replica="unknown": Unable to acquire replica: error: no such replica
[10/Apr/2013:10:21:27 +0000] NSMMReplicationPlugin - conn=90 op=3
repl="dc=domain,dc=com": StartNSDS90ReplicationRequest: response=6 rc=0
[10/Apr/2013:10:21:27 +0000] NSMMReplicationPlugin - conn=90 op=3
Relinquishing consumer connection extension
-Mr. Vesa Alho
11 years
Integration of foreign domains
by Kevin Thorpe
Hi, I'm stuck with foreign domain integration and not sure how to proceed.
We have our own LDAP domain (dc=<domain>,dc=com) and within it two
sections, ou=staff (us) and ou=People (clients). This works just fine and a
search on dc=domain,dc=com covers both sets of users as website logins.
Now I want to add in users from a client's LDAP server. I can add a new
domain (o=<client>,c=com) and attach it to their LDAP server and that
looks like it's working just fine, but how do I attach my website to this
setup?
I don't see how I can look up users across multiple domains.
What I think I need is to pull in a single branch of their domain into our
domain.
That would look something like:
dc=<domain>,dc=com
ou=Staff
ou=People
ou=<Client> <==== ou=Utilisateurs,o=<client>,c=com
but of course I'd still need to relay any bind requests in the ou=Client
section
to the client's LDAP server.
Can anyone point me in the right direction please?
NOTE: values in angle brackets are simply anonymised.
11 years
console vs nsslapd-allow-anonymous-access
by Alberto Viana
Hi all,
Why when i set nsslapd-allow-anonymous-access to off, the ds console stop
to work? (I cant login anymore at console)
The error message is:
Cannot connect to the directory server:
netscape.ldap.LDAPException: error result(32)
thanks
Alberto Viana
11 years
Extended control or extop
by Ivanov Andrey (M.)
Hi,
I remember reading somewhere on 389 DS site or in dev commits or in trac a
request or a realisation of the an extended control/operation that returns
the LDAP entries referenced by some attribute.
Something like you make a search of a group with this extended control, the
search takes all the 'uniqueMembers' and returns all the LDAP entries
referenced by the values of 'uniqueMember'. Could you point to me the right
control name or OID? Is it already present in some version of 389DS?
Thanks!
11 years
replication filtering
by Russell Beall
Hi,
I have a quick question about fractional replication.
There is an attribute which allows for excluding attributes as needed.
nsds5replicatedattributelist: (objectclass=*) $ EXCLUDE attribute1, attribute2, …
The documentation appears to require that the filter always be set to (objectclass=*). Was the intention of that filter to someday allow entries to possibly be filtered?
Is it possible to exclude entries based on an attribute? For example, is there any way to exclude entire entries which have a custom status attribute with a value of "inactive"?
Thanks,
Russ.
11 years
replace: userPassword and unhashed#user#password
by Thang Nguyen
I'm running 389-ds-base.x86_64 1.2.11.15-12.el6_4 on RHEL 6.3.
When I do a "replace: userPassword" with an empty set of values (which
will cause the attribute to be removed), 389ds only remove the
userPassword attribute and doesn't remove the unhashed#user#password
attribute.
I enabled more logging in the error log and this is what I see for
"delete: userPassword" and "replace: userPassword" with an empty set of
values.
delete: userPassword:
[02/Apr/2013:17:35:16 -1000] - => entry_apply_mods_wsi
[02/Apr/2013:17:35:16 -1000] - delete: userPassword
[02/Apr/2013:17:35:16 -1000] - removing entire attribute userPassword
[02/Apr/2013:17:35:16 -1000] - -
[02/Apr/2013:17:35:16 -1000] - modifiersname: cn=directory manager
[02/Apr/2013:17:35:16 -1000] - replace: modifiersname
[02/Apr/2013:17:35:16 -1000] - -
[02/Apr/2013:17:35:16 -1000] - modifytimestamp: 20130403033515Z
[02/Apr/2013:17:35:16 -1000] - replace: modifytimestamp
[02/Apr/2013:17:35:16 -1000] - -
[02/Apr/2013:17:35:16 -1000] - delete: unhashed#user#password
[02/Apr/2013:17:35:16 -1000] - removing entire attribute
unhashed#user#password
[02/Apr/2013:17:35:16 -1000] - -
replace: userPassword with an empty set of values:
replace: userpassword
[02/Apr/2013:17:37:03 -1000] - => entry_apply_mods_wsi
[02/Apr/2013:17:37:03 -1000] - replace: userPassword
[02/Apr/2013:17:37:03 -1000] - -
[02/Apr/2013:17:37:03 -1000] - modifiersname: cn=directory manager
[02/Apr/2013:17:37:03 -1000] - replace: modifiersname
[02/Apr/2013:17:37:03 -1000] - -
[02/Apr/2013:17:37:03 -1000] - modifytimestamp: 20130403033703Z
[02/Apr/2013:17:37:03 -1000] - replace: modifytimestamp
[02/Apr/2013:17:37:03 -1000] - -
Anyone know if this is how 389ds supposed to work or is it a bug?
Thank you.
Regards,
--thang
11 years
adding attribute
by Vesa Alho
Hi,
I have a need to create new attribute where to store password in
different hash than used in 389ds. This is because 3rd party does not
support our SSHA-512. I'm planning to add an attribute, but a couple of
basic questions:
1. I have understood it's usually good to avoid creating custom
attributes? So is it a good practise to use some unused attribute for
this kind of purpose, for example I found "usercertificate".
2. What is the best way to add new attribute to already existing
entries, create a script with ldapmodify commands?
-Mr. Vesa Alho
11 years
