Problem browsing LDAP with Outlook
by Chris Bryant
When configuring Microsoft Outlook (not Outlook Express) to access an LDAP directory, there is an option to 'Enable Browsing (requires server support)'. If this option is chosen and the directory server supports it, then you should be able to open the LDAP address book and page up and down through the results. I have been unable to get this working properly with 389 DS.
When I try to browse from Outlook against the 389 DS directory, I am able to see the first page of results perfectly. However, if I move to the next page, only the first object returned will have any attributes included, and all of the rest of the objects in the page will have no attributes. I have a test perl script that duplicates this functionality as well.
I can get this to work properly with an older version of Netscape Directory Server, and I can get it working with OpenDS. Since 389 DS advertises support for the controls that are required for this to work, just like the other two servers, then I would expect it to work there also.
Has anyone out there gotten this to work with 389 DS? If so, can you share if there was anything special that you needed to do to get this to work? I'm trying to determine if this is a bug in the server, or if I'm just missing something in the configuration.
Thanks,
Chris
USA.NET
You Run Your Business. We'll Run Your Email.
This message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information of USA.NET, Inc. Any unauthorized review, use, copying, disclosure, or distribution is prohibited. If you are not the intended recipient, please immediately contact the sender by reply email and delete all copies of the original message.
3 years, 1 month
CoS plugin and country related fields
by Vlad
Hello,
I'm trying to configure classic CoS plug-in to fill automatically
"Country" ("c") and "Friendly Country" ("co") based on "countrycode"
attribute. While classic CoS works perfectly fine with some ather
attributes, I can't get it working with the country related fields I
mentioned above. I'd appreciate any help!
Thanks in advance,
Vladimir.
11 years, 2 months
Replication broken after each service restart
by Wes Hardin
To preface this, my issue began after upgrading from 1.2.5.x to 1.2.10.4 about a
month ago, but I did not immediate recognize the severity at that time.
Upon upgrading, it was discovered that replication had ceased to replicate. I
got a message saying the "suffix was not enabled". I assume(d) this meant
replication was not enabled for the suffix and that I needed to enable it. From
the 389-console, the "Enable Replica" box was checked and the Replica Role was
"Single Master." I couldn't see any reason for the sudden failure and the
continued resistance against my attempts to synchronize my consumers.
Eventually, I unchecked "Enable Replica" and (automatically) deleted all my
replication agreements. I re-enabled the replica and began recreating all my
agreements. Replication resumed normal operation.
It wasn't until today that I realized the problem still exists. I rebooted my
single master yesterday and today found that replication had stopped again. I
exported all my agreements to an LDIF then nuked and rebuilt all my replication
settings as I'd done after the upgrade. Replication resumed. Just to test my
theory, I then restarted the server again and once again broke replication.
Luckily I was prepared this time and was quickly able to recover.
Here are some messages showing the rejected attempt to replicate. The first is
an update, the second is an initialize. Both seem to indicate replication is
not enabled despite evidence to the contrary.
[28/Jun/2012:08:35:37 -0500] NSMMReplicationPlugin - Replication agreement for
agmt="cn=ausldap001" (ausldap001:389) could not be updated. For replication to
take place, please enable the suffix and restart the server
[28/Jun/2012:09:31:00 -0500] NSMMReplicationPlugin - Total update aborted:
Replication agreement for "agmt="cn=mfnldap002" (mfnldap002:389)" can not be
updated while the replica is disabled
[28/Jun/2012:09:31:00 -0500] NSMMReplicationPlugin - (If the suffix is disabled
you must enable it then restart the server for replication to take place).
I have noticed that I have a lot of entries whose DNs include escaped
characters, which I don't remember seeing before. That is, \3D instead of '='
or \2C instead of ','. For example:
dn: cn=replica,cn=dc\3Dmaxim-ic\2C dc\3Dcom,cn=mapping tree,cn=config
objectClass: nsDS5Replica
objectClass: top
nsDS5ReplicaRoot: dc=maxim-ic,dc=com
nsDS5ReplicaType: 3
nsDS5Flags: 1
nsDS5ReplicaId: 7777
nsds5ReplicaPurgeDelay: 604800
cn: replica
nsState:: YR4AAAAAAADogOxPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==
nsDS5ReplicaName: 240eb382-c13b11e1-bf5ef100-4e39c57a
nsds5ReplicaChangeCount: 0
nsds5replicareapactive: 0
But based on the following link, I guess that's to be expected.
http://directory.fedoraproject.org/wiki/Upgrade_to_New_DN_Format
There also seems to be some inconsistency in how my root is referenced.
Sometimes it has a space between the two domain components, sometimes it does
not. You can actually see that in the example above. The DN value has a space,
the nsDS5ReplicaRoot value has no space.
I'm rather inexperienced in the management of LDAP. My upgrade from 1.2.5 to
1.2.10 was just a simple "yum upgrade". I hadn't seen the link about about the
DN format or any other upgrade guide. I'm fully willing to allow that I failed
to take some required step at the time of the upgrade.
Many thanks in advance for any help you can provide.
--
/* Wes Hardin */
UNIX/Linux Systems Administrator, IT Engineering Support
Maxim Integrated Products | Innovation Delivered® | www.maxim-ic.com
11 years, 3 months
Schema changes from 389 1.2.5
by Moisés Barba Pérez
Hi,
I would like to upgrade 389 from 1.2.5 to the last version before the
changes in the schema. I mean, In some version of 389 the syntax of some
attributes had change and I can't upgrade to that version yet, but I don't
know which is that version to upgrade to the previous one. Could you help
me?
Regards,
Moses.
11 years, 3 months
Evaluating 1.2.11.6 on Fedora17: nsds5ReplicaEnabled
by Juan Carlos Camargo
Hi there,
One of the features of version 1.2.11.6 that caught my eye was the ability to enable/disable replication agreements. I've installed a copy on one of my lab machines, install went on flawlessly, but I seem to be unable to find where to apply the nsds5ReplicaEnabled attribute. I've tried adding it to the nsds5ReplicationAgreement object (same way as when I add the onewaysync attr) but I cant find it. Has it already been implemented? Not pushing, simply investigating :)
Regards!
--
J u an Carlos Camargo Carrillo
957-211157 , 650932877
11 years, 3 months
Announcing 389 Directory Server versions 1.2.10.11 and 1.2.11.6 Testing
by Rich Megginson
The 389 Project team is pleased to announce the release of
389-ds-base-1.2.10.11 and 1.2.11.6 for Testing. 1.2.10.11 and 1.2.11.6
contain a fix for a password security issue:
#378 unhashed#user#password field https://fedorahosted.org/389/ticket/378
NEW: Platform Support
Pre-built RPMs of 1.2.11 and later are only available on Fedora 17 and
later. 1.2.10 is still supported on Fedora 16 and earlier and will
continue to get important updates.
Reminder: Issue Tracking System
We have moved our ticket tracking system from the Red Hat Bugzilla
https://bugzilla.redhat.com/enter_bug.cgi?product=389 to our Fedora
Hosted Trac https://fedorahosted.org/389.
This link shows all of the issues fixed in the 1.2.10 branch -
https://fedorahosted.org/389/report/12
This link shows all of the issues fixed in the 1.2.11 branch -
https://fedorahosted.org/389/report/13
Installation
yum install --enablerepo=updates-testing 389-ds
# or for EPEL
yum install --enablerepo=epel-testing
[--enablerepo=epel-testing-389-ds-base] 389-ds
setup-ds-admin.pl
Upgrade
yum upgrade --enablerepo=updates-testing 389-ds-base
idm-console-framework 389-admin 389-ds-console 389-admin-console
389-dsgw 389-adminutil
# or for EPEL
yum upgrade --enablerepo=epel-testing
[--enablerepo=epel-testing-389-ds-base] 389-ds-base
idm-console-framework 389-admin 389-ds-console 389-admin-console
389-dsgw 389-adminutil
setup-ds-admin.pl -u
How to Give Feedback
The best way to provide feedback is via the Fedora Update system.
* Go to https://admin.fedoraproject.org/updates
* In the Search box in the upper right hand corner, type in the name of
the package
* In the list, find the version and release you are using (if you're not
sure, use rpm -qi <package name> on your system) and click on the release
* On the page for the update, scroll down to "Add a comment" and provide
your input
Or just send us an email to 389-users(a)lists.fedoraproject.org
Reporting Issues
https://fedorahosted.org/389
More Information
* Release Notes - http://port389.org/wiki/Release_Notes
* Install_Guide - http://port389.org/wiki/Install_Guide
* Download - http://port389.org/wiki/Download
11 years, 3 months
How To Enable Track when password was last modified passwordTrackUpdateTime
by Tom Jalbert
I need this feature but I'm unsure where/how to turn it on. Could someone
point me in the right direction?
Thanks,
-Tom
>From "New Features in 1.2.11 lists"
Track when password was last modified
passwordTrackUpdateTime - if this is set to "on", the server will keep
track of the last password update time
pwdUpdateTime - new operational attribute in entries holds the last
password update time if passwordTrackUpdateTime is enabled
11 years, 3 months
Problem after disabling anonymous binds
by Jeroen van Meeuwen
Hi there,
I'm curious as to whether anyone else has experienced this problem before;
Disabling anonymous binds causes the 389-console to be unable to locate the
entry corresponding to the user name used to login with (or so it seems).
In other words, disabling anonymous binds causes 389-console to be rendered
disfunctional ;-)
I'd like to learn if this is a known problem, and/or whether there is a known
workaround for the issue.
Thank you in advance,
Kind regards,
Jeroen van Meeuwen
--
Systems Architect, Kolab Systems AG
e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com
pgp: 9342 BF08
11 years, 3 months
Announcing 389 Directory Server versions 1.2.10.10 and 1.2.11.5 Testing
by Rich Megginson
The 389 Project team is pleased to announce the release of
389-ds-base-1.2.10.10 and 1.2.11.5 for Testing. 1.2.10.10 contains a
fix for a crashing issue:
#390 [abrt] 389-ds-base-1.2.10.6-1.fc16: slapi_attr_value_cmp: Process
/usr/sbin/ns-slapd was killed by signal 11 (SIGSEGV)
https://fedorahosted.org/389/ticket/390
1.2.11.5 is the first stable release of 1.2.11. 1.2.11 contains many,
many new features and bug fixes. Please see the Release Notes for more
details.
NEW: Platform Support
Pre-built RPMs of 1.2.11 and later are only available on Fedora 17 and
later. 1.2.10 is still supported on Fedora 16 and earlier and will
continue to get important updates.
Reminder: Issue Tracking System
We have moved our ticket tracking system from the Red Hat Bugzilla
https://bugzilla.redhat.com/enter_bug.cgi?product=389 to our Fedora
Hosted Trac https://fedorahosted.org/389.
This link shows all of the issues fixed in the 1.2.10 branch -
https://fedorahosted.org/389/report/12
This link shows all of the issues fixed in the 1.2.11 branch -
https://fedorahosted.org/389/report/13
Installation
yum install --enablerepo=updates-testing 389-ds
# or for EPEL
yum install --enablerepo=epel-testing
[--enablerepo=epel-testing-389-ds-base] 389-ds
setup-ds-admin.pl
Upgrade
yum upgrade --enablerepo=updates-testing 389-ds-base
idm-console-framework 389-admin 389-ds-console 389-admin-console
389-dsgw 389-adminutil
# or for EPEL
yum upgrade --enablerepo=epel-testing
[--enablerepo=epel-testing-389-ds-base] 389-ds-base
idm-console-framework 389-admin 389-ds-console 389-admin-console
389-dsgw 389-adminutil
setup-ds-admin.pl -u
How to Give Feedback
The best way to provide feedback is via the Fedora Update system.
* Go to https://admin.fedoraproject.org/updates
* In the Search box in the upper right hand corner, type in the name of
the package
* In the list, find the version and release you are using (if you're not
sure, use rpm -qi <package name> on your system) and click on the release
* On the page for the update, scroll down to "Add a comment" and provide
your input
Or just send us an email to 389-users(a)lists.fedoraproject.org
Reporting Issues
https://fedorahosted.org/389
More Information
* Release Notes - http://port389.org/wiki/Release_Notes
* Install_Guide - http://port389.org/wiki/Install_Guide
* Download - http://port389.org/wiki/Download
11 years, 3 months
Proxying authentication
by Alberto Suárez
Hello!
Can I use the Pass-Through Authentication pluging to forward my user's
credentials (login name and password) to a non 389ds LDAP server when
the user tries to bind to the directory server and use the response of
that back-end server to allow or deny the bind operation?
Thank you.
Alberto Suárez.
11 years, 3 months