Summer Fun

The summer time means vacations, no school, hitting the beach, and all kinds of great fun. Unless of course, you are a system administrator for a school district. The summer then means you are squeezing in every major project that you can before school starts up again in August or September, depending on the region in which you reside. As such, the last thing you have time for is dealing with student active directory accounts.

Yet, you will have an influx of new students. And depending on your organizational unit structure, you may need to roll over these accounts into new OU’s based on graduation year or grade level. Maybe these grad year or grade level OU’s are within a higher level OU for each school in the district. Perhaps each grad year or grade level has a specific share somewhere, on which the user’s home directories must reside. These home directories need to move with the student throughout his or her career in the district. Then, of course, there are group memberships, which most likely created within the same design as the OU structure.

Manually provisioning all of this can take weeks. Scripting these tasks in visual basic is slow and tedious as well. With User Management Resource Administrator’s Automation module, you can streamline these tasks, and have them occur on a scheduled basis. Here is a high level overview of such a process:

• UMRA queries the SIS system, or csv export of student information
• This data is compared to AD
• New accounts are created based upon existence in the SIS system and not AD
• Updates to accounts occur based upon existence of the user in the SIS and AD
• Account disables are based upon either an inactive flag in the SIS, or the lack of the account existing in the SIS when it exists in AD

Processes for group and home directory provisioning can be based up a graduation year or grade level, even if this information is not necessarily provided (to be detailed in a coming post). Automation can be scheduled nightly, or more or less frequently as needed. All actions against AD accounts and their resources are logged for auditing and troubleshooting purposes. It can even generate email alerts for you.

You are now free to (not) enjoy your summer break doing other tasks.

You’re welcome. ;)

AD and beyond?

In past posts, I’ve talked about the User Management Resource Administrator automation module in terms of synchronizing data between some human resources system (or student information system) and active directory. Via either a scheduled export of employee or student data, or a direct connection to the database, UMRA creates and provisions user accounts for their entire life cycle in an organization. And generally, this is enough for most small organizations.

But as more and more larger organizations come to us for automated identity and access management, the more I am seeing that these organizations want to synchronize the data “past” active directory., or past the Microsoft network. Of course, this is something UMRA can accommodate.

For example, perhaps you have a custom web application built in-house. This web application allows for your end users to see certain demographic information about themselves. They can modify this information, and upon submission, submit the changes to their active directory account.

With an automated provisioning solution in place, your human resources system is the “master” source for employee information. UMRA synchronizes this on a scheduled basis (nightly, perhaps) with AD. Now, if your users are modifying their information during the course of the work day, this information will be overwritten on the next automation run with the data contained in the HR system database. UMRA automation can be configured to ignore these demographic, non-critical pieces of information during the nightly process. The only issue with this is that they would never be regularly updated. Only changes made via the web application would modify the data.

Alternatively, we can tie-in UMRA automation projects on the back-end of the in-house web app. These projects would capture the data entered into the web application, and propagate the changes not only to AD, but to the HR system database. This is only the beginning of what can be done with UMRA automation.

In coming posts, I will discuss synchronizing data with various other systems. If you want further information, feel free to send me an email.

Automation vs Workflow?

Two of the most common solutions we at offer for active directory account management are automation, and approval-based workflow. But how to chose one over the other?

Automation - Data is retrieved via a query to the HR system, or from a text or csv dump from said system. This information is used to create and provision accounts in AD, modify accounts as HR data changes, and disable and/or purge accounts for user terminations. All of this, of course, happens automatically on a scheduled basis.

Approval-based workflow - Forms, usually web-based, are accessed by someone usually in the human resources department. The HR employee enters information for the new employee intothe form, and this data is submitted for approval (usually multiple levels of approval). Upon approval, accounts are created and provisioned, updated, or disabled.

So which is a better solution? Well, why chose one over the other, and not both?

UMRA's automation module can be configured to query the HR database, and compare the user records found therein to active directory. Then the following would occur:

• Employee record is in the HR system, but there is no AD account - the account would be slated for creation in AD
• Employee record exists in both systems, but data has changed for the employee in the HR system - the AD account would be slated for an update, using the HR data as the master
• Employee record is set to inactive in the HR system, but is enabled in AD - the AD account is slated for a disable, based on organizational policies

Normally, automation would immediately effect the above, and notify the appropriate parties upon completion. But in this scenario, the organization needs approval for all actions regarding employee records and AD accounts. As such, the following would occur:

• Employee record is in the HR system, but there is no AD account - the account would be slated for creation in AD, and the information needed to create the account is stored in a SQL pending request database table. The appropriate party can view the request, and approve or deny as necessary. Upon approval, UMRA creates the account according to agreed upon specifications.
• Employee record exists in both systems, but data has changed for the employee in the HR system - the AD account would be slated for an update, using the HR data as the master and the information needed to update the account is stored in a SQL pending request database table. The appropriate party can then view the request, and approve or deny as necessary. Upon approval, UMRA updates the account with any new information provided by the HR system.
• Employee record is set to inactive in the HR system, but is enabled in AD - the AD account is slated for a disable, based on organizational policies and the information needed to create the account is stored in a SQL pending request database table. The appropriate party can view the request, and approve or deny as necessary. Upon approval, UMRA disables the account according to agreed upon specifications.

This provides less work for the HR and IT departments, but still allows the chain of command to do what it was intended to do. For further information on a solution like this, do not hesitate to email me via the link in the nav bar above, or visit Tools4ever.com.