admin account expires, expire time refuses to update
by brandon
I am in a curious situation (and by curious I mean frustratingly
annoying). I have enabled strong password policies, including
expirations, across my tree (policy of the site). This has since
effected my 'admin' account in
uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot. I
discovered this was happening when I was no longer to login to the
IDM/admin console.
Unfortunately, the IDM gave a very obtuse error about not being able to
find an object. I discovered the real problem when I tried an
ldapsearch with the admin uid, and it then returned password expired.
This is a side issue, not part of the core problem.
I used ldapmodify with "cn=directory manager" and changed the password
hash. I can then login with IDM again. I then go (in IDM) to the admin
account and I change passwordexpirationtime to be 2040........Z (i.e.
some time in the distant future). I save this change; restart the
directory server and the account is expired again. If I go through the
same reset process and pull up the value, it has not committed the
passwordexpirationtime attribute, it is back to the original
setting(!?) To be even more confusing, if I do an ldapsearch on the
uid=admin account, it doesn't even show the passwordexpirationtime
attribute (and thus cannot be updated). I can only see/change this via IDM.
Can anybody explain this behavior? Is there a better way to exclude the
admin account from the password policies of the server? Can somebody
explain why I can see some attributes on uid=admin that cannot be seen
with ldapsearch?
Versions:
389-ds-console-1.2.0-5
389-admin-1.1.9-1
389-admin-console-1.1.4-2
389-console-1.1.3-5
389-ds-base-1.2.3-1
389-admin-console-doc-1.1.4-2
389-adminutil-1.1.8-4
389-ds-console-doc-1.2.0-5
389-dsgw-1.1.4-1
389-ds-1.1.3-5
RHEL 5.5
Any help/insight into this matter would be greatly appreciated.
-B.G.
13 years, 8 months
Multi-master replication + AD password synchronisation
by Johan Venter
Hi all,
I have the following situation:
- ds1 running 1.2.6.a3
- ds2 running 1.2.5.rc3 (yes, I will get around to bringing them up to
the same version soon)
- Multi-master replication agreements between both hosts
- A synchronisation agreement to a Windows 2008 AD on ds1
Although I am sure I have tested password changes on ds2 synchronising
to ds1 then to the AD I have recently put ds2 in production and found
that this is not working. To be more specific:
- Password changes on Windows work fine, as the Password Sync service
picks them up, pushes them to ds1, which then replicates the change
to ds2
- Password changes on ds1 work fine, are replicated to ds2 and are
synchronised to AD
- Password changes on ds2 replicate to ds1, and while there are
entries in the Replication log on ds1 for a modification to the AD,
the Windows password is not changed
Looking at the documentation at
http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Windows_Sync.html...
there are no caveats mentioned regarding multi-master replication and AD
password sync, in fact their provided architecture diagram (lower part
of the page) seems to indicate it should work in this situation.
Furthermore, the text backs this up with:
"The Directory Server relies on the Multi-Master Replication Plug-in to
synchronize user and group entries. The same changelog that is used for
multi-master replication is also used to send updates from the Directory
Server to Active Directory as LDAP operations."
and
"Directory Server passwords are synchronized along with other entry
attributes because plain-text passwords are retained in the Directory
Server changelog."
I did search the mailing list and turned up
http://lists.fedoraproject.org/pipermail/389-users/2010-January/010903.html
but I was hoping there is a different answer 6 months on. It seems to me
that if 389 is storing password changes in the clear in the changelog
that it should be able to push this cleartext password to AD when ds1
gets the replication?
Alternatively if this is absolutely just not a supported feature, would
it be possible to setup a second AD synchronisation agreement on ds2 to
the AD but specify ONLY to sync userPassword attribute changes?
(disabling the create/delete new user/group options in the sync
agreement of course to try and not cause loops or other problems).
The same documentation references above specifically says NOT to have
different DS's syncing to the same AD domain, but does that still apply
if it's a very limited attribute synchronisation?
Any help appreciated.
Cheers,
Johan
13 years, 8 months
ns-slapd segfault during db2ldif export
by Johan Venter
Hi all,
Last night I attempted to upgrade my 389 cluster to the latest 1.2.6rc6.
The node that I started with is currently running 1.2.6rc3 and after the
yum upgrade (running on CentOS, so from epel-testing) I tried to follow
the instructions at
http://directory.fedoraproject.org/wiki/Subtree_Rename#warning:_upgrade_f....
The db2ldif export of NetscapeRoot was fine, but the export of userRoot
resulted in either 1 of 2 outcomes:
1. ns-slapd segfaulted
2. ns-slapd sat there doing nothing, using no CPU time at all
I tried multiple times with reboots in between and found that (1) only
happens the first time, then any attempt to rerun the same db2ldif
command results in (2).
I know this is not exactly a useful bug report, but I was hoping you
could point me at what I need to do to report properly - can I just run
gdb on the ns-slapd process and post the results or are there no debug
symbols in the binary from the testing packages?
Do I need to setup a VM, compile a debug build from source and see if I
can replicate?
Cheers,
Johan
13 years, 8 months
Missing encryption information
by Terry Soucy
Hi All,
We have two instances of 389 server running as slaves to a single
master. The master and one of the slaves have no troubles with SSL.
The other slave does not allow me to choose the cipher family under the
encryption tab in configuration. Also, when I click on "Manage
Certificates", nothing pops up. The server is responding to queries on
636 with no problems, and I was able to import the new server cert
without error using pk12util, but I can't change the server cert to use
in the console.
Any ideas?
--
Terry Soucy, Systems Analyst Integrated Technology Services
University of New Brunswick, Fredericton Campus http://www.unbf.ca/its
Voice: 506.447.3018 Fax: 506.453.3590 E-mail: tsoucy(a)unb.ca
** ITS is a scent-reduced workplace - www.unbf.ca/its/policies **
13 years, 8 months
389-console on OSX?
by Brian_Kosick@McAfee.com
Hi All,
Just curious if anyone has gotten the UI/console working on OSX? I did a quick look though the howto's but didn't see anything and did a google search and didn't come up with much...
Since it's Java based, I was thinking that, with a little work, I could bastardize the Windows howto and get it running on OSX. Anyone try this before?
Brian
13 years, 8 months
replica/rdn problems with 1.2.6 rc6
by Jonathan Boulle
When trying to enable consumer replication on a database/root suffix, we get an "operations error" (in the GUI or command line with ldapmodify) and the following in the log:
[05/Aug/2010:17:35:20 +0100] entryrdn-index - _entryrdn_insert_key: Suffix "dc=example" not found: DB_NOTFOUND: No matching key/data pair found(-30989)
[05/Aug/2010:17:35:20 +0100] - add: attempt to index 1 failed
[05/Aug/2010:17:35:20 +0100] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (dc=example); LDAP error - 1
However, the exact same procedure works fine on 1.2.5 (haven't tested with earlier RC versions of 1.2.6)
When trying to troubleshoot - if I manually add the following to the directory:
dn: dc=betfair
dc: betfair
objectClass: top
objectClass: domain
I no longer get the above error, and the "Enable Replica" step succeeds, but I see this in the log:
[05/Aug/2010:17:45:14 +0100] NSMMReplicationPlugin - replica_add_by_dn: replica with dn (dc=example) already in the hash
[05/Aug/2010:17:45:14 +0100] NSMMReplicationPlugin - replica_add_by_dn: replica with dn (dc=example) already in the hash
Haven't tested past this point - although this was definitely not necessary on e.g. 1.2.5. I suspect it's related to the RDN shift mentioned in the changelogs, but I've reproduced the same issue with
a) upgrades from previous versions of the packages (e.g. 1.2.5)
b) clean installs of the above packages on a completely fresh CentOS 5.5 build
Package versions:
389-ds-1.2.1-1.el5
389-admin-1.1.11-0.6.rc2.el5
389-ds-base-1.2.6-0.9.rc6.el5
Bugzilla time?
Cheers
________________________________________________________________________
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.
________________________________________________________________________
13 years, 8 months
389 v. 1.2.6 (bug) boolean value are case sensitive (eg."true" doesn't work)
by Roberto Polli
Hi all,
Since 1.2.6 I found this bug.
* lowercase boolean values are refused.
ex. this won't work anymore
syncmlEnabled: true
I must use:
syncmlEnabled: TRUE
quite strange behavior:
Let me know + Peace,
R.
--
Roberto Polli
Babel S.r.l. - http://www.babel.it
Tel. +39.06.91801075 - fax +39.06.91612446
Tel. cel +39.340.6522736
P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma)
"Il seguente messaggio contiene informazioni riservate. Qualora questo
messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene
notizia a mezzo e-mail. Vi sollecitiamo altresì a distruggere il messaggio
erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto
della legge in materia di protezione dei dati personali."
13 years, 8 months
Some "admin" questions
by Gerrard Geldenhuis
Hi
Not important but just curious about why there is http://port389.org/ and http://directory.fedoraproject.org/ since port389 gets redirected anyway.
And also is there any difference between RHDS (Redhat Directory Server) and 389? Is the relationship similar to Satellite and Spacewalk or is it purely a naming thing?
Best Regards
________________________________________________________________________
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.
________________________________________________________________________
13 years, 8 months
Announcing 389 Directory Server 1.2.6 Release Candidate 6
by Rich Megginson
The 389 team is pleased to announce the availability of Release
Candidate 6 of version 1.2.6. This release has several bug fixes.
Note: RC4 and RC5 were never released.
***We need your help! Please help us test this software.*** It is a
release candidate, so it may have a few glitches, but it has been tested
for regressions and for new feature bugs. The Fedora system
strongly encourages packages to be in Testing until verified and pushed
to Stable. If we don't get any feedback while the packages are in
Testing, the packages will remain in limbo, or get pushed to Stable.
The more testing we get, the faster we can release these packages to
Stable. See the Release Notes for information about how to provide
testing feedback (or just send an email to
389-users(a)lists.fedoraproject.org).
The packages that need testing are:
* 389-ds-base-1.2.6.rc6 - 389-ds-base
* 389-admin-1.1.11.rc2 - 389-admin
More information
* Release Notes - http://port389.org/wiki/Release_Notes
* Install_Guide - http://port389.org/wiki/Install_Guide
* Download - http://port389.org/wiki/Download
=== Bugs Fixed ===
This release contains several bug fixes. The complete list of bugs
fixed is found at the link below. Note that bugs marked as MODIFIED
have been fixed but are still in testing.
* Tracking bug for 1.2.6 release -
https://bugzilla.redhat.com/showdependencytree.cgi?id=543590&hide_resolved=0
** Bug 617013 - repl-monitor.pl use cpu upto 90%
** Bug 616618 - 389 v1.2.5 accepts 2 identical entries with different DN
format
** Bug 547503 - replication broken again, with 389 MMR replication and
TCP errors
** Bug 613833 - Allow dirsrv_t to bind to rpc ports
** Bug 612242 - membership change on DS does not show on AD
** Bug 617629 - Missing aliases in new schema files
** Bug 619595 - Upgrading sub suffix under non-normalized suffix disappears
** Bug 616608 - SIGBUS in RDN index reads on platforms with strict
alignments
** Bug 617862 - Replication: Unable to delete tombstone errors
** Bug 594745 - Get rid of dirsrv_lib_t label
13 years, 8 months
Missing jar file
by Gerrard Geldenhuis
Hi
I have just installed the latest RC6 release but when trying to run the Directory Server console I get
Failed to install a local copy of 389-ds-1.2.3.jar ....
There is no symlink or file with that name the version present is 389-ds-1.2.0.jar.
Should it really be pointing to 389-ds-1.2.0.jar or is 1.2.3 missing from the packaging?
I did a yum install 389-ds from epel and then a
yum upgrade --enablerepo=epel-testing 389-ds-base 389-admin
OS is Centos 5.5 fully updated.
Regards
________________________________________________________________________
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.
________________________________________________________________________
13 years, 8 months