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, 1 month
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
Windows sync stopped working
by Aaron Hagopian
I had everything setup to sync to my domain controller and things were
working fine. Recently I saw this message in the logs:
[30/Apr/2010:11:59:10 -0500] NSMMReplicationPlugin -
agmt="cn=toto.hra.local" (10:636): windows_replay_update: Cannot replay add
operation.
So I thought maybe I would try to remove the agreement and re-add it and
re-initalize. After doing this now I get this message again along with the
every 5 seconds.
[30/Apr/2010:12:01:31 -0500] NSMMReplicationPlugin -
agmt="cn=toto.hra.local" (10:636): Replica has no update vector. It has
never been initialized.
This is on 389-ds 1.2.5 running on x86_64 RHEL 5.4
I think this all started when I added an ipHost entry to an OU that should
not even be looked at for syncing purposes. Any ideas on how to clear this
up so I can sync with windows again? I'm not using the create new users or
groups, just trying to sync passwords.
13 years, 5 months
Re: [389-users] Migrate fedora-ds 1.0.4 SSL Enabled
by Craig Swanson
Rich,
Migration completed, SSL enabled, console is working!
I used the 25changefedorato389.pl as a guide.
In NetscapeRoot.ldif:
+ converted all cn=Fedora to cn=389
+ converted all fedora to 389 (this converted the jar files and nicknames).
Thank you for your help,
Craig Swanson
On 04/28/2010 10:09 AM, Rich Megginson wrote:
> Craig Swanson wrote:
>> Rich,
>>
>> Thanks for the prompt reply.
>> Ok, I'll not assume that SSL is the problem.
>>
>> My setup is:
>> SSL is enabled in its original configuration on the source.
>> updated autofs and mozilla ldif files.
>> db2ldif to export the userRoot and NetscapeRoot databases.
>> Modified just the source /opt/fedora-ds/admin-serv/config/adm.conf
>> and local.conf to replace cn=Fedora with cn=389
>>
>> The migration fails during migration of the Administration Server with:
>> check_and_add_entry: Entry not found cn=Tasks, cn=admin-serv-punch,
>> cn=389 Administration Server, cn=Server Group,
>> cn=punch.midwest-tool.com, ou=midwest-tool.com, o=NetscapeRoot error
>> No such object
> I think the main problem is that migration does not convert Fedora to
> 389. That's why you get the errors like
> +++check_and_add_entry: Entry not found cn=389 Administration Server,
> cn=Server Group, cn=punch.midwest-tool.com, ou=midwest-tool.com,
> o=NetscapeRoot error No such object
>
> Because the migrated NetscapeRoot.ldif file has cn=Fedora
> Administration Server
>
> There is an upgrade scriptlet -
> /usr/share/dirsrv/updates-admin/25changefedorato389.pl - if you are a
> perl hacker, you could probably take that and use it to fix
> NetscapeRoot.ldif before starting migration.
>
> If not, then your best bet is to dump the old NetscapeRoot to ldif and
> fix it manually - be sure to use db2ldif -U so that the LDIF lines
> won't be wrapped - if the lines are wrapped, it will make finding all
> occurrances of "Fedora" quite difficult if not impossible with
> something like sed/awk/perl.
>>
>> I'll send the debug log directly to you.
>>
>> Craig Swanson
13 years, 5 months
Re: [389-users] Migrate fedora-ds 1.0.4 SSL Enabled
by Craig Swanson
Rich,
Thanks for the prompt reply.
Ok, I'll not assume that SSL is the problem.
My setup is:
SSL is enabled in its original configuration on the source.
updated autofs and mozilla ldif files.
db2ldif to export the userRoot and NetscapeRoot databases.
Modified just the source /opt/fedora-ds/admin-serv/config/adm.conf and
local.conf to replace cn=Fedora with cn=389
The migration fails during migration of the Administration Server with:
check_and_add_entry: Entry not found cn=Tasks, cn=admin-serv-punch,
cn=389 Administration Server, cn=Server Group,
cn=punch.midwest-tool.com, ou=midwest-tool.com, o=NetscapeRoot error No
such object
I'll send the debug log directly to you.
Craig Swanson
Craig Swanson wrote:
> I am hoping for guidance in migrating this SSL enabled directory to
> 389-ds.
>
> From: fedora-ds 1.0.4 on fc6 i386
> To: 389-ds 1.1 on fedora 12 i386. The fedora 12 is on a new box
> with the same IP address and hostname.
>
> SSL is enabled on the source directory and source admin server.
>
> I have read the SSL HowTo, so I understand that the certs are stored
> differently under 1.1.
> Is it possible to import the existing SSL certs and set up the
> configuration so that the migration will succeed?
migration is supposed to take care of all of that for you
> If not, how do I correctly remove SSL from the source configuration?
> I could set up SSL on the target after the migration.
>
> Thank you,
>
> Craig Swanson
>
> ----------Supporting information ---------------------
>
> So far I have done this 1.0.4 to 1.1 prep:
>
> I have modified the source schema to use the updated autofs and
> mozilla ldif files.
> I have run db2ldif to export the userRoot and NetscapeRoot databases.
> I have modified the source /opt/fedora-ds/admin-serv/config/adm.conf
> and local.conf to replace cn=Fedora with cn=389
adm.conf - ok
local.conf - not so good - this is just a read-only copy of information
stored in o=NetscapeRoot in the actual database.
> Bad outcomes:
> I ran the cross platform migration in order to pull from the modified
> ldif files.
> migrate-ds-admin.pl -d --crossplatform --oldsroot=/opt/fedora-ds.104
> --actualsroot=/opt/fedora-ds -f /opt/migratePunch.inf
>
> The migration failed because I had not dealt with the SSL. Debug output:
>
> +[27/Apr/2010:12:44:26 -0400] - 389-Directory/1.2.5 B2010.012.2035
> starting up
> +[27/Apr/2010:12:44:26 -0400] - I'm resizing my cache now...cache was
> 208736256 and is now 8388608
> +[27/Apr/2010:12:44:27 -0400] - attrcrypt_unwrap_key: failed to unwrap
> key for cipher AES
> +[27/Apr/2010:12:44:27 -0400] - Failed to retrieve key for cipher AES
> in attrcrypt_cipher_init
> +[27/Apr/2010:12:44:27 -0400] - Failed to initialize cipher AES in
> attrcrypt_init
> +[27/Apr/2010:12:44:27 -0400] - attrcrypt_unwrap_key: failed to unwrap
> key for cipher 3DES
> +[27/Apr/2010:12:44:27 -0400] - Failed to retrieve key for cipher 3DES
> in attrcrypt_cipher_init
> +[27/Apr/2010:12:44:27 -0400] - Failed to initialize cipher 3DES in
> attrcrypt_init
> +[27/Apr/2010:12:44:27 -0400] - attrcrypt_unwrap_key: failed to unwrap
> key for cipher AES
> +[27/Apr/2010:12:44:27 -0400] - Failed to retrieve key for cipher AES
> in attrcrypt_cipher_init
> +[27/Apr/2010:12:44:27 -0400] - Failed to initialize cipher AES in
> attrcrypt_init
> +[27/Apr/2010:12:44:27 -0400] - attrcrypt_unwrap_key: failed to unwrap
> key for cipher 3DES
> +[27/Apr/2010:12:44:27 -0400] - Failed to retrieve key for cipher 3DES
> in attrcrypt_cipher_init
> +[27/Apr/2010:12:44:27 -0400] - Failed to initialize cipher 3DES in
> attrcrypt_init
These errors are probably ok if you are not using the attribute
encryption feature. You ideally should not have these errors, but this
doesn't mean SSL won't work.
>
> Disabling SSL in the source:
> I have tried to disable SSL on the source directory and admin server
> via the console.
Let's try to figure out what happened initially with migration first.
13 years, 5 months
Migrate fedora-ds 1.0.4 SSL Enabled
by Craig Swanson
I am hoping for guidance in migrating this SSL enabled directory to 389-ds.
From: fedora-ds 1.0.4 on fc6 i386
To: 389-ds 1.1 on fedora 12 i386. The fedora 12 is on a new box
with the same IP address and hostname.
SSL is enabled on the source directory and source admin server.
I have read the SSL HowTo, so I understand that the certs are stored
differently under 1.1.
Is it possible to import the existing SSL certs and set up the
configuration so that the migration will succeed?
If not, how do I correctly remove SSL from the source configuration? I
could set up SSL on the target after the migration.
Thank you,
Craig Swanson
----------Supporting information ---------------------
So far I have done this 1.0.4 to 1.1 prep:
I have modified the source schema to use the updated autofs and mozilla
ldif files.
I have run db2ldif to export the userRoot and NetscapeRoot databases.
I have modified the source /opt/fedora-ds/admin-serv/config/adm.conf
and local.conf to replace cn=Fedora with cn=389
Bad outcomes:
I ran the cross platform migration in order to pull from the modified
ldif files.
migrate-ds-admin.pl -d --crossplatform --oldsroot=/opt/fedora-ds.104
--actualsroot=/opt/fedora-ds -f /opt/migratePunch.inf
The migration failed because I had not dealt with the SSL. Debug output:
+[27/Apr/2010:12:44:26 -0400] - 389-Directory/1.2.5 B2010.012.2035
starting up
+[27/Apr/2010:12:44:26 -0400] - I'm resizing my cache now...cache was
208736256 and is now 8388608
+[27/Apr/2010:12:44:27 -0400] - attrcrypt_unwrap_key: failed to unwrap
key for cipher AES
+[27/Apr/2010:12:44:27 -0400] - Failed to retrieve key for cipher AES in
attrcrypt_cipher_init
+[27/Apr/2010:12:44:27 -0400] - Failed to initialize cipher AES in
attrcrypt_init
+[27/Apr/2010:12:44:27 -0400] - attrcrypt_unwrap_key: failed to unwrap
key for cipher 3DES
+[27/Apr/2010:12:44:27 -0400] - Failed to retrieve key for cipher 3DES
in attrcrypt_cipher_init
+[27/Apr/2010:12:44:27 -0400] - Failed to initialize cipher 3DES in
attrcrypt_init
+[27/Apr/2010:12:44:27 -0400] - attrcrypt_unwrap_key: failed to unwrap
key for cipher AES
+[27/Apr/2010:12:44:27 -0400] - Failed to retrieve key for cipher AES in
attrcrypt_cipher_init
+[27/Apr/2010:12:44:27 -0400] - Failed to initialize cipher AES in
attrcrypt_init
+[27/Apr/2010:12:44:27 -0400] - attrcrypt_unwrap_key: failed to unwrap
key for cipher 3DES
+[27/Apr/2010:12:44:27 -0400] - Failed to retrieve key for cipher 3DES
in attrcrypt_cipher_init
+[27/Apr/2010:12:44:27 -0400] - Failed to initialize cipher 3DES in
attrcrypt_init
Disabling SSL in the source:
I have tried to disable SSL on the source directory and admin server via
the console.
Next, I had attempted a migration. The migration completed, but, the
console failed authentication on the resulting 1.1 server.
http://myserver:64000
I went back to the source server. launching the console
http://myserver:64000 also failed authentication.
13 years, 5 months
Re: [389-users] 389-users Digest, Vol 59, Issue 21
by Aaron Mills
Thanks for your help all. it looks like CRYPT was the problem. I've changed passwords over to SSHA and everything works as designed.
-Aaron
From: Elías Halldór Ágústsson <elias(a)hi.is<mailto:elias@hi.is>>
Date: April 26, 2010 6:18:45 PM MDT
To: "389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>" <389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>>
Subject: Re: [389-users] Entire password not checked
Reply-To: General discussion list for the 389 Directory server project. <389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>>
Aaron Mills skrifaði:
However, whenever users authenticate via LDAP the server appears to check only the first 8 characters of their passwords.
You're probably using the CRYPT password method. Other, newer and safer
methods, such as SSHA, can store much longer passwords.
<Digest Footer.txt>
Aaron Mills
Systems Administrator
Return Path, Inc.
aaron.mills(a)returnpath.net<mailto:aaron.mills@returnpath.net>
13 years, 5 months
Entire password not checked
by Aaron Mills
Hi All,
I have an FDS and 389 instance set up with a number of users, and password policy requiring minimum password length, some numbers, and some other characters.
This all works well for mandating secure passwords. However, whenever users authenticate via LDAP the server appears to check only the first 8 characters of their passwords. For example if a user has a password of "foobar1234!" they can still login with "foobar12" or "foobar12bazbaz" I've tested this with unix client logins (via PAM) and directly via the ldapsearch command. Both exhibit the same behavior.
Goo diligence hasn't really turned up anything, though it could be I'm missing the obvious. Has anyone run into this problem before? Is this possibly an issue with they way i'm storing passwords?
-Aaron
13 years, 5 months
disable SSL at startup
by Thomas Cameron
Howdy -
Posting this to the list just because Google searches didn't tell me.
Very possible I was asking the wrong question, but here's what I was
searching for.
How do you disable SSL at startup for Fedora Directory Server (389)?
In /etc/dirsrv/slapd-[hostname]/dse.ldif, change the line:
nsslapd-security: on
to:
nsslapd-security: off
Back story: I was messing about with SSL certificates and I did
something wrong. Not sure what yet, but since my cert was borked,
after I installed it, 389 wouldn't start. Since the LDAP server
wouldn't start, the admin server wouldn't allow me to log in. I was
kind of screwed.
Once I set the LDAP server to start without SSL, I was able to log in
and now I can (hopefully) figure out what I did wrong with the
certificate.
The error I was getting was:
/var/log/dirsrv/slapd-e510/errors:[24/Apr/2010:18:12:30 -0500] - SSL
alert: CERT_VerifyCertificateNow: verify certificate failed for cert
e510 server-cert of family cn=RSA,cn=encryption,cn=config (Netscape
Portable Runtime error -8179 - Peer's Certificate issuer is not
recognized.)
13 years, 5 months
