389-users March 2012

389-users@lists.fedoraproject.org

45 participants
64 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

Re: [389-users] Repair replication
by Herb Burnswell 23 Apr '12

23 Apr '12

Thanks for the reply David. >> 1. How can I find out which system(s) is/are master, consumer, hub, etc? >>>>You should be able to determine the role of the Directory Server for each >>>>system by logging into the LDAP console under >>>>"Configuration->Replication". The role is either "Single Master", "Hub" or >>>>"Dedicated Consumer". I was able to determine that we have two "Multiple Master" systems. Let's call them 'A' and 'B'. System A has been the only system running for what appears to be several years (it is being backed up nightly). System B has been off for some time but is running now. >> 2. How do I confirm that the systems have the correct credentials for replication? (I am receiving: "Unable to acquire replica: Permission denied.") a. How can I change the bind dn "cn=replication,cn=config" credentials on each system to ensure replication will work? >>>>You can do that on the console as well. Just navigate down the directory >>>>tree and manually reset the password for the replication user account. >>>>There's a possibility that your replication user account's password expired. I can navigate to the screen to reset the password for the replication user account. I have not reset the passwords yet as I am reading documentation to confirm that system B will simply update it's data to system A's upon resuming replication. >> 3. I assume that upon repairing replication (apparently it has not been working for several years) the systems will all replicate to the most recent information. Correct? >>>>I think that's the tricky part. Make sure you backup your directory on all >>>>the LDAP first so you have something to roll back. I *believe* the last >>>>step when setting up replication is initializing the directory and that >>>>will wipe out directory on the other LDAP. Someone on the list might be >>>>able to provide a better on this but I am just giving you a heads up that >>>>this can be a complicated process. Given the fact that system B has not been running for some time, ideally it would simply replicate to the current data on system A. After replication is reestablished the systems are set up to "Always keep directories in sync". If anyone can confirm the behavior that will occur upon replication on these two systems it would be greatly appreciated. Thanks in advance, Herb ------------------------------ > > Message: 2 > Date: Thu, 22 Mar 2012 10:40:34 -0400 > From: Chun Tat David Chu <beyonddc.storage(a)gmail.com> > To: "General discussion list for the 389 Directory server project." > <389-users(a)lists.fedoraproject.org> > Subject: Re: [389-users] Repair replication > Message-ID: > <CANCf8oLYKet99sB_ou4U3CER8U89UgwZhGUBTHekcF9HWNKL9g(a)mail.gmail.com > > > Content-Type: text/plain; charset="iso-8859-1" > > Hey Herb, > > You should refer to the Red Hat Directory Server administration guide for > detail about setting up replication which you can locate in here. > http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/ > > >> 1. How can I find out which system(s) is/are master, consumer, hub, etc? > You should be able to determine the role of the Directory Server for each > system by logging into the LDAP console under > "Configuration->Replication". The role is either "Single Master", "Hub" or > "Dedicated Consumer". > > >> 2. How do I confirm that the systems have the correct credentials for > replication? (I am receiving: "Unable to acquire replica: Permission > denied.") > a. How can I change the bind dn "cn=replication,cn=config" credentials > on each system to ensure replication will work? > You can do that on the console as well. Just navigate down the directory > tree and manually reset the password for the replication user account. > There's a possibility that your replication user account's password > expired. > > >> 3. I assume that upon repairing replication (apparently it has not been > working for several years) the systems will all replicate to the most > recent information. Correct? > I think that's the tricky part. Make sure you backup your directory on all > the LDAP first so you have something to roll back. I *believe* the last > step when setting up replication is initializing the directory and that > will wipe out directory on the other LDAP. Someone on the list might be > able to provide a better on this but I am just giving you a heads up that > this can be a complicated process. > > Good luck > > - David > > 2012/3/21 Herb Burnswell <herbert.burnswell(a)gmail.com> > > > Hi All, > > > > I'm new to LDAP administration and have been tasked with fixing the > system > > replication of 4 Linux systems running Fedora Directory Services. I am > > very comfortable working with Linux/Unix but am not experienced with > LDAP. > > I've been reading the communications from this user group and reading as > > much as I can from documentation. I believe this environment is not too > > complex but I am looking for some guidance, any assistance is greatly > > appreciated. > > > > Info: > > > > OS: Fedora Core 4 > > LDAP: Fedora Directory Server v 7.1 > > > > First, I know that both the systems and FDS versions are ancient. > > However, at this point I need to get the replication working prior to > > putting together a migration plan. I have access to the Directory > Manager > > console and am comfortable running command line commands as well. Either > > way is fine. > > > > Questions: > > > > 1. How can I find out which system(s) is/are master, consumer, hub, etc? > > > > 2. How do I confirm that the systems have the correct credentials for > > replication? (I am receiving: "Unable to acquire replica: Permission > > denied.") > > a. How can I change the bind dn "cn=replication,cn=config" > credentials > > on each system to ensure replication will work? > > > > 3. I assume that upon repairing replication (apparently it has not been > > working for several years) the systems will all replicate to the most > > recent information. Correct? > > > > Again, any guidance is greatly appreciated. > > > > Thanks in advance, > > > > Herb > > > > -- > > 389 users mailing list > > 389-users(a)lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.fedoraproject.org/pipermail/389-users/attachments/20120322/edf… > > > >

5 22

Problem with plugin
by Juan Asensio Sánchez 03 Apr '12

03 Apr '12

Hi We have done a plugin that dynamically change some attributes of the search results. The main code is like this: int smbhack_hook( Slapi_PBlock* pb ) { // ... Slapi_Entry** s_entradas = NULL; Slapi_PBlock* pbi = NULL; // ... rv = slapi_pblock_get( pb, SLAPI_SEARCH_STRFILTER, &s_strfilter ); if (rv == -1) { slapi_unlock_mutex(cfg_lock); return LDAP_OP_IGNORED; } // ... slapi_search_internal_set_pb( pbi, s_dn, // Base s_scope, // Ambito s_strfilter, // Filtro s_attrs, // Atributos buscados s_attrsonly, // Flag de seleccion s_controls, // Controls s_uid, // DN vs uid plugin_id, // ComponentId SLAPI_OP_FLAG_NEVER_CHAIN // Flags ); // ... rv = slapi_pblock_get( pbi, SLAPI_PLUGIN_INTOP_SEARCH_ENTRIES, &s_entradas ); // ... if (s_entradas == NULL || s_entradas[0] == NULL) { slapi_unlock_mutex(cfg_lock); destruir_estructura_dn(pila_dn_invocador); slapi_pblock_destroy(pbi); return LDAP_OP_IGNORED; } // ... } The problem is thar when doing a search with this filter: (&(ou:dn:=People)(uid=myuid)(objectClass=sambaSamAccount)) the method slapi_pblock_getfor the attribute SLAPI_PLUGIN_INTOP_SEARCH_ENTRIES returns s_entradas != null, but if I do a search with this filter: (&(|(ou:dn:=Computers)(ou:dn:=People))(uid=myuid)(objectClass=sambaSamAccount)) s_entradas is null or s_entradas[0] is null and the operation is ignored. What could the reason? If anyone can be useful, this plugin simulates a samba domain trust, making some users of other organization in a group, change dinamycally their sambasid to make them a valid user in the target windows domain.

2 3

Strange problem with 389 console
by Brian Bresina 03 Apr '12

03 Apr '12

Account activation and inactivation no longer seems to be working with my 389 console system. Unfortunately, there are several people with admin rights to the ldap servers so I am unsure if someone might have messed the server up. Currently, I can select inactivate for an account and I will get back a box showing no errors. If I look at the account however, only the nsmangeddisalble role and nsdisabled roles have been set. The nsaccountlock is never added to the account. Also, if you right click on the account the activate is always greyed out. I can manually add the nsaccountlock attribute and set it to true. If I do this, the activate will appear when I right click on the account but when I activate it only the roles will be removed, the nsaccountlock attribute is still in place. Also I have noticed that there are two entries for some of the attributes if I go to add them to an account, nsaccount lock is one of them. Sadly, this is running in a production system, so I really need to have a way for other SAs to lock out accounts for users that are no longer on the system with having them added attributes for each account. Anyone know what might be going on here? Thanks. -- "I am not completely worthless, I can always serve as a bad example."

3 2

Authentication failed because the server was unable to generate authentication credentials. The authentication database could not be opened.
by Maurizio Marini 31 Mar '12

31 Mar '12

thsi was already discussed on this thread: http://lists.fedoraproject.org/pipermail/389-users/2009-April/009362.html but there was clue to solve the issue. this server is a CentOS 6 with following packages: 389-admin-1.1.25-1.el6.x86_64 389-ds-console-1.2.6-1.el6.noarch 389-adminutil-devel-1.1.14-2.el6.x86_64 389-ds-base-1.2.9.14-1.el6_2.2.x86_64 389-admin-console-1.1.8-1.el6.noarch 389-dsgw-1.1.7-2.el6.x86_64 389-ds-base-devel-1.2.9.14-1.el6_2.2.x86_64 389-admin-console-doc-1.1.8-1.el6.noarch 389-console-1.1.7-1.el6.noarch 389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64 389-adminutil-1.1.14-2.el6.x86_64 389-ds-console-doc-1.2.6-1.el6.noarch 389-ds-1.2.2-1.el6.noarch I have configured dsgw using: http://directory.fedoraproject.org/wiki/DSGW when i try to authenticate a test user, using /var/log/dirsrv/slapd-ds/access i see authentication is ok: [30/Mar/2012:22:30:23 +0200] conn=103 op=1 BIND dn="uid=xxx,ou=People,dc=xxx,dc=it" method=128 version=3 [30/Mar/2012:22:30:23+0200] conn=103 op=1 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=xxx,ou=people,dc=xxx,dc=it" i use xxx to obfuscate real names to protect my customer privacy. but something goes wrong after it, into dsgw Is there any dsgw log to diagnose better the issue? regards

2 6

console and groupOfNames
by Michael Gettes 30 Mar '12

30 Mar '12

I've been looking through the docs and I can't seem to find anything on this topic - so I figured I would ask. Is there any way to convince the java console to use groupOfNames instead of groupOfUniqueNames for the group look-ups? Yes, I know there are so many other tools out there including DSGW. But, I am curious as to whether or not console can be convinced some how. thanks! /mrg

2 1

Re: [389-users] db2bak.pl Fails when secure connections are required.
by Rich Megginson 30 Mar '12

30 Mar '12

On 03/30/2012 02:25 AM, MATON Brett wrote: > > OS RHEL 6.2 (/x86/_64) > > Packages Installed: > > 389-admin-1.1.29-1.el6.x86_64 > > 389-admin-console-1.1.8-1.el6.noarch > > 389-admin-console-doc-1.1.8-1.el6.noarch > > 389-adminutil-1.1.15-1.el6.x86_64 > > 389-console-1.1.7-1.el6.noarch > > 389-ds-1.2.2-1.el6.noarch > > 389-ds-base-1.2.9.14-1.el6_2.2.x86_64 > > 389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64 > > 389-ds-console-1.2.6-1.el6.noarch > > 389-ds-console-doc-1.2.6-1.el6.noarch > > 389-dsgw-1.1.9-1.el6.x86_64 > > openldap-clients-2.4.23-20.el6.x86_64 > > /usr/lib64/dirsrv/slapd-<instance>/db2bak.pl -v -D "cn=Directory > Manager" -w - > > Bind Password: > > Back up directory: > /var/lib/dirsrv/slapd-<instance>/bak/<instance>-2012_3_30_10_13_21 > > ldap_initialize( ldap://<FQDN>:389 ) > > ldap_bind: Confidentiality required (13) > > additional info: Operation requires a secure connection > > For me the following simple fix proved to be a working solution > (having said that I haven’t tried a restore yet): > > With ldapmodify, ldap://<host> apparently kicks off a TLS connection > whereas <host> on it’s own doesn’t. All very odd, anyhoo: > > db2bak.pl : Line 125 add “ldap://” before the host name. > > open(FOO, "| ldapmodify -x $vstr -h *ldap://*<host> -p 389 -D > \"$rootdn\" -w \"$passwd\" -a" ); > > /usr/lib64/dirsrv/slapd-<instance>/db2bak.pl -v -D "cn=Directory > Manager" -w - > > Bind Password: > > Back up directory: > /var/lib/dirsrv/slapd-<instance>/bak/<instance>-2012_3_30_10_14_14 > > *ldap_initialize( <DEFAULT> )* > > add objectclass: > > top > > extensibleObject > > add cn: > > backup_2012_3_30_10_14_14 > > add nsArchiveDir: > > /var/lib/dirsrv/slapd-<instance>/bak/<instance>-2012_3_30_10_14_14 > > add nsDatabaseType: > > ldbm database > > adding new entry "cn=backup_2012_3_30_10_14_14, cn=backup, cn=tasks, > cn=config" > > modify complete > > Straight forward enough to change the template… > Please file a ticket at https://fedorahosted.org/389 > Brett > > ------------------------------------------------------------------- > > *GreeNRB > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > > > -- > 389 users mailing list > 389-users(a)lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users

1 0

Changelog
by Jim Finn 29 Mar '12

29 Mar '12

Is it possible to view the contents of the changelog?

3 2

Announcing 389 Directory Server version 1.2.10.4 Stable
by Rich Megginson 29 Mar '12

29 Mar '12

The 389 Project team is pleased to announce the release of 389-ds-base-1.2.10.4. This release contains a fix for a bug that causes the directory server to hang when using compare operations with virtual attributes. No new features were added after alpha 8, just many bug fixes. There are also 389-adminutil, 389-admin, and 389-dsgw packages. NEW: EL6 support Beginning with RHEL 6.2, the 389-ds-base package is included in the base OS. Therefore, the 389-ds-base package can no longer be provided via EPEL, due to RHEL/EPEL packaging restrictions. However, the 389 Project will still make the full 389-ds-base package available via http://repos.fedorapeople.org/repos/rmeggins/389-ds-base. See http://directory.fedoraproject.org/wiki/Download for more information. NEW: 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. All of the old 389 bugs have been copied to Trac. All new bugs, feature requests, and tasks should be entered in Trac This link shows all of the issues fixed in the 1.2.10 branch - https://fedorahosted.org/389/report/12 In addition to the tickets for Milestone 1.2.10.3 there were a couple of issues found by valgrind that have been fixed. NEW: Plugin Authors WARNING: Plugins should be made transaction aware so that they can be called from within a backend pre/post transaction plugin. Otherwise, attempting to perform an internal operation will cause a deadlock. See http://directory.fedoraproject.org/wiki/Plugins 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

2 3

Possible problems on 1.2.10-0.6.a6.fc15.x86_64
by Edward Z. Yang 28 Mar '12

28 Mar '12

Hello folks, We recently updated our dirsrv instances to 1.2.10-0.6.a6.fc15.x86_64, and had it crash repeatedly one of our more loaded servers. We haven't debugged in depth but were curious whether or not anyone else had seen this problem. There were no error logs, but we weren't add loglevel debug. Edward

3 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users March 2012