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, 3 months
Re: [389-users] Repair replication
by Herb Burnswell
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/e...
> >
>
>
11 years, 7 months
Problem with plugin
by Juan Asensio Sánchez
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.
11 years, 8 months
Strange problem with 389 console
by Brian Bresina
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."
11 years, 8 months
Authentication failed because the server was unable to generate authentication credentials. The authentication database could not be opened.
by Maurizio Marini
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
11 years, 8 months
console and groupOfNames
by Michael Gettes
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
11 years, 8 months
Re: [389-users] db2bak.pl Fails when secure connections are required.
by Rich Megginson
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
11 years, 8 months
Changelog
by Jim Finn
Is it possible to view the contents of the changelog?
11 years, 8 months
Announcing 389 Directory Server version 1.2.10.4 Stable
by Rich Megginson
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
11 years, 8 months
Possible problems on 1.2.10-0.6.a6.fc15.x86_64
by Edward Z. Yang
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
11 years, 8 months
