Mailing-List: contact users-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@directory.apache.org
From: Mike Davis <mdavis@rez1.com>
To: <users@directory.apache.org>
References: <CACmQDJy=2Xq-G7m9oU_eEDqZyKH=oOrRFxh++QLObbGtJ+5X8g@mail.gmail.com> <017c01d30fa6$b12a17f0$137e47d0$@rez1.com> <CACmQDJwpK0TvWYarWhX=rSK4zsq40K8FQwBLr-ZK=aid1KuvyQ@mail.gmail.com> <01a201d30fb7$f1789640$d469c2c0$@rez1.com> <CACmQDJyoEbBrMiW_+xt8sdeANLE3uzhrD6wmKHima55BVyRrTA@mail.gmail.com> <7fb50dd4-151e-8d5e-6f86-b390c897f063@gmail.com> <01dd01d30fc4$447b1500$cd713f00$@rez1.com> <CACmQDJwbnjMLG8HVu8pezrZFg-QNr3fQO66T8+57VS8buVGq7A@mail.gmail.com> <020d01d31050$ec6dc000$c5494000$@rez1.com> <CACmQDJx30ur=F6+3Qir8=wySgWS-sT2i_mcmdoWpn_2NCEX67w@mail.gmail.com>
In-Reply-To: <CACmQDJx30ur=F6+3Qir8=wySgWS-sT2i_mcmdoWpn_2NCEX67w@mail.gmail.com>
Subject: RE: [ApacheDS] Password Policy not being enforced
Thread-Topic: [ApacheDS] Password Policy not being enforced
Date: Tue, 8 Aug 2017 11:53:04 -0400 (EDT)
Message-ID: <024801d3105e$6aecf240$40c6d6c0$@rez1.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Language: en-us
Thread-Index: AQIbzQyVy7bfUPKWHN18zs+XM2xomwHkVvjAAmAkCCEBqb6XXAKWzphKAdzh70kBrnk1ZgJS2GYBAceXQ+wCnMQYf6FS5RdQ
Content-Transfer-Encoding: quoted-printable
archived-at: Tue, 08 Aug 2017 15:53:13 -0000

Hey, shot in the dark here, but I think it's this value in your password=20
policy configuration.

ads-pwdcheckquality: 1

On my system, I have that set to 2. I believe 1 means relaxed, and if you=
=20
send an already hashed password, it can't unhash it to validate it, and j=
ust=20
assumes it's valid.

See the "Password checks and strength enforcement" section here:=20
http://directory.apache.org/apacheds/advanced-ug/4.3-password-policy.html


-----Original Message-----
From: Sambedi Fahted [mailto:sfahted@gmail.com]
Sent: Tuesday, August 08, 2017 11:17 AM
To: users@directory.apache.org
Subject: Re: [ApacheDS] Password Policy not being enforced

Hey, Mike.
That's correct. MinAge *is* being enforced, but minLength is *not*.

After changing the password on my Ubuntu machine (test ldap client), logg=
ed=20
in as "testuser", the modifiersName shows up as: "0.9.2342.19200300.100.1=
.1=3D=20
manager,2.5.4.11=3Dsystem".

Funny, the min/maxAge gets enforced for uid=3Dmanager,ou=3Dsystem, as wel=
l. So=20
it started to fail as the binddn, and logins to the linux machine stopped=
=20
working. :-p


On Tue, Aug 8, 2017 at 10:16 AM, Mike Davis <mdavis@rez1.com> wrote:

> Sam,
>
> Just to be clear, you're saying minAge IS being enforced, but
> minLength is NOT?
>
> Who shows up as modifiersName on the record after you change the passwo=
rd?
>
> // Mike
>
> -----Original Message-----
> From: Sambedi Fahted [mailto:sfahted@gmail.com]
> Sent: Tuesday, August 08, 2017 1:21 AM
> To: users@directory.apache.org
> Subject: Re: [ApacheDS] Password Policy not being enforced
>
> Hi, Mike & Emmanuel.
> Sorry, in advance, for the long message.
>
> So.. I'm not out of the woods yet, for some reason.
>
> I created the precriptiveACL:
> {
>     identificationTag "enablEditForManager",
>     precedence 15,
>     authenticationLevel simple,
>     itemOrUserFirst userFirst:
>     {
>         userClasses
>         {
>             name { "uid=3Dmanager,ou=3Dsystem" }
>         }
>         ,
>         userPermissions
>         {
>             {
>                 protectedItems { allUserAttributeTypesAndValues },
>                 grantsAndDenials
>                 {
>                     grantModify,
>                     grantRename,
>                     grantRead,
>                     grantCompare,
>                     grantReturnDN,
>                     grantAdd,
>                     grantBrowse,
>                     grantFilterMatch,
>                     grantRemove
>                 }
>             }
>             ,
>             {
>                 protectedItems { entry },
>                 grantsAndDenials
>                 {
>                     grantModify,
>                     grantRename,
>                     grantRead,
>                     grantCompare,
>                     grantReturnDN,
>                     grantAdd,
>                     grantBrowse,
>                     grantFilterMatch,
>                     grantRemove
>                 }
>             }
>         }
>     }
> }
>
> I changed my /etc/ldap.conf to use the uid=3Dmanager,ou=3Dsystem as bin=
ddn
> and I'm able to change passwords, but it's still not enforcing the
> minlength policy.
>
> Here's what the testuser ldif looks like now. As you can see the
> modifier's name now reflects the manager user:
>
> dn: cn=3Dtestuser,ou=3Dusers,dc=3Dredact,dc=3Dcloud,dc=3Dmyorg,dc=3Dcom
> objectClass: organizationalPerson
> objectClass: person
> objectClass: inetOrgPerson
> objectClass: top
> objectClass: posixAccount
> cn: testuser
> gidNumber: 500
> homeDirectory: /home/users/testuser
> sn: USer
> uid: testuser
> uidNumber: 1049
> givenName: Test
> loginShell: /bin/bash
> mail: test@myorg.com
> userPassword::
> e2NyeXB0fSQxJEk0clhTODB4JHRQSWVDOVRaQ1BuUElVb1FRbkh6QzE=3D
> accessControlSubentries: 2.5.4.3=3Denableeditforself,0.9.
> 2342.19200300.100.1.2
>
> 5=3Dredact,0.9.2342.19200300.100.1.25=3Dcloud,0.9.2342.19200300.100.1.2=
5=3Dm
> yorg,0
> .9.2342.19200300.100.1.25=3DcomaccessControlSubentries:
> 2.5.4.3=3Denableeditformanager,0.9.2342.19200300.100.
> 1.25=3Dredact,0.9.2342.19200300.100.1.25=3Dcloud,0.9.2342.19200300.100.=
1.2
> 5=3Dfulcr
> m,0.9.2342.19200300.100.1.25=3DcomaccessControlSubentries:
> 2.5.4.3=3Denableadminformanager,0.9.2342.19200300.100
> .1.25=3Dredact,0.9.2342.19200300.100.1.25=3Dcloud,0.9.2342.19200300.100=
.1.
> 25=3Dfulc
> rm,0.9.2342.19200300.100.1.25=3DcomcreateTimestamp:
> 20170802133738.851ZcreatorsName:=20
> 0.9.2342.19200300.100.1.1=3Dadmin,2.5.4.11=3DsystementryCSN:
> 20170808045939.984000Z#000000#001#000000entryDN:
> cn=3Dtestuser,ou=3Dusers,dc=3Dredact,dc=3Dcloud,dc=3Dmyorg,dc=3Dcomentr=
yParentId:
> b97b014f-2c00-4266-b578-1aa21053c437entryUUID::
> YmFmNDI4YjQtYzMyYy00NGM0LThkNTUtNDM2OGZkMjU1N2I3*-* modifiersName:
> 0.9.2342.19200300.100.1.1=3Dmanager,2.5.4.11=3Dsystem *-*modifyTimestam=
p:
> 20170808045939.335ZnbChildren: 0nbSubordinates: 0pwdChangedTime:
> 20170808045939.331ZpwdHistory:: MjAxNzA4MDgwMzU3MDguODU5WiMxLj
> MuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4 0MCM1NiNlMk55ZVhCMGZTUXhKRmxIZ
> FM1TU5uYzJKRWxoZVhOS1QyODFZMjB4ZGxGemJUUlhXa0 00ZWpFPQ=3D=3DpwdHistory:=
:
> MjAxNzA4MDgwNDUyNTguNDA5WiMxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4
> 0MCM2NCNlMU5UU0VGOVNqWTRkMnBKVWxSNGJTOVVlREZTYzBabWRUSnRibVZ3UTBsa1dXa
> HBXRm
> hJYlcxRlZVRTlQUT09pwdHistory:: MjAxNzA4MDgwNDUzMjMuNTA4WiMxLj
> MuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4 0MCM1NiNlMk55ZVhCMGZTUXhKRWhxY
> zJGdFVqWXdKR0pDU0ZaNGFYRTNWbk5oYTNkb1ZEQk5hVE 5ETURFPQ=3D=3DpwdHistory:=
:
> MjAxNzA4MDgwNDUzNDIuMDA5WiMxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4
> 0MCM4I01USXpORFUypwdHistory:: MjAxNzA4MDgwNDUzNTcuNzM1WiMxLj
> MuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4 0MCM1NiNlMk55ZVhCMGZTUXhKR295U
> 1RKNGJHVnhKRzFaZVZOemIySnhkMWxFU2tGYVQwaGlhMk ZvVlM4PQ=3D=3DpwdHistory:=
:
> MjAxNzA4MDgwNDU5MzkuMzMxWiMxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4
> 0MCM1NiNlMk55ZVhCMGZTUXhKRWswY2xoVE9EQjRKSFJRU1dWRE9WUmFRMUJ1VUVsVmIxR
> lJia2
> g2UXpFPQ=3D=3DsubschemaSubentry: cn=3DschemaI experimented and
> modified/cnfigured the precriptiveACL for a test manageruser I'd
> created within the directory
> structure,cn=3Dmanager,dc=3Dredact,dc=3Dcloud,dc=3Dmyorg,dc=3Dcom and I=
 had the
> same result:minlength and complexity not being enforced. The one thing
> it does enforceis the pwdminage, I get this:userPassword: 0x7B 0x63
> 0x72 0x79
> 0x70 0x74 0x7D 0x24 0x31 0x24 0x79 0x780x43 0x73 0x51
> 0x64...org.apache.directory.api.ldap.model.message.ModifyReq
> uestImpl@ed3df1c2:password is too young to updatepasswd: Permission
> deniedpasswd: password unchanged.Which is great, but it doesn't solve
> my problem.Any further thoughts?I appreciate the help.Cheers-SamOn
> Mon, Aug 7,
> 2017 at 5:29 PM, Mike Davis <mdavis@rez1.com> wrote:> Glad to be of
> help.>> -----Original Message-----> From: Emmanuel L=C3=A9charny [mailt=
o:
> elecharny@gmail.com]> Sent: Monday, August 07, 2017 5:22 PM> To:
> users@directory.apache.org> Subject: Re: [ApacheDS] Password Policy
> not being enforced>> Many thanks Mike for having replied to this
> question, it
> totally> slipped under my view :/>>> And yes, I conform that the admin
> totally> user
> will bypass any passwordPolicy> controls, simply because this is the
> only user able to rectify a bad> passwordPolicy configuration (well,
> there are workarounds, but not on> a running server).>>> Le 07/08/2017
> =C3=A0 22:26, Sambedi Fahted a =C3=A9crit :> > Thanks, Mike.> > I'll gi=
ve this a
> shot.> >> > On Mon, Aug 7, 2017 at 4:01 PM, Mike Davis
> <mdavis@rez1.com> wrote:> >>
> >> Hi Sam.> >>> >> I started with this> >>
> >> http://directory.apache.org/ap
> acheds/advanced-ug/4.2.7.1-> >>
> enable-authenticated-users-to-browse-and-read-entries.html>
> >>> >> And this> >> http://directory.apache.org/ap
> acheds/advanced-ug/4.2.7.2-> >> allow-self-password-modify.html> >>>
> >> From there, I built my own accessControlSubentry with a new> >>
> prescriptiveACI that looks something like this, scoped to> >>
> ou=3Dusers,ou=3Dsystem.> >>> >> {> >>     identificationTag
> "allowEditByApplicationAdmin",> >>     precedence 15,> >>
>  authenticationLevel simple,> >>     itemOrUserFirst userFirst:> >>    =
 {>
> >>         userClasses> >>         {> >>             name {
> "uid=3DapplicationAdmin,ou=3Dsystem" }> >>         }> >>         ,> >>
>  userPermissions> >>         {> >>             {> >>
>  protectedItems { entry },> >>                 grantsAndDenials> >>
>          {> >>                     grantRemove,> >>
>  grantModify,> >>                     grantBrowse,> >>
>  grantFilterMatch,> >>                     grantRead,> >>
>    grantRename,> >>                     grantCompare,> >>
>    grantAdd,> >>                     grantReturnDN> >>                 =
}>
> >>             }> >>             ,> >>             {> >>
>  protectedItems { allUserAttributeTypesAndValues },> >>
>  grantsAndDenials> >>                 {> >>
>  grantRemove,> >>                     grantModify,> >>
>  grantBrowse,> >>                     grantFilterMatch,> >>
>      grantRead,> >>                     grantRename,> >>
>  grantCompare,> >>                     grantAdd,> >>
>  grantReturnDN> >>                 }> >>             }> >>         }> >=
>
>  }> >> }> >>> >> Be aware that there is a bug in ApacheDS that causes
> some
> issues> >> with doing this. Right now, once the user's password is
> expired,> >> the password can't be changed (except by
> uid=3Dadmin,ou=3Dsystem),> >> because it tries to authenticate the user
> before changing the> >> password, and that authentication fails. I
> worked around that,> >> based on a conversation on this this group, by
> using grace logins,> >> and coding to treat a grace login like an
> expired, rather than honoringthe grace logins.> >>> >> // Mike> >>>
> >>> >> -----Original
> Message-----> >> From: Sambedi Fahted [mailto:sfahted@gmail.com]> >>
> Sent: Monday, August 07, 2017 2:16 PM> >> To:
> users@directory.apache.org>
> >> Subject: Re: [ApacheDS] Password Policy not being enforced> >>> >>
> >> Hi,
> Mike.> >> Thanks for the quick response. Yes. my (ubuntu) system is
> using
> the> >> uid=3Dadmin,ou=3Dsystem account in /etc/ldap.conf.> >>> >> What=
's
> the> >> the
> best way to create a user that would work for this?> >> Would I create
> an account like ou=3Dmanager,ou=3Dsystem, as an example?> >> Or would i=
t
> need to reside in the org's hierarchy, i.e.,> >>
> cn=3Dmanager,ou=3Dusers,dc=3Dredac,dc=3Dcloud,dc=3Dmyorg,dc=3Dcom?>
> >>> >> Thanks, again!> >>> >> Cheers> >> -Sam> >>> >> On Mon, Aug 7,
> >>> >> 2017
> at 1:57 PM, Mike Davis <mdavis@rez1.com> wrote:> >>> >>> Hi Sam,> >>>>
> >>> What credentials are you using to log in to the LDAP server? If>
> >>> >>>
> you are using uid=3Dadmin,ou=3Dsystem, that user, from everything I've>
> >>> been able to tell, can ignore the password policies. What I've>
> >>> done is create a separate user that my applications use to log in
> toLDAP.> >>> That user gets special rights to be able to change
> passwords. In> >>> that case, the policies are enforced.> >>>> >>> //
> Mike> >>>> >>> -----Original
> Message-----> >>> From: Sambedi Fahted [mailto:sfahted@gmail.com]> >>>
> Sent: Monday, August 07, 2017 1:44 PM> >>> To:
> users@directory.apache.org>
> >>> Subject: [ApacheDS] Password Policy not being enforced> >>>> >>>
> >>> Sorry
> if this creates a duplicate entry. I just read the> >>> instructions
> for list etiquette and I want to honor that.> >>>> >>> Somewhat
> reopening an old thread that went cold without a> >>> resolution, or
> at least not one that works for me.> >>> I've created a password
> policy and some test users and ApacheDS> >>> isn't enforcing the
> password policies.> >>> I have the policy set to not allow passwords
> longer than 9> >>> characters and from the linux host that's
> configured to use the> >>> ApacheDS server, I can create a password
> that's 6 characters long,> >>> that's as simple as "123456"> >>>> >>>
> I'm using: Apacheds-2.0.0-M24> >>>> >>> I created the following
> password policy:> >>> dn: ads-pwdid=3Ddefault,ou=3DpasswordPolicies,ads=
->
> >>> interceptorId=3DauthenticationIn> >>>> >>>
> terceptor,ou=3Dinterceptors,ads-directoryServiceId=3Ddefault,ou=3Dconfi=
g>
> >>>
> objectclass: ads-passwordPolicy> >>> objectclass: ads-base> >>>
> objectclass: top> >>> ads-pwdattribute: userPassword> >>> ads-pwdid:
> default> >>> ads-enabled: TRUE> >>> ads-pwdcheckquality: 1> >>>
> ads-pwdexpirewarning: 600> >>> ads-pwdfailurecountinterval: 30> >>>
> ads-pwdgraceauthnlimit: 3> >>> ads-pwdinhistory: 4> >>> ads-pwdlockout:
> TRUE> >>> ads-pwdmaxage: 3600> >>> ads-pwdmaxfailure: 2> >>>
> ads-pwdmaxlength: 10> >>> ads-pwdminage: 1800> >>> ads-pwdmindelay:
> 600>
> >>> ads-pwdminlength: 9> >>> ads-pwdvalidator:
> org.apache.directory.server.> >>> core.api.authn.ppolicy.Default> >>>
> PasswordValidator> >>>> >>> Here's the ldif export of a test user I
> created. The operational> >>> attributes are created, as you can see,
> but in addition to the min> >>> password length, the pwdmaxage isn't
> enforced, either.> >>>> >>> dn:
> cn=3Dtestuser,ou=3Dusers,dc=3Dredac,dc=3Dcloud,dc=3Dmyorg,dc=3Dcom>
> >>> objectClass: organizationalPerson> >>> objectClass: person> >>>
> objectClass: inetOrgPerson> >>> objectClass: top> >>> objectClass:
> posixAccount> >>> cn: testuser> >>> gidNumber: 500> >>> homeDirectory:
> /home/users/testuser> >>> sn: User> >>> uid: testuser> >>> uidNumber:
> 1049>
> >>> givenName: Test> >>> loginShell: /bin/bash> >>> mail:
> >>> test@myorg.com> userPassword::> >>>
> >>> e2NyeXB0fSQxJG9UYWNpSUF3JDV2c0dqLnVHeUtpL0RpMXNMQVFTMDA=3D>
> >>> createTimestamp: 20170802133738.851Z> >>> creatorsName:
> 0.9.2342.19200300.100.1.1=3Dadmin,2.5.4.11=3Dsystem> >>> entryCSN:
> 20170804213220.210000Z#000000#001#000000> >>> entryDN:
> cn=3Dtestuser,ou=3Dusers,dc=3Dredac,dc=3Dcloud,dc=3Dmyorg,dc=3Dcom> >>>
> entryParentId: b97b014f-2c00-4266-b578-1aa21053c437> >>> entryUUID::
> YmFmNDI4YjQtYzMyYy00NGM0LThkNTUtNDM2OGZkMjU1N2I3> >>> modifiersName:
> 0.9.2342.19200300.100.1.1=3Dadmin,2.5.4.11=3Dsystem> >>> modifyTimestam=
p:
> 20170804203344.706Z> >>> nbChildren: 0> >>> nbSubordinates: 0> >>>
> pwdChangedTime: 20170804203344.705Z> >>> pwdFailureTime:
> 20170804213220.200Z> >>> pwdHistory::> >>>
> MjAxNzA4MDQwNTM4NTQuNjA0WiMxLj
> MuNi4xLjQuMS4xNDY2LjExNS4xMjEu> >>> MS4> >>>
> 0MCM1NiNlMk55ZVhCMGZTUXhKRVZHTUM5Wk9VUmtKRTlwWWtkbWVXaEJSbk4> >>>
> zZURkUVNWaEtRMF> >>>  JNZFRFPQ=3D=3D> >>> pwdHistory::> >>>
> MjAxNzA4MDQxOTMwMzQuMDIxWiMxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEu> >>> MS4>
> >>>  0MCM1NiNlMk55ZVhCMGZTUXhKSEkxTUU1RVJtNXhKR1F3ZVdaQlEwOU9Wa1Y> >>>
> xUWxSeVR6RlBiam> >>>  xJUXk4PQ=3D=3D> >>> pwdHistory::> >>>
> MjAxNzA4MDQyMDI4NDguODA2WiMxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEu> >>> MS4>
> >>>  0MCM1NiNlMk55ZVhCMGZTUXhKRkpGTkRCSmQwcGxKRlIxVVU1MWFtRjZkaTl> >>>
> zTVd3dkxqQk1kaT> >>>  h4ZUM4PQ=3D=3D> >>> pwdHistory::> >>>
> MjAxNzA4MDQyMDMzNDQuNzA1WiMxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEu> >>> MS4>
> >>>  0MCM1NiNlMk55ZVhCMGZTUXhKRzlVWVdOcFNVRjNKRFYyYzBkcUxuVkhlVXR> >>>
> wTDBScE1YTk1RVk> >>>  ZUTURBPQ=3D=3D> >>> subschemaSubentry: cn=3Dschem=
a>
> wTDBScE1YTk1RVk> >>> >>>>
> >>> I think I'm missing one thing to make this work but I can't find>
> >>> >>>
> what that one thing.> >>> Can anyone please provide some insight?>
> >>>> >>> ~~Incidentally.~~> >>>> >>> Even the pwdAccountLockedTime
> operational attribute gets created> >>> after the allotted number of
> bad login attempts, but despite that> >>> I am still able to log in
> with the account with the correct password.> >>>> >>> dn:
> cn=3Dtestuser,ou=3Dusers,dc=3Dredact,dc=3Dcloud,dc=3Dmyorg,dc=3Dcom>
> >>> objectClass: organizationalPerson> >>> objectClass: person> >>>
> objectClass: inetOrgPerson> >>> objectClass: top> >>> objectClass:
> posixAccount> >>> cn: testuser> >>> gidNumber: 500> >>> homeDirectory:
> /home/users/testuser> >>> sn: User> >>> uid: testuser> >>> uidNumber:
> 1049>
> >>> givenName: Test> >>> loginShell: /bin/bash> >>> mail:
> >>> test@myorg.com> userPassword::> >>>
> >>> e2NyeXB0fSQxJG9UYWNpSUF3JDV2c0dqLnVHeUtpL0RpMXNMQVFTMDA=3D>
> >>> createTimestamp: 20170802133738.851Z> >>> creatorsName:
> 0.9.2342.19200300.100.1.1=3Dadmin,2.5.4.11=3Dsystem> >>> entryCSN:
> 20170807173256.649000Z#000000#001#000000> >>> entryDN:
> cn=3Dtestuser,ou=3Dusers,dc=3Dredact,dc=3Dcloud,dc=3Dmyorg,dc=3Dcom> >>=
>
> entryParentId: b97b014f-2c00-4266-b578-1aa21053c437> >>> entryUUID::
> YmFmNDI4YjQtYzMyYy00NGM0LThkNTUtNDM2OGZkMjU1N2I3> >>> modifiersName:
> 0.9.2342.19200300.100.1.1=3Dadmin,2.5.4.11=3Dsystem> >>> modifyTimestam=
p:
> 20170804203344.706Z> >>> nbChildren: 0> >>> nbSubordinates: 0> >>>
> pwdAccountLockedTime: 20170807173256.648Z> >>> pwdChangedTime:
> 20170804203344.705Z> >>> pwdFailureTime: 20170807173236.454Z> >>>
> pwdFailureTime: 20170807173239.031Z> >>> pwdFailureTime:
> 20170807173243.325Z> >>> pwdFailureTime: 20170807173249.384Z> >>>
> pwdFailureTime: 20170807173252.878Z> >>> pwdFailureTime:
> 20170807173256.648Z> >>>> >>> Thanks, again.> >>>> >>> -Sam> >>>> >>>
> >>>
> >> --> >> Cheers> >> -Sam> >>> >> >>> --> Emmanuel Lecharny>>
> >> --> >> Cheers> >> -Sam> >>> >> >>> --> Symas.com>
> directory.apache.org>>--Cheers-Sam
>


--
Cheers
-Sam