System Center Orchestrator and Service Manager
Morning,
Haven't posted in a while so here goes.
I've been tasked with looking into automation of various tasks in our environment. I found three processes which would clearly benefit from automation.
1. User onboarding
2. Group management
3. VM creation.
So with item one; user on boarding we already automate the majority of this using PowerShell scripts to do the grunt work so whilst things could be improved here I wanted to make something new.
So I looked into both Group Management and VM Creation.
I've heavily copied from various sources for both run books. Big thanks to those who post their skills and knowledge so that others can learn too!
The run book used to added users to a group uses a MSSQL database table to maintain a record of who was added, to what group and when. This run book is fired off from Service Manager web portal.
A second run book is used to check the database every hour and removes users from the any groups when needed.
The IT team have two accounts, a standard account; with email, web access etc...and an "admin" account which has no email/web access. The run book targets the "admin" account for elevation. Firstly if you do not have an "admin" account you cannot use this run book to elevate your privs. Secondly it is not a great idea to have elevated accounts which have email accounts, IMHO.
My run books are not pretty and do not contain any error checking/logging. However it does work for us.
I am assuming that you have created connections to your domain and to your Service Manager server and have knowledge of SMTP and MSSQL connection settings.
The DB I use is a 2008 MSSQL database where the scorch account has full permissions. The DB contains a table called Group_Membership which has four columns keyed on SR_ID;
Value : {related Object Guid from "Get Group Relationship"}
Value : {related Object Guid from "Get Parent SR Relationship"}
Value : {related Object Guid from "Get User Relationship"}
Name : Sam Account Name
Relation : Equals
Value : {Display Name from "Get Group Object"}
Again properties tabs needs you domain connection and the filters tab is as follows;
Name : Sam Account Name
Relation : Equals
Value : prefix-{First Name from "Get User Object"}
Group Distinguished Name: {Distinguished Name from "Get Group Object"}
User Distinguished Name: {Distinguished Name from "Get User"}
Hours:+{PeriodRequired from "Initialize Data"}
SR_ID : {ID from "Get SR Object"}
GroupName : {Group Distinguished Name from "Add User to Group"}
ExpireDate : {Format Result from "Format TimeStamp"}
UserName : {User Distinguished Name from "Add User to Group"}
I used information from the SR to personalise the email
<p>Hello {Display Name from "Get User Object"}</p>
<p>This is an automated response.</p>
<table>
<tr align=left>
<th>Account</th>
<th>Group</th>
<th>Date for removal</th>
</tr>
<tr>
<td>{Display Name from "Get User"}</td>
<td>{Display Name from "Get Group Object"}</td>
<td>{Format Result from "Format Time"}</td>
</tr>
If a user requests admin to their local machine (horror!) we use the same GPO to allow local admin priv to a discrete machine. Nice as a Power Shell report is run showing who has local admin and where.
Again both of these techniques are easily found on the web with a quick google search.
Haven't posted in a while so here goes.
I've been tasked with looking into automation of various tasks in our environment. I found three processes which would clearly benefit from automation.
1. User onboarding
2. Group management
3. VM creation.
So with item one; user on boarding we already automate the majority of this using PowerShell scripts to do the grunt work so whilst things could be improved here I wanted to make something new.
So I looked into both Group Management and VM Creation.
I've heavily copied from various sources for both run books. Big thanks to those who post their skills and knowledge so that others can learn too!
References
Automys's awesome site https://automys.com/library/category/system-center-orchestratorGroup Management
It has always been an aspiration of mine to run an IT team where the least privs model actually worked. So I wrote a run book - heavily copied from various sources which I will name later which allows for a user to elevate their privs for a set time.The run book used to added users to a group uses a MSSQL database table to maintain a record of who was added, to what group and when. This run book is fired off from Service Manager web portal.
A second run book is used to check the database every hour and removes users from the any groups when needed.
The IT team have two accounts, a standard account; with email, web access etc...and an "admin" account which has no email/web access. The run book targets the "admin" account for elevation. Firstly if you do not have an "admin" account you cannot use this run book to elevate your privs. Secondly it is not a great idea to have elevated accounts which have email accounts, IMHO.
My run books are not pretty and do not contain any error checking/logging. However it does work for us.
I am assuming that you have created connections to your domain and to your Service Manager server and have knowledge of SMTP and MSSQL connection settings.
The DB I use is a 2008 MSSQL database where the scorch account has full permissions. The DB contains a table called Group_Membership which has four columns keyed on SR_ID;
Add User to Group Run Book Overview
Here is the workflow of the run book which is called from Service Manager and actually adds the user to a group, records this in the database and then sends a friendly email to the end user. Below this I detail the settings of each step in the run book.
Initialize Data
This is the information received from Service Manager mapped into Orchestrator.
Get Group Relationship
This sets up the relationship to be able to grab the AD group data from the Service Manager SR
Get Group Object
Actually get the group information from the SR - I added a check for failure here. Mainly for testing purposes.Value : {related Object Guid from "Get Group Relationship"}
Get Parent SR Relationship
Set up the relationship for the actual SR
Get SR Object
Actually get the SR dataValue : {related Object Guid from "Get Parent SR Relationship"}
Get User Relationship
Set up the relationship for the AD User account
Get User Object
Grab the AD user account information from the SRValue : {related Object Guid from "Get User Relationship"}
Get AD Group
Find and return the AD group requested - only showing the filters tab here, clearly the properties tab should be filled with your connection to your domain!Name : Sam Account Name
Relation : Equals
Value : {Display Name from "Get Group Object"}
Get User
Find and return the actual AD User object - here I manipulate the username to append our "admin" prefix. This allows me to find the admin account for the user rather than the standard account. Nice.Again properties tabs needs you domain connection and the filters tab is as follows;
Name : Sam Account Name
Relation : Equals
Value : prefix-{First Name from "Get User Object"}
Add User To Group
Add the user to the group!Group Distinguished Name: {Distinguished Name from "Get Group Object"}
User Distinguished Name: {Distinguished Name from "Get User"}
Format Timestamp
Add those hours to the current date - the format is really important here and I spent a while getting this right. MSSQL requires the format to be correct to be able to store as a date in the DB.Hours:+{PeriodRequired from "Initialize Data"}
Write To Database
Write out all required information to the database, clearly setup the connection tab as required.SR_ID : {ID from "Get SR Object"}
GroupName : {Group Distinguished Name from "Add User to Group"}
ExpireDate : {Format Result from "Format TimeStamp"}
UserName : {User Distinguished Name from "Add User to Group"}
Send Email
Send out a nice email to the userI used information from the SR to personalise the email
<p>Hello {Display Name from "Get User Object"}</p>
<p>This is an automated response.</p>
<table>
<tr align=left>
<th>Account</th>
<th>Group</th>
<th>Date for removal</th>
</tr>
<tr>
<td>{Display Name from "Get User"}</td>
<td>{Display Name from "Get Group Object"}</td>
<td>{Format Result from "Format Time"}</td>
</tr>
Remove User from Group Run Book Overview
This run book runs every hour and removes expired users from groups as detailed in the database. Once you had completed the configuration of this run book remember to run it! This run book needs to be running all the time.
Check every Hour
Basically that.
Find Expired Permissions
A Query DB Activity set as follows. Remember to configure the MSSQL connection details!
Query : SELECT * FROM dbo.Group_Membership WHERE ExpireDate < GETDATE()
Get User
Extract the username from the DB select statement
Search Root : [FIELD({Full line as a string with fields separated by';' from "Find Expired Permissions"},';',3)]
Get Group
Extract the group name from the DB select statement
Search Root : [FIELD({Full line as a string with fields separated by';' from "Find Expired Permissions"},';',2)]
Remove User From Group
Group Distinguished Name: {Distinguished Name from "Get Group"}
User Distinguished Name: {Distinguished Name from "Get User"}
User Distinguished Name: {Distinguished Name from "Get User"}
Remove from DB
Another Query Database Activity, DB connections required as normal
Query : DELETE FROM dbo.Group_Membership
WHERE SR_ID = '[FIELD({Full line as a string with fields separated by';' from "Find Expired Permissions"},';',4)]'
Send Email
Again a nice email for our end user, no HTML this time though :)
Hello {Display Name from "Get User"}
Your account has now been removed from the group {Display Name from "Get Group"}
Tying this to Service Manager
Now need to actually get information from the user and into the run book. This is done using Service Manager - in my case.
I am assuming that you have your Service Manager all setup for synchronising your run books so I wont go into that - if not then there are plenty of great articles on the web to help you.
Group Policy Objects
I coupled this with a cool GPO setting and now I have all my team as admins on every Server and Client but without having Domain Admin unless they request it through Service Manager.If a user requests admin to their local machine (horror!) we use the same GPO to allow local admin priv to a discrete machine. Nice as a Power Shell report is run showing who has local admin and where.
Again both of these techniques are easily found on the web with a quick google search.
Comments
Post a Comment