Helping the helpdesk

Summer Fun

2009-07-25T00:42:00.003-04:00

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?

2009-07-22T21:15:00.000-04:00

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?

2009-07-15T21:10:00.000-04:00

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.

Group Management Tips

2009-07-11T22:30:00.000-04:00

From time to time, a client will approach me with the need to be able to quickly and easily manage groups within a clean interface, so as not to have to deal with Active Directory Users and Computers (ADUC), or allow access to ADUC for members of the helpdesk, or other delegated staffers.

It could be something as simple as needing an interface to pull up an active directory account, view the account's current group memberships, and add or remove memberships as neccessary. This can be provided via an ASP.NET portal with an UMRA backend, or via UMRA Forms and Delegation. But what if the client needs to see only a specific group type (domain local, distibution group, etc). Active Directory is not so kind as to simply label the group types in some attribute. Thus, some simple LDAP filter must be used. This is done by using the bit values for different types of groups, and the bitwise and (:1.2.840.113556.1.4.803:) to filter the results to display only the group types we wish to see. Keep in mind, this means the bit values are cumulative.

The following is a list of group types, and their associates bit values:

Global: 2
Domain Local: 4
Universal: 8
Security Group: 2147483648
Distribution Group: none

With the above values, we can build LDAP filters for the various group types we may wish to view. Let's say we want to only view Global Distribution Groups in a table, in our Group Management interface. The filter would look like this:

(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2)(!

(groupType:1.2.840.113556.1.4.803:=2147483648))

This filter is saying "show me all global groups (=2), but NOT security groups (=2147483648)". Since distributions groups have no bit value, and we are excluding the 2147483648 security group value, the table will display all global distribution groups by a process of exclusion.

Another example would be to see a list of all Domain Local Security groups. To accomplish this, the filter would look like the following:

(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483652))

This filter takes the value for a security group (2147483648) and adds the value for a domain local group (4) to give us the proper bit value and display all domain local security groups.

For further information on group filtering and management, feel free to email me at the link in the nav bar above, or visit Tools4ever's website.

The season approaches...

2009-05-18T23:34:00.002-04:00

Summer is almost here, which means school is ending. What does that mean to us? Well, this time of year, I am usually thinking ahead to late July onward. Two words come to mind, specifically:

Busy season.

Many of our clients are school districts, and though many are moving to automated solutions, quite a few want something they have a little more control over. They want a solution that runs when they choose. Perhaps they have an older SIS system, and only get a small subset of student data on an infrequent basis.

UMRA Mass is the module for these types of scenarios. These days, Mass has lives in the shaodw of Automation, but it is still a very viable module. Say, for example, you have a txt or csv dump of some student information such as:

First Name, Last Name, Grade, Graduation Year, School Code, StudentID

This information can be used for a batch student creation process. Many schools will delete all of their student accounts at the end of the school year. With UMRA Mass and a simple input file, these accounts can be recreated in OU's with group memberships mapped from their school codes. Home directories and mail are just as simple to create.

Of course, Mass is not relgated to account creation. Just like Automation, existing accounts can be updated with file data. They can be disabled based on some criteria contained in the file, or simply by their non-existence in the file.

Mass is not a replacement for automation, buy any stretch of the imagination. But for the admin of a small school or school district that wants to do some quick, and relatively easy, bulk user data processing, Mass is certainly a good fit.

Forms - application or web based?

2009-05-16T23:05:00.002-04:00

With UMRA, you can provide an interface to your helpdesk personnel, to human resources personnel, department managers, teachers, and the list goes on. The interface can provide many functions, such as:

creating AD accounts
creating email accounts/contacts
managing group memberships
updating user information

And the list goes on and on. The interface to these types of tasks can be provided in one of two ways - web pages or a client-based application. Let's look at each of these.

Web Pages

A more versatile solution, web pages can easily be configured to merge right into an organization's existing intranet. Based in ASP.NET, the pages can collect all information entered/selected and pass it to UMRA. UMRA can then pass the information to a SQL database for use in workflow processes (more on this in an upcoming post), and effect any changes within AD, and other ODBC compliant systems. Using ASP.NET code, the end user's credentials can be used to determine what information he/she will see and can modify.

Client-based Forms

Another versatile (though not as versatile as web pages) solution are UMRA Forms. The forms are created within the UMRA console, and permissioned to various users/groups therein. End users have a small forms client installed on their local machines, and via the form permissions, they can only view/operate the forms they are given rights to. These forms can also pass data to databases, AD, and other ODBC compliant systems.

Why go with one or the other?

If your interface needs are straight forward, in the sense that you wish to create simple forms for user account creation and modification with no need of workflow, and you only need the interface for a small number of people, then this is the choice for you. Of course, this is not to say that a solid workflow process cannot be created within UMRA forms, as I have done for clients in the past with much success.

For an organization that has many levels of approval, and wishes to tie AD into other systems, web pages are the way to go. Permissioning is solid, performance is better, and deployment is not an issue. From creating a simple user account to a multi-tiered workflow, UMRA in conjunction with ASP.NET is an excellent fit.

Feel free to contact me via email for more information, or visit the links on this blog.

Streamline Manual Processes

2009-05-01T09:21:00.000-04:00

More and more businesses and schools are moving towards a “paperless” environment.

Case in point – a hospital I worked with at the end of last summer. This particular organization had an entirely manual process for account creation and provisioning. Their paper process worked along the following lines.

New employee is hired.
Determination is made if new employee needs AD account
If AD account is needed, helpdesk receives an email with basic employee information for initial account creation
Form is filled out to determine new employee’s departmental needs
Form is forwarded to new employee’s manager
Manager determines what applications new employee will need access to
Form is forwarded to application managers for approval
Application managers grant/deny access to their systems for new employee
If new employee has AD account, it is determined if he needs email, OWA access, printer access, etc. If any of these are true, helpdesk gets email with these needs so group memberships can be applied to AD account

And this is just a portion of the process. There’s also user updates and terminations that have to be handled – all manually. Since the client is a hospital, there are many regulations that need to be followed for auditing and compliance. So, you can see why the client wished to go paperless. After much planning, and many discussions, we ended up going with a web interface written in asp.net/vb with an SQL backend, using User Management Resource Administrator to pass data between the pages and AD.

The web-based workflow works in a similar fashion to the paper version, as far as the actual flow of events. The initial page allows the user to select if it is a new account, existing account that needs to be modified (access to new systems, access removed from systems, etc), or an account termination. Depending on the selection, the user is guided through the workflow process via easy to read pages with concise options on each. The proper parties, depending on selections amongst the pages, are notified of what is happening, and what they must do to complete their part in the process. Additionally, various users that are involved in the process can only see pages, and data contained therein, that pertains to them specifically.

For example, if an account request is entered into the system, and part of the request contains the selection “Grant OWA access” among other systems, when the helpdesk gets their notification email that a request is pending, they would only see that the user account needs OWA access. None of the other options selected for the account would be visible to the helpdesk user.

All items processed, approvals, denials, and the like are stored in the SQL tables on the back end. This data is viewable via web pages as well, so the “paper trail” is easy to maintain.

The above is only the beginning of what we can do using web interfaces with User Management Resource Administrator. For more information, feel free to contact me directly, or check out Tools4ever.com.

Custom Password Generation

2009-04-29T23:04:00.001-04:00

Recently, I implemented an automated user provisioning solution for a Canadian school district with User Management Resource Administrator. The client had a need for a password generation/selection scheme that could be managed in house in simple text files. According to the client, they constantly create new passwords, and add them to these password lists.

The client's need was to have multiple password lists in a text format. Each list was custom created for a specific user type. The user type was specified in the user's record in the client's back-end system. UMRA will take this information, create a user account with a randomly selected password from one of the lists based on user type.

In order to keep this simple, and managable for the client, I had UMRA use if-then-else logic to determine which password list to use. If the user account was for a student grade 3-8, the first password list, populated with short, simple passwords is used. For students grade 9-12, a list of slightly more complicated passwords is used. Lastly, teachers have a seperate password list for UMRA to choose from.

Once the list is selected, it is loaded into a generic table within UMRA. Using "Manage Table", aa row count for the selected password list is determined and the value is stored in %RowCount%. UMRA then generates a random number ranging from 1 to %RowCount%(e.g. 51). The randomly generated value corresponds to a row in the selected password list, the password is then selected, and stored within the %Password% variable.

All passwords selected from these lists for new users are also included in a Master Password list. This list is an export containing the account username, first name, last name, password, location, and grade. This information is provided to the corresponding school Principals, the network admin, and the school board.

Keep your users happy

2009-04-28T20:15:00.001-04:00

Administrators face more challenges than laymen may realize. Users come to work or school, log in to their computers, and voila! Everything works (generally), like magic.

But how are hundreds or thousands of users able to function so easily day-to-day? IT staff are highly trained professionals that keep the entire network and all associated resources running, so to the end user it appears seemless. Generally, this is a manual (or manually scripted) process.

More and more administrators are looking to third parties to automate the drudgery of creating, updating, and deleting user accounts within their organizations. And, more and more administrators are turning to User Management Resource Administrator (UMRA), by Tools4ever.

With UMRA, you can automate all account lifecycling in your organization, freeing administrators to handle other, more complicated and critical tasks. From your HR/SIS to AD, and even to other systems, UMRA can create, provision, update, and disable users, as needed. Information from these user accounts can be propogated to other systems within your organization, such as web portals and other applications.

It does not have to end there. How often are end users contacting you (or your helpdesk) for a password reset? Why not put the ability to reset a password into the user's hands? With Self Service Password Reset Management (SSRPM), a user can reset their password via a "Forgot My Password" button on the Windows GINA, or logon screen. Additionally, a password reset web portal kiosk could be set up, and any user enrolled in the program can reset their password without needing to access their workstation.

To take this a step further, why not integrate the SSRPM web interface into your existing Exchange Outlook Web Access? Users load the OWA page, and have the option to enroll into the SSRPM service. If they are already enrolled, they can reset their domain password via a "forgot my password" link, and enter OWA once the reset occurs.

UMRA and SSRPM are only two of many identity management/access soultions that Tools4ever offers. For more information, go to http://www.tools4ever.com/.