Three different ways to use NextLabs 8.5 policy to block SharePoint site collections

NextLabs 8.5 provides new policy module to block SharePoint site collections. Here are three most popular ways to block SharePoint site collections.

1. Use Resource Components with site url. 

You can add one site collection url to one resource component and the policy can include multiple Resource Components to clock multiple site collection. See screenshots below.

2. Use expression in advanced condition in the policy.

You can add expression on the urls in advanced condition in the policy as in the below screenshot.

3. Use SharePoint site collection site property bag value or sub-site web property value.

a. First, add the SharePoint site collection site property bag key in the SharePoint Enforcer configuration.xml file.  Bounce the enforcer after the change.

Example is below.

    <PropertyBag disabled="false" level="SiteCollection">
      <Property disabled="false" name="SensitiveSiteCollection" attributename="SensitiveSiteCollection" />
    </PropertyBag>
    <PropertyBag disabled="false" level="SubSite">
      <Property disabled="false" name="SensitiveSubSite" attributename="SensitiveSubSite" />
    </PropertyBag>

b. Add the property to site collection property bag.

c. Construct the component resource in condition with the property bag. Then use the component resource in the policy.

Based on our testing, the option #3 is much simple than other two options. We will implement option #3 in the future for most of the policies. Of cause, the site collection bag can be modified by site owner and the policy can be impacted. As a result, we will need to address the property bag seciruty control if we use option #3.

Procedure to add IP condition for NextLabs policy on version 8.5

If you need to block/allow SharePoint request based on the original user request IP address, here are the procedures.

1. Go to the following web site and convert IPv4 to IP Decimal.

https://www.ipaddressguide.com/ip

2.  Create a resource component. In the conditions, add "inet_address" condition with the decimal value of the IP address from step #1. Then create the policy to include the resource component.

3. If you need to test the original IP in "X-Forwarded-For" that is in the request header but not in the direct request, you can use the "Modify Header Value" add-in for your testing. The screenshots are listed below.

Now you can test any http request header in the NextLabs policy.

Procedure to add IP range like sub-net for NextLabs policy on version 8.5

If you need to block or allow SharePoint request from certain sub-net, here are the procedures.

1. Create the locations file. This is a text file containing any number of location definitions, one per line. Each line has the format    

<LocationName> “<AddressMask>”

where <LocationName> is the name by which you want to refer to the site when referring to it in Control Center tools such as Policy Studio Desktop Client, and <AddressMask> is a CIDR-like mask for the 32-bit IP address of a machine that is in the given location. Note the following requirements:

• Each address mask must be enclosed in double quotes

• The location name may not contain spaces

• The two elements must be separated by a space

For example, to define a location called VPN that represents all PCs connecting through a virtual private network, you might create the following entry:    

VPN "192.168.254.0/24"

Create additional similar lines for all the other hosts that are part of the VPN group. Here is another example:    

intranet “10.0.0.0/8”

You can also put comments in the file by beginning each comment line with #. For example:

# The following lines define the machines in the

# Boston office 

2. Install the location and run import locations utility.

Change to the directory <InstallDir>\tools. By default, the directory is: \Program Files\NextLabs\PolicyServer\tools\ 

Run the Import Locations utility with appropriate values for all parameters, as shown in the following example. This line must provide the name and path of the locations file and connection information for the system database. The last parameter, -i, is required only if the database type is Oracle or SQL Server.

importLocations.bat -l <LocationsFile> -u <DB_user> -w <DB_password> -s <DB_server> -p <DB_port> -d <oracle|postgres|sqlServer> [-i <instance>]

Example is:

importLocations.bat -l locations.txt  -u NextlabsDBUser -w nextlabspassword-s SPSQLSBX -p 1433 -d sqlserver -i NextlabsDB

When the utility finishes running, all the locations defined in the input file are present in the Information Network Directory. You will see ‘Success’ after running the command.

You can use the enrolled sites as values for the Site property when defining Computer components in Policy Studio. 

3. Create the policy using the required subject and resource and action components. Add the Advanced Condition as below.

After save and deploy, you can use this policy. For more information, check "NextLabs Control Center Unified UI Edition Administrator’s Guide".

Automation to monitor NextLabs policies deployed to all SharePoint servers

After we have deployed NextLabs SharePoint entitlement management solution, we have come up a automation process to update the SharePoint entitlement policy daily. However, we found sometimes the updated policies are not deployed to ALL SharePoint WFEs. As a result, some servers might have the old policies. We have worked with NextLabs to provide a API so we could very the deployed policies are the updated ones. However, there is no such API at this time. 

In this article, I will provide a workaround to check the policy file on ALL SharePoint WFEs. If any file not updated during last 12 hours, the process will send out email to notify administrator.

This is  just a quick workaround and you may modify for your own purpose.

#**************************************************************************************
# References and Snapins
#**************************************************************************************
$snapin = Get-PSSnapin | Where-Object {$_.Name -eq 'Microsoft.SharePoint.Powershell'}
if ($snapin -eq $null) {
  Add-PsSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
}
#**************************************************************************************


#************************************************
#  Variables that you need to change
#************************************************

$policyPath = “C:\Program Files\NextLabs\Policy Controller\bundle.bin”
$timespan = new-timespan -days 0 -hours 12 -minutes 0

$emailFrom = "NextLabsMonitor@mycompany.com"   
$smtpserver="smtphost.mycompany.com"

$emailTo = "admin@mycompany.com"
$subject="NextLabs policy check "  + [System.DateTime]::Now.ToLocalTime() 
$message = "NextLabs policy checking results "  + [System.DateTime]::Now.ToLocalTime() 
$policyoutofdate = $false


#*********************************************
# Get all WFE servers
#********************************************    
$appServers = get-spserver | ? { $_.Role -eq "Application" }
    
foreach($server in $appServers)
{
    if($server.Status -eq "Online")
    {
        $ServiceName = “Microsoft SharePoint Foundation Web Application”
        $ServiceRef = Get-SPServiceInstance -server $server | where-object {$_.TypeName -eq $ServiceName}
        if($ServiceRef.Status -eq "Online") # This is WFE server that has NextLabs policies
        {
            $currentHostName = gc env:computername;
            $serverName = $server.DisplayName

            if($server.DisplayName.ToLower() -ne $currentHostName)
            {
                 $policyPath = "\\" + $server.DisplayName + "\" +  $policyPath.Replace(':','$');
            }

             if(Test-Path  $policyPath)
             {
                    # Check time
                    # Get-Item “C:\Program Files\NextLabs\Policy Controller\bundle.bin” | Format-List 

                    $lastWrite = (get-item $policyPath).LastWriteTime
                    if (((get-date) - $lastWrite) -gt $timespan) {
                        $policyoutofdate = $true
                        Write-Host "Policy might be out of date on server $serverName." -ForegroundColor Red
                        $message = $message + "`n" + "`n" + "`n" + "Policy might be out of date on server $serverName." + "`n"
                    } else {
                        # newer
                        Write-Host "Policy is fine on server $serverName." -ForegroundColor Green

                    }
                    #Write-Host "Checked the policy file"
              }
              else
              {
                    $message = $message + "WARNING: The NextLabs policy file does not exists on server $server" + "`n"
                    Write-Host "WARNING: The NextLabs policy file does not exists on server $server" -foreground yellow;
              }
        }
    }
    else
    {
            Write-Host -foregroundcolor Yellow "WARNING: Server $server is Offline. Skipping checking the NextLabs policy";
    }
}

$message = $message + "`n"
$smtp=new-object Net.Mail.SmtpClient($smtpServer)

if($policyoutofdate)
{
    $smtp.Send($emailFrom, $emailTo, $subject, $message)
}

Configuration to resolve NextLabs Entitlement policy does not block SharePoint system page issue

We are in the process to implement NextLabs entitlement to block the SharePoint 2013 site collections. We found although sites have been blocked, users could directly browse to site system pages like _layouts/settings and the actions are available for those who has “full control” permissions. This is critical security hole and here is the configuration steps to disable this.

• Login to site as site collection administrator  
• Click Site Settings-> Site Collection Administration -> NextLabs Entitlement Manager settings -> Select “Enable access control enforcement for Page resources”

This configuration will enable SharePoint Page Level Access Control allow users to control, via policy, who can access various SharePoint settings pages.

This will block the users to access the system pages. We are looking for some way we could apply this setting to selected site collection and automatically apply to new site collection created.

NextLabs SharePoint policy automation architecture design

SharePoint is a widely adopted platform for internal and external collaboration. After SharePoint 2013 introduced social feature, cloud integration, and easy sharing capability, enterprises using SharePoint find that SharePoint sites have a tendency to grow at an uncontrolled pace, in part due to the ad-hoc collaboration and discretionary access control model native to SharePoint. This can catch data owners off-guard, especially when it comes to ensuring that sensitive information is protected. In our case, we company has major acquisitions and spin offs. As a result IT security team requested to block certain users to access some identified confidential SharePoint site collections regardless of the SharePoint native access control. In other words, we would need to block the certain users to access those identified SharePoint site collections even they have been granted the access.

NextLabs’ Entitlement Manager for SharePoint is a content aware Entitlement Management solution that provides the capability to authorize, classify, enforce and audit enterprise resources across Microsoft SharePoint. NextLabs Entitlement Manager for SharePoint is designed to enforce policies that control whether and how users can access, download, and use the data stored on a SharePoint server. Compliant Enterprise policy is composed of policy components like site URLs. Policy components are logical constructs that are created in the Policy Author and reused across policies. SharePoint policy can be defined with User (like block User Group), Action (like deny), and Portal components (like list of site URLs), along with conditions as illustrated in the following example for our company, highlighted respectively: 

Only block users that is in AD Group1 to Access highly restrictive list of site collections that any owner in certain departments during any hour.

Since site collection could be provisioning anytime and users could be transferred from one depart to a different one. It would be impossible to manually update the site collection list as policy components. The challenge is how can we automatically build the policy components to accomplish this “dynamic” policy? Let us review the NextLabs’ Entitlement Manager first to design the automation architect.

The Entitlement Manager for SharePoint has the following components.

• Policy Author (Java application): Defines, manages and deploys SharePoint policy.
• Control Center (J2EE server): Stores policy in a central repository and deploys policy sets to distributed Entitlement Managers for SharePoint across the enterprise.
• Administrator (Web application): Monitors system health and checks that policies are up-to-date for each Entitlement Manager.
• Entitlement Manager for SharePoint (Windows service): Detects user actions and enforces policy.
• Reporter (Web application) – Monitors real-time activities and queries the Entitlement Manager for SharePoint logs to analyze and audit trends and patterns.

The two primary components are the Adapter and the Policy Controller. The Adapter runs inside IIS and the Policy Controller as a Windows Service as indicated in the below graph.

   

Adapter

The Adapter functions as the Policy Enforcement Point (PEP) by detecting user actions on SharePoint, obtaining a policy decision from the Policy Controller, and enforcing policy. It is tightly integrated with ASP.NET and SharePoint with the following event monitoring and blocking interfaces:

• Event Receiver – SharePoint provides synchronized event receivers that expose a limited number of events that can be controlled through this high level interface.

• HTTP Module – ASP.NET provides a low level interface to pre-process HTTP requests. This interface provides added event controls that are not supported by the Event Receiver.

When a monitored event occurs, the Adapter sends a policy evaluation request to the Policy Controller through the .NET Adapter SDK. The Adapter uses the same public interfaces in the SDK that can be used to extend the Compliant Enterprise policy enforcement platform to any .NET application.

The Entitlement Manager for SharePoint not only enforces policies but also notifies end-users with customizable notifications to alert and educate users. The notification message can be customized for each policy using the Policy Author.

When the Policy Controller returns a denial decision, it includes a notification obligation for that policy. The Adapter blocks the action and triggers a SharePoint error to display the customized message.

Policy Controller

The Policy Controller is an independent run time that provides the following policy management and evaluation services:

• Police Engine – functions as the Policy Decision Point (PDP) for fast policy evaluation across multiple dimensions.

• IceNet Client – communicates with the Control Center to download policies, upload activity logs, and provide the Adapter health status.

• Obligation Manager – dispatches notification obligations to the Adapter, executes email notification and logging obligations internally, and launches any executable to perform custom obligations.

Now the key part for the automation is how we could automate to push the policy to Policy Controller. We would need to look at the policy components. SharePoint policy can be defined with the following three major components.

• User - AD group with specific attributes
• Action - deny, allow, or report
• Portal components - list of the site collection URLs as example

These three components is indicated in the following Policy Stdio. The three components are highlighted.

Since the user for the specific groups can be identified dynamically from claims SID, it will not require any change. The only  change required is the site collection list for the portal components as in the below screenshot.

At this point, it is cleat the the automation goal should update the policy site collection URLs automatically. Here is the architect design for the automation.

We have two scheduled jobs. 

One schedule job is on SharePoint server to run query against SharePoint using SharePoint server API and generate the site collection list. The site collection list will be written as portal component xml format on NextLabs Control Center (CC) server. 

The second schedule job is on NextLabs Control Center (CC) server. This job will pick up the portal component xml, import, submit, and deploy the policy. Then the deployed policy will be pushed to Policy Control on SharePoint side. As a result, the policy will be applied to SharePoint. The automation architect is described as the following picture.

Here is the detailed design for the automation process. We create the policy through Policy Studio and configure the following automation to update the site URLs in portal component.

1. SharePoint scheduled job - window console app to read SharePoint configuration as query criteria and policy template for xml format. 
2. SharePoint scheduled job - window console app to query SharePoint through server API and generate SharePoint site collection list as NextLabs portal component xml input file.
3. Import tool to read portal component xml and submit to Control Center.
4. Import tool to send portal component Control Center to approve.
5. Entity Deploy tool to deploy the portal component.
6. Control Center ICENET server to ready administration configuration like push setting.
7. Control Center ICENET server push policy to Policy Controller server on SharePoint server

At this point, SharePoint will have the updated new policy and the policy will be enforced. We will publish the detailed automation scripts in different blog.