Any way to restrict CRUD operations via an alternative application?

HCL Domino Domino Forum
1

Hi All,

We have a (super)user who has been using VBA in an Excel spreadsheet to create and manipulate documents in a Domino database application.

The user has ‘Editor’ access to the application, and should normally be able to edit the document contents.

They have been, however, creating documents using VBA. That logic doesn’t consider such important document fields as Readers, Authors, etc. .

We would like to restrict access to all Domino data so that it can only be created/modified using an IBM Notes client.

I have tried looking through the ECL, but that only restricts what ‘others’ do.

Since he has his Notes client available, the external logic is using his normal Notes credentials.

I have tried setting a hidden field with the Notes client and looking for that in the QuerySave event of the form design.

Unfortunately, the external code pays no attention to the form events and the save is executed despite the missing field.

I have de-selected the ‘Don’t prompt for a password…’ option in the user security preferences, but that has no effect at all (suspected as much!).

The ONLY thing I have been able to suggest is to hide the database design… not much good now that they have already written the external logic.

I’m hoping that there is a solution out there that I’m missing.

Is there a way to ensure no external applications are able to access, create or modify Notes database documents?

Any/all suggestions would be most appreciated!

2

Subject: Appreciate the replies guys, and…

… 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!

3

Subject: Well, those important fields are normally easily added through NotesDocument.computewithform

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.

4

Subject: Well, those important fields are normally easily added through NotesDocument.computewithform

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.

5

Subject: Why

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.

6

Subject: You’ve touched on my solution so far Mike…

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!

7

Subject: Be Harsh

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.