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.
2 years, 9 months
audit log doesn't log adding a entry
by Picture Book
Hi, version: 1.2.10.2build: 2012.180.1655 After audit log is enable, I do not see any record in the audit log after a entry is added. Thanks. $grep changetype log/audit changetype: modify
changetype: modify
changetype: modify
changetype: modify
changetype: modify
changetype: modify
changetype: delete
changetype: modify
changetype: modrdn
changetype: modify
10 years, 8 months
Announcing 389 Directory Server version 1.2.11.12 Testing
by Rich Megginson
The 389 Project team is pleased to announce the release of
389-ds-base-1.2.11.12 for Testing. This release includes support for
POSIX attributes in Windows Sync, several bug fixes, and cleanup of
various issues found by valgrind and Coverity. The 389 team would like
to thank Carsten Grzemba for contributing his POSIX Windows Sync plugin
to the project.
The new packages and versions are:
389-ds-base 1.2.11.12
NOTE: 1.2.11 will not be available for Fedora 16 or earlier, nor for EL6
or earlier - 1.2.11 will only be available for Fedora 17 and later. We
are trying to stabilize current, stable releases - upgrades to 1.2.11
will disrupt stability.
Installation
yum install 389-ds --enablerepo=updates-testing
# or for EPEL
yum install 389-ds --enablerepo=epel-testing
setup-ds-admin.pl
Upgrade
yum upgrade 389-ds-base --enablerepo=updates-testing
# or for EPEL
yum upgrade 389-ds-base --enablerepo=epel-testing
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 Bugs
If you find a bug, or would like to see a new feature, use the 389 Trac
- 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
10 years, 9 months
SSL connection based on cert
by Alberto Viana
Hi,
I´m tyring to test a SSL connection from one server(linux) to 389DS using
openssl:
openssl s_client -connect MY_389_SERVER:636 -cert local_server.crt -key
local_server.key -CAfile CA-AD.crt
And I got this error on my 389DS log:
[31/Aug/2012:14:04:57 -0300] conn=146531 Netscape Portable Runtime error
-8101 (Certificate type not approved for application.); unauthenticated
client E=email(a)email.com,CN=server.my.domain,OU=GTI,O=COMPANY,L=Rio de
Janeiro,ST=Rio de Janeiro,C=BR; issuer CN=MY AD
The both certificates (my 389DS and local server(linux) were generated by
my AD Server. Just to notify that I already import my CA certificate into
389 database (I have AD password replication working using the AD CA).
What am I missing?
Thanks a lot.
10 years, 9 months
Protection of entries on downstream master or hub
by Lucas Sweany
I would like to protect certain entries in a hub 389-ds host from getting
obliterated during a full re-initialization of an agreement. Strange yes,
but hear me out.
To keep duty separation intact, we've set up a scenario where we've got one
group managing Active Directory and one 389 server (389-A), and another
group maintaining a 389 hub (389-B). 389-A syncs from AD one-way, and then
replicates to 389-B. However, things like sudoers and posix attributes
(uids and gids) are managed on 389-B for convenience. Unfortunately, the
sudoers OU and uids/gids get destroyed if 389-A performs a
re-initialization of the agreement--by design I'm sure.
Is there a way to protect the sudoers OU and specific attributes of users
on 389-B in this scenario? It looks like my options are to mess with
fractional replication, ACIs, to meticulously back-up these attributes and
restore them in the rare event we need to re-initialize, or to give up the
convenience and have those attributes managed on 389-A.
Is there no easy answer to this without giving up the ability to manage
some things locally on 389-B?
Thanks,
-Lucas
10 years, 9 months
GUI errors when viewing replication agreements
by Wes Hardin
When viewing replication agreements in the 389-console (under the Configuration
tab, Replication, userRoot), the first time I select each replication agreement,
I am greeted by an error window titled "Insufficient Permissions" stating "The
user cn=root does not have the permission to perform this operation."
cn=root is my directory manager account. I am not trying to make any changes, I
get this error simply by selecting the agreement so I can view it and check the
status. I can click OK to acknowledge the error and then I am prompted to login
again. I can hit cancel and continue navigating, but if I attempt to make any
change in this area, the "Save" button does not activate to let me do so. I can
use the Directory tab and navigate down through cn=config tree and change the
agreement entries via the normal property editor window. I can also delete the
agreement from the Configuration tab.
I'm using 389-console 1.1.7-0ubuntu1 on Kubuntu 12.04, but I have colleagues who
run the 389-console from the server (389-console-1.1.7-3.el5.noarch) and see the
same error.
These are the packages on the server, which is CentOS 5.7:
# rpm -qa 389-\*
389-admin-1.1.29-1.el5.x86_64
389-console-1.1.7-3.el5.noarch
389-ds-base-libs-1.2.10.4-5.el5.x86_64
389-admin-console-1.1.8-1.el5.noarch
389-ds-base-devel-1.2.10.4-5.el5.x86_64
389-ds-base-1.2.10.4-5.el5.x86_64
389-ds-console-1.2.6-1.el5.noarch
389-ds-console-doc-1.2.6-1.el5.noarch
389-adminutil-1.1.15-1.el5.x86_64
389-admin-console-doc-1.1.8-1.el5.noarch
389-adminutil-devel-1.1.15-1.el5.x86_64
While troubleshooting replication a while back, I lost all my replication
agreements and recreated them all from the CLI using some instructions I found
for RHDS. I don't recall if this error occurred before that or not. If I
delete and re-create the agreement through the GUI, I do not get this error when
selecting that same agreement, even after restarting the GUI.
--
/* Wes Hardin */
UNIX/Linux Systems Administrator, IT Engineering Support
Office: +1 (972) 371-6909 | Mobile: +1 (972) 342-5679
Maxim Integrated Products | Innovation Delivered® | www.maxim-ic.com
10 years, 9 months
389-ds-base-1.2.10.14-1.el5 broke my server
by Orion Poplawski
So, 389-ds-base-1.2.10.14-1.el5 came in today and broke my server, ldap
searches returned the base of the tree but nothing else. I needed to
downgrade to 1.2.9.9 and restore my /etc/dirsrv/slapd-cora directory from backup.
I ran it in debug mode for a bit before reverting. Those logs are here:
http://www.cora.nwra.com/~orion/dirsrv.debug
I also had to remove 50ns-mail.ldif that re-appeared again to avoid conflicts
with my custom 60sendmail.ldif, but I expect that I guess.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
10 years, 9 months
Skipping entries on consumer initialize
by Wes Hardin
When initializing a consumer, I get many messages similar to this:
import userRoot: WARNING: Skipping entry "uid=davsmith,ou=win,ou=People,dc=maxim-ic,dc=com" which has no parent, ending at line 0 of file "(bulk import)"
It is believed that all affected entries had been moved within the directory using a moddn change in the past few months (using Apache Directory Studio). I was just able to "break" another account by doing this same action and reinitializing my consumer.
Move entry:
#!RESULT OK
#!CONNECTION ldap://dalldap001.maxim-ic.com:389
#!DATE 2012-08-28T12:01:56.870
dn: uid=test4phy,ou=People,dc=maxim-ic,dc=com
changetype: moddn
newrdn: uid=test4phy
deleteoldrdn: 1
newsuperior: ou=bri,ou=People,dc=maxim-ic,dc=com
Re-init:
[28/Aug/2012:18:05:36 +0100] - import userRoot: WARNING: Skipping entry "uid=test4phy,ou=bri,ou=People,dc=maxim-ic,dc=com" which has no parent, ending at line 0 of file "(bulk import)"
Moving the account back to it's original location and reinitializing the consumer again "fixes" it. The entry does not appear on the consumer until I reinitialize.
If I remember correctly, in the past, I was not able to do a moddn (A few months back I moved from 1.2.5 to 1.2.10). Is moddn considered safe? If I copy and paste the entry to the new location and delete the old entry manually, this works just fine.
I also get one instance of this message on each initialize:
import userRoot: WARNING: Skipping entry "nsuniqueid=2dca7101-594d11df-8622cf4b-918cdd63,uid=fxdtest,ou=chm,ou=People,dc=maxim-ic,dc=com" which has no parent, ending at line 0 of file "(bulk import)"
This one really confuses me since nsuniqueid isn't an entry, it's an attribute. Even stranger is that the value of nsuniqueid in the error message does not match the current value:
dn: uid=fxdtest,ou=chm,ou=People,dc=maxim-ic,dc=com
createTimestamp: 20120827200045Z
creatorsName: uid=whardin,ou=dal,ou=people,dc=maxim-ic,dc=com
entrydn: uid=fxdtest,ou=chm,ou=people,dc=maxim-ic,dc=com
entryid: 13315
hasSubordinates: FALSE
modifiersName: uid=whardin,ou=dal,ou=people,dc=maxim-ic,dc=com
modifyTimestamp: 20120827200214Z
nsUniqueId: d2729e81-f08111e1-8cbef100-4e39c57a
numSubordinates: 0
parentid: 5877
passwordGraceUserTime: 0
subschemaSubentry: cn=schema
I have deleted and recreated this account in the past few days. The value of nsuniqueid in the error message appears to be the value of the now deleted entry.
These are the packages on the server, which is CentOS 5.7:
389-admin-1.1.29-1.el5.x86_64
389-admin-console-1.1.8-1.el5.noarch
389-adminutil-1.1.15-1.el5.x86_64
389-console-1.1.7-3.el5.noarch
389-ds-base-1.2.10.4-5.el5.x86_64
389-ds-base-libs-1.2.10.4-5.el5.x86_64
389-ds-console-1.2.6-1.el5.noarch
The consumer is also CentOS 5.7, but slightly newer 389-ds:
389-admin-1.1.29-1.el5.x86_64
389-admin-console-1.1.8-1.el5.noarch
389-adminutil-1.1.15-1.el5.x86_64
389-console-1.1.7-3.el5.noarch
389-ds-base-1.2.10.13-1.el5.x86_64
389-ds-base-libs-1.2.10.13-1.el5.x86_64
389-ds-console-1.2.6-1.el5.noarch
--
/* Wes Hardin */
UNIX/Linux Systems Administrator, IT Engineering Support
Maxim Integrated Products | Innovation Delivered® | www.maxim-ic.com
10 years, 9 months
Directory Express Gateway problems with bind
by Anders Nielsen
Hi,
I have changed the default ACI from ldap://anyone to ldap://all to require
authentication prior to search - this works ok from normal clients. For
the DSGW I edited the orgchart.conf file to include a bind dn and password
- these options seem only to be available to the org. chart application.
The org. chart works correctly, but when the phonebook application
attempts to search it does not (obviously) authenticate and gets nothing
(same goes for the other parts of the DSGW). I have attempted to use a
binddnfile in dsgw.conf, as described on the wiki, but get syntax errors
on the file. The wiki says only to add the DN and password but nothing on
formatting syntax.
Any ideas on how to format the contents of the binddnfile?
Thanks in advance.
Best regards
Anders Nielsen
10 years, 9 months
PasswordExpiringControl, PasswordExpiredControl and DraftBeheraLDAPPasswordPolicy10RequestControl
by Juan Asensio Sánchez
Hi
We are testing the password policy in the 389DS. Using CentOS 5.5
i386, 389-ds-base 1.2.5. I have enabled the global password policy,
and set 180 days for password expiration, 14 days for warnings, and 3
grace logins. If I do a login before the 14 days befor the password
expiration, the bind is correct. If the bind is done during the 14
days before the password expiration, a PasswordExpiringControl is sent
to the client (verified with a groovy script using the UnboundID LDAP
SDK). After the password expires, the login is successful (without
being sent any control) for 3 times (all correct), and then the bind
is incorrect (error 49, invalid credentials), and also a
PasswordExpiredControl is sent.
My question, shouldn't the server send the PasswordExpiredControl also
during the 3 grace login?
If not, I have tested the
DraftBeheraLDAPPasswordPolicy10RequestControl
(http://tools.ietf.org/html/draft-behera-ldap-password-policy-10), and
it looks that is implemented (at least, in part) in 389DS. What is the
status of the implementation of this drafts (yes, I know it is a
draft, but is very useful). I am interested mostly in notifying the
user about its expiring/expired password, or remaining login attempts.
This looks to work in 389DS. Is there any more useful function I can
use?
Regards and thanks in advance.
10 years, 9 months
