ACL Magic Part 2

OK Last time we look at the very basic of the Domino/Notes ACL system, today we are going to go a bit further and look at Creating Agents, Folders, Reading and Writing Public Doc, Prevent Copying/replication.

The ACL looks like this when you 1st create a new database:

Today we will look at the Attributes of the user type.  We have already seen that there are 7 user Types starting at No Access, and ending at Manager.  when you create a new databases you or who every is creating the databases (the user.id file) will be the Manager of that database.


As can be see from the illustration on the left.  


There are 9 items below the Access Name.  These add or remove functionality for the person.  As you are the manager you have the ability to do anything.

Lets create a new user who we want to give restricted abilities to.  Click on Add and select the person from the the server name and address book, click the blue icon of a body.  If you can remember there full qualified name then you can just type it in the box, without needing to open the address book.  The name must be exact other wise it will not work, so I do suggest that you use the address book.  Tip, you can select multiple people at once from the address book, by ticking in the left hand column.  The will all be added with the same setting as the last user created, if this is a brand new databases then they will be added with Reader Access.  The Attributes will be blank except for Replicate and Copy.

Ok Lets discuss what each of the Attributes mean.

Create documents mean just that the user has the ability to create a new document.  This is a default for all levels except No Access, Reader, Editor, designer and of course Manager.  Depositor is mandatory to Create documents, which I think is self explanatory. Author can have create documents or not.

Delete documents.  This is a very important setting, perhaps one of the 2 most important Attributes. This prevents people deleting document.  This Attribute can be given or removed from all Access Types even Manager.  Why I here you ask?Its very easy to delete a document, most people do not ready the warning message when its come up says are your sure the just hit yes.  Other than the users own mail file where its OK for the owner to have delete capability.  All other databases should have the Delete capability removed, even for the Manager of the databases.  No matter how careful you are no matter how much experience you have you can always delete an important document by mistake.  We have all done it.

By removing Delete capability from even your self then it makes you think about do you really want to delete that document, cause you have to go into the ACL and give your self  Delete capability, please remember to change it back again!!!

Create Private Agents. Just a quick definition of what an Agent is: Lotus Notes Domino agents are versatile functions that can automate simple, everyday IT tasks, lessen the workload for developers and administrators, and increase efficiency.  A Private Agent is an Agent created by a user just for that user.  Now very few pure users will ever create a agent, private or otherwise.  Agents are created using the Domino Designer, which, in my view, users should never be allowed to touch.

Personal agents can run in the background on the server, as well as on your local workstation. As the name implies, personal agents mean that you are the only one who can run them. For example, you might create an agent to automatically sort documents for you in a database. If you are in the ACL of a particular database, your agent can then operate on that database.

The concept of personal folders and views brings a change from earlier versions of Notes. In R3, every user could create private views. Private views resided in your desktop file, not in the database. Consequently, a slight misunderstanding surrounds the "Create personal folders/views" option. If the box is checked, any view or folder that you create is stored inside the database on the server, and consumes server resources. If the box is unchecked, you can still create private views. These reside in the desktop just as they did in R3. Leaving the box unchecked doesn't mean a user cannot create a view, but only that it will remain private.

Create personal folders/views.  This is pretty obvious it allows users to create local folders and views Within a Lotus Notes mailbox and other databases such as Personal Journal, local address book and document libraries etc., users can create folders that are used to file messages or other documents. There are two basic types of folders that can be created: Shared (default) and Private (aka Personal), with some variations of each.

Private folders can be distinguished from the shared folders by the appearance of the padlock icon overlaid on the top of the folder icon.

Private folders have the following limitations:

1. Private folders can only be seen by the person who created them. If you have given access to your mailbox to other users, they will not be able to see your private folders. While this is working as intended, it can sometimes be an issue when the user was not aware of this.

2. Private folders cannot be accessed in iNotes or using the IMAP client, even by the person who created them. They are only visible in the Lotus Notes client.

3. Private folders are not stored in the mail file on the server, hence they are not backed up. These folders are stored inside the desktop.ndk file on user's workstation and if something happens to this file, it will result in an irreversible loss of these folders.

You cannot convert folders from Private to Shared . The only way to change a folder from one type to another is to create a folder of the other type with the same name, and move the messages from the old folder to the new folder, then delete the old folder by clicking on Actions -> Folder Options -> Delete Folder.


Tip: Where ever you are in Notes if you [press the F1 key you will get online help, as the help is context sensitive you will get help on files and folders if you are creating one.


As you can see from the illustration when you create a private folder you get too choose the folder type and where you want it within your folder structure.


The creation of a shared folder is exactly the same as a private folder its just that the folder /view can be shared and therefore on the server, be careful with this one as if you allow people unlimited access to creating folder and views on a server databases you can end up with lots of rubbish folders and views.  Remember that each view takes up server apace and time.


Create Lotus Script/Java agents. LotusScript and Java agent creation relates to the personal agents concept. Their use enhances personal agents beyond the use of formulas or simple actions.



Since LotusScript and Java agents on server databases can take up significant server processing time, you may want to restrict which users can run them.


Whether or not a user can run agents depends on the access set by the Domino administrator in the Agent Restrictions section of the Server document in the Domino Directory. Even if you select "Create LotusScript/Java agents" for a name in the ACL, the Server document still controls whether or not the user can run the agent on the server. Work with your server administrator to set access rights for users to run agents on a server.  This is an important point, the Server document will take precedence over the ACL.  So if the user does not have the ability to run Java or Lotus Script in the Server Security document setting the ACL of a individual Database will not give it to them.

Reading and writing public documents

Release 4.5 introduced the concept of reading and writing public documents. Public documents were offered for calendar and scheduling purposes, as a way for users to search calendar entries in other users' mail files.

Instead of relying on Readers fields to restrict access, each calendar entry includes a "Not for public viewing" option. When you create a calendar entry and select this option, users with "Read public documents" rights will not see the entry. (By default, anyone with Author access and above has "Read public documents" rights.) For example, this would allow your administrative assistant to manage your calendar, create calendar entries, or apply the calendar entries.

You can set the "Read public documents" and "Write public documents" options for the No Access and Depositor levels. "Write public documents" can be set only for Readers and Authors.

Replicate or Copy Documents.  This is a vitaly important feature of the ACL, use it carefully.  Please make sure that you fully understand this.

This option when selected/deselected allows/prohibits respectively the following:

1. Users to create local replicas or local copies of a database.
2. Select content from a document opened in read mode.
3. Copying, printing, or forwarding documents in the database.
4. Controls the replication of the documents with $KeepPrivate.

Deselecting the option prohibits users from printing, copying, forwarding documents. N.B. However, still there are chances that user may take a print screen and print the data from the image file. They can also copy the data from the document to the clipboard and save it as word file or text file and print that.  If you want to stop this then you will have to find something that prevents the operating system from doing it.

That’s how you can control this via design specifications i.e. through ACL in a particular database.

Now, how to restrict the user from copying / forwarding / printing the documents / e-mails that you sent to another database / someone’s mailbox? They have usually manager access to their mailbox; in that case you cannot make the change in their mailbox directly. Doing so would stop them from creating their archive databases too.  You could give them Designer, or as I prefer Editor access.

When you select the “Replicate or copy documents” option in the ACL, any documents created by people / groups that do not have this option checked will then be marked with a reserved field $KeepPrivate. $KeepPrivate field is set to “1” in that case; thus, prohibiting the documents from getting copied/forwarded/printed.

The same happens in case of selecting the “Prevent copying” check box in Delivery Options dialogue box.

You must have guessed by now that if you want to get rid of the prohibition, then you need to either reset the $KeepPrivate field or need to remove it completely from the document.

.

.

.

OK thats the end of ACL Magic Part 2, next time we will look at Roles, the Database Log files and Advanced Settings, user types and a few other things.

Basics of Using Domino/Notes ACL System. ACL Magic, Part 1

I though that it would be helpful to write a series of small articles concerning the Domino/Notes Access Control System.

These will be aimed at inexperienced or medium experience Domino Administrators.  It will also be suitable for people who have a small Notes system and are running it them selves.  There will be tips for even the experienced administrator.

Ok Lets Start:
The Domino Access Control List, or ACL for short, is the Domino way of controlling access to any Domino Databases, be it a mail file, the Address Book (also called Domino Directory) or any other databases.  Domino have many administration databases, such as events4.nsf,  ddm.nsf, catalogue.nsf.  Each and everyone one of these databases has its own ACL.

When you crate a Domino database or even when Domino is 1st installed an ACL will be created automatically for that database.  So if you create a new user they will be assigned an ACL, normally they will get editor access to that databases and you as the administrator will also have admin access to there mail file.

The purpose of the ACL is to protect. This can be show in this Domino Security diagram, I will cover everything in this diagram in this and subsequent articles.

The Notes Access Control List (ACL) is a highly integrated component of the Domino kernel architecture. Present within Notes from the beginning, its design has stood the test of time and use.  The ACL has been around since the beginning (1989).

At the same time, the ACL has evolved to handle an extraordinary number of tasks that traverse the entire Notes environment. Users sometimes find it difficult to understand why (even, how) the ACL works as it does.

Since I don't want to repeat items already documented, I will focus on tips for using the ACL design. Every Notes user can benefit from this article. You can easily understand and apply the ACL, once you assimilate its core structures: the seven access levels (Manager, Designer, Editor, Author, Reader, Depositor and No Access), the five user types (Person, Server, Mixed group, Person group, and Server group) and database roles. You use all these features from the Basics panel of the ACL dialog box to control user and server access to your database.

When you select a user name, the dialog box displays the user type and access level, as well as the detailed access enhancement or restriction options applicable to the access level. Access levels and user types, taken together, specify the maximum access allowed for any user for a given database.

Keep this key point in mind at all times: users can never be granted more access rights than are assigned to them within the Basics panel of the ACL dialog box. As a database manager, you begin by selecting for each user the core rights that belong to a level (some of which are enabled by default) and then enhance or restrict a user's level as needed by modifying the additional options within an access level. A user's access level and the status of the options within that level determine the user's database rights.

I will explore, in turn, each of the four panels of the ACL dialog box: Basics, Roles, Log, and Advanced.

The Basics panel of the ACL

The core functionality of the ACL is contained within the Basics panel. Since this article does not attempt to duplicate existing documentation, we only briefly outline the structure of the dialog box:

Selecting "Show All" in the People, Servers, Groups field displays every user registered for a given database for all seven access levels. Alternatively, you can request a view of Managers only, Designers only, and so on. You can add, rename, and remove users within the ACL dialog box.

When you select a user name, the dialog box displays the user type and access level, as well as the detailed access enhancement or restriction options applicable to the access level. Access levels and user types, taken together, specify the maximum access allowed for any user for a given database.

No Access

This level is self-explanatory. Zero Access.  Nothing.

Depositors and Readers

Depositors can insert documents into a database, but they can't read those documents. Readers, on the other hand, can read documents, but cannot deposit them. Although opposite in function, they complement each other conceptually because each is dedicated to a single purpose. (One additional right Readers have is that they can run agents.)

Authors

Authors can create and edit their own documents. ACL design becomes challenging at the Author level, since varied sub-choices become available.

For example, you can also allow Authors to delete documents. However, they cannot delete just any document in the database. They can only delete documents that contain an Authors field with their name in it. An Authors field is a field whose type is designated as "Authors." The users, groups, or roles specified in the Authors field(s) on a document are considered "owners" of the document if they have been granted Author rights through the ACL. This applies solely to those granted Author rights; anyone with more or less rights than an Author is not considered the document owner, whether or not their name was specified in the field.

People sometimes find it puzzling that Authors cannot create documents by default. (Why, they wonder, would you deselect "Create documents" rights for an Author?). Actually, authorship rights are assigned either because you yourself created the document, giving you those rights by definition (assuming there was an Authors field on the document when you created it), or your name appears in an Authors field for that document.

If your name is not a member of a document's Authors fields, you can't edit or do anything else with that document other than read it. Should you click an "Edit document" button within that document, nothing will happen, even if you created the document.

What guarantees you can edit a document after you have created it? The database Designer must put an Authors field in the document that grabs your name when you create the document. Or, your name could be added subsequently to the Authors field(s) of a document that you did not create.

Editors

Most access options become available (are not grayed out) at the Editor level. What you can restrict, again, is the freedom to delete documents. With deletion enabled, Editors can delete any document, whether or not their own name appears in the document's Authors field(s).

In fact, the delete rights extend only to deletion of the physical document itself. An Editor can always delete a document's entire content (logically, editing out everything in the document), but not the document itself.

Editors can have the ability to create personal agents, create personal folders/views, and create shared folders/views. In Release 3.0, the ability to create shared folders and views was limited to Designers and above. Release 4.0 extended this capability to an Editor, so that users with Editor access in their mail files are not restricted to creating personal folders and views. Their folders and views can reside in the same hierarchy as the rest of the shared folders and views, and they don't need to have Designer access (which would allow them to modify existing forms and views).

In addition to being able to run formulas and simple agents, you can also give Editors the ability to create LotusScript and Java agents.

Designers

At the Designer level, you can allow users to delete documents and create LotusScript/Java agents. Again, the delete rights only refer to the physical document itself. Designers can certainly modify the design of everything, as well as delete the contents of a document.

As for agents, in addition to being able to create personal agents, Designers can create shared agents. If you don't allow Designers to create LotusScript or Java agents, they are restricted from making any LotusScript or Java changes to the database. Otherwise, their rights are nearly complete.

Managers

Managers receive the ability to do everything. This includes assigning themselves the right (or not) to physically delete documents. Delete capability is restricted, by default, as a convenience check to ensure that accidental deletions are prevented. The same reasoning and dialog box behaviour applies to Designers and Editors.

Access priority is No Access, Manager, Designer, Editor, Author, Reader, Depositor.

One specialty in the ACL are the "Public Access" documents. The name is a little misleading. Public access does not mean these documents are available to the general public, but rather, that they are intended for a wider audience. They are created when a form contains the property "Make available to public access users" (this programmatic and can be added to any form by a Notes programmer). This property creates a Notes item with the name $PublicAccess and sets its value to 1. You can use this field in your applications in code and decide on a document by document basis if a document should be available for public access users. In the Notes mail template Calendar entries and contacts are "Public Access" documents. Calendaring was the reason why "Public Access" had been introduced into Notes R4.5. It allowed to grant people access to see your calendar without allowing them to access your eMail. Without this option every eMail would need to be protected by reader fields which would have interesting consequences for routing and database performance.

All this can be summed up in this table:

Table and some text orgionaly created by my good friend:  Stephan Wissel. 

The recommended access for authorized access is Author.

OK that's it for today, next time we will look at:- Creating Agents & Folders, Reading and Writing Public Docs and Roles and user types.  Plus a couple of other fun bits.

Please feel free to add comments, if they are nice one I might even publish them.