SmartCloud Tip #03: Important Details to Setting the ACL on your Mail Files
When you move to SmartCloud Notes, you get many great benefits, but of course there are a few tradeoffs. One of those is giving up Manager access to the mail files. Whether you’re the mail file owner or the system administrator, the best access you’ll ever have is Editor. And unless you explicitly configure it otherwise, by default only the mail file owner will have any access at all. This is actually great for enforcing best practices. Users should never have more than editor access anyway, and in countries like France, the law prohibits administrators from accessing a user’s mail without their permission. Yes, the owner can always use delegation to grant others access to their mail file, but that only works if they are available to give that access. That doesn’t help for employees that are out sick or no longer employed at your company.
If you want anything other than the default, you need to plan ahead because once the mail file has been migrated, you can’t change the ACL. This means adding certain groups and roles to the ACL of the existing mail files as well as to the template for any future mail files.
There are typically 3 groups you will want to add to the ACL. The first is your administrator group. Without this, administrators can’t perform some basic administrator tasks, like opening the mail file to do troubleshooting.
The second group that may need access are support personnel who may need access to the mail files, but should not be included in your administrator group. For example, this may be regional administrators, or designated people on the help desk, or HR, or the legal department. How you organize these groups will vary depending on the organization and size of your company. Note that you need a different mail template in SmartCloud for each different ACL. For example, you will need a different template for each region if each region will have a different group of regional administrators.
The third consideration is providing access for your application servers in the event you have applications that run agents that directly touch the mail files. Keep in mind that no agents can run on directly on the SmartCloud mail servers so any agents will need to be run on a server you maintain on site. Typically databases use mail routing to get things into your mail file, but I have encountered a few applications that add entries directly to the calendar. The process of assigning access to these groups is simple, but must be done in advance of migrating the mail files into SmartCloud and also requires modifying the ACL of your mail template that will be posted in SmartCloud so future accounts created in the cloud will have them.
First, create a role called ExcludeDelegate in the ACL of the mail files, then create the three groups mentioned above as you need and apply that role to them. (More on exactly how to do this later.) The following screen shot was taken from the database catalog and shows these ACL entries framed in red boxes. Note that regardless of what level of access you give these groups in the mail file on site, it will not have more than Editor when it is moved to the cloud. But if those entries do not have the ExcludeDelegate role applied, they will be removed entirely from the ACL upon migration.
So how do you get these settings applied to all of your mail files in advance? You could add the entries using the administrator client. On the files tab, select a set databases then right click and choose Access Control – Manage. A dialog box displays that allows adding, modifying, or deleting ACL entries. It also allows creating roles. But the ability to actually applying those roles to ACL entries is missed. (I say BUG, IBM says “functioning as designed”) So the only way to assign a role to an ACL entry via the Administrator UI is to manually open each database one at a time and add the role to the entry. Not exactly convenient when trying to assign the [ExcludeDelegate] role to entries in hundreds or thousands of mail files before migrating them to SmartCloud.
Footnote: An SPR# GPKS6TNBN4 is a request to fix the admin client to mass-update roles in ACLs. Read this article for more details:
Please take a moment to open a ticket with IBM technical support and request that your company be added to this SPR. The more companies that request an enhancement, the more urgent they consider it.
Meanwhile, you can accomplish this using third party tools, such as Ytria EZ ACL tool, a module in the suite of useful admin tools. (Contact me for a discount code) or you can write an agent to accomplish this task.
Prepare your environment with these steps well in advance of migrating and things will be much less complicated at the time of migration.
If you found this tip helpful, you might also be interested in my other tips:
SmartCloud Tip #01 Using the Notes admin client to compliment the SmartCloud web admin screens
SmartCloud Tip #02: Best Practices to get mail files ready to move to SmartCloud
Posted on March 3, 2014, in Cloud, Quick Tip, SmartCloud and tagged Access Control, ACL, migration, SmartCloud. Bookmark the permalink. 3 Comments.
Thanks for your SmartCloud Migration tips, we are just embarking on this and your tips have been good reminders.
Glad to hear it Steve. If there are other tips you would like to see covered, ask. And as you get through your migration, if you want to publish your success story, let me know. See my contact page for my email address.
Pingback: SmartCloud Tip #04: Special considerations for Soft Deletions with MMR | The Notes Guy in Seattle