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
changelogdb has gotten large...
by Hartmann, Tim
Hi,
I've run into a situation where one of the files in /var/lib/dirsrv/<instance>/changelogdb has grown almost as large as the partition it's on. In my directory server configs, I noticed I was keeping an unlimited changelog, so I set that to what seems like a reasonably long amount of time (18 weeks) but didn't see any decrease in the file size. I'm wondering now about the best course of action. I can
a) move the whole dirsrv directory to another partition with more space available and symlink the old location to the new, which worked when I tested it, but I wanted to make sure I wouldn't be hosing something up the next time I upgrade.
b) find some means of manually shrinking the *.db ( can you even do that?)
c) point dirsrv at a new location, and reinitialize the consumers (which doesn't seem all that desirable)
Has anyone else found it necessary to shrink your changelogdb?
Thanks
-Tim
13 years, 3 months
dynamic group expansion: writing a patch...
by Roberto Polli
Hi all,
I'd like to start a patch on dynamic group expansion, but dunno where to
start.
Can you point me?
Should be something like reusing VLV code?
Thx+Peace,
R-
--
Roberto Polli
Babel S.r.l. - http://www.babel.it
Tel. +39.06.91801075 - fax +39.06.91612446
Tel. cel +39.340.6522736
P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma)
"Il seguente messaggio contiene informazioni riservate. Qualora questo
messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene
notizia a mezzo e-mail. Vi sollecitiamo altresì a distruggere il messaggio
erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto
della legge in materia di protezione dei dati personali."
13 years, 4 months
Announcing 389 Directory Server 1.2.6 Release Candidate 1
by Rich Megginson
The 389 team is pleased to announce the availability of Release
Candidate 1 of version 1.2.6. This release a couple of bug fixes.
***We need your help! Please help us test this software.*** It is a
release candidate, so it may have a few glitches, but it has been tested
for regressions and for new feature bugs. The Fedora system
strongly encourages packages to be in Testing until verified and pushed
to Stable. If we don't get any feedback while the packages are in
Testing, the packages will remain in limbo, or get pushed to Stable.
The more testing we get, the faster we can release these packages to
Stable. See the Release Notes for information about how to provide
testing feedback (or just send an email to
389-users(a)lists.fedoraproject.org).
The packages that need testing are:
* 389-ds-base-1.2.6.rc1 - 389-ds-base
* 389-admin-1.1.11.rc1 - 389-admin
There are some new console/java packages too, and there is a new version
of the 389-ds "meta" package - 1.2.1
* Release Notes - http://port389.org/wiki/Release_Notes
* Install_Guide - http://port389.org/wiki/Install_Guide
* Download - http://port389.org/wiki/Download
=== Bugs Fixed ===
This release contains a couple of bug fixes. The complete list of bugs
fixed is found at the link below. Note that bugs marked as MODIFIED
have been fixed but are still in testing.
* Tracking bug for 1.2.6 release -
https://bugzilla.redhat.com/showdependencytree.cgi?id=543590&hide_resolved=0
13 years, 4 months
Modify dse.ldif using commands
by Juan Asensio Sánchez
Hi
To modify some parameters of the conguration, like nsslapd-cachememsize, it
is required to stop the server and manually change the setting in the
dse.ldif. Is there any way/command/utility to modify that file without using
grep and sed? I say this because when doing this, we must be careful to
check if the attribute is defined, if not create or replace its value using
sed; or change that value only for certain databases, not for all. It should
be like an ldapmodify, but not using an LDAP server, just loading the
specified dse.ldif file and applying the changes specified in other ldif
file.
Any suggestion? Regards.
13 years, 5 months
Re: [389-users] Synchronizing passwords
by Juan Asensio Sánchez
Hi
Although I think the best solution for this is that Samba only update the
Unix password, and the server generates dinamically the sambaLM and sambaNT
passwords using a plugin (perhaps, in the future, we will contribute with
this plugins, but not right now), I have solved the problem described in my
first message in this way, in the samba configuration:
* ldap passwd sync = No
* unix password sync = Yes
* passwd program = /usr/bin/perl -w
/opt/ldap/smbldap-tools/bin/smbldap-passwd -u %u
* passwd chat = "Changing UNIX password for*\nNew password*" %n\n "*Retype
new password*" %n\n "*Password changed*"
So when a user tries to modify his password, then Samba tries to call the
"passwd program", and only if the command returns succesfully (the "passwd
chat" is ok), then it tries to update samba passwords, so the LDAP password
policies are checked when calling the smbldap-passwd script, because it will
fail if the password is not strong enough and the server rejects it.
I had to modify the script smbldap-passwd, because when the password is
changed succesfully, it did'nt print anything, and "passwd chat" needs some
string to check that the change has been succesfully (i had added "password
changed" in the script after the ldap operation when it is succesfull).
Hope this can help somebody.
Regards.
El 21 de junio de 2010 15:46, Miguel Medalha <miguelmedalha(a)sapo.pt>escribió:
>
> Emmm, well, this makes samba update userPassword when changing the
>> password from Windows. But if i change the password from Linux, samba
>> passwords are not updated, because linux machines are autheticating directly
>> with LDAP, not with Samba (just userPassword).
>>
>
> In that case, the LDAP server must be capable of updating the Samba
> passwords when the LDAP password is changed, which takes us back to your
> original question.
>
> Anyway, the smb.conf parameter to use for that would be:
>
> "ldap passwd sync = Only"
>
> (Only = Only update the LDAP password and let the LDAP server do the rest.)
>
>
> If the 389 server doesn't do the required operation, I suppose that by
> using the regular LDAP tools (ldapmodify, ldappasswd, etc.) combined with a
> shell script it will be easy to modify all passwords with a single command.
>
>
13 years, 5 months
The 1.2.6 release will be very soon . . .
by Rich Megginson
. . . but before we release to the stable repositories, we need your
feedback. Please take a moment to let us know (reply to this message is
fine - bodhi karma is preferred) if you have used 389-ds-base 1.2.6.rc2
and/or 389-admin 1.1.11.rc1 (and related packages) and, if so, what
problems you had, if any. We're trying to be good Fedora community
citizens, while at the same time getting the code out our users quickly.
13 years, 5 months
Migrating from AD to 389 DS
by harry.devine＠faa.gov
We have a Windows 2003 AD domain here at work. We have a mix of Windows
servers and Linux servers, and we are looking to consolidate functions
down a little bit. If we can remove the need for AD, we can have 1
Windows server and the rest will be Linux. I've seen from reading the
389-ds site and docs that 389-ds and AD can share information, but what
about REPLACING AD?
Years ago, our functions at work, along with how machines were configured,
lent themselves to having an AD domain. These days, the basic function of
our domain is for authentication. Thats it, nothing else (no Exchange, no
Group Policy, etc.). So, it would seem like 389-ds would suit our needs
very well. So this leads to my question(s):
Has anyone replaced an AD domain with a 389-ds? How did you do it? How
hard was it to migrate the user information from AD to 389-ds? I know
that the Windows box will need pGina installed on it, too. I plan on
putting 2 servers into a test environment to have 389-ds running on 1 with
CentOS 5.4 and Windows 2003 on the other with pGina 1.8.8 on it to test
it. But I'd like to hear if my long-term plan/hope is feasible and if it
can be accomplished.
Thanks,
Harry
Harry Devine
Common ARTS Software Development
AJT-144
(609)485-4218
Harry.Devine(a)faa.gov
13 years, 5 months
Directory Re-population
by Chun Tat David Chu
Hi All,
We use 389 Directory as part of our development lab. Every time when we do
a new test, we need to repopulate our 389 directory to a clean slate (i.e.
delete all existing data and re-create a base hierarchy tree).
Our current way of doing so is simply using the ldapdelete command to remove
all existing data and use ldapadd to re-create the base hierarchy tree.
This approach is okay but sometime it could take up to 20 to 30 minutes to
delete all existing data depending on the amount of data saved in the
directory.
Is there a more efficient way to repopulate the 389 Directory?
Thanks!
David
13 years, 5 months
