Skip to Content

Using Transparent Authentication with SAP IDM VDS

The Virtual Directory Server (VDS) is an interesting tool, however like all IT tools, it’s just some interesting sounding technology if we do not have the ability to put it into a Use Case for the Business.  With VDS one of the things that is frequently requested is some sort of authentication to the data in represented in the Virtual Directory configuration. 

Of course this is not mandatory for every use case, but  frequently it is required and the easiest thing to do is to leverage another Directory Server that contains users and passwords.  Fortunately VDS provides something called Transparent Authorization which can be used in this case.  I recently had an opportunity to work with this functionality on a recent project and thought I would share some .

One of the really cool things is that you can use this with virtually any kind of VDS implementation where VDS is being used in its LDAP representation mode (Not sure if this will work for Web Services as well) So I’m not going to spend too much time talking about the greater configuration, but I’ll focus more on what needs to happen for authentication to take place. If you’d like to play around with a configuration take a look at this post, where I walk through a virtualization of the IDM Identity Store.

First step is to change set up the authentication.  Note that we set the Authentication class to “MxTransparentAuthentication” by selecting the “Change…” button.  Next create two parameters as seen bellow, TRANSPARENT_DS and DEFAULTGROUP.  These should be set to the IP/defined Hostname of the server to be used for Authentication and then specify the default VDS group that will be used.

VDS-authenticated class.png

Now we need to configure the Pass through part of the authentication so that the user credentials will be passed.  This is done by using the asterisk ( * ) character.  This character is used throughout VDS as a wildcard in the configuration.

VDS-Authenticated Node.png

Once this is done, start the configuration (or restart it if it’s already started) and test it out as I’ve done below using Apache Directory Explorer (or the LDAP based application / browser of your choice.)

VDS-Authentication Client.png

There you go, you’re ready to access your configuration based on authenticating on an external Directory Service!

You must be Logged on to comment or reply to a post.
  • This VDS is interesting but also strange.

    I tried transparent authentication against an AD LDS instance. I was successful but I have to provide the full distinguished name of the user as is in AD LDS. Your blog looks like you are using an AD domain as the backend.

    The idea of the virtual tree should be to hide the details of the source.

    I assume there is some magic parameter for the MxTransparentAuthentication class which can be used to manipulate the DN.

    Or do I have to use some of the other external classes?

    Where are the supported parameters for each class documented? Without your blog I would have been lost to understand how to use the class.

    • Thomas.

      Glad you got something from the blog.

      The virtual tree is just a representation of the back end data.  It can look like anything.  There's no real requirement that it look different.

      I messed around with this a bit and then asked some others how to make the best use of it.  Unfortunately the documentation of VDS is somewhat vague.  SAP doesn't do a very good job of promoting it either.

      One of the main reasons for this is that you can make VDS do virtually ANYTHING so it's kind of hard to give advice.

      I would really like to hear more about how people are using or would like to use VDS.  Hopefully, this will raise some awareness at SAP and persuade them to do more to promote and develop it beyond HCM and GRC integration.



      • Hi Matt,

        the VDS will be the LDAP gateway to AD LDS which used by more than 150 applications for authentication and authorization. Depending if I consider consumers I will have about 30.000 (no consumers) to a view million (with consumers) users in the ADLDS.

        I would like to use the AD LDS as my authentication store and thought configuring VDS for transparent authentication might be smart. But it seems it wasn't. I want to hide the AD LDS structure from the applications which means the application / user does not know the FDN in AD LDS. I could not manage to find a way to do this with MxTransaparentAuthentication class.

        I see in the Trace the LDAP bind name is the name I provide in my LDAP browser. I see also some entries in the trace like DN_ATTRIBUTES parameter was NOT given, DN_TRANSFORMATION parameter was not given and so on.

        My goal is to present the application / user a virtual tree like


             - o=users

        And not the AD LDS tree

        DC= something

             - DC = nextlevel

                  - ou=first ou level

                       -ou=second ou level

                            -ou = third ou level

                                 -ou = Ext Users

                                 -ou = Int Users

                                 -ou = functional users

        And so on.

        The application should authenticate with dn: cn=TheUserId,o=users

        and not with cn=TheUserID,ou=Int Users,ou=third ou level,ou=second ou level,...

        Any idea?


        • Since transparemt authentication requires the calling application knows the structure of the LDAP I am authenticate against I tried external authentication with some of the default classes shiped by SAP.

          Some performance test with 10.000 ldap binds revealed it works fair.

          Know I am looking for some tuning docs for VDS. One question I have but can not find an answer for is the virtual directory server->server properties->environment -> engine properties: minimum number of engines.

          What is an engine? Is it like a thread or some more heavyweight stuff? Gets every session its own engine? Is there an intrinsic maximum number?

          I also receive an error could not check in engine in the operation log.


          • Hmm... That's digging pretty deep into the guts of VDS.

            What I can tell you I get from the help file:

            Minimum number of engines

            A server starts with zero engines and creates new engines as required. When an engine has been idle for the time given in "Keep free engine", it is decommissioned. In this field, you can specify that the server should keep a minimum number of available engines.

            This value is most important if there is a rapid change between the maximum and minimum number of simultaneous connections (burst load).

            So it would appear to be somewhat self regulating.  If you're looking for more information, you might want to open an OSS ticket.


  • Hi Matt,

    Great blog just like the many others you have published 🙂

    I'm trying to set up authentication via VDS to authenticate against the Identity Store identities.

    I have selected the Authentication class as MXAuthMIC - Authentication to SAP Netweaver IdM Identity Centre.


    Name Value

    TREE                    Identity Store

    DEFAULTGROUP Authenticated

    DNATTT               UID

    However, I can't authenticate against any of the test users I have created in the Identity store.

    Am I missing a step? Please advise.

    Thank you,


    • Kautilya,

      I've never tried to authenticate back to the Identity Store via VDS.  I'd have to try and set something up in my test environment. However since IDM also authenticates back to the UME database or AD, you might be able to point to that.


          • Hi Matt,

            The use case is we want to use another Identity Provider to validate Identities by calling SAP IDM via VDS (username and password validation) for authentication purposes.

            In this instance the IdM will act as the Directory Server that contains users and passwords.