[Fedora-directory-users] (no subject)
by Steve Saady
I am trying to migrate from OpenLDAP to Fedora-DS. The LDAPImport utility seems like the fastest and easiest way to do it. Unfortunately, for me, it fails. At the command line, it reports:
"Can't call method "get_value" on an undefined value at
LdapConnectionManager.pm line 486, <STDIN> line 9."
The log file reports:
"LdapConnectionManager: Currently connected -- searching."
TCPdump, indicates that the base DN of my search is null. I do not
think this is relative, but when the script asks for the "email domain",
suggesting "netscaperoot", is that my normal e-mail domain? The example
confuses me. Any ideas or suggestions would be appreciated.
Which brings me to my current dilemma... Unable to use LDAPImport, I try
the ol-schema-migrate.pl script, re-dir to a new file (i.e.,
perl ./ol-schema-migrate.pl inetorgperson.schema >
XXinetorgperson.ldif). What should I call those resulting files? I
assume I should call them *.ldif, but how do I determine what numeric
prefix to give them? The highest numbers I have currently are 60
(60pam-plugin.ldif), and then 99 (99user.ldif). Should I just number
mine counting up from 61?
18 years, 4 months
[Fedora-directory-users] Solaris 9 ssl/tls setup. (security library: bad database.)
by Michael Montgomery
I have successfully gotten solaris 9 (patched with recommended patches)
to work without using ssl/tls, but can't seem to get ssl/tls working.
I've read the following:
http://directory.fedora.redhat.com/wiki/Howto:SolarisClient
and this
http://forum.sun.com/thread.jspa?threadID=12811&tstart=30
And multiple other links to getting this working, but can't seem to get
it to initialize the database. Everything in my ldap directory appears
to be setup, being that redhat and freebsd with ssl work without issues,
and solaris 9 works without tls/ssl, so the issue, I assume, is with the
*.db files in /var/ldap.
bash-3.00# pwd
/var/ldap
bash-3.00# ls -l *.db
-r--r--r-- 1 root other 65536 Dec 20 11:07 cert8.db
-r--r--r-- 1 root other 16384 Dec 20 11:07 key3.db
-r--r--r-- 1 root other 32768 Dec 20 10:26 secmod.db
bash-3.00# id mmontgomery
Dec 20 11:15:47 solarisldap nscd[1774]: libsldap: Status: 91 Mesg: openConnection: failed to initialize TLS security (security library: bad database.)
Dec 20 11:15:47 solarisldap last message repeated 1 time
Dec 20 11:15:47 solarisldap nscd[1774]: libsldap: Status: 7 Mesg: Session error no available conn.
id: invalid user name: "mmontgomery"
bash-3.00# ldapclient -v manual -a authenticationMethod=tls:simple -a credentia
lLevel=proxy -a defaultSearchBase="dc=*****,dc=*********,dc=***" -a domainNa
me=********** -a followReferrals=false -a preferredServerList=10.5.1.18 -a
serviceAuthenticationMethod=pam_ldap:tls:simple -a proxyPassword=******* -a
proxyDn=cn=proxyagent,ou=profile,dc=******,dc=*****,dc=****
Everything works fine up until this point:
start: /usr/lib/ldap/ldap_cachemgr... success
Dec 20 11:13:21 solarisldap automount[1770]: libsldap: Status: 91 Mesg: openConnection: failed to initialize TLS security (security library: bad database.)
Dec 20 11:13:21 solarisldap last message repeated 1 time
Dec 20 11:13:21 solarisldap automount[1770]: libsldap: Status: 7 Mesg: Session error no available conn.
start: /etc/init.d/autofs start... success
start: /etc/init.d/nscd start... success
Dec 20 11:13:21 solarisldap sendmail[1777]: libsldap: Status: 91 Mesg: openConnection: failed to initialize TLS security (security library: bad database.)
Dec 20 11:13:21 solarisldap last message repeated 1 time
Dec 20 11:13:21 solarisldap sendmail[1777]: libsldap: Status: 7 Mesg: Session error no available conn.
Dec 20 11:13:21 solarisldap sendmail[1777]: libsldap: Status: 91 Mesg: openConnection: failed to initialize TLS security (security library: bad database.)
Dec 20 11:13:21 solarisldap last message repeated 1 time
Dec 20 11:13:21 solarisldap sendmail[1777]: libsldap: Status: 7 Mesg: Session error no available conn.
Dec 20 11:13:21 solarisldap sendmail[1777]: libsldap: Status: 91 Mesg: openConnection: failed to initialize TLS security (security library: bad database.)
Dec 20 11:13:21 solarisldap last message repeated 1 time
Dec 20 11:13:21 solarisldap sendmail[1777]: libsldap: Status: 7 Mesg: Session error no available conn.
Dec 20 11:13:21 solarisldap sendmail[1777]: libsldap: Status: 91 Mesg: openConnection: failed to initialize TLS security (security library: bad database.)
Dec 20 11:13:21 solarisldap last message repeated 1 time
Dec 20 11:13:21 solarisldap sendmail[1777]: libsldap: Status: 7 Mesg: Session error no available conn.
Dec 20 11:13:21 solarisldap sendmail[1778]: libsldap: Status: 91 Mesg: openConnection: failed to initialize TLS security (security library: bad database.)
Dec 20 11:13:21 solarisldap last message repeated 1 time
Dec 20 11:13:21 solarisldap sendmail[1778]: libsldap: Status: 7 Mesg: Session error no available conn.
Dec 20 11:13:21 solarisldap sendmail[1778]: libsldap: Status: 91 Mesg: openConnection: failed to initialize TLS security (security library: bad database.)
Dec 20 11:13:21 solarisldap last message repeated 1 time
Dec 20 11:13:21 solarisldap sendmail[1778]: libsldap: Status: 7 Mesg: Session error no available conn.
Dec 20 11:13:22 solarisldap sendmail[1777]: libsldap: Status: 91 Mesg: openConnection: failed to initialize TLS security (security library: bad database.)
Dec 20 11:13:22 solarisldap last message repeated 1 time
Dec 20 11:13:22 solarisldap sendmail[1777]: libsldap: Status: 7 Mesg: Session error no available conn.
Dec 20 11:13:22 solarisldap sendmail[1778]: libsldap: Status: 91 Mesg: openConnection: failed to initialize TLS security (security library: bad database.)
Dec 20 11:13:22 solarisldap last message repeated 1 time
Dec 20 11:13:22 solarisldap sendmail[1778]: libsldap: Status: 7 Mesg: Session error no available conn.
Dec 20 11:13:22 solarisldap sendmail[1778]: libsldap: Status: 91 Mesg: openConnection: failed to initialize TLS security (security library: bad database.)
Dec 20 11:13:22 solarisldap last message repeated 1 time
Dec 20 11:13:22 solarisldap sendmail[1778]: libsldap: Status: 7 Mesg: Session error no available conn.
start: /etc/init.d/sendmail start... success
System successfully configured
I've used a netscape browser to get my Cert from the FDS, and scp'd the
key3.db, and cert8.db files to the solaris client. From what I can
tell, it can read these files:
bash-3.00# /usr/local/bin/certutil -L -d .
server-cert P,,
bash-3.00# /usr/local/bin/certutil -L -d . -n "server-cert"
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1001 (0x3e9)
Signature Algorithm: PKCS #1 MD5 With RSA Encryption
Issuer: CN=CAcert
Validity:
Not Before: Mon Dec 19 20:33:04 2005
Not After: Sat Mar 19 20:33:04 2016
Subject: CN=server-cert
Subject Public Key Info:
Public Key Algorithm: PKCS #1 RSA Encryption
RSA Public Key:
Modulus:
b7:07:1a:32:33:38:c9:22:53:30:13:07:15:a6:2e:74:
b3:c8:26:bd:84:1f:97:57:b6:3d:56:13:5c:90:a2:56:
ff:52:ce:4c:d3:54:c5:7a:ab:94:2e:fc:17:7c:18:69:
d1:df:e4:88:68:c6:aa:c2:14:21:a7:27:c7:4b:45:19:
89:c3:9f:8f:2b:22:69:b6:9e:3b:0b:84:b4:78:66:d7:
84:f5:17:f0:12:bc:56:d4:20:34:86:49:02:2a:9f:22:
9c:c2:3b:c2:48:5c:c1:df:7d:22:19:8f:3d:9b:c2:83:
1b:0f:f1:92:be:70:d2:95:15:cf:f0:0c:3e:74:78:4b
Exponent: 65537 (0x10001)
Fingerprint (MD5):
D4:1D:8C:D9:8F:00:B2:04:E9:80:09:98:EC:F8:42:7E
Fingerprint (SHA1):
DA:39:A3:EE:5E:6B:4B:0D:32:55:BF:EF:95:60:18:90:AF:D8:07:09
Signature Algorithm: PKCS #1 MD5 With RSA Encryption
Signature:
2c:5c:60:05:f0:97:30:9c:57:a3:87:69:75:26:71:b2:
e7:7d:c8:eb:36:35:bd:e6:9f:db:4d:0f:23:75:e0:bc:
76:4d:aa:ae:7f:9c:ac:e4:c0:35:7d:5f:22:4e:52:40:
fb:3f:bf:a8:8d:50:b3:00:9b:73:bf:2b:54:84:14:8a:
c1:00:52:95:e6:47:98:78:5d:cb:ff:76:50:cc:94:09:
53:13:b9:11:4e:eb:c8:1a:88:dd:42:76:dd:6c:32:7d:
1a:17:c1:a2:fd:03:e2:47:12:84:c3:72:da:b1:05:61:
3b:d6:26:99:1d:e6:b9:48:7a:ca:96:98:22:ce:bc:70
Certificate Trust Flags:
SSL Flags:
Valid Peer
Trusted
Email Flags:
Object Signing Flags:
Anybody have any ideas what I may be missing here?
Thanks again.
18 years, 4 months
[Fedora-directory-users] user password management
by Douglas Hussey
Has anyone used Password Management Servlet (PWM) v1.2.0 with Fedora
Directory Server? (It works with eDirectory)
Or could someone recommend either a servlet or web based tool that my
users could use (login) to change their passwords. I don't want to
write something if someone already has.
Thanks for the help
cheers
Doug
18 years, 4 months
[Fedora-directory-users] Admin Console
by Jim Summers
Hello List,
New to the list here and just beginning to evaluate the fedora-directory
server. I have been running Sun's iplanet DS5.1 for a couple of years
now and would like to migrate away from that platform.
Installed Sun Java 1.5.0.4
I installed the 1.0.1 binary and then ran setup.
Then when attempting to start the admin console, the blue Fedora
Directory Server / Please Login logo box is displayed. But the next
window where login info can be entered is never displayed. It hangs
until I go back a do a Ctrl-C.
Ideas or suggestions on what I may have overlooked?
TIA
--
Jim Summers
School of Computer Science-University of Oklahoma
-------------------------------------------------
18 years, 4 months
[Fedora-directory-users] Replication - consumer failed to replay change
by Kevin M. Myer
Hello,
I have three instances of FDS running - two are in a multimaster config
(directory1 and directory2), with all subtrees replicated and one is a
dedicated slave (garnet), with half a dozen subtrees replicated.
directory1 and directory2 are running FDS 7.1, garnet is running FDS
1.0.1.
Most of the writes go to directory1, and although I have not tested
writing to every subtree from directory1 -> directory2 and directory2
-> directory1, replication seems to be working fine for the most part.
However, I noticed yesterday morning the following entry:
[16/Dec/2005:09:06:16 -0500] NSMMReplicationPlugin - agmt="cn=IU13"
(directory2:636): Consumer failed to replay change (uniqueid
6a76611a-1dd211b2-8027b642-689d0000, CSN 43a2c9d8000000010000):
Operations error. Will retry later.
This is repeated every five minutes to the present time. Is there a
way to look at the changelog entries to see what modification caused
this problem? And if not, whats the best way to go about clearing up
the error?
Also, is FDS smart enough so that if you have a two-server multimaster
replication setup, and you use one master to initialize the other,
which has an existing replication setup with the master, that it won't
send the changes back? In other words, if I have directory1 and
directory2, and they are setup in multimaster, with replication
agreements in place for a subtree, and there's a problem in the subtree
on directory2, can I use directory1 to initialize directory2, or will
directory2 then turn around and try to initialize directory1?
Kevin
--
Kevin M. Myer
Senior Systems Administrator
Lancaster-Lebanon Intermediate Unit 13 http://www.iu13.org
18 years, 4 months
Re: [Fedora-directory-users] ShadowPassword / ShadowExpire
by Jim Summers
Jeff Medcalf wrote:
> Jim,
>
> I haven't tried this on FDS, but given that it has the same base as
> SunONE and the old iPlanet, I would assume it works the same as those
> directory servers. In that case, and assuming that you are using
> pam_ldap, go ahead and use the password policy: pam_ldap knows about it
> and works correctly with it.
I am a little confused on what is actually being used. I see the
following entries in machines here:
=========================================
Dec 19 09:34:22 XXXXXX sshd[14463]: PAM rejected by account
configuration[13]: User account has expired
Dec 19 09:36:21 XXXXXX sshd[14515]: nss_ldap: reconnecting to LDAP server...
Dec 19 09:36:21 XXXXXX sshd[14515]: nss_ldap: reconnected to LDAP server
after 1 attempt(s)
=========================================
So I am not sure as to whether pam_ldap or nss_ldap is in use. I guess
they could be one in the same?
and system-auth has:
======================================
auth required /lib/security/$ISA/pam_env.so
auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
auth sufficient /lib/security/$ISA/pam_ldap.so use_first_pass
auth required /lib/security/$ISA/pam_deny.so
======================================
So I would think it is pam_ldap.
I am going to double-check the pam config to make sure it is still
following recommendations.
>
> Oh, and if you are using the pam_ldap that comes with Solaris, you
> might try switching to the open source version: the Sun version is
> terribly buggy and horrible.
Will do. The majority are linux clients.
>
> On Dec 16, 2005, at 3:06 PM, Jim Summers wrote:
>
>> Hello List,
>>
>> Being in the midst of evaluating and hopefully migrating to FDS
>> soon. I have stumbled onto a odd problem.
>>
>> My user information is kept in the People container. We have been
>> using shadowExpire / shadowLastChange fields.
>>
>> This all seems to work except when a user's account is ready to
>> expire and is prompted to change their password. Using passwd, the
>> user can change the password, but the system continues to prompt for
>> a new password upon each successive login.
>>
>> Looking at the data, the shadowExpire / LastChange never get
>> updated. I am also not seeing any errors being generated in the
>> logs. I can manually update those fields and the problem goes away.
>> But I guess I thought passwd / nss_ldap / pam would update those
>> fields as needed.
>>
>> Looking in the docs, all I see is configuring a password policy. But
>> that seems to be directed at users actually connecting to the
>> directory via console / ldapsearch, etc....
>>
>> Initially I thought I was having some ACI issues but I am really not
>> sure. It could be that I need to drop the shadow stuff and configure
>> the password policy?
>>
>> Advice or suggestions on what I am missing or where I have gone wrong?
>>
>>
>> TIA
>> --
>> Jim Summers
>> School of Computer Science-University of Oklahoma
>> -------------------------------------------------
>>
>> --
>> Fedora-directory-users mailing list
>> Fedora-directory-users(a)redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>
> --
> Jeff Medcalf
> jeff(a)caerdroia.org
>
>
--
Jim Summers
School of Computer Science-University of Oklahoma
-------------------------------------------------
18 years, 4 months
[Fedora-directory-users] log files not cleaned up
by Gerhard de Jager
Hi.
We are running Fedora Directory server v. 7.1
It has about 24 million records in the directory, and runs fine for
about a week.
Then suddenly the log files written to <fedore-dir>/slapd/db/ are not
removed.
They start to build up, and are not deleted.
More log fiels aer added (example log.0000011701, log.0000011702 etc).
Does anybody know what can be done and if those files can be removed, or
is there a command that can be run to make fedora-ds process those
files?
Any help would be greatly appreciated.
Thank you,
Gerhard
This e-mail is sent on the Terms and Conditions that can be accessed by Clicking on this link http://www.vodacom.net/legal/email.aspx "
18 years, 4 months
[Fedora-directory-users] SSL: importing a cert and key - howto anywhere?
by Graham Leggett
Hi all,
I have got a basic fedora DS running, and I now need to switch on SSL. I
have found the SSL docs, which describe in some detail how to create a
CSR, etc etc.
The missing detail is how to import a certificate and key you already
have - the admin console seems quite happy to import certs, but it seems
to be oblivious to the importing of keys.
Anyone know what incantation you have to chant to get DS to import a key
or a p12 file?
Regards,
Graham
--
18 years, 4 months
[Fedora-directory-users] Changing IP of the admin server - is this possible?
by Graham Leggett
Hi all,
I have just gone through the setup process to install an instance of
Fedora DS. Nowhere in the setup process is SSL or TLS mentioned, at the
end of the config process I have an insecure LDAP server.
My next task is to try and switch on SSL/TLS for both the admin console,
and the LDAP server itself. I figure out how to add my certs to the
alias directory using certutil and pk12util.
My next task is to move the admin server port from my default 1390 to a
secure version at 1637. A recursive grep finds the port 1390 in a whole
host of config files. Changing the config files to 1637 causes me to end
up with a broken admin server to which startconsole cannot connect.
Just to clarify - is it worth me trying to fix the admin server port in
my config files, or is this too complicated to be worth while? Should I
just delete the fedora-ds installation and start again from scratch?
It seems one of the most basic things that need to be fixed in the
directory is to simplify the configuration. Some of the config is in
Windows INI format, some of the config is in XML, some of the config is
in name: value format, it's very difficult as a new user of the software
to be able to figure out what is going on.
Regards,
Graham
--
18 years, 4 months
[Fedora-directory-users] ShadowPassword / ShadowExpire
by Jim Summers
Hello List,
Being in the midst of evaluating and hopefully migrating to FDS soon. I
have stumbled onto a odd problem.
My user information is kept in the People container. We have been using
shadowExpire / shadowLastChange fields.
This all seems to work except when a user's account is ready to expire
and is prompted to change their password. Using passwd, the user can
change the password, but the system continues to prompt for a new
password upon each successive login.
Looking at the data, the shadowExpire / LastChange never get updated. I
am also not seeing any errors being generated in the logs. I can
manually update those fields and the problem goes away. But I guess I
thought passwd / nss_ldap / pam would update those fields as needed.
Looking in the docs, all I see is configuring a password policy. But
that seems to be directed at users actually connecting to the directory
via console / ldapsearch, etc....
Initially I thought I was having some ACI issues but I am really not
sure. It could be that I need to drop the shadow stuff and configure
the password policy?
Advice or suggestions on what I am missing or where I have gone wrong?
TIA
--
Jim Summers
School of Computer Science-University of Oklahoma
-------------------------------------------------
18 years, 4 months