Re: Remove ID copies from NAB and replicating it to client.

This is a multipart message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
I think the default on all databases is not to 'enforce a consistent ACL'.
 I think that is so that the back door into hacking the file locally is
left open.  I don't see any problems with turning it off.

You're right.  Mapping a drive, and ftp, should both be blocked by AS/400
security.  However too many shops give their developers *ALLOBJ.

Have you looked at the other persons suggestion from the other day?

We do some unique things with our NAB, and LEI.  We store the employee
number in it.  We also store the employee number in the accounting field
in the iSeries user profiles.  That, and some tweaking from the payroll
software, handles terminations pretty quickly.  I've been told that even
IBM modifies their NAB.  We also use this to propagate a file on our
iSeries which contains user profile and email address.  It makes it easy
to send email from the 400, (using the QtmmSendMail api), to the user
running the job without assuming that their email address is
userprofile@dekko.com  Not only that, I have 26 different login's I use.
If they give me the old heave ho then they can search all 400 user
profiles for my employee number in the accounting code.

Here's an interesting idea.  Use LEI to perform one way replications from
your nab to another Notes database with a limited number of fields.
Replicate that database to your hearts desire.



Rob Berendt
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin




"Roger Vicker, CCP" <rvicker@vicker.com>
Sent by: domino400-admin@midrange.com
04/03/2002 05:49 PM
Please respond to domino400


        To:     domino400@midrange.com
        cc:
        Fax to:
        Subject:        Re: Remove ID copies from NAB and replicating it to 
client.


Rob,

The security issues were what I was looking for. I thought the big one
would
be extracting the ID files and being able to use them. I just checked the
names.nsf and found the "Enforce a consistent ACL" is not checked from
"out
of the box". I can see where the user could un-check the "Copy ACL" on the
replicator and that along without the Consistent ACL, all kinds of
disasters
are in the making. Is there any gotchas to look out for in changing it?
Wouldn't the -Default- user only having Author and read access prevent any
replication back to the server?

Mapping a drive and FTP should be blocked by the OS400 object security.
Only
QNOTES and *ALLOBJ can get to it.

The system only has a few users so the size of the NAB is not that big a
deal. It seems like there should be a better way to get the user info
(real
name, short name...) when Notes is disconnected then to need to access a
replica of the NAB.

Seems like you are helping me all over the Midrange lists.

Thanks.

Roger Vicker, CCP

rob@dekko.com wrote:

> This is a multipart message in MIME format.
> --
> [ Picked text/plain from multipart/alternative ]
> Often people turn off the 'enforce ACL on local copy'.  Therefore they
> might be able to make a change to the local nab and have it replicated
> back up to the server.  A common hack is to ftp a persons email to a
> client and pooch through it from there.  Or in the case of where the
> server also has a client, (unlike the iseries) you can pooch through the
> files with that client opening it up as a local instead of through the
> server.  Mapping a drive is another method but has been known to cause
> corruption, and quite frequently.
>
> And, all the clients already have a names.nsf so you would have to use a
> different name for the local nab.
>
> Size is an issue, but you've already received a suggestion on that.  Our
> nab is 35mb.  Multiply that by 800+ clients.  All of whom get their PC's
> backed up using Tivoli Storage Manager to iSeries disk space  and you
get
> 28gb.  Granted it will probably be about half when you add in the
> compression of TSM so let's guess 14gb.  And now we have one of the
> reasons we have an iSeries in which we measure disk space in terabytes.
> Developers like this are a disk salesperson's dream.
>
> Rob Berendt
> --
> "They that can give up essential liberty to obtain a little temporary
> safety deserve neither liberty nor safety."
> Benjamin Franklin
> _______________________________________________

--
*** Vicker Programming and Service *** Have bits will byte ***
www.vicker.com
***
I think ;-)


_______________________________________________
This is the Lotus Domino on the iSeries / AS400 (DOMINO400) mailing list
To post a message email: DOMINO400@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/domino400
or email: DOMINO400-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/domino400.