[Fedora-directory-users] I cannot startconsole
by adirek sanyakhuan
after I setup fedora directory. I try startconsole
this is error
[root@ldp fedora-ds]# ./startconsole -u admin -a http://ldp.pccp.ac.th:1500/
Exception in thread "main" java.lang.UnsatisfiedLinkError:
/usr/java/j2re1.4.2_10/l ib/i386/libawt.so: libXp.so.6: cannot open
shared object file: No such file or dire ctory
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(Unknown Source)
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
at sun.security.action.LoadLibraryAction.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.awt.Toolkit.loadLibraries(Unknown Source)
at java.awt.Toolkit.<clinit>(Unknown Source)
at com.sun.java.swing.plaf.windows.WindowsLookAndFeel.initialize(Unknown
So urce)
at com.netscape.management.nmclf.SuiLookAndFeel.initialize(Unknown
Source)
at javax.swing.UIManager.setLookAndFeel(Unknown Source)
at com.netscape.management.client.console.Console.common_init(Unknown
Sourc e)
at com.netscape.management.client.console.Console.<init>(Unknown Source)
at com.netscape.management.client.console.Console.main(Unknown Source)
how I do?
Hope this helps.
18 years, 3 months
[Fedora-directory-users] weird error when querying directory server
by Bliss, Aaron
this works great from a redhat 4 box, however from my redhat 3 box I
receive the following error:
ldapsearch -x -ZZ '(uid =azb)'
ldap_start_tls: Connect error
additional info: Start TLS request accepted.Server willing to
negotiate SSL.
relevant entries of /etc/ldap.conf look like this:
pam_password md5
ssl start_tls
ssl on
tls_cacertfile /etc/openldap/cacerts/cacert.pem
tls_cacertdir /etc/openldap/cacerts/
client has read and execute to the ca certificate
relavent entries of /etc/openldap/ldap.conf
TLS_CACERTDIR /etc/openldap/cacerts
TLS_REQCERT allow
I'm just trying to verify that ssl logins are working from the redhat 3
box; secure logins from the redhat 4 box work fine. Thanks very much
for your help.
Aaron
www.preferredcare.org
"An Outstanding Member Experience," Preferred Care HMO Plans -- J. D. Power and Associates
Confidentiality Notice:
The information contained in this electronic message is intended for the exclusive use of the individual or entity named above and may contain privileged or confidential information. If the reader of this message is not the intended recipient or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that dissemination, distribution or copying of this information is prohibited. If you have received this communication in error, please notify the sender immediately by telephone and destroy the copies you received.
18 years, 3 months
[Fedora-directory-users] Debug Level 2 is not working
by Sam John
The debug level option -d2 is supposed to give packet level debug information. However, I am not getting any logs when I try to authenticate a client machine using LDAP server.
[root@server server]# ./ns-slapd -D /opt/fedora-ds/slapd-server -i /opt/fedora-ds/slapd-server/logs/pid -w /opt/fedora-ds/slapd-server/logs/startpid -d2
[17/Jan/2006:17:06:35 -0700] Fedora-Directory/1.0.1 - debug level: packets (2)
[17/Jan/2006:17:06:35 -0700] - Fedora-Directory/1.0.1 B2005.342.165 starting up
[17/Jan/2006:17:06:36 -0700] - slapd started. Listening on All Interfaces port 389 for LDAP requests
I dont get any logs after this, when a client machine tries to autheticate the LDAP server.
Any help would be greatly appreciated!!!
Thanks
Sam John
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
18 years, 3 months
RE: [Fedora-directory-users] weird error when querying directory server
by Bliss, Aaron
all set, not sure why, but changing line in /etc/openldap/ldap.conf to
TLS_CACERT /etc/openldap/cacerts/cacert.pem
took care of it; thanks again.
Aaron
________________________________
From: fedora-directory-users-bounces(a)redhat.com
[mailto:fedora-directory-users-bounces@redhat.com] On Behalf Of Bliss,
Aaron
Sent: Tuesday, January 17, 2006 7:47 PM
To: fedora-directory-users(a)redhat.com
Subject: [Fedora-directory-users] weird error when querying directory
server
this works great from a redhat 4 box, however from my redhat 3 box I
receive the following error:
ldapsearch -x -ZZ '(uid =azb)'
ldap_start_tls: Connect error
additional info: Start TLS request accepted.Server willing to
negotiate SSL.
relevant entries of /etc/ldap.conf look like this:
pam_password md5
ssl start_tls
ssl on
tls_cacertfile /etc/openldap/cacerts/cacert.pem
tls_cacertdir /etc/openldap/cacerts/
client has read and execute to the ca certificate
relavent entries of /etc/openldap/ldap.conf
TLS_CACERTDIR /etc/openldap/cacerts
TLS_REQCERT allow
I'm just trying to verify that ssl logins are working from the redhat 3
box; secure logins from the redhat 4 box work fine. Thanks very much
for your help.
Aaron
www.preferredcare.org
"An Outstanding Member Experience," Preferred Care HMO Plans -- J. D.
Power and Associates
Confidentiality Notice:
The information contained in this electronic message is intended for the
exclusive use of the individual or entity named above and may contain
privileged or confidential information. If the reader of this message
is not the intended recipient or the employee or agent responsible to
deliver it to the intended recipient, you are hereby notified that
dissemination, distribution or copying of this information is
prohibited. If you have received this communication in error, please
notify the sender immediately by telephone and destroy the copies you
received.
18 years, 3 months
[Fedora-directory-users] Nis Netgroups and access.conf not quite working as advertised.
by Michael Montgomery
I've been trying to setup and test using Nis Netgroups as a means of
access control, and have run into some difficulties. I have two client
systems (ldap01, ldap02) setup to authenticate against an ldap database.
Pam_Ldap and everything are setup and functioning as they should with
respect to allowing users queried from the ldap database to login. Here
are the relevant details.
(I'm using this, btw
http://directory.fedora.redhat.com/wiki/Howto:Netgroups )
[root@ldap02 security]# hostname
ldap02.inside.exampledomain.com
[root@ldap02 ~]# host ldap02.inside.exampledomain.com
ldap02.inside.theplanet.com has address 10.5.1.17
[root@ldap02 ~]# host 10.5.1.17
17.1.5.10.in-addr.arpa domain name pointer ldap02.inside.exampledomain.com
[root@ldap02 security]# getent netgroup unixisusers
unixisusers ( , mmontgomery, )
[root@ldap02 security]# getent netgroup unixissystems
unixissystems (ldap01, , inside.exampledomain.com) (ldap02, , inside.exampledomain.com)
[root@ldap02 security]# id mmontgomery
uid=1000(mmontgomery) gid=10000(UnixIS) groups=10000(UnixIS)
[root@ldap02 security]# tail access.conf | grep -v '#'
+ : root : LOCAL
+ : mmont : ALL
+ : @unixisusers@@unixissystems : ALL
- : ALL : ALL
[root@ldap02 pam.d]# cat system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
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
account required /lib/security/$ISA/pam_unix.so
account required /lib/security/$ISA/pam_access.so
account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet
account [default=bad success=ok user_unknown=ignore] /lib/security/$ISA/pam_ldap.so
account required /lib/security/$ISA/pam_permit.so
password requisite /lib/security/$ISA/pam_cracklib.so retry=3
password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow
password sufficient /lib/security/$ISA/pam_ldap.so use_authtok
password required /lib/security/$ISA/pam_deny.so
session required /lib/security/$ISA/pam_limits.so
session required /lib/security/$ISA/pam_unix.so
session required /lib/security/$ISA/pam_mkhomedir.so skel=/etc/skel umask=077
session optional /lib/security/$ISA/pam_ldap.so
When trying to login remotely, I get this:
/var/log/messages:
Jan 9 16:17:19 ldap02 pam_access[1552]: access denied for user `mmontgomery' from `202.10-5-1.inside.exampledomain.com'
Adding this to access.conf, makes it work though:
+ : @unixisusers : ALL
Does anyone have any ideas what I'm overlooking here?
Thanks
18 years, 3 months
[Fedora-directory-users] Winsync: UIDs
by Hartmut Wöhrle
Hallo everyone,
I have a question connected with Winsync from Windows NT.
When I do the replication (works fine now!) I recieve all Users and the uids
in capital letters. Now I want to change them into lower case.
ldapmodify refuses to change, and when I try to change it by the gui (not the
best way with about 2000 users.... but ok for a test :) , I get the message
"Unkown error with naming attribute" and in addition the entrydn and the uid
were changed, but the
dn: uid=....
is the same as before.
Also the gui shows the old name - even when refreshing.
So this seems to be a vital "non-changeable" value.
I thought to perform an ldapsearch writing out all avlues then edit the
entries by a script and with ldapdelete and ldapadd rewrite them in the
directory. But I think then the replication will not realize them as the same
users and create the entries once again - with capital letters.
Is there a possibility to have all uids in lower case when performing the
replication? Any switch that I forgot?
Cu
Hartmut
FDs Version 7 installed from RPM
--
===========================================
Hartmut Woehrle
EMail: hartmut.woehrle(a)mail.pcom.de
18 years, 3 months
[Fedora-directory-users] Re:Samba & Fedora Directory Server Integration
by Howard Chu
fedora-directory-users-request(a)redhat.com wrote:
> From: Mark McLoughlin <markmc(a)redhat.com>
> Subject: Re: [Fedora-directory-users] Samba & Fedora Directory Server
> Integration
>
> Yeah, it sucks.
>
> One of the main issues is that for SMB authentication each user's
> password needs to be stored in LM and NT formats in the sambaNTPassword
> and sambaLMPassword attributes. So, when the user set its password, some
> code needs to have access to the plaintext password and translate it
> into LM and NT format. The easiest way is to use smbpassword, but you
> could use your own code to set the password in all formats at once ....
> or, I'm sure you could right a fedora-ds plugin which would save the
> password in those formats whenever it is set.
>
> But it doesn't end there. Even just for SMB authentication, there are
> other attributes which smbpasswd manages and there's a lot of voodoo
> involved.
>
> To give you idea of the kind of stuff you need to do in order to not
> use smbpasswd, see the code below. I wish I could explain the code in
> detail, but I've forgotten a lot of the details.
>
Sure it's tedious, but it's not so bad. The OpenLDAP smbk5pwd module
that I wrote handles it easily enough, and I've written a SLAPI plugin
(written for SunONE, probably works fine on Fedora-DS but untested as
yet) that does pretty much the same.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
18 years, 3 months
[Fedora-directory-users] Howto Map the certificate's distinguished name to a distinguished name known by your directory
by Bliss, Aaron
I have replication working over ssl using simple authentication, however
I would like to have this working using certificate based
authentication. According to this doc
http://www.redhat.com/docs/manuals/dir-server/ag/7.1/ssl.html#1087158
under the section marked setting up certificate based authentication, it
is necessary to map the certificate's distinguished name to a
distinguished name known by your directory. This makes sense, as you
must be able to tell the server your connecting to how much access you
have to the destination directory. This corresponds to the error that I
get when attempting to initiate replication over a certificate based ssl
replication link "LDAP error: Invalid credentials. Error Code: 49" I
believe this will work when I'm able to map the certs dn to a dn in the
directory. Does anyone know how to do this, or can you point me to some
documentation? Thanks again for your help.
Aaron
www.preferredcare.org
"An Outstanding Member Experience," Preferred Care HMO Plans -- J. D. Power and Associates
Confidentiality Notice:
The information contained in this electronic message is intended for the exclusive use of the individual or entity named above and may contain privileged or confidential information. If the reader of this message is not the intended recipient or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that dissemination, distribution or copying of this information is prohibited. If you have received this communication in error, please notify the sender immediately by telephone and destroy the copies you received.
18 years, 3 months
RE: [Fedora-directory-users] RE: some questions on using ssl with fds
by Bliss, Aaron
I would say the machines are pretty locked down; I've ran the bastille
scripts against them, used CIS scoring tool to lock them down even more
and they are of course behind our dmz....Normal users would never get a
direct shell on the directory servers; the only other user that would
have shell access to the boxes would be our security administrator.
Aaron
-----Original Message-----
From: Richard Megginson [mailto:rmeggins@redhat.com]
Sent: Sunday, January 15, 2006 4:51 PM
To: General discussion list for the Fedora Directory server project.
Cc: Bliss, Aaron
Subject: Re: [Fedora-directory-users] RE: some questions on using ssl
with fds
Bliss, Aaron wrote:
>I'm happy to report that I got things working. As noted in my slapd
>log file,
>
>[15/Jan/2006:15:32:05 -0500] - Fedora-Directory/1.0.1 B2005.342.165
>starting up
>[15/Jan/2006:15:32:05 -0500] - slapd started. Listening on All
>Interfaces port
>389 for LDAP requests
>[15/Jan/2006:15:32:05 -0500] - Listening on All Interfaces port 636 for
>LDAPS re Quests
>
>After following document listed below under section labeled starting
>the directory server with ssl enabled, both servers are accepting
>requests on 389 and 636.
>
Excellent.
>I have a question though; how much of a security threat would it pose
>if I used a password file to start the directory server automatically?
>
>
That depends - how secure is your machine?
>Thanks very much to the fds developers, mailing list users and the
>designers of documentation.
>
>Aaron
>
>-----Original Message-----
>From: Bliss, Aaron
>Sent: Sunday, January 15, 2006 2:26 PM
>To: 'General discussion list for the Fedora Directory server project.'
>Subject: RE: some questions on using ssl with fds
>
>I believe that I'm very close to getting this to work for me. This is
>what I've done:
>
>1. created my own CA certificate by running this openssl req -new -x509
>-keyout private/cakey.pem -out cacert.pem
>
>2. using the gui, I followed the steps listed here
>http://www.redhat.com/docs/manuals/dir-server/ag/7.1/ssl.html#1085091
>under Obtaining and Installing server certificates, including the step
>4 marked Trust the certificate authority. Everything to this point
>looks great; on each directory server the server certificates look fine
>including verifying that my new CA is listed and verified under the CA
>certs tab.
>
>I believe at this point that each directory server will inherently
>trust each other's server certificate, as their own certificates were
>signed by my own CA. Is this true? If so, can someone tell me what
>the next step is to enable ssl replication between the 2 directory
>servers as well as secure client authentication? Thanks very much.
>
>Aaron
>
>
>-----Original Message-----
>From: Bliss, Aaron
>Sent: Friday, January 13, 2006 10:26 PM
>To: General discussion list for the Fedora Directory server project.
>Subject: some questions on using ssl with fds
>
>These are some basic questions that I'm sure you guys will know how to
>answer straight away. Please forgive my ignorance, as I'm still trying
>to understand how ssl works and how to get it to work in fds both for
>my directory servers and clients. First some background information.
>I have 2 directory servers and several client servers. My goal is to
>get the directory servers to replicate using an encrypted link (they
>are currently replicating great using standard ldap port. My second
>goal is to have the client servers authenticate to the directory
>servers using ssl. I currently do not have a CA in my organization,
>and would like to use self signed keys to achieve goals listed above.
>I'm trying to understand how this is supposed to work; I took a look at
>the howto
>www.redhat.com/docs/manuals/dir-sever/ag/7.1/ssl.html#1087158 and have
>just a few questions.
>
>Correct me if I'm wrong, but the way this will work is that I will
>first create a CA cert on directory server A (step 6), generate server
>certificate (step 7). Next step will be to export the CA cert and
>import into directory server B.
>
>1. When creating the server cert at step 6, what are the appropriate
>values for the -n and -s switches, assuming that my company is named
>company.org.
>
>2. When creating the server certificate at step 7, what are the
>appropriate vaules with the -n, -s and -c switches?
>
>3. What are the switches to use to export the CA certificate using the
>certutil as well as the appropriate switches to import this certificate
>on another server.
>
>4. Is it true that after importing the CA cert into directory server B
>and generating a server certificate on this server, the 2 directory
>servers will inherently trust each other as their server certificates
>were generated from the same CA certificate? If so, I believe that I
>will then be able to create a replication link between the 2 directory
>servers over a ssl link?
>
>5. How do I configure the client servers to use ldaps? Do I need to
>generate server certificates for each box? If so, where are these
>certificates stored on the client servers. Thanks very much for your
>help with this.
>
>Aaron
>
>www.preferredcare.org
>"An Outstanding Member Experience," Preferred Care HMO Plans -- J. D.
>Power and Associates
>
>Confidentiality Notice:
>The information contained in this electronic message is intended for
the exclusive use of the individual or entity named above and may
contain privileged or confidential information. If the reader of this
message is not the intended recipient or the employee or agent
responsible to deliver it to the intended recipient, you are hereby
notified that dissemination, distribution or copying of this information
is prohibited. If you have received this communication in error, please
notify the sender immediately by telephone and destroy the copies you
received.
>
>
>--
>Fedora-directory-users mailing list
>Fedora-directory-users(a)redhat.com
>https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>
www.preferredcare.org
"An Outstanding Member Experience," Preferred Care HMO Plans -- J. D. Power and Associates
Confidentiality Notice:
The information contained in this electronic message is intended for the exclusive use of the individual or entity named above and may contain privileged or confidential information. If the reader of this message is not the intended recipient or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that dissemination, distribution or copying of this information is prohibited. If you have received this communication in error, please notify the sender immediately by telephone and destroy the copies you received.
18 years, 3 months
[Fedora-directory-users] RE: some questions on using ssl with fds
by Bliss, Aaron
I'm happy to report that I got things working. As noted in my slapd log
file,
[15/Jan/2006:15:32:05 -0500] - Fedora-Directory/1.0.1 B2005.342.165
starting up
[15/Jan/2006:15:32:05 -0500] - slapd started. Listening on All
Interfaces port
389 for LDAP requests
[15/Jan/2006:15:32:05 -0500] - Listening on All Interfaces port 636 for
LDAPS re
Quests
After following document listed below under section labeled starting the
directory server with ssl enabled, both servers are accepting requests
on 389 and 636. I have a question though; how much of a security threat
would it pose if I used a password file to start the directory server
automatically?
Thanks very much to the fds developers, mailing list users and the
designers of documentation.
Aaron
-----Original Message-----
From: Bliss, Aaron
Sent: Sunday, January 15, 2006 2:26 PM
To: 'General discussion list for the Fedora Directory server project.'
Subject: RE: some questions on using ssl with fds
I believe that I'm very close to getting this to work for me. This is
what I've done:
1. created my own CA certificate by running this openssl req -new -x509
-keyout private/cakey.pem -out cacert.pem
2. using the gui, I followed the steps listed here
http://www.redhat.com/docs/manuals/dir-server/ag/7.1/ssl.html#1085091
under Obtaining and Installing server certificates, including the step 4
marked Trust the certificate authority. Everything to this point looks
great; on each directory server the server certificates look fine
including verifying that my new CA is listed and verified under the CA
certs tab.
I believe at this point that each directory server will inherently trust
each other's server certificate, as their own certificates were signed
by my own CA. Is this true? If so, can someone tell me what the next
step is to enable ssl replication between the 2 directory servers as
well as secure client authentication? Thanks very much.
Aaron
-----Original Message-----
From: Bliss, Aaron
Sent: Friday, January 13, 2006 10:26 PM
To: General discussion list for the Fedora Directory server project.
Subject: some questions on using ssl with fds
These are some basic questions that I'm sure you guys will know how to
answer straight away. Please forgive my ignorance, as I'm still trying
to understand how ssl works and how to get it to work in fds both for my
directory servers and clients. First some background information. I
have 2 directory servers and several client servers. My goal is to get
the directory servers to replicate using an encrypted link (they are
currently replicating great using standard ldap port. My second goal is
to have the client servers authenticate to the directory servers using
ssl. I currently do not have a CA in my organization, and would like to
use self signed keys to achieve goals listed above. I'm trying to
understand how this is supposed to work; I took a look at the howto
www.redhat.com/docs/manuals/dir-sever/ag/7.1/ssl.html#1087158 and have
just a few questions.
Correct me if I'm wrong, but the way this will work is that I will first
create a CA cert on directory server A (step 6), generate server
certificate (step 7). Next step will be to export the CA cert and
import into directory server B.
1. When creating the server cert at step 6, what are the appropriate
values for the -n and -s switches, assuming that my company is named
company.org.
2. When creating the server certificate at step 7, what are the
appropriate vaules with the -n, -s and -c switches?
3. What are the switches to use to export the CA certificate using the
certutil as well as the appropriate switches to import this certificate
on another server.
4. Is it true that after importing the CA cert into directory server B
and generating a server certificate on this server, the 2 directory
servers will inherently trust each other as their server certificates
were generated from the same CA certificate? If so, I believe that I
will then be able to create a replication link between the 2 directory
servers over a ssl link?
5. How do I configure the client servers to use ldaps? Do I need to
generate server certificates for each box? If so, where are these
certificates stored on the client servers. Thanks very much for your
help with this.
Aaron
www.preferredcare.org
"An Outstanding Member Experience," Preferred Care HMO Plans -- J. D. Power and Associates
Confidentiality Notice:
The information contained in this electronic message is intended for the exclusive use of the individual or entity named above and may contain privileged or confidential information. If the reader of this message is not the intended recipient or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that dissemination, distribution or copying of this information is prohibited. If you have received this communication in error, please notify the sender immediately by telephone and destroy the copies you received.
18 years, 3 months
