389-users April 2010

389-users@lists.fedoraproject.org

29 participants
31 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

changelogdb has gotten large...
by Hartmann, Tim 10 Sep '10

10 Sep '10

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

4 3

Strange behaviour - SAMBA is writing on a Dedicated Consumer Server
by Diretorio Livre 06 May '10

06 May '10

6 15

Windows sync stopped working
by Aaron Hagopian 01 May '10

01 May '10

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.

2 3

Re: [389-users] Migrate fedora-ds 1.0.4 SSL Enabled
by Craig Swanson 28 Apr '10

28 Apr '10

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

1 0

Re: [389-users] Migrate fedora-ds 1.0.4 SSL Enabled
by Craig Swanson 28 Apr '10

28 Apr '10

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.

1 0

Migrate fedora-ds 1.0.4 SSL Enabled
by Craig Swanson 28 Apr '10

28 Apr '10

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.

2 1

Re: [389-users] 389-users Digest, Vol 59, Issue 21
by Aaron Mills 28 Apr '10

28 Apr '10

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>

1 0

Entire password not checked
by Aaron Mills 27 Apr '10

27 Apr '10

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

3 2

disable SSL at startup
by Thomas Cameron 27 Apr '10

27 Apr '10

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.)

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users April 2010