Archive for the ‘Best Practices’ Category

Novell IdM – Implementing Remote Loader on Microsoft Windows

Tuesday, August 2nd, 2011

When implementing Novell’s (or NETIQs) Identity Manager product there are times when a certain connector(s) must be run on the MS Windows platform. If Meta-Directory Engine is running on a Linux (or other non-Windows) platform the requirement is the use of the Remote Loader. When asked if it is better to run the Remote Loader on a Windows Domain Controller or simply on a Windows Member Server, the answer is to run it on a Member Server for several reasons:

  1. Most organizations maintain a very controlled environment particularly when it comes to what is installed on Domain Controllers.  Most organizations will not allow a service such as the Remote Loader (RL) to run on said Domain Controllers.  As a result it is generally required, due to policy, to run the Remote Loader on a Member Server.  
  2. Additionally, through experience, we have found over the years that due to patching and security controls that take place specific to Domain Controllers it becomes more efficient, in terms of over-arching stability, to run the RL on a Member Server.  
  3. Lastly, the separation of duties between the Active Directory team and the Identity Management team generally makes life easier to manage the RL if it is running on a Member Server (i.e. less political).

Another advantage of running the RL on a Member Server is the ability to run the RL in a clustered environment. Member Servers may be configured in a Microsoft cluster with instrumental registry keys for password synchronization configured as a clustered resource.  This will allow the Domain Controllers to communicate with the clustered resource for password synchronization to the Identity Vault and it will allow the Identity Vault to do the same.  This is a configuration that is supported by both Novell and Microsoft and is considered to be the best way to provide password synchronization failover.

Questions, comments or concerns?  Feel free to reach out to us at IDMWorks.

Best Practice Role Management Methodologies

Tuesday, July 26th, 2011

When developing Roles within an organization it is important to pre-select the proper Role Management Methodology for use on your project and for ongoing operations once your roles are ready to go live.  There are two approaches that can be used when developing access roles for a company or organization:

  • Top down – With this approach uses a pre-defined method of organizing user access based upon known or developed plan.  An example of this would be: defining user access based upon job function and what access that job requires as the method of organizing people into roles.
  • Bottom up -  With this approach you examine what access people currently have and assign roles based upon what rights those users have. An example of this would be: discovering what rights all (or a group) people have and selecting common access rights for the role being developed.

Both of these approaches have merits and drawbacks associated with their use such:

  • Top down

+  Most effective and comprehensive method of role development

+  Aligns access rights and compliance to business goals regarding compliance

-  Requires business and organizational understanding of access rights at the site

-  Requires significant time in role development before implementation

-  Often difficult to quantify all role assignments and proper access

-  Complexity often leads failure role development or “stuck in the weeds”

  • Bottom up

Quick role development

-  Highly difficult to quantify specific access rights for the roles developed

-  Requires access and mining of specific access data

-  Difficult to align business objectives and compliance with developed roles

It is has been my experience that using a hybrid approach using the following methodology will make a role discovery project successful:

  • Top + Bottom Role discovery – This method uses one or more business or organizational top down role methods and follows with a bottom up approach for discovery and verification.  An example of this would be: take employees job codes as the basis for role creation and locate the access rights associated with the job codes.  Use manual or campaign determination of proper access rights for the roles developed.
  • 80 / 20 Rule - The goal should not be to develop roles for every person at the company or organization.  The goal is provide the most role value by locating access right combinations that cover the majority of individuals.  Implement these effective roles quickly.  Address the exception or difficult to quantify roles later (or when possible).  For example: CEO is not a role, it is a unique job function or more accurately an “exception role”.
  • Phased approach – It has been my experience that role implementation encompassing the entire organization often fails due to the time and complexity required to complete.  Political and/or procedural roadblocks appear, addition of access endpoints and role function or purpose questions occur.  You should implement roles across focused areas of the company or organization where goals are well understood and attainable.

Questions, comments or concerns?  Feel free to reach out to us at IDMWorks.

Oauth vs. Xauth – When to pick the “O” vs. the “X”

Tuesday, May 31st, 2011

Oauth vs.Xauth (Open Authorization vs. Extended Authorization), there have been wars fought over less.  while  not getting into the philosophies that separate the two sides let’s start by looking at them as two separate tools.

The analogy is as follows: I can appreciate a good flat head screw driver and I believe there are jobs that require a Phillips screw driver. And while many Phillips screws can be worked with a flat head screw driver a Phillips screw driver won’t work on a flat head screw.

Such is the case with Oauth and Xauth.  Both will accomplish sign on using an Oauth token, however Xauth is more a form of Oauth light, only really appropriate in a small percentage of applications.  But be aware you still need to understand the Oauth authentication process, even when using Xauth.

Xauth is typically used for mobile and desktop applications that don’t use a browser directly.  Oauth is used for browser based authentication.  But this may be too much of a simplification.  I prefer that Xauth is used when Oauth can’t be used.  And when using Xauth you must also figure out how to dispose of the name/password that was used to retrieve the token.

Questions, comments or concerns are always welcome.  Feel free to reach out to us at IDMWorks.

Testing Your ABAC (Attribute Based Access Control) Solution

Thursday, May 26th, 2011

When testing your ABAC (Attribute Based Access Control) or PBAC (Policy Based Access Control) vendor solutions you have or will have a few items to consider.  The chief one being, will what we have bought or built suit our needs?

As was stated in an earlier blog, there are quite a few vendors to start looking at in the ABAC field including Axiomatics, Bitkoo, Oracle, CA, Jericho Systems,Vordel, Cisco, Siemens, Epok, Layer 7, Quest, Pericore, NextLabs and IBM.

But for today’s entry I wanted to throw out a few tools I have worked with to test the messaging between the PEP (Policy Enforcement Point), the PDP/PDS (Policy Decision Point/Service), the Attribute Stores and the Policy Services.

I realize a quick list only scratches the testing service as fully defined test cases building off of both operational and system requirements is a necessity but I wanted to highlight a few tools and their basic functionality for those about to go down this path.  Feel free to sound off below and add your own tools and test mechanisms.  I might just update to entry to reflect them.

Tool Description
Parasoft SOATest
  • Used to conduct functional, operational, and performance testing
  • Used to test message layer functionality by utilizing Web Service Description Language (WSDL) to generate client tools to automate testing for Web services
  • Used to record end-user Web application interactions for playback to examine system behavior and performance
Parasoft Load Test Verifies application performance and functionality under heavy load. Existing end-to-end functional tests are leveraged for load testing, removing the barrier to comprehensive and continuous performance monitoring.
TCPMon Used to monitor traffic on TCP connections
Wireshark Used as a network protocol analyzer for Unix and Windows
soapUI Used to conduct functional testing of Web Services including SOAP and REST
NMAP Used to capture IP packets to determine what services (application name and version) the vendor applications are utilizing
NCES CTK Used  for testing coverage for the service request and the service response within NCES

The long and short of it is that you want to have the ability to test SOAP, SAML and most importantly XACML messaging within your solution

As always, questions, comments or concerns?  Feel free to reach out to us at IDMWorks.

Novell IDM Entitlement DN & Stylesheets

Tuesday, May 10th, 2011

Entitlements can be a bit quirky in driver policies.  Drivers have the ability to add an entitlement from that driver to an object but they don’t have the ability to add a different driver’s entitlement or remove an entitlement through policy.  When a situation occurs where entitlements have to be added or removed that can’t be done through policy that’s when you call in stylesheets.  Stylesheets are flexible and powerful tools in the driver’s toolbox but they are not as user friendly and require advanced developer knowledge over standard policies.

Stylesheets can suffer from an annoying issue if they contain hard coded object DNs in the XML.  The issue is that when the stylesheet is migrated from one environment to the next the object DN(s) aren’t detected correctly after migration.  I have seen it a number of times where an object DN is the same in a QA and Production environment, the stylesheet tests fine in QA, but when migrated to Production the stylesheet doesn’t execute correctly. And the odd thing is in this situation that when you review the driver logs the DN is correct in both the input doc and the stylesheet.

The quick and dirty fix is just to copy the desired object DN from the input doc in the log, paste it in the stylesheet, and restart the driver.  Even though the values are the same this process corrects the issue and after a driver restart the stylesheet will operate as expected.

There is a better approach to avoid this issue. As with most values, it is better to use variables instead of hard coding values like object DNs in your logic.  The cleaner, more reliable solution is to create a Global Configuration Variable (GCV) on the driver, or driver set depending on your needs, for each of the DNs and then just reference the GCVs in the stylesheets.  This allows the stylesheet to be migrated between environments without risking the DN values should they be different between environments or DN value recognition for hard coded values.

Below is an example of how to reference a GCV in a stylesheet:

<xsl:when test=”(component[@name='volume'] = ‘~Entitlement_DN_GCV~‘)”>

Notice that the GCV is within the single set of quotes ( ‘ ).  This is a string value so when the GCV is translated to the actual value it will need to be treated as a string.  The key symbol here is the tilde ( ~ ) that encapsulates the GCV name.  This character symbolizes the use of a GCV so the driver engine knows to substitute the GCV name with the value stored in that GCV on the driver or driver set.

And regardless of whether you are using stylesheets or policies it is always better to use GCVs for these types of values and avoid hard coding values.  It just makes life easier.

As always, questions, comments or concerns?  Feel free to reach out to us at IDMWorks.

Export of CA Role and Compliance Manager (RCM) data to CA IdM

Thursday, April 21st, 2011

Accomplishing synchronization or provisioning of users, resources and/or roles from CA RCM into CA IdM involves a complicated configuration setup for RCM and IdM and understanding what requirements and limitations exist.

Here is a short list of  items that should be considered:

1.    CA RCM to IdM integration is predicated on the fact that users, resources and or roles are imported first.

2.    Configuration of the CA IdM resource connector is a requirement for managing users, resources and roles at the managed IdM endpoints.

3.    Not all IdM endpoints have a resource connector that can be configured.  The following chart shows what is supported for release 12.5 and as RCM and IdM versions are released this list will grow:

Endpoint Version Additional comments
Active Directory (ADS) Active Directory 2003 Customizable Connector method and Legacy method available
UNIX (ETC) Red Hat 5.1 Customizable Connector method and Legacy method available
MS SQL Server (SQL) MS SQL 2005 SP3 Customizable Connector method and Legacy method available
Generic LDAP (LDA) CA eTrust Directory 8.1 Customizable Connector method and Legacy method available
Windows NT (N16) Windows 2003 SP2 Customizable Connector method and Legacy method available
Oracle Database (ORA) Oracle 11g Customizable Connector method
OS400 (AS4) OS400 V5 R2 Customizable Connector method only available
SAP (SAP) ECC 6.0 Legacy method only available
DB2 Database (DB2) DB2 9.1 (UDB) Legacy method only available

 

4.    The defaultMapping.xml file provides the mapping of RCM attributes to IdM attributes.  It has been my experience that the list of attributes on the IdM side is fixed and substitutes likely will not work.

5.    At least one endpoint must be configured in the endpointTypeMapping.xml file.

There are plenty of other considerations, configurations and methods to make the import/export successful (look for future blogs on the subject).  The grapevine has indicated that major changes involving more integration between the products will occur with the release of RCM 12.5 SP4 coupled with IdM 12.5 SP7.

As usual, Questions, comments or concerns?  Feel free to reach out to us at IDMWorks.

Running A Successful CA Role & Compliance Manager (RCM) Project

Monday, April 18th, 2011

Mission Statement:  The most important aspect of goal driven project is for all participants to have complete understanding of what is to be accomplished.

A CA RCM project can be driven by a common framework that defines from start to finish what & how it will be accomplished in a RCM project.  To this end, we recommend a 5 phase plan that accomplishes the following:

1.    Gather Requirements – A questionnaire should be provided to the customer.  This questionnaire is designed to gather information about the project participants, scope, goals, environment, etc.

2.    Define Requirements - The responses from the questionnaire are provided to be discussed, revised and finally accepted by the customer and the implementer.  The purpose is for all parties to have a thorough understanding of the project’s purpose and goals.

3.    Design – Defines the approach, architecture, use cases, quality attributes, hardware considerations and validation for the RCM implementation.

4.    Integration - Or better known as the “Implementation & Installation Guide” detailing precisely what steps, executables, parameters, and configuration was done to install and configure the software and hardware for the customers environment.

5.    Functional Test Cases – The execution of the use cases, including step-by-step screenshots, parameters, options, and scripts is documented.  This provides the customer with an operational guide to follow so that the product can be used by customer’s employees after the implementer departs.

All of these phases should be driven by a strong master project plan executed by a Program Manager defining resources, task assignments and time-lines.

Questions, comments or concerns?  Feel free to reach out to us at IDMWorks.

Automate Common IT Fulfillment Processes with CA ITPAM

Monday, April 18th, 2011

Computer Associates – Information Technology Process Automation Manager (CA ITPAM, formerly called OASIS) takes the CA Service Catalog Workflow feature to new heights.  CA ITPAM has the ability to automate end-to-end processes using flexible, policy-based rule sets to establish process chains across the organization. ITPAM replaces steps that are manual, time-consuming, and prone to error with automated, efficient data flows. Your organization can leverage ITPAM to provide auditable and reliable IT resource request, approval and fulfillment procedures, update requests with curent state information, create/modify asset lists, open/update/close tickets in common ticketing systems, provide notifications via Outlook using Exchange or POP, send approval requests to groups or individuals for response in the ITPAM Client, and much more. Common tasks can be replicated using graphical OOTB Operators and flexible java-based functions to create efficiencies, enforce business rules and ensure regulatory compliance, i.e. separation of duties, approval thresholds, logging, auditing etc.  ITPAM gives you visibility into formal company procedures and processes in real time using the Orchestrator & Process Monitor features built right in.

CA ITPAM Orchestrator provides native support for some of the most common computing platforms and back-end service environments in use today. ITPAM Orchestrator can be can be installed on a multitude of common computing platforms such as Windows Server 2003 & 2008, SuSE 9.x/10/11, Red Hat 3.0/4.0 AS & ES, HP-UX 11i, Sun Solaris 9/10, and IBM AIX 5.3+. ITPAM Agents can be installed on Windows XP/Vista/7, Red Hat 3/4/5, SuSE 9/10/11, HP-UX 11i, and AIX 5.3 and higher.  In addition, ITPAM provides native support for industry standard fare such as LDAP Directory Services, databases Oracle 10g/11g, SQL 2005/2008, & MYSQL r4.2. Note that ITPAM requires Java Development Kit 1.6_04 or higher and Java Runtime Environment 1.6 or higher, and anything other than IBM AIX will also require a Jboss J2EE application server (the application server is included in the installation media).

ITPAM integrates easily with supported versions of CA Service Desk, Enterprise Entitlements Manager (EEM) (and other supported LDAP data stores) and Service Catalog. It can be installed in a multitude of configurations with various security and data store options. More information can be found at the CA website by clicking here:

CA has partnered with IDMWorks to provide proof of concept demonstrations and ITPAM implementation services for a number of their global clients.  See for yourself how ITPAM can transform your business by deploying efficient, secure, reliable, and automated IT request, approval, and fulfillment processes.  Contact IDMWorks for a demo today!

CA Identity Manager: How to Approach Authoritative Sources

Thursday, April 7th, 2011

Simple Answer: Very Carefully!

On a recent project our team was charging full steam ahead with creating a custom JNDI connector with Connector Xpress to use an existing LDAP as an authoritative source for CA IdM. We encountered a few complexities using Explore Correlate as an all in one synchronization tool that I ‘d like to share.

Explore Correlate

When using Connector Xpress you will most likely be using Explore Correlate to create/update IdM users.It can get cumbersome to set up as Explore Correlate is not meant to maintain IdM users. The team started down this path but our complex Org structure made it near impossible to both determine and set the Org.  As a rule, Explore Correlate places all new users into the default Org.

The solution we found was to 1) catch each create event and 2) use Policy Express to set the Org on the fly.

Reverse Attribute Mapping

Any information you want to pull back from the Connector must be mapped to a Global (Provisioning Directory) attribute, then to a User Directory attribute (assuming you are following the CA recommended architecture of separate user and provisioning directories).  In the end, we would recommend a well thought out flat file feed or setting up TEWS (Task Execution Web Services - CA’s web services core) to accomplish this.

As always if you have any questions, comments or concerns, feel free to reach out to us at IDMWorks.

Ten Questions to Ask Yourself before a Data Center Relocation

Friday, March 25th, 2011

This is not a “top ten” list ordered by level of humor. This isn’t necessarily in order of importance. The following are just ten queries with thoughts on business-as-usual status, relocation impact, and how IDMWorks Data Center Migration (DCM) specialists might help you.

1. How long can you freeze progress?
Business goes onward. The primary purpose of the enterprise is not IT. IT exists to support the primary goals of the enterprise and to do it economically. Even when you are preparing for relocation business units expect most changes when they want them. Periods with even partial freezes for relocation must be minimal to maintain your enterprise’s real primary purpose.

2. How much spare resource capacity do you have?
If you have the resources to do a Data Center Migration internally, some may think you are overstaffed. Most enterprises have been trimming expenses wherever they could, including IT staffing.  This generally means that your technical people are pressed to keep up with current operations.  You may be stretching them just by asking them to learn and practice new techniques. Now, on top of that, you are looking at migrating to a new Data Center. You probably won’t avoid changes to your technology. In fact, some technology changes may be in the reasons to execute the migration.

3. How big is a relocation project?
You have a Data Center full of units that will have an average age of four years when they are replaced. This means that on average your staff replaces 2% of the equipment every month. A relocation calls for de-installing and re-installing 100% of the equipment in about two months. Relocation is 24 times the normal workload.

4. Do you have expertise on your staff?
Few companies move a Data Center more than once a decade. Even if you have people on staff who moved a Data Center ten years ago, they won’t recognize how constant process improvement has changed the applicable processes.

Ask yourself this:
• Do you know the lead times for the technology changes in a migration?
• Have you considered what topology will carry you into the future best?
• Is your purchasing department well versed in the nuances of the trades you will engage?

5. How well do your silos work together?
Your teams are probably in silos. We can assume that your enterprise executes deployments beautifully with application, server, network, storage, and backup teams all getting their jobs done in a few days.  Remember that Relocation is 24 times the normal workload? In a migration, you will need power, networking, storage, equipment, and applications to execute seamlessly in minutes.

6. How do you want to be remembered?

Quality will be remembered. If you spend a vast sum to obtain the proper facility; but have problems bringing up the applications in it, that memory will live anecdotally through many budget cycles. The saying is that Data Center Migrations are career changing – which way would you like your change to be?

7. Do you know the risks of a DCM?
You know your day-today risks however, there are additional risks to consider in a migration.  Statistically, only 4% of system failures are the result of hardware failing when running in place.  That risk quadruples (16%) when you de-install and re-install equipment. Plus it is typical to add almost the same amount from human error when operators are only trying to restart systems as they were. How many of your systems were configured by parties who are no longer present? Plus there may be network configuration complications. One of the most irritating statistics is about 2% of “outages” being caused by tests that report false defects. Unfortunately you have to remember to test the tests.

8. How much can you rely on your IT structure?
There are a collection of things that you expect to be working in your favor. Like your network, phones, email, identity validation, help desk, fire alarm sensors and other infrastructure. When you are moving these very systems can fail on you in the most interesting ways. I believe there is a corollary to Murphy’s Law that “If a reliable system fails, it will fail at the most inopportune time.”

And yet sometimes reliability is actually the enemy. Those landscape sprinklers that always come on at 2AM? Not so good when you are moving a load of switches and servers past them at 2AM.  For that matter, from a staff standpoint, don’t schedule a move for Mothers’ Day weekend, you won’t have time to handle all the complaints.

9. How large is the “team” to whom you will communicate?
There are actually several aspects to the communication problem.  For example, I once heard of an unhappy board member whose first notice of a major move came from an outside acquaintance at a sporting event.

  • As situations change you need to document status at the time decisions are made so that hindsight does not become obscured by changes after the fact.
  • Upper management expects IT management to clearly convey the risks they are accepting and the financial reasons for accepting that level of risk.
  • There are teams inside of IT and Accounting, business units, IT vendors, communication vendors, management teams, relocation vendors, maintenance teams (contract updates, tax rate changes, standby), general employee pool, customer pool, non-IT vendors, and maybe a dozen more categories of communication targets. For these various targets, there will be a variety of different message mediums and timings.

10. Does your budget fit your needs?
Also known as the Goldilocks question: Are you buying just right, or too much (wasting resources), or too little (limiting future processing)?
The relocation should fund infrastructure for a period specified in the goals of the project. The physical facility usually needs to be serviceable through the end of lease/life. At the same time you consider that the exit date for the new Data Center is years away; you should also weigh throughput that will become available using newer technologies. In an ever-’green‘er world, there may be financial reasons to plan for future changes.  With increasing availability of collocation and cloud resources, there is a serious risk of overbuilding. Enterprise management needs to be assured that funds committed to IT are being used wisely. It is beneficial to have experts involved before you commit to particular topologies and technologies and before you are requesting bid proposals.

What IDMWorks can do for you

At IDMWorks we have a phased approach to the relocation:
1. We will ensure your goals are met. We consider your stated and implied goals for the relocation project and help you set-up a core team to coordinate the project.
2. We will ensure proper discovery. We gather and combine data on your systems, information communication, and applications in a discovery effort. This includes interviews on expected technology changes.
3. We will ensure you plan correctly (and obtain final budget approvals). This includes analyzing prototypes to illustrate alternatives, checking designs for facilities and cable infrastructure, actually planning (with your staff’s input) equipment locations, move timing and patching.
4. We will test, retest and ensure proper execution. With your staff and our support teams, we test readiness before moves, execute moves, and confirm results of each move.
5. We will ensure you close your old facilities (if applicable) and the project. There are many Project Management Phases that apply to DCM – Charter, Discover, Design, Deploy and Validate, and then Close.  Our DCM PMs handle status reports, core team meetings, to-do lists and both create and maintain project plans at various levels of detail.

Get to know peace of mind, get to know IDMWorks Data Migration Services.

IDMWORKS specialists help your teams understand the fit and take pride in overall success. Successful relocations often become bonding experiences that even reduce staff turnover. Smarter, faster, and happier.