Re: [Fedora-directory-users] Certificate authentication with SASL External
by Yann
>>Remember that authentication is not the same as authorization - having the
valid certificate just proves who you are to the server; the server doesn't
have to accord you any privileges/authorization just because of that.
>>
>>Correct, but the OP _wanted_ to make an authorization decision for this
identity, not just perform authentication.
>>I think what he wants is to be able to use the subject DN in the client's cert
directly as the bind identity for access control purposes. This isn't
supported. >>Not because the original developers missed some grand X.500
vision, but because
>>nobody needed to do that (and haven't for 10 years, until now...).
Yes David, it's exactly what i want to do...
So, it's not supported in FD :-(
I tried to find another way to do that; ex: when i bind with a certificate with
no match entry in the LDAP directory, FDS say:
[10/Feb/2006:17:14:11 +0000] conn=510 SSL failed to map client certificate to
LDAP DN (No such object)
BUT, he's allow to view unprivilegied part of LDAP, because it's authenticated
by SASL before... like an anonymous account.
When he create an entry, the owner is "" (empty).. !?
So, is it possible to change this "default mapping" to something else to do what
i want to do ? :-)
Thanks !
Yann
18 years, 2 months
[Fedora-directory-users] FDS on Ubuntu / Debian
by Olivier Brugman
Hi Folks,
Thank you for this great software. It rocks!
After installation on FC 3 and X/OS 4, i wanted to install FDS on Ubuntu
and Debian GNU/Linux (Sarge), my platforms of preference.
FWIW, this is how it worked for me:
FDS-on-Ubuntu/Debian-howto
==========================
This document describes howto install the Fedora Directory Server (FDS)
on Ubuntu 5.10 (Breezy Badger) or Debian GNU/Linux Sarge. I presume you
already have done a minimal installation of the OS of choise.
Most steps to Ubuntu and Sarge are equal, however this howto is base on
the installation of the 'sudo' package. As an alternative you can 'su -'
on Debian and skip the sudo part of the commands.
1 Get the software
==================
Download a prebuild rpm from
http://directory.fedora.redhat.com/wiki/Download Choose the version
suitable for Fedora Core 3 and RHEL4. For Debian GNU/Linux Sarge the rpm
for RHEL3 is required (Ubuntu has libc6 version 2.3.5 while Sarge has
version 2.3.2).
2 Install alien-package
=======================
Alien is a tool that supports converting software in 'rpm' format to
'deb' format.
sudo apt-get install alien
3 Build the fedora-ds .deb package
==================================
sudo alien /YOURPATH/fedora-ds-1.0.1-1.RHEL4.i386.opt.rpm (Ubuntu)
sudo alien /YOURPATH/fedora-ds-1.0.1-1.RHEL3.i386.opt.rpm (Debian Sarge)
4 Build dependencies
====================
The Fedora Directory Server needs 'libtermcap.so.2', so install it.
sudo apt-get install termcap-compat
Install the Sun Java SDK or JRE version 1.4.2. Don't forget to set the
JAVA_HOME and PATH variables!
The admin-server of FDS depends on Apache2 compiled conform the worker
model, so let's install it
sudo apt-get install apache2-mpm-worker
As Fedora calls the daemon 'httpd' while Ubuntu calls it 'apache2' (like
Debian), we want to create a symbolic link to satisfy FDS' setup
utility.
sudo ln -s /usr/sbin/apache2 /usr/sbin/httpd
5 Install .deb package
======================
sudo dpkg -i /YOURPATH/fedora-ds_1.0.1-2_i386.deb
6 Create a user and group for the daemon
========================================
sudo groupadd fds
sudo useradd -s /bin/false -g fds fds
7 Run the setup program
=======================
Now we want to configure the FDS. As the setup utility won't find the
Apache2 modules on Debian/Ubuntu by default, we'll have to help it.
First we'll create an install.inf file by running the setup utility with
the '-k' option.
sudo /opt/fedora-ds/setup/setup -k
Choose '1' for as minimal questions as possible.
Choose 'fds' when asked which user and group apply.
After finalizing the setup wizard the directory server itself will be
started as user 'fds'. It listens on the port you just configured (i
chose port '389', the default LDAP-port).
When done, copy the install.inf file to /opt
sudo cp /opt/fedora-ds/setup/install.inf /opt
sudo chmod 640 /opt/install.inf
Then add this rule to the [admin] section of the file:
ApacheRoot= /usr/lib/apache2
Afterwards rerun the setup utility with the following options:
sudo /opt/fedora-ds/setup/setup -s -f /opt/install.inf
8 Adjust the admin-server's httpd.conf
======================================
We have to make some changes to the
'/opt/fedora-ds/admin-serv/config/httpd.conf' file.
Some modules do not have to be loaded as they are compiled in
statically. So outcomment these lines:
...
#LoadModule access_module /usr/lib/apache2/modules/mod_access.so
#LoadModule auth_module /usr/lib/apache2/modules/mod_auth.so
#LoadModule log_config_module /usr/lib/apache2/modules/mod_log_config.so
#LoadModule env_module /usr/lib/apache2/modules/mod_env.so
...
#LoadModule setenvif_module /usr/lib/apache2/modules/mod_setenvif.so
#LoadModule mime_module /usr/lib/apache2/modules/mod_mime.so
...
#LoadModule
negotiation_module /usr/lib/apache2/modules/mod_negotiation.so
#LoadModule dir_module /usr/lib/apache2/modules/mod_dir.so
...
#LoadModule alias_module /usr/lib/apache2/modules/mod_alias.so
...
9 Now try to start the admin-server
===================================
sudo /opt/fedora-ds/start-admin
If it works, Good :-)
If not, you probably didn't have enough coffee!
Cheers,
Olivier Brugman
18 years, 2 months
Re: [Fedora-directory-users] Restore a backup in a multimaster replication topology
by Mike Jackson
>If someone delete data by doing a wrong operation, and this deleting is
>replicated in all the replicas, I want to restore the lost data from a
>backup, and I want the entries to have the same nsuniqueid than before. Of
>course, I want this import to be replicated to all the replicas. If
>possible, I want to be able to restore a subtree of the directory, and not
>the whole.
The way I handle this in a multi-master setup is:
1. Restore machine 1 from backup
2. Re-initialize machines 2-4 from machine 1
I have written a perl script (and a module) which completely handles an
MMR restore job over-the-wire. Restoring a 4-way MMR setup with 10k
entries takes less than 5 minutes.
I am the process of trying to open-source this tool (among others), but
it may take a long time or may not happen at all. You can find out how
to write it yourself by driving the operations with the admin console
and sniffing the traffic with ethereal.
Only suffixes can be restored from backup. If you have built your
subtrees as suffixes, then you can restore at the subtree level.
BR,
Mike
18 years, 2 months
[Fedora-directory-users] Restore a backup in a multimaster replication topology
by François Beretti
Hi,
If someone delete data by doing a wrong operation, and this deleting is
replicated in all the replicas, I want to restore the lost data from a
backup, and I want the entries to have the same nsuniqueid than before. Of
course, I want this import to be replicated to all the replicas. If
possible, I want to be able to restore a subtree of the directory, and not
the whole.
Is it possible ?
Thank you very much
François
18 years, 2 months
[Fedora-directory-users] Search w/ empty base dn
by Glenn W. Bach
I'm replacing an ldap server with Fedora Directory. The old one allows
searches with the base dn empty. Is there a way to allow searches with a
blank base dn in Fedora Directory?
18 years, 2 months
[Fedora-directory-users] problem with solaris 9 install
by basile
hi
i have fds install on sunfire v440 with solaris9
fds works fine , but when i want to use fds as users database i have a
problem :
i use pam.conf , nsswitch.conf , ldap_client_file(cred) of another
solaris9 install which works fine
when i use this fds as users database for my other solaris 9 ( the one
where all works ) all works fine
it seems not to use the ldap_client_cred to bind to the directory
( all patchs are present , schema are the same on the two
installation , i have same data
in the directory ldaplist works )
i have no idea ( i thinks pam don t use well ldapclient )
here are logs when i try id user
[09/Feb/2006:12:40:14 +0100] conn=107 fd=68 slot=68 connection from
xxx.xxx.xxx.xxx to xxx.xxx.xxx.xxx
[09/Feb/2006:12:40:14 +0100] conn=107 op=0 SRCH base="" scope=0
filter="(objectClass=*)" attrs="supportedControl supportedSASLMechanisms"
[09/Feb/2006:12:40:14 +0100] conn=107 op=0 RESULT err=0 tag=101
nentries=1 etime=0
[09/Feb/2006:12:40:14 +0100] conn=107 op=1 UNBIND
[09/Feb/2006:12:40:14 +0100] conn=107 op=1 fd=68 closed - U1
thanks
basile
18 years, 2 months
Re: [Fedora-directory-users] DS Console from a remote machine?
by Dominik Bay
Sorry raj for mailling this directly to you
Am 08.02.2006 um 18:38 schrieb Rajkumar S:
> Dominik Bay wrote:
>> Copy starconsole and java into one directory on your Workstation,
>> set JAVA_HOME properly to the directory where the java binary and
>> the libs are located. Then simply do a ./startconsole -a http....
>
> Thanks for the tip Dominik. It worked!
Nice to hear :-)
And for all the Mac OSX Users here:
export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/
1.5.0/
cd ~/fedora-ds
./startconsole -u admin -a http://127.0.0.1:2341/
do the job :-)
Just fyi. JAVA_HOME=/usr/bin doesn't work, /usr/bin/java is a script.
And here is a diff for the startconsole script:
liliana:~/fedora-ds eimann$ diff -u startconsole.orig startconsole.new
--- startconsole.orig 2006-02-08 18:50:54.000000000 +0100
+++ startconsole.new 2006-02-08 18:51:44.000000000 +0100
@@ -31,7 +31,7 @@
#
# Make sure java exists and is executable
#
-if [ ! -f $JAVA_HOME/bin/java -a ! -x $JAVA_HOME/bin/java ]
+if [ ! -f $JAVA_HOME/Home/bin/java -a ! -x $JAVA_HOME/Home/bin/java ]
then
echo "$0: The java program is not in your path, or is not
executable."
exit 1
@@ -40,8 +40,8 @@
#
# See if libjava and libjvm exist, and set the lib path. These are
linked to by JSS.
#
-LIBJAVA_DIR=`find $JAVA_HOME -name libjava\.s[ol] | sed 's/\/libjava
\.s.$//'`
-LIBJVM_DIR=`find $JAVA_HOME -name libjvm\.s[ol] | sed 's/\/libjvm\.s.
$//'`
+LIBJAVA_DIR=`find $JAVA_HOME -name libjava.jnilib`
+LIBJVM_DIR=`find $JAVA_HOME -name libjvm.dylib`
if [ -z "$LIBJAVA_DIR" -a -z "$LIBJVM_DIR" ]
then
@@ -69,4 +69,4 @@
#
# Launch the Console
#
-cd java; $JAVA_HOME/bin/java -ms8m -mx64m -cp .:./base.jar:./
mcc10_en.jar:./jss3.jar:./ldapjdk.jar:./mcc10.jar:./nmclf10_en.jar:./
nmclf10.jar -Djava.library.path=../lib -Djava.util.prefs.systemRoot=.
-Djava.util.prefs.userRoot=.
com.netscape.management.client.console.Console $*
+cd java; $JAVA_HOME/Home/bin/java -ms8m -mx64m -cp .:./base.jar:./
mcc10_en.jar:./jss3.jar:./ldapjdk.jar:./mcc10.jar:./nmclf10_en.jar:./
nmclf10.jar -Djava.library.path=../lib -Djava.util.prefs.systemRoot=.
-Djava.util.prefs.userRoot=.
com.netscape.management.client.console.Console $*
It's just quick and dirty, so please don't blame me ;-)
--
Mit freundlichen Grüßen / Kind regards
Dominik Bay
Cablesurf Technik
18 years, 2 months
RE: [Fedora-directory-users] Account lockout counters not replicating; how to unlock users?
by Bliss, Aaron
Hmm; thanks very much for your help; so what are my options? Changing
from supplier/consumer to multi-master? Does the global password issue
still exist in a multi-master environment? Are there any concerns with
this? Or is the global password issue with supplier/consumer
replication something that is or can be addressed? Thanks.
Aaron
-----Original Message-----
From: fedora-directory-users-bounces(a)redhat.com
[mailto:fedora-directory-users-bounces@redhat.com] On Behalf Of Richard
Megginson
Sent: Tuesday, February 07, 2006 10:10 PM
To: Ulf Weltman
Cc: General discussion list for the Fedora Directory server project.
Subject: Re: [Fedora-directory-users] Account lockout counters not
replicating;how to unlock users?
Ulf Weltman wrote:
> Richard Megginson wrote:
>
>> Bliss, Aaron wrote:
>>
>>> Ulf, Thanks for getting back to me; yep, I understand that the
>>> consumer can never replicate information to the supplier (I wasn't
>>> very clear before, sorry about that); I set the
>>> passwordIsGlobalPolicy to on on both servers, and things are looking
>>> better; the passwordRetryCount, retryCountResetTime,
>>> accountUnlockTime attributes are now getting replicated properly
>>> from supplier to consumer, and deleting passwordRetryCount,
>>> retryCountResetTime attributes from the supplier does unlock
>>> accounts, however I'm still having a bit of a problem; what I've
>>> seen is that if a users account gets locked on the consumer because
>>> of bad password attempts, if that same user then attempts to login
>>> to a server that is configured to first attempt to bind to the
>>> supplier server, the user is allowed to login; What I see happening
>>> is that the passwordRetryCount, retryCountResetTime,
>>> accountUnlockTime attributes are set on the consumer properly,
>>> however these attributes are never set if the bad password attempts
>>> occur from a server that attempts to bind to the consumer first.
>>> Any ideas? Thanks again.
>>>
>>>
>> Yes, this is a limitation of password policy. What you really want
>> is for the consumer to pass the BIND request back to a master and
>> have all of the password policy attributes computed on the master to
>> be replicated to all other servers. Ulf, were you ever able to get
>> Chain On Update to work in this configuration?
>> http://directory.fedora.redhat.com/wiki/Howto:ChainOnUpdate
>
>
> I think using the passthrough plugin to pass the bind back to a
> central point was the only solution I came up with but it needs a
> patch, it doesn't like getting controls back (Bugzilla #176302).
>
> For ChainOnUpdate I didn't see a way to get it to work for this case.
> The internal update that adds the PWP state didn't seem to get
> chained, only updates coming from external clients.
Oh, that's right. We need to chain the bind requests.
So the answer to the original question is - no - you cannot have global
password policy yet.
>
>>
>>> Aaron
>>>
>>> -----Original Message-----
>>> From: fedora-directory-users-bounces(a)redhat.com
>>> [mailto:fedora-directory-users-bounces@redhat.com] On Behalf Of Ulf
>>> Weltman
>>> Sent: Tuesday, February 07, 2006 6:19 PM
>>> To: General discussion list for the Fedora Directory server project.
>>> Subject: Re: [Fedora-directory-users] Account lockout counters not
>>> replicating;how to unlock users?
>>>
>>> Hello Aaron. Two separate things:
>>> I may have misunderstood your configuration, but nothing is
>>> replicated from a consumer to a master unless the consumer is
>>> actually configured as a hub with an agreement back to the supplier.
>>> You can use passthrough authentication trickery to cause binds to be
>>> performed at the master if you don't want bi-directional
replication.
>>>
>>> Also, those three attributes (passwordRetryCount,
>>> retryCountResetTime,
>>> accountUnlockTime) are special and will not replicate in any case
>>> unless you set passwordIsGlobalPolicy to on in cn=config.
>>>
>>> Ulf
>>>
>>> Bliss, Aaron wrote:
>>>
>>>
>>>
>>>> P.S. Normal replication is happening, as well as typical referrals
>>>> from
>>>>
>>>
>>>
>>>
>>>
>>>
>>>> consumer to supplier (i.e. password changes). Any help with this
>>>> will be much appreciated, as this is a rather huge problem right
>>>> now. Thanks again.
>>>>
>>>> Aaron
>>>>
>>>> -----Original Message-----
>>>> From: fedora-directory-users-bounces(a)redhat.com
>>>> [mailto:fedora-directory-users-bounces@redhat.com] On Behalf Of
>>>> Bliss, Aaron
>>>> Sent: Tuesday, February 07, 2006 5:11 PM
>>>> To: General discussion list for the Fedora Directory server
project.
>>>> Subject: [Fedora-directory-users] Account lockout counters not
>>>> replicating;how to unlock users?
>>>>
>>>> Here's my setup; 2 directory servers, 1 supplier, 1 consumer; I'm
>>>> not sure why, but for some reason I'm not seeing password retry
>>>> counters being replicated from the consumer to the supplier; here
>>>> is what I've seen (I have fds setup to lock accounts after 5 bad
>>>> password attempts, reset failure count after 15 minutes):
>>>> -if a user types their password incorrectly on a server that binds
>>>> first to a consumer, then their password retry count increments
>>>> only on
>>>>
>>>
>>>
>>>
>>>
>>>
>>>> the consumer -if a user successfully binds to the server, then
>>>> their password retry count does get reset This is a problem for a
>>>> couple of reasons. If an account becomes locked out because of bad
>>>> password attempts, I've tried deleting the attributes of
>>>> passwordRetryCount and accountUnlockTime
>>>> (http://directory.fedora.redhat.com/wiki/Howto:PasswordReset) from
>>>> the supplier, however for some reason this is not replicated to the
>>>> consumer (is this an indication of a different problem?) this is a
>>>> problem as I have some of my linux servers to look to the supplier
>>>> first for authentication, and then the consumer second, and visa
>>>> versa for load balancing. According to fds documentation, account
>>>> lockout counters may not work as expected in a multi master
>>>> environment
>>>> http://www.redhat.com/docs/manuals/dir-server/ag/7.1/password.html#
>>>> 1086
>>>>
>>>> 4
>>>> 46 ; this is one of the reasons that I opted for a single master
>>>> environment; please advise and thanks. Given the issues that I'm
>>>> having, what is the best way to unlock accounts that have been
>>>> locked due to bad password attempts?
>>>>
>>>> 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
>>>>
>>>>
>>>> --
>>>> Fedora-directory-users mailing list
>>>> Fedora-directory-users(a)redhat.com
>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> --
>>> 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.
>>>
>>>
>>> --
>>> Fedora-directory-users mailing list
>>> Fedora-directory-users(a)redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>
>>>
>
>
18 years, 2 months
[Fedora-directory-users] DS Console from a remote machine?
by Rajkumar S
Hi,
I have installed fedora-ds in a remote machine in datacenter. The server does not have X
installed, nor it is possible to access it from my place. So is it possible to get the
Console running from my desktop (Debian Linux) PC ? What Steps are needed to get that
working ?
raj
18 years, 2 months
RE: [Fedora-directory-users] Account lockout counters not replicating; how to unlock users?
by Bliss, Aaron
Ulf, Thanks for getting back to me; yep, I understand that the consumer
can never replicate information to the supplier (I wasn't very clear
before, sorry about that); I set the passwordIsGlobalPolicy to on on
both servers, and things are looking better; the passwordRetryCount,
retryCountResetTime, accountUnlockTime attributes are now getting
replicated properly from supplier to consumer, and deleting
passwordRetryCount, retryCountResetTime attributes from the supplier
does unlock accounts, however I'm still having a bit of a problem; what
I've seen is that if a users account gets locked on the consumer because
of bad password attempts, if that same user then attempts to login to a
server that is configured to first attempt to bind to the supplier
server, the user is allowed to login; What I see happening is that the
passwordRetryCount, retryCountResetTime, accountUnlockTime attributes
are set on the consumer properly, however these attributes are never set
if the bad password attempts occur from a server that attempts to bind
to the consumer first. Any ideas? Thanks again.
Aaron
-----Original Message-----
From: fedora-directory-users-bounces(a)redhat.com
[mailto:fedora-directory-users-bounces@redhat.com] On Behalf Of Ulf
Weltman
Sent: Tuesday, February 07, 2006 6:19 PM
To: General discussion list for the Fedora Directory server project.
Subject: Re: [Fedora-directory-users] Account lockout counters not
replicating;how to unlock users?
Hello Aaron. Two separate things:
I may have misunderstood your configuration, but nothing is replicated
from a consumer to a master unless the consumer is actually configured
as a hub with an agreement back to the supplier. You can use
passthrough authentication trickery to cause binds to be performed at
the master if you don't want bi-directional replication.
Also, those three attributes (passwordRetryCount, retryCountResetTime,
accountUnlockTime) are special and will not replicate in any case unless
you set passwordIsGlobalPolicy to on in cn=config.
Ulf
Bliss, Aaron wrote:
>P.S. Normal replication is happening, as well as typical referrals from
>consumer to supplier (i.e. password changes). Any help with this will
>be much appreciated, as this is a rather huge problem right now.
>Thanks again.
>
>Aaron
>
>-----Original Message-----
>From: fedora-directory-users-bounces(a)redhat.com
>[mailto:fedora-directory-users-bounces@redhat.com] On Behalf Of Bliss,
>Aaron
>Sent: Tuesday, February 07, 2006 5:11 PM
>To: General discussion list for the Fedora Directory server project.
>Subject: [Fedora-directory-users] Account lockout counters not
>replicating;how to unlock users?
>
>Here's my setup; 2 directory servers, 1 supplier, 1 consumer; I'm not
>sure why, but for some reason I'm not seeing password retry counters
>being replicated from the consumer to the supplier; here is what I've
>seen (I have fds setup to lock accounts after 5 bad password attempts,
>reset failure count after 15 minutes):
>-if a user types their password incorrectly on a server that binds
>first to a consumer, then their password retry count increments only on
>the consumer -if a user successfully binds to the server, then their
>password retry count does get reset This is a problem for a couple of
>reasons. If an account becomes locked out because of bad password
>attempts, I've tried deleting the attributes of passwordRetryCount and
>accountUnlockTime
>(http://directory.fedora.redhat.com/wiki/Howto:PasswordReset) from the
>supplier, however for some reason this is not replicated to the
>consumer (is this an indication of a different problem?) this is a
>problem as I have some of my linux servers to look to the supplier
>first for authentication, and then the consumer second, and visa versa
>for load balancing. According to fds documentation, account lockout
>counters may not work as expected in a multi master environment
>http://www.redhat.com/docs/manuals/dir-server/ag/7.1/password.html#1086
>4
>46 ; this is one of the reasons that I opted for a single master
>environment; please advise and thanks. Given the issues that I'm
>having, what is the best way to unlock accounts that have been locked
>due to bad password attempts?
>
>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
>
>
>--
>Fedora-directory-users mailing list
>Fedora-directory-users(a)redhat.com
>https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>
>
--
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, 2 months
