Understanding Effective ACL Access in HCL Domino

An ACL Entry Is Not the Same as Effective Access

In a small Domino environment, checking a database ACL manually may be sufficient. In an infrastructure that has grown over many years, however, the actual access path can become much less obvious.

A user may receive access through a directly assigned group, through several levels of nested groups, through an organizational entry or through other ACL entries that participate in Domino’s access calculation.

Building an Effective Access Matrix

The accompanying Engine-Script demonstrates how these questions can be analyzed programmatically across multiple Domino servers and databases.

The demo first retrieves the Domino users and resolves their complete Names Lists, including direct and indirect group memberships. It then enumerates the databases on the configured servers, reads their ACLs and evaluates every user against every successfully retrieved ACL.

• retrieve Domino users from the Domino Directory
• resolve direct and nested group memberships
• enumerate databases across one or more Domino servers
• read the original ACL entries of each database
• retrieve the available ACL history
• calculate effective access for each user/database combination
• store access levels, roles, privileges and ACL flags
• write the results into a central Domino reporting database

The example deliberately focuses on the core ACL and group-resolution scenario. Domino provides additional ACL properties and security mechanisms — such as Maximum Internet name-and-password access and special administrative access — that could also be incorporated into more specialized analysis workflows. The API Engine provides additional functions for accessing such information, but they have intentionally been left out here to keep the example focused.

Resolve Once, Read Once, Reuse in Memory

A straightforward implementation could reopen every database and rebuild every user’s group memberships repeatedly during the analysis. That would create unnecessary work.

The demo therefore separates preparation from evaluation.

The Core of the Effective Access Calculation

The complete sample script contains database enumeration, reporting documents, ACL history, error handling and optional document-level analysis. The core access calculation itself remains relatively compact.

/* Resolve the user including direct and nested group memberships. */
UserGroups := @ResolveUserGroups(UserName; hNamesList);

/* Open a Domino database and create an in-memory copy of its ACL. */
DBh := @OpenDB(ServerName + "!!" + DBPath);
hACL := @ReadACL(DBh);

/* The database itself is no longer required for the ACL calculation. */
DBh := @CloseDB(DBh);

/* Determine the effective ACL access for this user. */
Result := @ACLGetEffectiveUserAccess(
    hACL;
    hNamesList;
    UserLevel;
    UserPrivileges;
    UserPrivilegeNames
);

@LogReport(UserLevel);
@LogReport(UserPrivileges);
@LogReport(UserPrivilegeNames);

/* Release the temporary in-memory structures. */
hACL := @ReleaseACL(hACL);
Result := @DestroyNameList(hNamesList);

The full demo expands this principle into a complete matrix across all configured users, databases and servers.

The Same Data Can Answer Different Security Questions

Once the calculated access information has been written to the reporting database, Domino views can present the same data from different perspectives.

Looking Beyond the Current ACL

The demo also retrieves the available Domino ACL history using @GetACLHistory and stores it together with the analyzed ACL.

This adds useful context to a current access snapshot and provides another source of information for audit or security processing.

• inspect the current ACL configuration
• retrieve the ACL history available from Domino
• combine current access information with historical ACL information
• use the data as the basis for custom change tracking
• trigger project-specific checks or notifications

ACL Access Is Only One Layer

Effective database ACL access does not automatically mean that a user can read or modify every document in the database. Domino can apply additional document-level security through Reader Names and Author Names fields.

For that reason, the sample includes an optional scan that searches documents for Reader and Author Names fields. If such fields are found, a reporting document is created containing information about the source database and document together with a direct Domino document link.

The sample opens matching source documents with summary information only and limits the number of generated Reader/Author reporting documents per database. This output limit keeps the demo reporting database manageable, but it does not reduce the number of source documents that may need to be examined.

From Access Analysis to Automated Security Workflows

The reporting database included with the example is intentionally simple. Its purpose is to demonstrate what information can be collected and how the results can be made available for further processing.

Once the effective access information is available programmatically, many additional workflows become possible.

Try the ACL Analysis in a Test Environment

The current Domino API Engine evaluation package includes the sample Engine-Script and matching Domino test databases used for this ACL analysis scenario.

The sample is intended for a controlled non-production environment. Before starting it, review the configured server names, database paths and especially the optional Reader/Author document scan.