Reprovisioning & Change Management

November 4th, 2009

Apologies readers for the prolonged silence on this blog. Let me pick up the discussion from where I left in my last post.

We already talked about the need for request management and customized workflows. Next I want to talk about re-provisioning or maintenance of OCS configuration for user accounts.

On a typical day, IT help desk in a mid-to-large enterprise handles hundreds of support incidents related to user configuration updates. Depending on the business rules and regulations some of these updates can be continually complex and time consuming. These updates often fall into three broad categries:

  1. Updating the use configuration settings for a user. A user may have been promoted or moved to a different project and hence the entitlements for the user have changed. Or, may be the user account was mis-configured to begin with and now needs to be synchronized with their entitlements and configured accordingly. In either of these scenarios an administrator has to manually fix the configuration settings for the user account.
  2. Often system administrators do a phased roll out of various OCS features. They start with a initial set of features for a small group of people and then later expand the coverage to a bigger group with more and more features. Planning a phased rollout has always been a maintenance nightmare for administrators.
  3. Additionally, system administrators are continually improving the business processes which eventually results in changes in entitlements for existing users or re-provisioning of user accounts with new configuration settings on different server pools.
    The provisioning system should be extensible enough to adapt to the enterprise’s specific needs not just from an initial on-boarding perspective but also as an ongoing update to enforce the rules and policies for all users.

Ensim Unify enables system administrators to automate several maintenance processes which can be configured to ensure that everybody’s entitlements are enforced in the account settings. For example – if the SIP URI for a user is configured to be same as their email address, the maintenance jobs will ensure that this rule is enforced at all times. Any inconsistencies or mis configurations in the deployment will be detected and corrected by the system without requiring any administrator intervention.

agupta Uncategorized

OCS User Provisioning Considerations - Customizable Workflows

September 23rd, 2009

In my last post we discussed various considerations around request management and how administrators can use Ensim Unify to quickly integrate OCS user provisioning with their existing provisioning request management. Once administrators have overcome the integration with their request management systems, the next challenge they face is how to customize the provisioning workflow based on various business rules and policies.

Issue #2 : Customizable provisioning workflows
Most enterprises have various business rules and regulations which drive entitlements for all users. In regulated environments these rules can be very complex and strictly enforced. Typically these business rules define the various OCS options that will be enabled for each user and the OCS server pool on which the user account is provisioned. A global enterprise can have various considerations like - geographical location, SLA committed, department or project group in determining the server pool location while processing the provisioning request. Similarly, OCS entitlements could be a combination of some of these considerations.

The one-click template based provisioning from Ensim Unify allows system administrators to integrate Ensim Unify with their entitlement engine and at the same time hide the complexity from junior administrators . Additionally, Ensim Unify offers automated capacity management to implement OCS server pool location based on various internal rules.

Provisioning is not a one-time event. Re-provisioning and addressing daily moves, updates and changes continually takes up administrator’s time and attention. In my next post I will address some of the issues around change management and how Ensim Unify addresses those issues.

Amit Gupta
Director – Product Management
Ensim Corporation
Email: agupta@ensim.com

agupta Uncategorized ,

OCS User Provisioning Considerations - Request Management

September 2nd, 2009

Over the past few months, we have helped several Fortune 100 customers get a handle on their OCS provisioning and ongoing management of user changes. Because the process was so interesting and insightful, I wanted to relay the key issues that we solved in some of these OCS deployments in the hope that many of you will be able to better prepare for these – you won’t be able to avoid them, but knowledge is half the battle. I’ll break each issue in an article of its own and try to provide as much details as possible.

Planning an OCS deployment and rollout for a mid to large enterprise (anything over 10,000 seats) is complicated at best, daunting at its worst. System administrators have to carefully evaluate the capacity requirements, network topology, telephony deployment scenarios and various other considerations before they can put together a project plan for OCS rollout. As administrators plow through various stages of this plan, they almost always neglect the provisioning or on-boarding process, which eventually becomes a gating item for their rollout.

While some administrators may be able to work around the provisioning challenges by working through the native Active Directory or OCS management interface, for most mid to large organizations it will be almost impossible to handle all the provisioning requests manually.

Issue #1: Integration with existing systems

Each enterprise has an existing mechanism for triggering the new-hire or on-boarding request and this request management mechanism should be updated to address OCS provisioning for new hires. System administrators, typically, would have a tailored request management system, however in most cases it is a variation of the following few scenarios:

• Often HR system is the first IT system that gets seeded with the new hire information and from there on a request is triggered to provision various IT services like mail, telephone, access card etc for the new employee. Some of these services might require some manual approvals and might be addressed offline. An administrator will have to augment this new hire process to further add OCS provisioning requests for new employees automatically based on their entitlements.

• Because of additional Microsoft CAL implications some enterprise may not want to roll out OCS for all employees and may want to implement a charge-back mechanism for business units or cost centers before OCS access is enabled for requested employees. Typically, in such cases an administrator has to update an existing (or build a new ) intranet website for managers to request OCS service for their direct reports or setup a self registration page for employees. These intranet pages should be further integrated with the charge back systems to make sure that the cost center or the business unit is billed accordingly.

• Additionally, an enterprise might have an ERP system or identity management framework implemented which will have to be updated to trigger OCS provisioning requests as new identities are created in the IT systems.

Ensim Unify OCS Manager has robust extensibility through web service APIs. These APIs implement most WS-* standards enabling inter-operability with any existing system and allowing system administrators to address any of the scenarios mentioned above. More technical details will follow in some of the subsequent articles.

While this is just the first aspect of OCS user provisioning, it is clear that system administrators should include user provisioning in their upfront planning to avoid any hiccups during the rollout.

Amit Gupta

Director – Product Management

Ensim Corporation

Email: agupta@ensim.com

agupta Uncategorized , , , ,

Sys Admins Day - What is it that you need?

August 5th, 2009

It’s now on my calendar, SysAdmins Day - its the last Friday of July and believe it or not - we just celebrated it. I found this in one of the blogs I often read. However, it was the comments that I enjoyed most; one said:

“I’m an IT guy, if you want to appreciate me, then for one day stay away from my desk, my phone number, and my email address. That will be appreciation enough.”

I laughed to myself, but I can see his point - just think about all the responsibilities a System Administrator has:

  • staff training and support
  • software installation, maintenance, and upgrading
  • hardware installation, maintenance, and upgrading
  • research and trouble shooting
  • routing network administration and maintenance
  • network documentation and network management in some cases
  • database supervision
  • etc. etc.

Depending on the size of your organization, the tasks, complexity and workload increase. So “hats off” to the IT professionals out there. There are companies out there trying to make your life easier.  ;-)

mgallegos Uncategorized ,

Departing Employees and CICO Systems

July 29th, 2009

A recent posting in Federal Computer Week: 6 steps to cutting the cord to departing employees by Alan Jock, brought up several questions. Alan points out numerous concerns of faulty de-provisioning with departing employees and lists a number of steps that should be taken to deal with exiting employees. To paraphrase:

  1. Managers enter exiting employees name and departure date into CICO system (Check In Check Out) and review list of assets the employee was assigned during employment.
  2. The CICO system sends automated e-mail alerts to departments related to exiting employees.
  3. Managers match employees assets list with actual assignments to find a more complete list of resources and access rights in the exiting employees possession.
  4. The fourth step creates work orders for staff members to recover or deactivate each of the assets identified in the previous steps.
  5. In the CICO process, managers update the check-out work orders to indicate status for retrieved or deactivated resources.
  6. On the last day of employment HR reviews the checklist to flag and act on any missing elements in the CICO process.

This seems like a pretty straightforward set of steps in a fairly complex workflow that is part of a completely custom system. All this effort is designed to simply de-provision an employee. This brings up several questions: why is it so complicated and why does it need so many steps that require human intervention?  How would a system like this be audited? What are the security risks?

In a enterprise grade provisioning system, all the information regarding access, assets, and entitlements needed to de-provision a departing employee should already be there. All the policies should already be in-place and in-force. If all the information needed is already there, then any HR person should be able to press a button and de-provision the employee based on those established IT policies. (Immediately remove permissions and access, archive email and forward for a period of time, allow managerial access etc., etc.)

Workflow systems that generate work orders and send email to accomplish tasks are, by definition, less secure then a provisioning and access control system that completes these tasks without requiring human intervention. It would also seem less costly then maintaining a system such as this and might even help streamline existing processes. Food for thought.

mgallegos Uncategorized

HIPAA and the Risk Equation

July 7th, 2009

In a recent posting by Greg Masters of SC Magazine, HIPAA compliance was the focus of the discussion around compliance and risk mitigation. Even though enforcement actions have been minimal and HIPAA appears to really only provide general security guidelines specific to the health care; we see an increasing burden on IT to “prove” that it can protect sensitive patient data. We also see the major “risk” to health care organizations not from direct enforcement actions, but from lawsuits brought by patients who were damaged in some way when their medical records were compromised. Costs there could be quite high.

Mr. Masters brings up two very important points related to general security and risk mitigation that affect IT:

  • the requirement that employees change passwords every 60 to 90 days
  • increasing policy awareness among employees related to data sensitivity

Both points can substantially increase the burden on IT to ensure compliance with established policy. (This assumes that those policies are there in the first place.) Software designed to “ensure” that these policies are enforced can make a huge difference in the amount of overhead required. In addition, this makes self-service operations like password reset even more important.

These capabilities can make IT’s efforts to manage and mitigate risk much more effective as well as decrease the burden. It should come as no surprise that we recommend IT look for solutions that automate these activities wherever possible. Do you have any other suggestions?

mgallegos Uncategorized ,

What do you mean… you accidently deleted the OU?

July 1st, 2009

Most people would be amazed at how often this happens. Many senior system administrators have probably already been through it - that accidental deletion of an organizational unit (OU) in Active Directory. It can be accidental fat finger where someone is in the process of deleting a single user and accidentally deletes the whole OU.

The people that have been through it are cringing right now remembering when it happened. The ones it has not happened to are in blissful denial. You can hear them saying: 0ur people are seasoned pro’s, no one makes those kind of mistakes, it can’t happen here, we have trained people, we have procedures to prevent that, that will never happen to us… However, the truth remains that at some time in your IT career, more than likely, you’ll have this unfortunate experience. Hopefully, just once.

As Jan De Clercq notes in his post “How can I protect Active Directory (AD) objects such as organizational units (OUs) from accidental deletion by administrators?” it’s pretty difficult to UNDO this mistake. It usually means some restructuring etc. It also seems to us that trying to protect objects on an individual level could get cumbersome, but that approach is better than hoping nothing goes wrong.

This is why we stress protecting AD on a programatic basis using your existing policies. This is the only way you will truly save your active directory from “unauthorized” changes. Additionally, it will open up a host of time saving and more secure options for operations like the provisioning / de-provisioning process - things like eliminating orphan accounts etc. More on that later…

Scott Young Uncategorized

To Script or Not to Script

June 26th, 2009

We still see a fair number of organizations using scripts to automate the IT processes including management of Active Directory (AD). This is often the first line of defense when using the native interfaces for user management becomes too time-consuming or too much of a security risk when the established procedures (if they exist) are not being followed.

In the right circumstances and with the right skills, scripts can help IT cover specific tasks. A couple of questions to take into consideration:

  • Do the scripts have error checking?
  • Do the scripts produce audit trails that will satisfy compliance requirements?
  • Scripts need to run on each server - are they all the same version?
  • Have they been adequately tested?
  • If a script fails, does it have a recovery process that can back-out changes?
  • If you upgrade the applications, do the scripts have to be rewritten?
  • Do you understand the scripts well enough to revise them if the person who originally wrote them leaves?
  • Are the programming skills of the administrative staff at the right level for the task?

These are just a few things to consider. There are some great scripting languages out there. PowerShell is certainly one. Depending on the size of your organization and the complexity of your requirements, scripts can solve certain set of problems. This assumes your group has the time to code and maintain them. On the other hand, if you have specific policies to implement, audit/compliance requirements, and a fairly dynamic user base, the do-it-yourself approach may not be the best option. If that’s the case, you might want to consider a solution that was designed from the ground up to solve these problems.

Scott Young Uncategorized

IT Gone Bad

June 18th, 2009

Doug Barney’s Blog had a very interesting post on the topic - “if IT is policing security, who is policing IT” (my paraphrase) — IT Good and Bad.  Its an issue that, as you would expect, we run into on a regular basis; usually in clean-up mode after there’s been an incident. We won’t add to the numerous stories of a few IT Administrators and their wayward ways, however its important to point out that this happens pretty frequently.

The key to remember is that, from our perspective, IT’s access (and everyone else for that matter) should be limited to what they need to be able to effectively do their jobs. This is true not just for security reasons, but for compliance and overall operational reasons as well. If all your admins have privileged accounts (including access to the native interfaces), you will eventually have problems. These can be as simple as misconfiguration or as nasty as a security breach.

Keeping your systems safe is a policy matter that should be reflected in software designed to protect and insulate these mission critical systems. It can also save you lots of time.

mgallegos Uncategorized

Exchange 2010 Migration Creates IT Strategy Discussion

June 9th, 2009

With the beta release of Exchange 14 (officially Exchange 2010), the migration drumbeat has begun. However,  strategy sessions in many organizations are coming up with more questions than answers.

Noting that these larger players often have existing investments in OCS (some with LCS), SharePoint, and Exchange (2003 and 2007), they are looking at how this migration will affect other collaboration applications as well as the management overhead required by newer, feature-rich versions of these favorites. Of the organizations still on Exchange 2003, many are reviewing the idea of embracing cloud services and are considering offerings from both Google and Microsoft for certain groups of users. Additional complexity comes from teams that would like to see tighter telephony integration - the unified communications (UC) approach. Planning for UC implementations have always required longer timelines and application level expertise.

We are experts in all these types of implementations and have a long history of supplying management tools designed to address just these types of complex implementations. If your organization is considering any of these options, please don’t hesitate to let us know. I’m certain we can help.

Scott Young Uncategorized