You Can View User Feedback To This Tip
Perhaps the most misunderstood security feature in the whole Domino/Notes product line is the option "enforce a consistent access control list across all replicas of this database." The reason for the confusion is simple: This option does not enforce a consistent Access Control List across all replicas of a database.
The option (referred to as enforce consistent here) does not ensure that local copies of a database have the same ACL as server copies. It does not require that multiple server copies have the same ACL as one another. It does not prevent local users from looking at restricted views and forms that they are not authorized to see. And it does not prevent local users from seeing documents that exclude them with a Reader field.
So, what good is enforce consistent if it does not provide any of these controls? The option does two things, both of which are indeed useful, if we understand what they are:
- Enforce consistent prevents two copies of a database from replicating with each other, if they have different Access Control Lists.
- Enforce consistent prevents a user from accessing a local database if he or she is not listed in the ACL.
The first feature stops users from upgrading their local access for a database, reading unauthorized documents (or making unauthorized changes) and then replicating with a server copy. The server notices that the user is up to no good (because the local ACL is different) and disallows the replication.
The second feature adds a partial additional layer of protection by locking local users out of a database that they have no right to enter. It is a weak form of local security. This feature should not be considered a real security control, however, because it has several weaknesses.
Some versions of Domino/Notes R4 contained a NOTE.INI variable to bypass the enforce consistent option (Disable_Local_Access_Control=1). While I have not conducted tests on this variable, my research says that the variable worked on both servers and workstations, on many early versions of 4.x. I understand that the variable was removed from later versions of 4.x and is not present in R5.
In R5, I strongly suspect that the enforce consistent option can be bypassed by a clever user. This is because a local user is free to create a Notes ID certifier with any name at all, then to use the certifier to create any kind of Notes ID with any name. So a local user can create ID files that match the names listed in a local database ACL. My brief attempt to do this on a test database was not successful, but I suspect it can be done.
In summary, the enforce consistent option is a valuable addition to the security administrators toolbox (and I use it myself). It is important to keep in mind, however, that the wording of the option is misleading and the option does not offer the strong level of protection that it appears to.
Credit: This article is based on my experience with this feature, information from Lotus documentation, research on several discussion groups, and a conversation with a Domino developer.
Chuck Connell is president of CHC-3 Consulting, which helps organizations with all aspects of Domino and Notes, especially administration and security. CHC-3 helps companies to outsource their Domino administration needs via the Web site DominoAdministration.com and runs the popular security site DominoSecurity.org.
Code
USER FEEDBACK TO THIS TIP
- Great tip. One reason I use the "Enforce consistent ACL" is to allow Roles to work in local replicated DBs. —William Jones
- I think this is an excellent tip, I have two things to add. First, you shouldn't talk about copies when you actually mean replicas. And second, and more important: >1. Enforce consistent prevents two copies of a >database from replicating with each other, if >they have different Access Control Lists. This is not true because this would mean no ACL change could ever been made and replicated. It just prevents manager access to local replicas. And I think I heard somewhere it makes "roles" work again on those local replicas. Your conclusions are perfectly right again. :) Except, I think the local authentication is not simply about "same name", but also a public/private key algorithm (at least I hope so). So you actually need the private key from the ID to enter. But security can be overcome with a text or hex editor because the data in a local database is not encrypted by default. That's why you should turn this feature on if you deal with delicate data. Greetings, Thilo Hamberger — Thilo Hamberger
