Temporary Permissions with System Center

Posted: 4th December 2013 by Anders Bengtsson in Orchestrator, System Center Service Manager

Do you have multiple accounts for administrator of your IT environment? Do you have for example one local administrator account, one Active Directory administrator account, one account to administrate some business service and one account that you use to log on to your workstation and read your e-mail? Do you remember all the passwords? I often see customers having a challenge remember all passwords and when to use which account.

Another funny (or scaring) side of it is that everyone is more or less administrator of everything, it is just a question about clicks. For example an engineer is not a domain admin but administrator of Orchestrators that integrates with Active Directory using a domain administrator account. Another example could be an engineer without any administrator accounts except is Operations Manager administrator, with indirect access to all servers as local system, including domain controllers.

One thing that also crossed my mind is why do so many engineers have permissions to do 200 tasks, when you normally only do 20 tasks? Why do you have an account that could delete the entire domain when all you do is reset passwords and add members to groups? There is an imminent risk of human errors.

I am no security expert but I want to show a way to minimize number of administrator accounts floating around, and maybe minimize human errors. The scenario is that no engineers have more than one account. That account is a normal user account, no special administrator permissions at all. When the engineer are about to do something special he or she request permissions and also describes the work that will be done. The engineer also select number of hours permissions are needed.

Figure 1 The Service Request form

The service request templates includes the following activities

  1. Runbook, update approval step. This step will look which system the requester has requested permissions to, and then depending on the system configure the manual approval step. If it is for example Active Directory the runbook activity will add a group of people that can approve Active Directory permissions.
  2. Review Activity, “managers” or “owners” approve temporary permission
  3. Runbook, grant temporary permissions. A runbook grants the requester permission to the system

Figure 2 Service Request Template

 

The first runbook, 2.7.2 in this scenario, is the runbook that will update the review activity based on the request. The review activity is configured in the service request template without any reviewers, it is the 2.7.2 runbook that will populate the list of Reviewers. A dynamic approval step J

The second runbook, 2.7.1 in this scenario, is the runbook that will grant permission to the requester. It gets the user requesting permissions and add that user to a group in Active Directory. The Map System To Group activity will decide which security group to add the user to, depending on system. In the end of the runbook it updates the service request with information that permissions has been granted and when the permissions will be removed. The Format Timestamp activity is used to get expire time for the permissions. But there is one more extra important activity in the runbook. The Write to Temp Permissions database activity. For each permission granted this activity writes a row to a SQL database.

 

Figure 3 Temp Permissions database

The last runbook, 2.7.3 in this scenario, is removing permissions. Every 10 minutes it query the Temp Permissions database for permissions to remove. If there is any permissions to remove, based on the ExpireDate column, the runbook will remove the user from the security group and remove the record in the database. There will still be logs in the technical log database for Orchestrator, more info about logs here. You will also have a work item, a Service Request, in Service Manager which information about the temporary permission, including requester, approver, description and system.

 

You can download the runbooks, 20131204_TempPermissions. Note that this is provided “AS-IS” with no warranties at all. This is not a production ready solution, just an idea and an example.