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

Rob, Gabriella,

I like both of your comments.

The developer doesn't feel that with a 20 name NAB the extra steps are worth 
it. Except
for security I tend to agree on that point. I have checked the "Enforce 
consistent ACL"
but am still concerned about the IDs being stored in it and replicated to the 
client.

With the consistent ACL can one user access another user's entry and detach 
their ID? I
only have an Admin access so can't test it on a local copy. When I try to 
remove the
IDs the menu option for CUT is grayed out. So how do I remove them?

Thanks.

Roger Vicker, CCP

rob@dekko.com wrote:

> 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 ;-)
>

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