Tableau Security Made Easy

When I joined Tableau last year, I was found that the security model presented in training classes was a model that was counter to what I considered a best practice, based on nearly twenty years working in the Business Intelligence (BI) space. The model presented was what I would consider a legacy security model. It requires the creation of three groups for each Project on Tableau Server.

As you can see, this organization has five groups, each with their own Project in Tableau Server. For each Project, three groups are created: Viewers, Explorers, and Creators. Users of any given Project would be put into the appropriate group for that Project. The problem is that we end with too many groups to maintain. Imagine an organization that has fifty groups, each with their own Project. They would end up with 150 groups to maintain in Tableau. This is simply too many groups, and creates a maintenance nightmare. The same results can be accomplished with a fraction of the groups.

My experience is that it’s much easier to maintain a modern security model:

The idea here is that any user who is an Explorer or Creator would simply be added to the Explorers or Creators group, but not both. In the example above, Mary is a member of the Sales group, which grants her the rights to see the Sales Project. She is also a member of the Creators group, which grants her the right to create and edit workbooks. This dual membership accomplishes the same thing as the single group membership in the legacy security example, but results in far fewer groups to maintain.

My first thought was that, perhaps Tableau isn’t capable of this type of security model. So I built a Tableau server and tried it out. I was delighted to find that I could make it work, and it was pretty simple. And, as I started sharing this with people inside Tableau, it generated quite a bit of enthusiasm. So here’s how it is accomplished:

Step 1: Create your groups. You can create them in Tableau, or in your identity store (e.g. Active Directory). Create one group for each Project, as well as a group for Explorers, and a group for Creators.

Step 2: Move your users into the appropriate groups. In the example above, Dave has a Viewer license, so he only needs to be a member of the Operations group. Mary, on the other hand, is a Creator, so she is added to the Sales group, as well as the Creators group.

Step 3: Set permission for groups on each project. The Marketing group will be added to the Marketing Project, and given only Viewer rights. The Creators group will also be added to the Marketing Project, and will be given all rights except View and Project Leader (Project Leaders get View rights). In the same way, the Explorers group would be added to the Marketing Project, and given all Explorer rights, except View and Project Leader.

Although the Creators group has lots of permissions on the Marketing Project, it doesn’t have view rights. So members of the Creators group cannot see the Marketing Project, unless they are also a member of the Marketing group. And since rights are cumulative, a member of both Marketing and Creators will receive all the rights they need to create content within the Marketing Project.

As you can see, this is a very simple and efficient way to manage your groups within Tableau.

How do you model your security in your Tableau environment? Have you used a method like this? Let me know in the comments what your thoughts are on this approach.

SAP BusinessObjects Monitoring – Part 3

The Monitoring Application is a new application in SAP BusinessObjects 4.0. You will find the application in the CMC under Manage. This is the 3rd, and final, article in the series on Monitoring. In Part 1, we covered how to set up the application. Make sure you do this before trying to use the application. In Part 2, we covered how to use the application. Now, in Part 3, we will discuss the creation of the Monitoring universe, so you can track the health of the system over time.

By default, the monitoring trending data are stored in four tables in a Derby (Java) database. However, with SP04, we now have the option to transfer this data to the Audit database. This provides several advantages:

  • The Derby tables will only store three months worth of data. The Audit DB tables will store as much data as you want.
  • Connecting to the audit tables, to build a universe, is much easier than connecting to Java tables.

Therefore, it is recommended to migrate the data from the Derby tables, to the Audit database. Let’s talk about how to do that.

Migrating the Trending Data

The Trending database contains four tables:


We’ll cover what’s in these tables later. Prior to migrating the trending data from the Derby database to the Audit database, these four tables need to be created in the Audit database. SAP provides the scripts to create the tables. They are on the BusinessObjects server in the following location:

<Install Dir>\SAP BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\Data\TrendingDB
Choose the script that matches your Audit database platform. Then, using a tool that can access the Audit database, log into the database with an account that has full control, and run the SQL script. It will create all four tables, as well as the needed indexes for those tables.
Next, you’ll need to export the data currently in the Derby tables, to CSV files. It’s pretty simple: Log into the CMC, and go to Applications –> Monitoring. Click on the button that says, “Export Data from Embedded database as CSV files”. This will output three CSV files, one for each table, to the following location:
<Install Dir>\SAP BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\Data\TrendingDB
Before you import the CSV files into the Audit database, you may need to turn IDENTITY_INSERT on for the four tables. The reason for this is that the tables have identity columns, with auto-generated values. Some database do not allow the insertion of values into those columns. To turn on IDENTITY_INSERT, run the following command against the database, for each of the four tables:
NOTE: IDENTITY_INSERT can only be turned on for one table at a time. You will need to turn it on for a table, then import the data to that table, then turn it off again before proceeding to the next table.
Once the data has been imported, make sure you turn IDENTITY_INSERT off again by running the following command:
Proceed to import the CSV files, one at a time, into the Audit tables, using the appropriate tool for your database. It is recommended that the files be imported in the following order:
Activating the Audit Database
The next step is to activate the Audit database for use with the Monitoring application. Start by editing the SBO file, adding the needed alias to it. You will find the SBO files in the following location on the server:
<Install_Dir>\dataAccess\connectionServer\odbc\<db Type>.sbo
Open the one that matches the Audit database platform that you are using. Here’s an example of what to add for SQL server:
<DataBase Active=”Yes” Name=”MS SQL Server 2008″>
<Parameter Name=”Extensions”>sqlsrv2008,sqlsrv,odbc</Parameter>
<Parameter Name=”CharSet Table” Platform=”Unix”>datadirect</Parameter>
<Parameter Name=”Driver Name”>SQL (Server|Native Client)</Parameter>
<Parameter Name=”SSO Available” Platform=”MSWindows”>True</Parameter>
Refer to the Data Access Guide for more information on editing the SBO file(s).
Finally, log into the CMC, and go to Applications –> Monitoring, and change the Trending database from Embedded to Audit. You will need to restart the Monitoring service after making this change. The Monitoring service is located in an Adaptive Processing Server.
OK. You are ready to start creating the Monitoring universe.
Creating the Monitoring Universe
BI4 doesn’t come with a universe for the Trending database. So, you’ll need to create one. Unfortunately, finding information on the schema, such as a data dictionary, can be very challenging. Here is the basic schema for the Trending tables:
Here’s a basic description of what is stored in each of these table:
  • MOT_TREND_DETAILS: Dimension table; stores information about metrics, probes, and watches
  • MOT_TREND_DATA: Fact table; collects trend data about metrics watches, and probes, including DateTime and value (By default, values are collected every 15 seconds)
  • MOT_MES_DETAILS: Fact table; records information about threshold breaches and alert notifications
  • MOT_MES_METRICS: Dimension table; stores information about Watches and the metrics that are part of each Watch
From these tables, following are the columns that you will most likely be interested in:
  • MetricName: Obviously, this is simply the name of the metric. This will be a dimension object in the universe
  • Type: There are three possible types of metrics: “Subscription”, “ManagedEntityStatus”, or “Probe”.
  • Name: If the Type is “ManagedEntityStatus”, this will provide the name of the Watch. Otherwise, it will simply contain the same text as the Type, in caps.


  • Time: This is the time at which the data was collected. It is a BIGINT or NUMBER or FIXED field.
  • Value: This is the value of the metric at the time it was collected.
  • MessageKey: If an error is thrown, this will contain the error message key. If it was successful, this will be null. For Watches, it can also contain either “watchEnabled” or


  • Time: This is the time at which the data was collected. It is a BIGINT or NUMBER field.
  • AlertType: This represents the notification delivery type. It is a SMALLINT or NUMBER data type.


  • Name: This is the name of the watch.

As you can see, the universe will be fairly simple. Of course, you may want to create some filter objects, so that you can do reporting based on specific historical periods, such as current month, current year, etc.

I hope you have found this series as useful as I have, in researching it and learning it all. Let me know if you learn anything that I haven’t covered here.

SAP BusinessObjects Monitoring – Part 2

In Part 1, we looked at setting up the new Monitoring Application in SAP BusinessObjects 4.0. So, now that we have the application set up, in Part 2, we will look at using the application. Monitoring is a Flash application (What were they thinking?) built into the CMC. So, to get there, log into the CMC, and click Monitoring from the main menu. There were some substantial changes made to the Monitoring application in Support Pack 4 (SP04). This article will be based on SP04, but I will point out what is different from the BI4.0 base install.


There are five tabs across the top of the application. The first tab is the Dashboard, so that’s what you see when you first launch the application. The Dashboard has five panes (four prior to SP04):

  • Overall Health: A single icon gives you a quick overview of the health of the system. When you mouse over it, it looks like you can click to drill into it, but you can’t.
  • Recent Alerts: We will talk about Alerts later, but this pane shows any Alerts that were triggered within the past 24 hours, so you can get a quick view of the recent health of the system.
  • BI Landscape: We’ll talk more about Watches later, but this pane includes a graphical or tabular view of the Watches within the system. You can drill into any of the Watches shown here to get more information.
  • Watch Graph: The Watch Graph is directly below the Dashboard Watches pane, and displays a graph for the select Watch above. There are two views of each Watch. There is a Live view, which constantly updates with the status of the Watch, and there is a Historical view that allows you to view the status of that watch over a historical time period.
  • KPIs: This pane displays three Key Performance Indicators for the system. You can click on any of them to view more details for Running Jobs, Pending Jobs, or User Sessions.

Monitoring Dashboard BI4 SP04


Metrics are individual pieces of information that contribute to the overall health indication of the system. They are items that are measured within the system. The system comes with over 250 metrics. In addition, you can create your own metrics, based on the built in metrics. A few examples of standard metrics would include the following:

  • Number of Defined Web Intelligence Reports (I believe they meant documents, not reports)
  • Current Number of Tasks (Web Intelligence Processing Server)
  • Completed Jobs (CMS)

What you do with these metrics is completely up to you. You can use them in Watches and Alerts, setting thresholds for Warning and Danger alerts. The list of Metrics is quite impressive, and can generally tell you almost anything you want to know about the system.

You can view the current, or historical, value of a metric by selecting the metric in the left pane, then adding it to the right pane.

Note that the default view is a live view, that is updated every 15 seconds. Click the Go to History button to view historical data. When viewing historical data, you can define the time frame by clicking the calendar buttons.


The Watchlist tab allows you to monitor the Watches in the system. What is a watch? No, it’s not that thing on your arm that tells you the current time. 🙂 A Watch allows you to set thresholds for the Metrics, and determine what values for a Metric represent healthy, warning, or danger levels. For example, You may decide that when the disk space for the Input FRS reaches 70% capacity, you want to trigger a warning, and when it reaches 85% capacity, you want it to trigger a danger status.

There are a number of built in Watches, which you will probably want to edit, changing the thresholds to levels that make sense for your environment. You can also decide which watches will be a KPI (Shown on the dashboard) and/or written to the trending database, allowing you to see historical data for that watch.

If a Watch evaluates to True, what action do you want to see happen? This is called the Notification. And how long should the Watch evaluate to True before that action is taken? This is called the Throttle. For example, if the number of concurrent running jobs exceeds X, should the system send a notification immediately, or wait until it sustains that level for X number of minutes? These are options that you can set within a Watch.

Some of the options on watches include sending an email, or triggering a Probe. You can have an email sent in case of a Caution alert, or Danger alert, or both. To do this, click the Directory button next to the Notification Settings.


A probe is a device that executes a workflow, mimicking the actions of a user. The purpose of a probe is to test user actions, and make sure that they work as expected. There are nine built in Probes. Some of them can be run as is. Some of them will need additional setup before they can be run. For example, the CMS Ping Probe, which simply checks to see if the CMS is up and running, can be run as is. However, the Interactive Analysis Probe (Which you should rename as Web Intelligence Probe) needs to have the CUID of a Web Intelligence document, so it can use that document to test if a document can be opened, refreshed, and saved in various formats.

You will need to modify the URL of the BI Launchpad Probe. Here is the correct URL:

http://<servername&gt;:8080/BOE/portal (Make sure you replace <servername> with the name of your server)

For the Web Intelligence Probe, I would recommend using one of the Sample documents, built against the eFashion universe. This way, the probe doesn’t hit your production database, and the document runs quickly. Remember, the purpose of this probe is simply to make sure that users can open and refresh Web Intelligence documents.

The system allows you to register new Probes, either Java based, or Script based. You can also delete existing Probes that you don’t need.


All those Alerts that you set up in the Watchlist, will show up here. This is simply a list of all alerts that have been raised within the system. You can click on the alert to see the details of the alert. Keep in mind that alerts can also be sent to email addresses. For example, you can set up an alert that emails you if it crosses one or both thresholds. This is set up in the Watchlist tab.


Using the Monitoring application can be a challenging task, given the number of built in Metrics, and lack of training available from SAP. But don’t give up. It’s a powerful tool, with a lot of potential. If there is something that you want to do, and can’t figure it out, comment here, and I’ll see if I can help.
In part 3, we’ll discuss building a universe on the Monitoring trend data, so you can do historical reporting on the system’s health.

SAP BusinessObjects Monitoring – Part 1

SAP BusinessObjects 4.0 includes a new application, available through the Central Management Console (CMC) called Monitoring. What is this new application all about? Well, the bad news is that the documentation, and training, available for this new application is virtually nonexistent. Aside from a brief section in the Administrator’s Guide, there is no training or documentation available on how to use Monitoring. So, I’ve spent quite a bit of time trying to figure it out. This article is designed to document my learnings. This will be the first in a series of posts explaining how to set up monitoring, how to use monitoring, and how to create a universe for monitoring.

What is Monitoring?

Monitoring is a built in application, that allows administrators to monitor the health of the system. The most important aspects of Monitoring are Watches and Probes. Watches allow you to set thresholds for over 250 metrics within the system. You can be notified when these thresholds are breached. For example, you can have a Watch that will monitor the disk space consumed by the Output FRS, and be notified when that consumption reaches a specific point.

Probes are applets that perform workflows, just to make sure that system is working as intended. For example, there is a probe that will open a Web Intelligence document, refresh it, export it as Excel, or PDF (or both), and then close the document. If any part of that fails, you can be notified.

Monitoring includes a dashboard that allows you to see quickly the health of the system. You can see the current, or the historical, state of the system.

Setting up Monitoring

The data for Monitoring is stored in the Monitoring database. That’s right, BI 4.0 has 3 databases. But the Monitoring database doesn’t have to be set up. It is installed with the system. The Monitoring data is stored in a Derby database. This is simply a set a java tables. By default, they are stored in the install directory of BusinessObjects. And, since they are not stored in a typical RDBMS, we don’t ask a DBA to back them up. Backups are done within BusinessObjects, using the CMC.

On your BusinessObjects server, create a directory for the backup of the Derby tables. For example:


Next, log into the CMC, and go to Applications, and double click on the Monitoring Application. This will open the Properties window of the Monitoring Application. Make sure that “Enable Monitoring Application” is checked. In the “Trending database backup directory” field, enter the location for the backup, that you just created. Click Save and Close.

Next, go to the Servers area of the CMC, and restart the Adaptive Processing Server (APS). If you have more than one of them, restart the one with the Monitoring Service.

Once the APS is running, go back to the Applications area, and open the Monitoring Application again. Next to the “Run database backup task” label, you will see a button labeled “Now”. Click that button. This will create a backup of the Derby Database into the specified directory. Depending on how much data has been collected, this may take a while. Be patient. Once it completes, you will get a message that the backup completed successfully.

You can also, in the same place, schedule automatic backups, anywhere from every hour, to every 750 hours. I would recommend no more then 24 hours for your automatic backups. If you plan to create a universe on these tables, you may want to backup even more often, depending on your reporting needs. I’ll cover creating the universe in Part 3 of this series.

Monitoring History

The data that is stored in the Monitoring database tables isn’t kept forever. By default, the database has a 1Gb limit, although you can increase that size in the CMC – Applications – Monitoring Application. However, at some point, the application would slow down, if you let the tables get too large. If you want to keep the historic data for a long time, I would suggest extracting the data from these tables, and storing it in a RDBMS.

The Monitoring Application also integrates well with SAP Solution Manager, as well as Wiley Introscope.


That’s all there is to setting up the Application. In part 2 of this series, I’ll cover tips on using the application. And in part 3, I will cover the creation of a universe based on the Monitoring database. Stay tuned.

The Importance of Governance

I don’t know if this is a new phenomenon, or if I’m just more observant of it, but there seems to be a trend in BI today that is rather troubling: the lack of governance. What is governance, you ask? That’s a good question.

Before anything is published into a BI system, it should be subjected to a process that insures that it meets certain standards. In other words, someone needs to look at it and see if it is formatted correctly, has the right naming convention, includes the right information, or disclaimers, etc. This process is known as governance.

In the world of SAP BusinessObjects, governance can be applied to Connections, Universes, Documents, Dashboards, Workspaces, etc. Let’s take a look at the things that can be applied to the governance process.

  1. Naming Standards
    1. Should define a guideline for everything that can be built in BusinessObjects
    2. The goal is to create a consistent experience for users, and an easily maintainable and supportable system for developers and administrators
    3. Naming conventions can be applied to the following objects:
      1. Database connections
      2. Universe names
      3. Universe class names
      4. Universe object names
      5. InfoView folder names
      6. Document names
        1. SAP BusinessObjects Web Intelligence (Webi)
        2. SAP Crystal Reports
        3. Xcelsius (SAP BusinessObjects Dashboards)
        4. Other
  2. Security – three approaches:
    1. See everything except what is forbidden
    2. See nothing except what is needed
    3. Hybrid (usually the preferred approach)
  3. Reporting Guidelines
    1. Define how a report is made public
      1. How it is done now?
      2. What works well?
      3. What doesn’t work well?
      4. How should it be done?
    2. Establish formatting standards for public documents
      1. Creates a common look and feel to all public reports
      2. Makes it easier for users to find what they need on public reports
  4. Best Practices
    1. Job scheduling
      1. Limit the number of users who can schedule, to one or two per group
      2. Take advantage of Events
      3. Don’t schedule everything for the same time
      4. Apply a global limit to instances
      5. Avoid scheduling the same document multiple times
    2. Universe techniques
      1. Keep universes small and focused (no more than 700 objects)
      2. Never use underscores in anything that a user will see
      3. Give the universe a user friendly name and description
      4. Set the universe connection to “Disconnect after each transaction”
      5. Set the array fetch size to an appropriate level
      6. Set reasonable universe limits
      7. Set parameters appropriate to your database
      8. Every object should have a user friendly description
      9. Never have more than 3 levels of classes/subclasses
      10. Use proper case for object names
      11. Use full words for object names
        1. Use “Date” rather than “Dt”
        2. Use “Number” rather than “No” or “Nbr”
      12. Use Index Awareness to improve performance
      13. Every measure object should have an aggregate function in the select
      14. Format all numeric objects in the universe
      15. LOVs should have meaningful names
      16. No two objects should have the same name
      17. Use only custom hierarchies
      18. Set cardinalities on all joins

Now that we know what’s possible in a governance process, let’s take a deeper look at some of these.

Naming Convention Suggestions:

Connections: The connection name should be devised so that it includes information about the database that it is connecting to. For example:

Syntax: Environment_Platform_Database

Example: DEV_TD_CSR (Development Environment, Teradata, CSR database)

Universes: Universe long names should match the application that the data belongs to, as well as the focus of the universe. For example, if the data is from the CSR application, and the focus of the universe is sales, the universe could be named “CSR Sales”. The idea is to use a name that makes sense to the users.

Universe Class and Object Names: These should be consistent between universes. For example, if the Month object from Universe A, and the Month Name object from Universe B, return the same values, they should both be called the same thing. This creates a consistent user experience, and avoids confusion.

Documents: It can be very helpful to begin the name of a document with a code that identifies the universe or group that it belongs to, as well as sequential number. For example:

Syntax: Universe-SequentialNumber Document Name

Example: CS0001 Quarterly Sales By Title

In this example, CS represents Customer Service, and 0001 is simply a sequential number. This type of naming allows the documents to be sorted easily by universe, and also helps the user to specify which document they are referring to when they need to discuss documents.


As a starting point, we should review the current security, and see what works well, and what doesn’t. If the current security meets the needs of the organization, then we can keep the current security, and tweak as needed. The three common approaches to security are as follows:

See everything except what is forbidden. In this approach, everyone sees everything by default. Then, content is hidden that is not allowed to be seen by specific users. This approach can be very hard to manage.

See nothing except what is needed. In this approach, the default is to see nothing, and only grant access to content that is required. This is easier to maintain, but can create a bureaucracy that will only frustrate users looking for content that they can’t see.

Hybrid. In this approach, most, but not all, content is hidden by default. Some content is deemed appropriate for all users, and, therefore, is granted to all users. Other content is only granted as needed. This is the easiest to maintain, and is also the best for the users. Users don’t want to see everything, as the volume of content can be overwhelming. By limiting them to what they need, as well as what they are allowed to see, their view becomes more manageable.

Reporting Guidelines

There should be a standard format applied to all public documents. This common “look and feel” makes it easier for users, as they always know what they’re looking at, and always know where to find what they need on the report. They also can tell, very easily, when they are looking at a document that has not received official approval. Standards may include, but are not limited to, the following:

  • Cover page that includes standard information about the document:
    • Document name
    • Document author
    • Document description
    • Universe(s) in use in this document
    • Last Refresh Date/Time
    • Query filters, include prompts
    • Disclaimers
    • Company logo
      • Which logo?
      • Size
      • Position
    • Standard report colors
    • Document/Report naming conventions

All documents will need to pass the governance process before being placed into a public folder. This process should be streamlined, so as not to create a bottleneck.

There should be one or two people, in each group, who are trained to apply the governance process to a document, and who have permission to add objects to a public folder. These people will be responsible for making sure that all documents meet enterprise standards before being published.


Everything we do should be designed to make life better for the users. We need to treat them like customers, and we want their business. So make sure that your governance process is designed to do just that. Don’t let it become a hurdle that the users need to jump over. Streamline the process as much as possible.

Setting up a governance process is a difficult process. It needs to involve key users who will give input of what the standards should be. The problem is that everyone will feel strongly that their way is best. So your job is to try to find a solution that meets everyone’s needs as much as possible. Give it a shot, and let me know how it goes.

BOE XI 3.x Security Made Easy

Over the years, the security model in BusinessObjects Enterprise has evolved from user oriented security to object oriented security.  Those of you lived through the transition from 6.5 to XI, if you’re still sane, have seen some dramatic changes to the security model. The challenge of migrating from 6.5 to XI was that we had to permanently delete all knowledge of 6.5 security in order to fully understand the security model in XI.

And if that wasn’t enough, we also had to face some drastic changes between XIR2 and XI 3.x. Now, in XI 3.x, we have a true object oriented security model. What does that mean? It simply means that everything in XI 3.x is an object to which security can be applied. And when I say everything, I mean everything, from servers, to users, to universes, to documents, etc. Everything stored in the system is an object. Of course, this is a secret that we admins must keep. We can’t let the users in on the truth that each of them is nothing more than an object in the system. 🙂

So, the purpose of this post is to look at the security model in 3.x and look at some tips to make the whole thing as simple as possible.

Starting at the Root

In XIR2 we had something called Global Settings. In Global Settings we could set the Everyone group to No Access. This meant that no one would have access to anything unless we added them to a group that had access to a given object. This is quite different in XI 3.x. We no longer have Global Settings. We have a root folder called Public Folders. However, if we set the Everyone group to No Access at the root, then no one can see any other folder in the Document List, even if View rights are granted, as they can’t see the root folder. This is true no matter what group they belong to.

However, if we grant the Everyone group View rights to the root folder, then we have to go into each sub folder, under the root, and grant the Everyone group No Access. This is very time consuming, and terribly confusing. Is there a better way to accomplish this? I’m glad you asked. The answer, of course, is Yes!

So here’s the trick. Log into the Central Management Console (CMC), and go to Folders. Click on All Folders, on the left. Then click on the Manage button, and choose Top-Level Security – All Folders. Click OK at the pop-up box. Select the Everyone Group, and go to Assign Security. If there are any Access Levels listed under Assigned Access Levels, click the Remove Access button. At this point, it’s best to start with No Access.

Next, click the Advanced tab. Then, click Add/Remove Rights. This will take you to the General section of the Advanced rights window. Scroll down the list on the right, and find the setting for View Objects. Choose the following settings:

  • Granted
  • Apply to Object (Checked)
  • Apply to Sub Objects (Unchecked)

Allow me to explain.  By granting the right to View Objects, we are allowing the Everyone group to see the root folder. In InfoView, this folder is called Public Folders. However, by unchecking “View Sub Objects”, we are granting the View right to the root folder, but not allowing that right to be inherited to the rest of the Public Folders. At this point, you can grant the appropriate rights to each folder for each group. No one will have access to any folder unless they are a member of a group that has rights to that folder.

Beware of Everyone

Is that the equivalent to “Trust No One”? In any case, we want to be aware of, and beware of, any settings we apply to the Everyone group. Why? Because everyone, including you, is a member of the Everyone group. Therefore, anything you set for the Everyone group applies to you, as an administrator. This is true provided you are logging in with your own UserName, as a member of the Administrators group. This does not apply to the Administrator account, as you cannot remove rights from the Administrator.

So, with this in mind, never, ever, use the ‘Explicitly Denied” setting on the Everyone group. Rather, set the Everyone group to No Access for all objects, except as noted above. No Access uses the “Not Specified” setting, rather than the “Explicitly Denied” setting. Not Specified is far more flexible. It means that a user will not receive a given right as a member of that group, but may receive the right as a member of another group. It’s a very powerful setting.

The only time you should ever grant rights, other than No Access, to the Everyone group, is when you want to grant access to an object for everyone in the organization. For example, you may have a folder in InfoView that holds HR forms. This is obviously a folder that all employees need to access. In this case, it would be appropriate to grant View rights for the Everyone group to that folder.

Dual-ing with Security

You’ve probably heard this before, but it’s well worth repeating, as it is one of the best methods for simplifying your security model. Set up a dual security model. Here’s how it works. You create two types of groups: Content and Application.

Content Groups: These groups tend to mirror your folder structure. For example, if you have a Sales folder, you will have a Sales group. The Sales group will have rights to the Sales folder. The content groups are used to grant rights to the folders and, therefore, the content of the folders.

Application Groups: These groups are used to grant rights to various applications. For example, you might have a group called Web Intelligence Developers. Members of this group will have the rights to create documents in Web Intelligence.

With this model, every user is a member of at least one content group, and one application group. Of course, they may be members of multiple content and application groups, based on their needs.

Back Away From The Users

I can’t say this enough: do not set security for individual users. Ever. If you do, you are setting yourself up for a huge security nightmare. Rather, set security for groups, and add members to the appropriate groups. Even if you have one user who has special security needs, create a group for that user, and set the security for the group. That way, if the user ever leaves that position, you can simply remove them from that group, and replace them with the user who has taken their place.

And the Documents, too!

The same rule that goes for users, goes for documents, too. Don’t ever set security on individual documents. Create folders, add the documents to the appropriate folders, and set the security on the folders. Don’t make this more complicated than it needs to be. You have enough work to do without making security more complicated.

Use the Best Tools

Unless you have a fairly simple deployment, setting up and maintaining security in the CMC can be time consuming and frustrating. There are tools available that make it much easier. My favorite is 360View from GB and Smith. This tool can reduce your setup time by as much as 90%. I’ve used it, and have been very impressed with it. Of course, there are many similar tools available. So find one that meets your needs and use it.

Do you have additional security tips and tricks that you have used to make life easier? Share them in the comments below.