Problems extending Active Directory Schema

Jackson Shaw blogs about still MORE issues that are arising from trying to update schemas in active directory. This is why I encourage people NOT TO TRY THIS AT HOME (or at work). It's disruptive and can have some serious effects on your network infrastructure. Use the existing schema in a virtual directory, extend the schema there. Then you don't have to worry about the issues involved here. Point the applications that need this schema extension to the virtual directory instead of AD. Most virtual directories will let you mount an existing structure (proxy) and extend the entries from various data sources (including data bases, other directories, applications or web services). Some virtual directories will even allow a join function to extend the entry from its own local store if the needed schema attributes do not currently exist. Kind of neat huh? So why all the drama? I think people just don't understand this technology - you can use your existing stores and pretty much do anything you want with them, without replication. Performance you say? Well, if it really becomes a problem, there are several caching options and cache refresh options in virtual directories also. If you don't have a virtual directory (or one that has these options) in your arsenal, get one - it will save you a lot of headaches, and a lot of time. Become the famed Engineer Mr Scott of Star Trek fame and get everything done in one third the time or less!

read more | digg story

Matt Flynn Blog, Burton Group, affirm Virtual Directories as a Valuable IdM infrastructure component

Matt (see http://360tek.blogspot.com/2008/01/year-of-virtual-directory.html) asserts his continued position as an advocate of using virtual directories- and references Burton Group's affirmation of this technology as well in a recent webinar. Burton also published a paper recently (Nov'07) "Virtual Directories: Valuable Present, Promising Future" that is great information on the state of the vendors in this market and their capabilities. Not all of them have all the flexibility that Matt refers to "That is, virtualizing the data structure, access protocols, server locations, etc. and presenting the same useful data from its original source in real time (or cached) in virtually any format and over most common data interfaces." The Burton Group study will help a lot in sorting that out.http://identityinfrastructure.blogspot.com/

read more | digg story

Weakness in IdM Products

http://duckdown.blogspot.com/2008/01/common-weakness-in-all-identity.htmlThis author takes a harsh, but not well versed stand, into criticizing ALL IdM software packages out there for the lack of integration into various data stores, especially Active Directory. If it were that simple, don't you think all the vendors would do it? Just the fact that the symptom is there for ALL IdM packages, should tell you there is MORE to the story, no??? First check out Gavin's response, a good one - and saved me from more ranting on here... http://blog.suretecsystems.com/archives/77-A-Common-Weakness-in-all-Identity-Management-Products,-but-not-OpenLDAP.html First - Active Directory is for INTERNAL users primarily. Not useful for all IdM initiatives, say for a partner portal, or federated business environment where the user list is NOT your network users. Second - If you know much about Active Directory you will know 1st AD admins don't want you messing with it, you can cause serious problems if you do - extending schemas, customer object classes, etc pose problems, plus its SLOW - HENCE why ADAM exists in the first place, but then why isn't everyone clamouring over the use of ADAM? Like Gavin Henry says... I encourage this author to take a look at the white paper Open LDAP wrote (http://symas.com/documents/Adam-Eval1-0.pdf) and you will start to see the limitations and disjointed nature of LDAP compliant directory services and AD.

read more | digg story

Completeness of Metadata

http://www.b-eye-network.com/view/6722 This is just kind of interesting, nothing great... BUT the issue of how you do handle large amounts of metadata does ring true. The author states that perhaps you must limit your metadata and not try to get a complete picture. Of course you do! You must limit it to the context in which it is relevant! This is why I think the hierarchal views found in directories are great, they can give you direct context of data, natively (i.e. look at the DN of a user object) - if you build these trees correctly you have some great information to leverage. Let's take it one step further, look at a virtual directory - where you can change the labels and tags as you want, giving the DN a more explicit meaning.If your confused, don't feel bad, I've confused many on this topic - but if you can get your head around it, it will pay off!!

read more | digg story

Five Steps to Better Data Management

In this article Michael Daconta spells out in his vision what steps need to be taken to ensure successful future growth of your enterprise architecture. http://www.gcn.com/print/27_2/45685-1.htmlPay attention to step#4. Install a data services layer in your service-oriented architecture plumbing. This isn't just an SOA thing, don't wait for SOA come to you, create a data service layer now. You will be one step closer to SOA (if planned well, so go ahead and ask the vendors you talk to, what the plan is for SOA integration in future releases) and one step closer to unbelievable flexibility and an almost end to this constant reinventing the wheel for each application you bring online.

read more | digg story

Global Key Mapping

I read an article a few days ago in the latest issue of DMReview titled, "Global Keys: A Unified Key Mapping Architecture".

I visited the authors blog at http://www.globalkeysdesign.com/global_keys/blog_index.html and found it to be a good start of a very important discussion about creating a centralized mapping of keys for multiple data repositories that contain equivalent data (or identities).

Check out my post
http://www.globalkeysdesign.com/global_keys/2008/01/what-me-work.html

MDM without boiling the ocean

The concepts are the same for Identity Management, you don't have to solve every problem in the world to get started solving your integration problems... BUT you can make some savvy choices, like planning ahead and going with solutions that have "legs". If you have read my blog entries you know I love the data-virtualization concept and benefits. The author of this article (http://www.it-director.com/blogs/Fern_Halper/2007/12/MDM_without_boiling_the_ocean.html) is starting to see some of the benefits of the data-virtualization idea, its too bad there isn't any examples given or benefits achieved. Identity Management can be as daunting as MDM (master data management), and in many ways more critical. My recent run-in with Blue-Cross of California shows my point, they have decided to integrate their multiple systems (e.g. star, gemcorp, etc) into a web service so that members can access information and services at a single point - sounds simple enough right? on the contrary, its not working and they are puzzled as to why... members who are in multiple systems, perhaps inactive in one data silo and active in another for example, can not access the website or retrieve registration information. As of my last contact with that group, they have no ETA on when they will solve this problem, nor have they isolated where the problem lies... amazing... It is obvious to me that it lies in the choice of data integration tools, it looks like Blue Cross will be relying on their old systems, and a lot more member calls (btw their tech support is reporting a minimum wait time of 25 minutes as of yesterday), and upset customers for awhile longer.... Create an abstraction layer that can grow with you. Solve one piece of the puzzle at a time, when you have a piece in place, implement it without disrupting other current systems.... this one of the largest benefits I am finding in using data-virtualization tools like virtual directories, I don't have to use it for everything at once (I can implement authentication via ldap proxy using a virtual directory server, and later add services such as provisioning or user management), and it operates into my current environment natively as I need it to (i.e. ldap, or sql, or xml/web services, etc) not some new custom protocol. How do you eat an elephant? one bite at a time! Break your project into small pieces, with your eye on creating tools for the future, you just might be able to boil the ocean yet...

read more | digg story