Share via

How to Provide Temporary and Secure Administrative Access to Critical Systems and Applications

  • Article

Introduction

Active Directory provides an easy way to centrally manage accounts within an organization. It also provides an efficient way to delegate the administration and manage the accesses on AD-integrated Windows systems.

For critical systems and applications, some companies would like to restrict the accesses for changes as much as possible. This is feasible by creating AD groups to grant administrative access and then managing the users’ accesses by adding then when a change is required and then removing them once the change is completed. However, it might become a complicated and time consuming task if this is done manually.

This article shares a way that can be used to provide a temporary and secure administrative access to AD-integrated Critical Systems and Applications by combining the use of AD DS Fine-Grained Password Policies and Orchestrator. This is explained through a scenario detailed below.

Scenario

CONTOSO is a company that provides services to their customers through SharePoint Web portals hosted on-premise. As these portals are Business-Critical for CONTOSO, the company decided to restrict the access to these servers by providing temporary and secure accesses to administrators when changes are required. The administrators should provide the reason for the access when they request for it and CONTOSO IT Governance team should be informed when an access is granted in order to keep a track of what is getting done.

CONTOSO have the following technical implementation to meet their requirements:

  • An AD group named “Sharepoint_Admins” was created. Members of this group have Full Control access to the Sharepoint servers.
  • All administrative accesses that were granted directly to the Sharepoint administrators were revoked
  • A specific IT team was identified as eligible to have administrative access to Sharepoint servers. These team members need to contact AD administrators to provide them administrative access when required
  • The AD administrators add the requestor AD account to “Sharepoint_Admins” group when an administrative access should be granted. The access is revoked once the changes are complete
  • An AD DS Fine-Grained Password Policy was applied on an AD group that contains the members of the IT team that was identified as eligible to have administrative access in order to require a complex password and periodic password changes.

CONTOSO was able to provide a temporary and secure administrative access to their Sharepoint servers. However, the new process resulted in having a lot of interaction between the teams and delays when making changes. CONTOSO requested the assistance of a Microsoft Partner to support them in improving their implementation.

Solution

To improve the implementation of CONTOSO, an automation should be added to support the process. The temporary and secure administrative access could be granted by using the following:

  • An AD generic account will be created and will be added as member of “Sharepoint_Admins” group
  • An AD DS Fine-Grained Password Policy will be created (It will require a complex password that is periodically changed as required by CONTOSO) and will be applied on “Sharepoint_Admins” group
  • Orchestrator will be used to send administrative access requests, validate the identity of the requestor and grant the required temporary access. A two Factor authentication will be implemented to enhance the security of the implementation

Below is the workflow for granting or rejecting an administrative access:

Implementation

The first step would be to provision a new AD account and add it to “Sharepoint_Admins” group. As RDP connections do not end automatically when an AD account expires or is disabled, a forced disconnection could be configured under Sessions tab in the user account properties.

Once the account was provisioned, you need to create a new PSO object to apply the required AD DS Fine-Grained Password Policy on “Sharepoint_Admins” group.

Now, the last part is to configure Orchestrator to support CONTOSO requirements.

All you need are:

  • An SQL table that will be used to store the authorized users’ SIDs and a Code for each one of them. The following columns will be used:
    • SID: This column is used to store the authorized users’ SIDs (Security Identifier)
    • Code: This column is used to store the pre-shared keys used for the two Factor Authentication

  • An SQL table that will be used to store the administrative access requests and details. The following columns will be used:
    • Status: This column is used to store the status of the administrative access requests. The status can be Approved or rejected
    • Platform: This column is used to store the name of the Platform for which the administrative access is requested. In the case of CONTOSO, it will be Sharepoint
    • DisplayName: This column is used to store the display name of the user requesting the administrative access
    • SID: This column is used to store the SID of the user requesting the administrative access
    • Datetime: This column is used to store the Date and Time of the request
    • AccessDuration: This column is used to store the duration (in minutes) of the access requested by the requestor
    • Reason: This column is used to store the reason for requesting the administrative access

  • An Orchestrator Runbook that will check the requestor identity, grant the access to the requestor if validated and send the mail notifications and store the requests in an SQL database to track the changes

To create the Orchestrator Runbook, you need to use seventeen (17) activities:

  • Initialize Data: It will allow the Runbook to take the following as input:
    • AccessReason: The requestor need to specify the reason for his access
    • Key: The user will need to specify his pre-shared key value (A pre-shared key per user eligible to have access will be generated and provided to him to allow using the Runbook. This key will be used for the two Factor authentication and is required to get the request approved)
    • Duration (Minutes): The requestor need to specify the duration of his access in minutes

  • Query Database: It will allow getting the requestor SID by querying Orchestrator database. You will need to subscribe to the Activity Process ID from “Initialize Data” and “Runbook Server Name from “Initialize Data” in order complete the SQL query below:

SELECT [CreatedBy]

  FROM [Orchestrator].[Microsoft.SystemCenter.Orchestrator.Runtime.Internal].[Jobs]

WHERE [Id] IN

(SELECT     POLICYINSTANCES.JobID

FROM        [Orchestrator].[dbo].[POLICYINSTANCES] INNER JOIN

                      [Orchestrator].[dbo].[ACTIONSERVERS] ON [Orchestrator].[dbo].[POLICYINSTANCES].ActionServer = [Orchestrator].[dbo].[ACTIONSERVERS].UniqueID

WHERE     (POLICYINSTANCES.ProcessID = Activity Process ID from “Initialize Data”  AND (ACTIONSERVERS.Computer = '“Runbook Server Name from “Initialize Data” ') AND (POLICYINSTANCES.Status IS NULL))

** **

  • Run .NET Script: It will allow converting the requestor SID to sAMAccountName. You will need to subscribe to the Full line as a string with fields separated by ‘;’ from “Query Database” data from the previous activity. You will also need to publish account variable so that it can be used by the next activity and specify the NetBIOS name of your AD domain. The PowerShell command used for this is the following:
$sid = New-Object System.Security.Principal.SecurityIdentifier ('Full line as a string with fields separated by a colon (;) from “Query Database”');            
$account = $sid.Translate([System.Security.Principal.NTAccount])            
$account = $account.Value.TrimStart("Domain_NetBIOS_Name\")

  • Get User: It will allow filtering AD accounts and find the user account with the sAMAccountName provided by the previous activity

  • Query Database: It will allow getting the requestor pre-shared key from the SQL table

  • Compare Values: It will allow comparing the pre-shared key value provided by the requestor with the one stored in the SQL database

The next three (3) activities (Send Email and Write to Database) will be triggered when the previous comparison finds that the pre-shared keys do not have the same value. The link between the previous activity and these activities has Comparison result from Compare Values equals false as Include condition.

  • Send Email: Two activities will be used to send two mail notifications when the comparison results are not positive. A mail notification will be sent to the requestor (The e-mail address will be extracted from Get User activity created previously) and another one will be sent to CONTOSO Escalation team to inform about the rejected request.

  • Write to Database: It will store the information about the rejected request in the SQL table that is used for tracking

The next activities will be triggered when the previous comparison finds that the pre-shared keys have their values matching. The link between the previous activity and these activities has Comparison result from Compare Values equals true as Include condition.

  • Format Date/Time: It will get the current Date and time, convert the format to yyyy-MM-ddTHH:mm:ss and adjust the Date and time to be plus the number of minutes provided by the requestor for the duration of the administrative access (This will be used to set the expiry date and time of the AD generic account). You need to adjust the hours so that the timing will be in UTC (the acronym for the French equivalent of Coordinated Universal Time formerly called GMT).

Remark: You can get the current date and time by using an Orchestrator variable where you set NOW() as value.

  • Update User: It will allow setting the expiry date and time provided by the previous activity on the AD generic account

  • Generate Random Text: It will allow generating a random text that will be used as the new password of the AD generic account

  • Reset User Password: It will allow resetting the AD generic account password to be the one generated by the previous activity

  • Update User: It will allow setting User Must Change Password to be true on the AD generic account (This will force the requestor to change the password before using the account)

The next three (3) activities (Send Email and Write to Database) will be triggered when the previous activity will finish running with success.

  • Send Email: Two activities will be used here to send two mail to inform about the approval and the success of the request execution. A mail notification will be sent to the requestor (The e-mail address will be extracted from Get User activity created previously) and another one will be sent to CONTOSO Escalation team to inform about the approved request.

  • Write to Database: It will store the information about the approved request in the SQL table that is used for tracking

Required operations to maintain the implementation

The person in charge of maintaining the implementation need to maintain the SQL table by updating the following:

  • The Runbook permissions to allow the access only to the Authorized users
  • The SQL table that is to store the authorized users SIDs and pre-shared keys

To allow an authorized user to use the Runbook, you will need to grant Read and Publish permissions on the Runbook.

Once the user was granted access, he need to have his data stored in the SQL table. To do that, you will need to have:

  • The user SID: You can get it by running the following Powershell command:

Import-module activedirectory

(Get-ADUser admin.malek).SID.Value
  • The user pre-shared key: It should be a key meeting the complexity requirements of the company

 

User experience

When a requestor would like to get administrative access, he will need first to provide his AD credentials to access Orchestrator and start the Runbook.

Once the AD authentication was done successfully and the Runbook is started, the user will need to provide the reason for the access, the pre-shared key and the duration of the operation.

 

If the provided pre-shared key matches with the one stored in the SQL table then the request will be approved and the requestor will receive the temporary credentials to use by mail.

The user will then have administrative access to the Sharepoint servers and will need to change the provided password before starting to use the account. The new password need to meet the applied AD DS Fine-Grained Password Policy. When the specified operation duration is over, the account expires in AD.

If there is no matching then the requestor will receive the following mail notification:

Tracking and Escalation

The tracking is done by two methods: e-mail notification and recording the access in an SQL database.

An e-mail notification is sent when an eligible user has its administrative access request approved:

An e-mail notification is also sent when the requester types the wrong pre-shared key (The AD account might be compromised):

Below is a screen capture of the recorded events in the SQL Database:

Conclusion

This Wiki article shared a way to provide a temporary and secure access to Critical systems and applications. A two Factor authentication is used and two levels of tracking (Mail notification and recording of the events in a Database) are implemented to allow a better follow-up on changes. An escalation to the Escalation team is also implemented to notify about potential non-authorized access in case if the requestor AD account password was compromised.