I can't think of a single company that I've worked at where this behavior would be tolerated.

Change his ACL access to No Access and report him to his manager and your manager, being sure to point out that his work is jeopardizing the security that was put in place for the application.

Is he allowed to behave like this.   That being said you know what documents he created so just run a scheduled agent against those documents to either fix the missing fields or delete the documents this user created.

... I understand your points.

However, I am looking for security measures that I can implement to restrict such activity in the future.

The user has been instructed not to undertake such activity in the future.

We were lucky that there really wasn't any malicious intent - "Just trying to be more efficient" we're told.

The effects of the activity have been remedied.

What I want to know is...  how can I prevent this from ever happening again?

Hiding the design will certainly thwart efforts to create practical documents in the database.

What's to stop a user with malicious intent running code to create hundreds of thousands of documents?

The circumstances are rare I know, but I would've thought there'd be a means of restricting the platforms used to manage Notes/Domino data.

Again, any suggestions would be most appreciated!

Honestly, that one call is *so* easily added, I would say your user either should've known, or shouldn't have been adding data.

So, you want to prevent this user from creating a document in a database. The simplest way to do it is to ride behind anyone adding documents, deleting them as you go along.

You can also set certain fields based on whether the document came from Notes. Unfortunately, so can a script.

Less intrusive, the agent can check for vital fields. No reader fields? delete it. No author fields? delete it. (it'll need to check whether the fields themselves are tagged as readers & authors, too.)

After a while, swashbucklers get the hint that this isn't how to be "more efficient".

And then when they conform with the proper methods of setting up a document you may well find they can be more efficient and play nicely.

Because it isn't that hard.

Thanks for your reply Mike!

The route I've adopted thus far consists of three components...

• Hide the database design
• Add a hidden, computed 'flag' field to the Notes form design
• Look for that field in an agent that's triggered 'after documents are created or modified' and remove documents where it's missing

Unfortunately, the agent is basically a scheduled agent and doesn't prevent document creation.

The documents are, however, effectively removed.

That may be all that's required, because that will identify 'dirty data' and let us know who is executing the logic.

I was focussing on access to Notes via COM.

I thought that, if I unregistered 'nlsxbe.dll' from the registry, that would prevent such activity - It has not.

I also tried removing the .TLB files from the Notes executable folder - removal of 'notes32.tlb' and 'domobj.tlb' have no effect at all. Removal of 'ltsci3.tlb' screws everything up (as expected!).

I honestly thought (when first asked about this) that there'd be a simple technical solution that I have overlooked somewhere... I was mistaken.

Thanks again Mike!