389-users November 2010

389-users@lists.fedoraproject.org

26 participants
35 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] get base dn from ldapsearch
by Angel Bosch Mora 15 Jul '11

15 Jul '11

> Maybe I am understanding this wrong but could you not just check in > the config what the search base is set to on the client side? What is > the problem you are trying to solve? > yes, you're right. i can just take a look at ldap.conf but there's several places to look: - debian/ubuntu uses /etc/ldap/ldap.conf - RHEL/CentOS uses /etc/openldap/ldap.conf - custom compilations can use any path. ex: /usr/local/ldap/ldap.conf - windows openldap uses... i don't really know :P so what im trying to do is resolving configured base without knowing anything about the client. for example, this command gives me the server even if i dont know anything about the conf: ldapsearch -d1 -x -LLL "(uid=example)" uid 2>&1 | grep ldap_connect_to_host im just a little bit surprised that i can't find any debuglevel that gives me the BASE abosch

8 17

Re: [389-users] New 389 ds install - cannot logon to adm console
by trisooma 14 Jan '11

14 Jan '11

If i am reading the code correctly (and looking at the logging below), the line that has a severity of 'crit' should dump info for the ldap server we are connecting to. In my case (and Eric's too) only 'ldap://:389' is printed; sometimes even with an odd number like 23395496 (see Eric's first post). [Tue Nov 30 22:01:43 2010] [crit] openLDAPConnection(): util_ldap_init failed for ldap://:389 [Tue Nov 30 22:01:43 2010] [warn] Unable to open initial LDAPConnection to populate LocalAdmin tasks into cache. [Tue Nov 30 22:01:44 2010] [notice] Apache/2.2.17 (Unix) configured -- resuming normal operations [Tue Nov 30 22:01:44 2010] [crit] openLDAPConnection(): util_ldap_init failed for ldap://:389 [Tue Nov 30 22:01:44 2010] [warn] Unable to open initial LDAPConnection to populate LocalAdmin tasks into cache. The code that logs this error looks like this [mod_admserv/mod_admserv.c:517] ap_log_error(APLOG_MARK, APLOG_CRIT, 0 /* status */, NULL, "openLDAPConnection(): util_ldap_init failed for ldap%s://%s:%d", data->secure ? "s" : "", data->host, data->port); It seems that the struct 'data' is not filled with the correct values. BTW. this code was taken from 389-admin-1.1.12.a2 I hope this helps, Regards, Trisooma

4 9

Building 1.2.7
by Roberto Polli 10 Dec '10

10 Dec '10

Hi all, I tried to build 1.2.7 with openldap only, but it seems I still require mozldap for the ldif.h (like specified in the documentation). Do you suggesto to continue building 1.2.7 with mozldap only? Peace, R. -- Roberto Polli Project Manager Babel S.r.l. - http://www.babel.it T: +39.06.91801075 M: +39.340.6522736 F: +39.06.91612446 P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma) CONFIDENZIALE: Questo messaggio ed i suoi allegati sono di carattere confidenziale per i destinatari in indirizzo. E' vietato l'inoltro non autorizzato a destinatari diversi da quelli indicati nel messaggio originale. Se ricevuto per errore, l'uso del contenuto e' proibito; si prega di comunicarlo al mittente e cancellarlo immediatamente.

8 14

Re: [389-users] New 389 ds install - cannot logon to adm console
by trisooma 30 Nov '10

30 Nov '10

See below for my info, it looks like i am using the exact same versions of the program. [shadowuser@icicle ~]$ rpm -qi 389-ds-base 389-adminutil 389-admin Name : 389-ds-base Relocations: (not relocatable) Version : 1.2.7 Vendor: Fedora Project Release : 2.fc14 Build Date: Tue 16 Nov 2010 07:21:59 PM CET Install Date: Mon 29 Nov 2010 09:06:52 PM CET Build Host: x86-16.phx2.fedoraproject.org Group : System Environment/Daemons Source RPM: 389-ds-base-1.2.7-2.fc14.src.rpm Size : 5574559 License: GPLv2 with exceptions Signature : RSA/SHA256, Sat 20 Nov 2010 09:54:28 PM CET, Key ID 421caddb97a1071f Packager : Fedora Project URL : http://port389.org/ Summary : 389 Directory Server (base) Description : 389 Directory Server is an LDAPv3 compliant server. The base package includes the LDAP server and command line utilities for server administration. Name : 389-adminutil Relocations: (not relocatable) Version : 1.1.10 Vendor: Fedora Project Release : 2.fc14 Build Date: Fri 02 Apr 2010 03:54:55 PM CEST Install Date: Mon 29 Nov 2010 09:06:37 PM CET Build Host: x86-01.phx2.fedoraproject.org Group : Development/Libraries Source RPM: 389-adminutil-1.1.10-2.fc14.src.rpm Size : 155108 License: LGPLv2 Signature : RSA/SHA256, Tue 27 Jul 2010 03:02:24 AM CEST, Key ID 421caddb97a1071f Packager : Fedora Project URL : http://port389.org/wiki/AdminUtil Summary : Utility library for 389 administration Description : 389-adminutil is libraries of functions used to administer directory servers, usually in conjunction with the admin server. 389-adminutil is broken into two libraries - libadminutil contains the basic functionality, and libadmsslutil contains SSL versions and wrappers around the basic functions. The PSET functions allow applications to store their preferences and configuration parameters in LDAP, without having to know anything about LDAP. The configuration is cached in a local file, allowing applications to function even if the LDAP server is down. The other code is typically used by CGI programs used for directory server management, containing GET/POST processing code as well as resource handling (ICU ures API). Name : 389-admin Relocations: (not relocatable) Version : 1.1.12 Vendor: Fedora Project Release : 2.fc14 Build Date: Thu 18 Nov 2010 07:56:53 PM CET Install Date: Mon 29 Nov 2010 09:06:58 PM CET Build Host: x86-05.phx2.fedoraproject.org Group : System Environment/Daemons Source RPM: 389-admin-1.1.12-2.fc14.src.rpm Size : 1091939 License: GPLv2 and ASL 2.0 Signature : RSA/SHA256, Sat 20 Nov 2010 09:51:01 PM CET, Key ID 421caddb97a1071f Packager : Fedora Project URL : http://port389.org/ Summary : 389 Administration Server (admin) Description : 389 Administration Server is an HTTP agent that provides management features for 389 Directory Server. It provides some management web apps that can be used through a web browser. It provides the authentication, access control, and CGI utilities used by the console. [root@icicle shadowuser]# cat /etc/dirsrv/admin-serv/adm.conf AdminDomain: phasma.nl sysuser: nobody isie: cn=389 Administration Server,cn=Server Group,cn=icicle.phasma.nl,ou=phasma.nl,o=NetscapeRoot SuiteSpotGroup: nobody sysgroup: nobody userdn: uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot ldapStart: /usr/lib/dirsrv/slapd-icicle/start-slapd ldapurl: ldap://icicle.phasma.nl:389/o=NetscapeRoot SuiteSpotUserID: nobody sie: cn=admin-serv-icicle,cn=389 Administration Server,cn=Server Group,cn=icicle.phasma.nl,ou=phasma.nl,o=NetscapeRoot The directory server starts without errors, and i can use commands like ldapsearch/ldapmodify without a problem. Any suggestions? Regards, Trisooma

1 0

Re: [389-users] New 389 ds install - cannot logon to adm console
by trisooma 30 Nov '10

30 Nov '10

Hi, I am having the exact same issue: - fresh install of 389-ds (version 1.2.1-1.fc14) - server config: (as per http://directory.fedoraproject.org/wiki/Howto:AdminServerLDAPMgmt) nsAdminAccessAddresses: * nsAdminAccessHosts: - servers are running (dirsrv/dirsrv-admin) - firewall is disabled (all traffic is accepted) - SELinux is disabled - curl can access auth url locally, see below: [shadowuser@icicle ~]$ curl http://localhost:9830/admin-serv/authenticate <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>401 Authorization Required</title> </head><body> <h1>Authorization Required</h1> <p>This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required.</p> <hr> <address>Apache/2.2 Server at localhost Port 9830</address> </body></html> server log insists that access is denied for this ip, see below: [Mon Nov 29 22:26:37 2010] [crit] openLDAPConnection(): util_ldap_init failed for ldap://:389 [Mon Nov 29 22:26:37 2010] [warn] Unable to open initial LDAPConnection to populate LocalAdmin tasks into cache. [Mon Nov 29 22:26:38 2010] [notice] Apache/2.2.17 (Unix) configured -- resuming normal operations [Mon Nov 29 22:26:38 2010] [crit] openLDAPConnection(): util_ldap_init failed for ldap://:389 [Mon Nov 29 22:26:38 2010] [warn] Unable to open initial LDAPConnection to populate LocalAdmin tasks into cache. [Mon Nov 29 22:26:56 2010] [notice] [client 127.0.0.1] admserv_host_ip_check: Unauthorized host ip=127.0.0.1, connection rejected [Mon Nov 29 22:27:37 2010] [notice] [client 127.0.0.1] admserv_host_ip_check: Unauthorized host ip=127.0.0.1, connection rejected [Mon Nov 29 22:27:54 2010] [notice] [client 127.0.0.1] admserv_host_ip_check: Unauthorized host ip=127.0.0.1, connection rejected [Mon Nov 29 22:28:02 2010] [notice] [client 127.0.0.1] admserv_host_ip_check: Unauthorized host ip=127.0.0.1, connection rejected [Mon Nov 29 22:28:05 2010] [notice] [client 127.0.0.1] admserv_host_ip_check: Unauthorized host ip=127.0.0.1, connection rejected [Mon Nov 29 22:41:27 2010] [notice] [client 127.0.0.1] admserv_host_ip_check: Unauthorized host ip=127.0.0.1, connection rejected What could be wrong? Regards Trisooma

3 3

Please Help Test 389 Directory Server 1.2.7.1
by Rich Megginson 29 Nov '10

29 Nov '10

389-ds-base-1.2.7.1 is now in Testing. This release has some key fixes for bugs in 1.2.7. Please help us test. The sooner we can get this release tested, the sooner we can push it to Stable and make it generally available. There is also a new 389-admin-1.1.13 package. 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 --enablerepo=updates-testing 389-ds-base 389-admin # or for EPEL yum upgrade --enablerepo=epel-testing 389-ds-base 389-admin setup-ds-admin.pl -u How to Give Feedback The best way to provide feedback is via the Fedora Update system. Each update is broken down by package and platform. For example, if you are using Fedora 12, and you have successfully installed or upgraded all of the packages, and the console and etc. works, then go to the links below for Fedora 12 and provide feedback. * 389-ds-base-1.2.7.1 ** EL-5 - https://admin.fedoraproject.org/updates/389-ds-base-1.2.7.1-1.el5 ** Fedora 12 - https://admin.fedoraproject.org/updates/389-ds-base-1.2.7.1-1.fc12 ** Fedora 13 - https://admin.fedoraproject.org/updates/389-ds-base-1.2.7.1-1.fc13 ** Fedora 14 - https://admin.fedoraproject.org/updates/389-ds-base-1.2.7.1-1.fc14 scroll down to the bottom of the page, and click on the Add a comment >> link * select one of the Works for me or Does not work radio buttons, add text, and click on the Add Comment button If you are using a build on another platform, 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, you can enter it here - https://bugzilla.redhat.com/enter_bug.cgi?product=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

1 0

Slow response from server
by Gerrard Geldenhuis 29 Nov '10

29 Nov '10

Hi We are getting a slow responses from one of our LDAP servers and I am not sure what is causing the problem I have run a logconv.pl -j and the following is interesting: Connections Reset By Peer: 0 Resource Unavailable: 136 - 136 (T1) Idle Timeout Exceeded We have a cache hit ratio of 99% and only using about 10% of the available cache size. I am leaning towards the problem being network related and maybe needing to set timeout values less aggresively on our clients for this particular host but was hoping that there might be some more checks and analysis that I can run to determine the health of the LDAP server. I am working on an internal trouble shooting guide and could potentially move some of the generic information into the 389 wiki. Regards ________________________________________________________________________ In order to protect our email recipients, Betfair Group use SkyScan from MessageLabs to scan all Incoming and Outgoing mail for viruses. ________________________________________________________________________

2 6

New 389 ds install - cannot logon to adm console
by Eric Donkersloot 29 Nov '10

29 Nov '10

Hi all, I just installed 389 directory server, but somehow I cannot log on to the administration console: /var/log/dirsrv/admin-serv/error: [Fri Nov 26 16:15:06 2010] [notice] Apache/2.2.17 (Unix) configured -- resuming normal operations [Fri Nov 26 16:15:06 2010] [crit] openLDAPConnection(): util_ldap_init failed for ldap://:23395496 [Fri Nov 26 16:15:06 2010] [warn] Unable to open initial LDAPConnection to populate LocalAdmin tasks into cache. [Fri Nov 26 16:15:26 2010] [notice] [client 127.0.0.1] admserv_host_ip_check: Unauthorized host ip=127.0.0.1, connection rejected This is the config on the server: nsAdminAccessAddresses: *.surfnet.nl 192.87.*.* 127.0.0.1 nsAdminAccessHosts: * Installed software: 389-adminutil-1.1.10-2.fc14.i686 389-admin-1.1.12-2.fc14.i686 389-ds-console-1.2.3-1.fc14.noarch 389-ds-console-doc-1.2.3-1.fc14.noarch 389-ds-1.2.1-1.fc14.noarch 389-console-1.1.4-1.fc14.noarch 389-ds-base-1.2.7-2.fc14.i686 389-admin-console-1.1.5-1.fc14.noarch 389-dsgw-1.1.5-2.fc14.i686 389-admin-console-doc-1.1.5-1.fc14.noarch I try to log in to the console as the admin user, I start the console through a tunneled ssh session. The server is running F14 (i686) by the way. What am I missing here ? Kind regards, Eric -- Eric Donkersloot SURFnet Radboudkwartier 273 3511 CK Utrecht The Netherlands M +31 6 4115 4547 eric.donkersloot(a)surfnet.nl

3 4

Bind to consumer binds to provider as well
by Gerrard Geldenhuis 29 Nov '10

29 Nov '10

Hi In our setup we have clients authenticating against a consumer server. The consumer server is chained to the provider server for writes and we have passwordpolicy configured including lockout settings. We replicate all password data. When I do a bind to the consumer(slave) I also see a bind to the provider(master) this seems really silly. My understanding is that this behaviour is caused by needing to centrally store login attempts. I have raised this matter previously but just wanted to double check that the behaviour I am seeing is expected and not due to a misconfiguration on our part. Best Regards ________________________________________________________________________ In order to protect our email recipients, Betfair Group use SkyScan from MessageLabs to scan all Incoming and Outgoing mail for viruses. ________________________________________________________________________

3 10

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users November 2010