389-users August 2012

389-users@lists.fedoraproject.org

36 participants
38 discussions

Problem browsing LDAP with Outlook
by Chris Bryant 26 Aug '20

26 Aug '20

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 2

audit log doesn't log adding a entry
by Picture Book 01 Oct '12

01 Oct '12

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

2 3

Announcing 389 Directory Server version 1.2.11.12 Testing
by Rich Megginson 03 Sep '12

03 Sep '12

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

2 2

SSL connection based on cert
by Alberto Viana 31 Aug '12

31 Aug '12

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.

2 1

Protection of entries on downstream master or hub
by Lucas Sweany 30 Aug '12

30 Aug '12

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

2 3

GUI errors when viewing replication agreements
by Wes Hardin 30 Aug '12

30 Aug '12

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

2 10

389-ds-base-1.2.10.14-1.el5 broke my server
by Orion Poplawski 30 Aug '12

30 Aug '12

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

2 2

Skipping entries on consumer initialize
by Wes Hardin 29 Aug '12

29 Aug '12

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

2 2

Directory Express Gateway problems with bind
by Anders Nielsen 29 Aug '12

29 Aug '12

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

2 1

PasswordExpiringControl, PasswordExpiredControl and DraftBeheraLDAPPasswordPolicy10RequestControl
by Juan Asensio Sánchez 28 Aug '12

28 Aug '12

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.

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users August 2012