Quest has been an OEM customer of the Symlabs virtual directory product for some time now. It was actually this exercise that started me to think about how customers – including Quest – weren’t really deploying a virtual directory (VDS) for the sake of having a virtual directory. Customers are deploying a VDS to solve very particular problems like easing the integration of identity data and systems into an existing identity management project or allowing directory-enabled applications to be kept in place despite the fact that the underlying directory was being re-architected or migrated.
So one of our goals will be to incorporate Symlabs’ VDS technology into a number of existing Quest products to make it easier to solve some of these problems. Our existing migration products have successfully helped thousands of customers migrate from one platform to the another but one of the problems that keeps coming up is: How do I migrate my directory-enabled applications? Most customers turned to a virtual directory for help. That’s why we feel that including a virtual directory capability as part of our migration products will prove useful to our customers. The same goes for our identity and access management product Quest One Identity Manager. We already provide a wealth of connectors for our customers to integrate their systems with Q1IM. Why not expand their capabilities and benefits by including a virtual directory as part of our identity and access management product?
I think Quest is uniquely positioned to leverage virtual directory technology into a host of products that the traditional virtual directory companies just don’t have today – like migration products. We'll also leverage Symlabs’ federation product by incorporating it into our existing federation and WebSSO products giving them broader reach and extended capabilities.
Exciting times!
Technorati Tags: Quest,QSFT,Symlabs,virtual directories,federation,identity management,LDAP,Active Directory,WebSSO
No comments:
Post a Comment