Acceptable entries in the ACL

Refer to this topic for details on any entry you make in an Access Control List (ACL).

Acceptable entries in the ACL include:

  • Wildcard entries
  • User, server, and group names (including user and group names of Internet clients)
  • LDAP users
  • Anonymous, used for anonymous Internet user access and anonymous HCL Notes® user access
  • Database replica IDs

Each ACL entry can have a maximum of 255 characters.

Add names to the ACL in hierarchical format for better security. For example: 

Sandra E Smith/West/Renovations/US
Randi Bowker/Sales/FactoryCo

Wildcard entries

To allow general access to a database, you can enter hierarchical names with a wildcard character (*) in the ACL. You can use wildcards in the common name and organizational unit components.

Users and/or servers who do not already have a specific user or group name entry in the ACL, and whose hierarchical names include the components that contain a wildcard, are given the highest level of access specified by every one of the wildcard entries that match.

Here is an ACL entry in wildcard format:

*/Illustration/Production/Renovations/US

This entry grants the chosen access level to:

Mary Tsen/Illustration/Production/Renovations/US
Michael Bowling/Illustration/Production/Renovations/US

This entry does not grant the chosen access level to:

Sandy Braun/Documentation/Production/Renovations/US
Alan Nelson/Renovations/US

You can use a wildcard only at the leftmost portion of the ACL entry. For example, you can't use the entry:

*/Illustration/*/Renovations/US

to represent these entries:

Michael Bowling/Illustration/West/Renovations/US
Karen Richards/Illustration/East/Renovations/US

When you use a wildcard ACL entry, set the user type as Unspecified, Mixed Group, or Person Group.

User names

You can add to an ACL the names of any individuals with certified Notes® user IDs or Internet users who authenticate using name-and-password or SSL client authentication.

  • For Notes® users, enter the full hierarchical name for each user; for example, John Smith/Sales/Renovations, regardless of whether the user is in the same hierarchical organization as the server that stores the database.
  • For Internet users, enter the name that appears as the first entry in the User name field of the Person document.
    Note: Many alias names can be entered in the user name field and used for authentication; however, it is the first name in the list that is used to perform the security authorization check. This is the name that should be used on all HCL Domino® database ACLs, in the security settings on the Server document, and in .ACL files.

Server names

You can add server names to an ACL to control the changes a database receives from a database replica. To ensure tighter security, use the full hierarchical name of the server -- for example, Server1/Sales/Renovations -- regardless of whether the name of the server being added is in a different hierarchical organization than that of the server that stores the database.

Group names

You add a group name -- for example, Training -- to the ACL to represent multiple users or servers that require the same access. Users must be listed in groups with a primary hierarchical name. Groups can also have wildcard entries as members. Before you can use a group name in an ACL, you must create the group in the HCL Domino® Directory or in either a secondary Domino® Directory or an external LDAP Directory that has been configured for group authorization in the Directory Assistance database.

Note: Be sure that any group names you use in an ACL comply with the specified guidelines for creating them. The use of erroneous names may cause access problems.
Tip: Use individual names rather than group names for the managers of a database. Then when users choose Create > Other > Special/Message to Database Manager, they'll know whom they are addressing.

Groups provide a convenient way to administer a database ACL. Using a group in the ACL offers the following advantages:

  • Instead of adding a long list of individual names to an ACL, you can add one group name. If a group is listed in more than one ACL, modify the group document in the Domino® Directory or the LDAP Directory, rather than add and delete individual names in multiple databases.
  • If you need to change the access level for several users or servers, you can do so once for the entire group.
  • Use group names to reflect the responsibilities of group members or the organization of a department or company.
Tip: You can also use groups to let certain users control access to the database without giving them Manager or Designer access. For example, you can create groups in the Domino® Directory for each level of database access needed, add the groups to the ACL, and allow specific users to own the groups. These users can then modify the groups, but they can't modify the database design.

Terminations group

When employees leave your organization, you should remove their names from all groups in the Domino® Directory and add them to a Deny List Only group used to deny access to servers. The Deny Access list in the Server document contains the names of Notes® users and groups who no longer have access to Domino® servers. You should also make sure that the names of terminated employees are removed from the ACLs of all databases in your organization. When you delete a person from the Domino® Directory, you have the option to Add deleted user to deny access group if such a group has been created. (If no such group exists, the dialog box displays No Deny Access group selected or available.)

LDAP users

You can use a secondary LDAP directory to authenticate Internet users. You can then add the names of these Internet users to database ACLs to control user access to databases.

You can also create groups in the secondary LDAP directory that include the Internet user names and then add the groups as entries in Notes® database ACLs. For example, an Internet user may try to access a database on a Domino® Web server. If the Web server authenticates the user, and if the ACL contains a group named "Web," the server can look up the Internet user's name in the group "Web" located in the foreign LDAP directory, in addition to searching for the entry in the primary Domino® Directory. Note that for this scenario to work, the Directory Assistance database on the Web server must include an LDAP Directory Assistance document for the LDAP directory with the Group Expansion option enabled. You can also use this feature to look up the names of Notes® users stored in foreign LDAP directory groups for database ACL checking.

When you add the name of an LDAP directory user or group to a database ACL, use the LDAP format for the name, but use a forward slash (/) rather than a comma (,) as a delimiter. For example, if the name of a user in the LDAP directory is:

uid=Sandra Smith,o=Renovations,c=US

enter the following in the database ACL:

uid=Sandra Smith/o=Renovations/c=US

To enter the name of a nonhierarchical LDAP directory group in an ACL, enter only the attribute value, not the attribute name. For example, if the nonhierarchical name of the LDAP group is:

cn=managers

in the ACL enter only:

managers

To enter the name of a hierarchical group name, include LDAP attribute names in ACL entries. For example, if the hierarchical name of the group is:

cn=managers,o=acme

in the ACL enter:

cn=managers/o=acme

Note that if the attribute names you specify exactly correspond to those used in Notes® (cn, ou, o, c) the ACL will not display the attributes.

For example, if you enter this name in an ACL:

cn=Sandra Smith/ou=West/o=Renovations/c=US

because the attributes exactly correspond to those used by Notes®, the name appears in the ACL as:

Sandra Smith/West/Renovations/US

Acceptable ACL entries for LDAP users

Table 1. Acceptable ACL entries for LDAP users

LDAP DN

ACL entry

 
cn=Scott Davidson+ id=1234, ou=Sales,o=Renovations
 
cn=Scott Davidson+id=1234/ou=Sales/o=Renovations
 
cn=Scott Davidson,o=Renovations\, Inc
 
cn=Scott Davidson/o=Renovations, Inc
Note: If the LDAP name includes a backslash followed by another character, omit that backslash when you specify the name in the database ACL.
 
uid=smd12345,dc=Renovations,dc=Com
 
uid=smd12345/dc=Renovations/dc=Com
 
uid=Sandra Smith,o=Renovations,c=US
 
uid=Sandra Smith/o=Renovations/c=US

Anonymous

Any user or server that accesses a server without first authenticating is known by the name "Anonymous" at that server. Anonymous database access is given to Internet users and to Notes® users who have not authenticated with the server.

Anonymous access is generally used in databases that reside on servers available to the general public. You can control the level of database access granted to an anonymous user or server by entering the name Anonymous in the access control list, and assigning an appropriate level of access. Typically you assign Anonymous users Reader access to a database.

The default ACL entry for Anonymous for all database template (.NTF) files has an access level of Reader, so that users or servers can successfully read from the template when creating or refreshing .NSF files based on that template.

The default ACL entry for Anonymous for database (.NSF) files is No Access.

Table 2. Conditions for Anonymous access to a database

Anonymous access enabled for Internet protocol

Anonymous access not enabled for Internet protocol

Anonymous access enabled in database ACL

Users access the database with the Anonymous entry's access level. For example, if Anonymous access is set to Reader, anonymous users who access the database will be granted Reader access.

Users are prompted to authenticate when they attempt to access any resource on the server. If the user is not listed in the database (through a group entry, a wildcard entry, or if the user name is explicitly listed), then the user accesses the database with the -Default- entry's access level.

Anonymous given "no access" in database ACL

If Anonymous has been granted "No Access" (and the Read & Write public documents privileges are not enabled) Anonymous users are not allowed access to the database and they will be prompted to authenticate. When they authenticate, the name is checked in the database ACL to determine the level of database access that should be granted.

Anonymous not listed in database ACL

Anonymous users access the database with the -Default- entry's access level. For example, if -Default- access is set to Reader, and there is no Anonymous entry in the ACL, anonymous users who access the database will be granted Reader access.

Anonymous users (both those who are given access to a database through the Anonymous entry and those who have access through the -Default- entry) who attempt to do something in the database that is not allowed for their access level will be prompted to authenticate. For example, if Anonymous is set to Reader, and an anonymous user tries to create a new document, that user is prompted to authenticate with a name and password.

Tip: If you want all users to authenticate with a database, then make sure that Anonymous is in the database ACL with an access level of No Access, and be sure that the Read Public Documents and Write Public Documents are not enabled. Add the Internet user's name to the ACL with the level of access you want them to have.

The Domino® server uses the group name Anonymous solely for access control checks. For example, if Anonymous has Author access in the database ACL, the true name of the user appears in the Authors field of those documents. The Domino® server can display only the true name of anonymous Notes® users, but not of anonymous Internet users, in the Authors field of the document. Authors fields are never a security feature, regardless if anonymous access is used; if the validity of the author's name is needed for security, then the document should be signed.

Replica IDs

To allow an agent in one database to use @DbColumn or @DbLookup to retrieve data from another database, enter the replica ID of the database containing the agent in the ACL of the database containing the data to be retrieved. The database containing the agent must have at least Reader access to the database containing the data to be retrieved. Both databases must be on the same server. An example of a replica ID in a database ACL is 85255B42:005A8fA4. You can enter the replica ID in uppercase or lowercase letters, but do not enclose it in quotation marks.

If you do not add the replica ID to the access control list, the other database can still retrieve data if the -Default- access level of your database is Reader or higher.

Order of evaluation for ACL entries

ACL entries are evaluated in a specific order to determine the access level that will be granted to an authenticated user trying to access the database. If a user fails to authenticate with a server, and the server permits access anyway, access will be computed as though the user's name was "Anonymous."

  • The ACL first checks the user name to see if it matches an explicit entry in the ACL. The ACL checks all matching user names. For example, Sandra E Smith/West/Renovations would match the entries Sandra E Smith/West/Renovations/US and Sandra E Smith. In the event that two different entries for an individual have different access levels (for example, applied at different times by different administrators), the user trying to access the database would be granted the highest access level, as well as the union of the access privileges of the two entries for that user in the ACL.
    Note: If you enter only the common name in the ACL (for example, Sandra E Smith), then that entry matches only if the user's name and the database server are in the same domain hierarchy. For example, if the user is Sandra E Smith, whose hierarchical name is Sandra E Smith/West/Renovations, and the database server is Manufacturing/FactoryCo, then the entry Sandra E Smith will not get the correct level of access for ACLs on the server Manufacturing/FactoryCo. The name must be entered in full hierarchical format in order for the user to obtain the correct level of access to ACLs on servers in other domains.
  • If no match is made on the user name, the ACL then checks to see if there is a group name entry that can be matched. If an individual trying to access the database happens to match more than one group entry -- for example, if the person is a member of Sales and there are two group entries for Sales - Renovations Sales and Sales Managers -- then the individual is granted the highest access level, as well as the union of the access privileges of the two entries for that group in the ACL.
    Note: If the user matches an explicit entry in the ACL, and is a member of a group that is also listed in the ACL, then the user always gets the level of access assigned to the explicit entry, even if the group access level is higher.
  • If no match is made on the group name, the ACL then checks to see if there is a wildcard entry that can be matched. If the individual trying to access the database happens to match more than one wildcard entry, the individual is granted the highest access level, as well as the union of the access privileges of all of the wildcard entries that match.
  • If a group entry and a wildcard entry both apply to a user attempting to access the database, then the user has the access assigned to the group entry. For example, if the group Sales has Reader access and the wildcard entry */West/Renovations has Manager access, and both entries apply to a user, then the user has Reader access to the database.
  • Lastly, if no match can be made from among the database ACL entries, the individual is granted the level of access defined for the -Default- entry.