Posts Tagged ‘IDM’

« Older Entries

Tips & Tricks: Novell IDM JDBC Driver Filter Gotcha

Thursday, October 20th, 2011

***NOTE: As with all Tips and Tricks we provide on the IDMWorks blog, use the following AT YOUR OWN RISK.  We do not guarantee this will work in your environment and make no warranties***

Have you ever had a JDBC driver that wouldn’t find changes in the database while using a triggerless Publisher channel?

The obvious things to check are the views/tables in the database the driver monitors to make sure the changes appear there correctly. Ideally you will check the class objects and attributes in the driver filter to make sure they are sent to Synchronize for the Publisher channel. Additionally you should check to make sure the Publisher channel is enabled and configured properly in the driver settings.

Unfortunately once you have checked these items you still may have the issue.

Having run into this issue a few times I’d recommend taking another look at the Driver Filter.

Basically what happens in a JDBC driver with a triggerless connection to a database is that it polls the database tables or views configured in the driver settings at the scheduled intervals by doing a “SELECT *” command for each table or view tracked. If a class in the filter has the “Track member of template” set to “No” the driver does not do the SELECT statement for the table or view associated with that class.  Thus, in the filter, the class object setting for “Track member of template” should be set to “Yes” if you want those objects monitored in the Publisher channel.

Another way this issue can be found is by reviewing the driver logs. Each time the driver checks for changes in the database the SELECT statements are recorded (provided that the logging is turned on and set to an appropriate level). If no SELECT statement is found for a table/view that is expected then the template setting is the  likely cause.

And since this is a filter setting the fix is easy:
1. Open the driver filter in Designer
2. Select the desired class in the filter
3. Set the “Track member of template” setting to “Yes”
4. Save the filter changes
5. Deploy the filter changes to eDirectory
6. Restart the driver to initialize the changes

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

Tags: , , , , , , ,
Posted in Novell, Novell Identity Manager, Tips & Tricks | No Comments »

Novell IDM Best Practices: Don’t Forget the Small Stuff

Monday, October 17th, 2011

Don’t Forget the Small Stuff

When developing a Novell IDM driver its easy to get focused on requirements and lose track of the little things that can come back to bite you later on. The perfect example of this is the DirXML-Associations attribute.

This handy little attribute is typically automatically set by a driver to establish a relationship between an object in eDirectory and the object in the driver’s connected system.  When this value is set for a specific driver it allows future changes to be processed more quickly and efficiently.  These relationships are stored in eDirectory on the object and consist of the unique identifiers from the connected systems; for example, the Microsoft Active Directory driver leverages the Active Directory’s GUID value for the account to create the association in eDirectory.

The problem is that once these associations are created there are only two ways of getting rid of them.  The most obvious way is to delete the associated object in eDirectory.  If the object holding the values is deleted then it goes without saying that the values are deleted.  This method doesn’t require any additional coding or consideration in the driver.

The other method is to remove the association value from the attribute in eDirectory either manually (not recommended) or programmatically by creating a policy in the driver that contains the Remove Association action.  This means that someone has to create a policy or policies that contain a number of conditions to determine if/when an association should be removed.  The only thing is that in the course of requirements gathering and design these use cases and conditions are overlooked and not documented and therefore do not get implemented.

More often than not requirements simply dictate that a driver is not to delete objects out of eDirectory.  The natural instinct is to create a simple policy that checks to see if the current transaction is a delete event and if so to do a simple veto action.  The veto action will stop the transaction from processing through the driver to eDirectory and will result in the eDirectory object being unchanged, including the driver association.

So what’s the issue with keeping a driver association in eDirectory after the object/account/record has been deleted out of the connected system?  Well, simply put, it causes errors! This is because of how the driver detects and uses the association values in the DirXML-Associations attributes for more efficient transaction processing its a problem to have an association for a driver that points to a nonexistent record.

The result is that when an transaction for an object in eDirectory in such a state processes through the associated driver the driver will use the invalid association as its target reference.  This causes the transaction to result in an error because the target reference no longer exists.  The obvious result of this is that no changes are made in the target system.

On the flip side of things, if an unassociated object/account is created/modified in the target system and the driver attempts determines that the record in questions matches are previously associated eDirectory record the driver will attempt to merge the records and create a new association in eDirectory with the new account.  This causes an issue too.  An eDirectory object is only allowed to have one association per driver and since the driver already has an association for the old record on the eDirectory object the merge process will fail and the driver logs will record an error along the lines of “Object already associated“.

In either case the obsolete associations in eDirectory essentially defeat the purpose of having an identity management system.  Removing an association through driver policies is simple to do and can go a long way in developing a system that delivers reliable identity management capabilities between the various connected systems.  So the next time you are planning a driver or get a requirement that demonstrates the use case where the relationship between eDirectory and a connected system is being destroyed remember to clean up the association.

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

Tags: , , , , , , , , ,
Posted in Best Practices, Identity Management, Novell, Novell Identity Manager | No Comments »

Fixing the Dreaded “Novell eDir-to-eDir Driver Code (-8015) Operation Vetoed by Filter”

Wednesday, September 21st, 2011

***NOTE: As with all Tips and Tricks we provide on the IDMWorks blog, use the following AT YOUR OWN RISK.  We do not guarantee this will work in your environment and make no warranties***

Novell eDir-to-eDir Driver Code (-8015) Operation Vetoed by Filter

If you ever find yourself working an eDir-to-eDir driver and run up against the “Code (-8015) Operation vetoed by filter” wall please allow me to help.

If you search Google (or whatever you search provider of choice is) you will undoubtedly find several postings across a variety of websites from many people who have run into the same error. While I won’t discourage you from reading those postings I will say don’t be too upset if you don’t find the answer you are looking for among them.

Most online posts regarding this error talk about bad or missing association values or remote loader logs for other drivers; like the Active Directory driver. While those are good things to know odds are your eDir-to-eDir driver doesn’t use a remote loader, you have checked the input document for malformed tags or values, and have generally already done a lot of the basic troubleshooting methods.

When dealing with the eDir-to-eDir driver it is important to remember that you are actually dealing with TWO drivers, not just one.  It is easy to forget that when dealing with an eDir-to-eDir connection that there are two filters, two publisher channels, and two subscriber channels that have to be coordinated to avoid issues.  With this particular error it is typically caused by an attribute or class being set to synch in one driver filter but not the other filter.

To make matters even more confusing, the error appears in the log for the driver that has the attribute in the filter.  Usually when a developer sees an error in a driver log that mentions the driver filter they assume the error is referring to that driver.  In this situation that is simply not the case.  It is the companion driver that is vetoing the event because the data being passed isn’t in its filter so the transaction is thus rejected by the companion driver’s filter and the message is returned and captured by the originating driver.  Confusing at a minimum.

The solution to this error when using an eDir-to-eDir driver is to check the filter on BOTH eDir-to-eDir drivers to make sure that both filters have the necessary attributes with the proper settings and correct any differences that are necessary (remember to restart the driver after making changes!).

As a note: Transactions cross from one eDirectory instance to the other eDirectory instance using the eDir-to-eDir drivers, the transaction flips channels, so it is important to keep that in mind when building policies on connecting drivers.  Events that start in “Vault 1″ goes through the subscriber channel of “eDir Driver A” and when that driver hands the transaction off to “eDir Driver B” the transaction is now on the publisher channel before ending in “Vault 2″.  Unfortunately, this is another easy to make mistake when dealing with this “daisy chain” type connection between Novell eDirectories.

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

Tags: , , , , , , ,
Posted in Novell, Novell eDirectory, Tips & Tricks | No Comments »

The Pitfalls of Body Shopping

Thursday, September 1st, 2011

Being in the Identity Management services business, we get approached all the time by various body-shops looking to fill their clients IDM needs. A large percentage of these firms are looking to address their clients’ needs with cheap resources. When I say cheap, I mean typically less than a equivalent full time employee resource would get in this field.

The question is are they really addressing the clients’ needs by obtaining cheap resources versus spending a bit more money to obtain truly qualified resources? My observations are no, they really are not meeting up to the clients expectations. You may wonder how I can make such a statement, but time and again I see requests coming in for the same project after just a couple of months.

A few things could be happening here:
1. The resource is not qualified and is asked to leave
2. The resource recognizes that they are not qualified and leaves due to pressure
3. The resource leaves to obtain a better rate for their skills
4. The client may not have been truly ready to start the project and needs to do a reset

Regardless of the reason, the one being affected here is the client. When running a body-shop volume typically takes precedence over quality as does margin.

I don’t believe that all the companies that are contracting for resources are looking for the cheapest body, but more likely the best rate for qualified resources.  The real gray area in these circumstances is what does qualified resource mean? Unfortunately in some cases it means having the right buzzwords in a resume, in others, it means an individual that can pass a 5 or 10-minute interview with a non-technical manager.  The shame of it is that it can affect the rest of us through the inevitable loss of trust.

I have found that the typical complexities associated with Identity Management in general (and in a lot of other technical niches) require skilled and experienced resources to successfully accomplish a majority of the required tasks. Skilled resources have extensive experience, are high in demand, and can command a decent salary. This is where the rub is.  The old adage of “you get what you pay for” reigns supreme.  Can you really ask for a “junior” resource that has 10 years experience in the niche, an MS in Comp Sci, 20 years over all experience and can Architect, Manage and Implement the product stack?  The simple answer is, “No”, yet go speak with your average body shop recruiter and watch how often that comes up.

By stepping away from the body-shop approach, the end client has a lot to gain.

Case in point, your friendly neighborhood IDMWorks!   By having an actual Team of resources dedicated to our specific niche, in this case IDM, we have a few advantages that become aware very fast to our customers. 

1) Our team support each other the moment a need arises.  When one of our resources gets stuck they simply shine the internal Bat-Signal and everyone jumps in with their own experiences to jump the hurdle.

2) We have a repository and knowledge base that our employees have access to and contribute to. Why recreate the wheel or spend 2 days of Internet research? 

3) We have weekly calls by practice and discuss unique challenges and determine the best approach for resolution.  Your projects are our projects and these discussions allow us to forgo getting stuck on previously known issues.

Looking to save money initially?  You can go the body-shop approach but in the long run, your cost will likely be more. 

Pay a little more up front and you are more likely to recognize success the first time around.  This goes beyond us, IDMWorks, as a company and speaks to any non-commoditized sector.  Buy into a team and the talent first.

Feel free to reach out to us at IDMWorks and let us show you our team approach to your project.

Tags: , , , , , , ,
Posted in Best Practices | No Comments »

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.

Tags: , , , , , , ,
Posted in Best Practices, Novell, Novell Identity Manager | No Comments »

CA Identity Manager High Availability & JBoss Clustering

Thursday, April 21st, 2011

Over the course of the last few years I have seen configurations of  CA Identity Manager for High Availability without using Application Server clustering.  This is no longer an accepted practice. My understanding is that CA will be publishing an official technical note to debunk the old practice.  As such I’d recommend the following:

CA Identity Manager 12.x uses caching for transactions. The utilization of this feature can cause synchronization issues if the application is setup in a high availability mode without application server clustering.

An example I can give is a project I was involved with using JBoss as the CA IdM application server.   As such I will be addressing JBoss clustering in this entry.

JBoss uses a Hypersonic database to manage internal JMS data (JMS Queues).  JBoss uses the JMS queues for tracking tasks and processes within the application.  It is recommended to use a shared MS SQL database for the JMS database.  There are documents available online which explain how to migrate from Hypersonic to MS SQL.  In my example we opted to use the same MS SQL infrastructure used by Identity Manager to house the JMS database. In simplified terms, the steps to accomplish to clustering of IdM on JBoss is as follows:

1. Create a new SQL database (JBOSS_JMS)
2. Create a user/owner for this DB (jbossjms)
3. Migrate JBoss to SQL from the Hypersonic DB
4. Bring all services back up and test to ensure the migration was successful
5. Follow the procedures in the IdM documentation to configure JBoss clustering

Note: It is not recommended to configure both the migration and clustering all at once. It would be much easier to troubleshoot one major change at a time.

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

Tags: , , , , , ,
Posted in CA, CA Identity Manager, Identity Management, JBoss | 2 Comments »

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.

Tags: , , , , , , , , , , ,
Posted in Best Practices, CA, CA Identity Manager, Identity Management, Identity Provisioning | No Comments »

CA Identity Manager TEWS secrets revealed!

Thursday, April 7th, 2011

***NOTE: As with all Tips and Tricks we provide on the IDMWorks blog, use the following AT YOUR OWN RISK.  We do not guarantee this will work in your environment and make no warranties***

Whenever a task is created in CA Identity Manager, there is automatically a Query, Search, ObjectProfileTab, SearchResult and other pseudo tasks created in the WSDL, if the task is Web Services Enabled.  If you study the web services samples that come with the CA IdM product and see all of the searches, etc… you know where the tasks are coming from because they do not appear in the application. If you create a new task, then generate the WSDL in your environment, and search for the task in question, you will also see the pseudo tasks.

Before I figured this out, I was able to execute TEWS (Task Execution Web Services - CA’s web services core) calls directly, including reset user password, or modify user if I either hard coded or figured out the USER_ID through other means. The problem was that no matter what the approach, all I ever received from TEWS was a transaction ID. After studying the WSDL, I found that all of my tasks magically had tasknameSearch, tasknameQuery, tasknameSearchResult, tasknameObjectProfileTab, etc… in the WSDL. D’oh! This is what I was was missing. We can use those magic hidden “tasks” to gather the data that we need to submit my requests via xml posts within  asp/jsp pages rather than writing Java classes.

As an example, run the tasknameQuery pseudo task to gather the attributes on a profile screen within a task created, then  parse that data to make decisions.   Then formulate another transaction that executes the actual task to make the desired changes to the user(s) in question.

In summation, if you follow the documentation to configure and enable TEWS, compile the postXML.java class, then generate your WSDL, you should good to go.

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

Tags: , , , , , ,
Posted in CA, CA Identity Manager, Identity Management, Identity Provisioning, Tips & Tricks | 1 Comment »

Work-Around: CA Identity Manager “Password Reset Force Change” Checkbox

Thursday, April 7th, 2011

***NOTE: As with all Tips and Tricks we provide on the IDMWorks blog, use the following AT YOUR OWN RISK.  We do not guarantee this will work in your environment and make no warranties***

Unfortunately the check-box, when checked as true, does not work in CA IdM R12.5 :(

Fortunately, we located a workaround for this by inserting the following Javascript into the checkbox field on the screen attached to the reset password task:

function init(FieldContext) {
FieldContext.setValue(“true”); }

Also fortunate, CA support is aware of the issue and a fix should be included in an upcoming service pack.

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

Tags: , , , ,
Posted in CA, CA Identity Manager, Identity Management, Identity Provisioning, Tips & Tricks | No Comments »

Migrating away from Sun Identity Manager? If only it were that simple.

Thursday, March 3rd, 2011

Here at IDMWorks we get asked time and again to migrate from Sun Identity Manager to a number of products including Oracle, Novell, IBM, and CA Identity Manager.

We can tell you with no uncertainty that regardless of what a vendor or implementation partner has stated that there is no cut and dry methodology for “migrating” from Sun IdM to any of the other major IdM products.

As of now, there simply is no magic tool that you can use to export a Sun IdM environment into another product.  A vendor may be able to write a tool or two to migrate some of the important pieces of Sun IdM over, like resources, users, or basic meta-data that is common to all Sun IdM implementations (we speak from having done so a few times now ourselves) but as Identity Management is never a simple plug and play right out of the box, with no customization, it is not and cannot be done that simply.

So if you have a plain vanilla out-of-the-box implementation of Sun IdM, you might be in luck :) . If you’re like every Sun IdM implementation that IDMWorks has implemented, you have custom forms and workflows that have been written to facilitate your company’s processes for on-boarding, requests, off-boarding, approvals, etc.

The majority of these customizations are written in XPRESS.   XPRESS, unfortunately, is a proprietary XML language that was created expressly for the Waveset IdM product, which was purchased by Sun Microsystems, which was in turn purchased further down the road (and is being “phased out” under the name Oracle Waveset) by Oracle.  Each of the XPRESS forms and workflows is useless to another product.  Even if somehow translated they would be awkward at best to integrate into most other products as the product architecture and internal logic are very different.

The method many of our customers are taking to migrate is to document each process and configuration and create a migration plan to slowly bring up the new product solution to replace the functionality they currently have.  In other words, start from scratch using your original requirements and tools.  The key to success there is to have awesome, thorough, well planned and written documentation! Something we push VERY hard on our customer base here at IDMWorks.

With some luck (and a good vendor/partner) you have documented lessons learned from your original IdM implementation that you can use to expedite the new project and avoid some of the pitfalls that may have occurred the first time. The first and most important step to moving from one IdM platform to another is coming up with a rock solid migration plan that makes the transition as smooth as possible.

In all fairness, at IDMWorks, we don’t have the magic migration tool, but we do have the expertise to make your transition to a new IdM product a success.  Feel free to reach out to us to and let us show you what we can do to smooth the process.  As our front page says, “Get to know Peace of Mind”.

Tags: , , , , , , , , ,
Posted in Best Practices, Identity Management, Oracle Waveset, Sun Identity & Access Management, Sun Identity Manager | No Comments »

« Older Entries