Testing PeopleSoft LDAP integration with Active Directory

By Larry Grey • April 2, 2009

We’ve talked with a few different PeopleSoft customers recently that use Active Directory with PeopleSoft, but the AD teams in their organizations don’t provide access to test Active Directory servers for applications that integrate with AD.

Microsoft saw this sort of thing coming awhile back and came out with something called Active Directory Application Mode (ADAM). They’ve changed the name since then to Active Directory Lightweight Directory Services (ADLDS), but you’ll mostly find references to ADAM in various writeups out there. ADAM is the same codeline as Active Directory, but intended for just this sort of scenario.

The cool thing about ADAM is that it runs as a standalone service (it can even run on machines that are not members of a specific domain), so it’s much easier for the PeopleSoft support team to put up a copy of ADAM on a machine somewhere for development and testing purposes.

ADAM/ADLDS is included as an optional component of Windows Server 2003 R2 or you can download it free from Microsoft. You can even run it on an XP workstation if you don’t have the ability to put it on a server.

A good place to begin with using ADAM is this writeup on DevX. It is not PeopleSoft specific, but it will help you get everything up and running. Then you can configure your dev/test PeopleSoft instances to talk to ADAM instead of your production Active Directory servers so that you can test out different scenarios to see how they behave without incurring the wrath of your AD administrators 🙂

Once that is up and running, then you can use our LDAP query tips and techniques to enhance the PeopleSoft delivered integration.

Labels: 2009, LDAP, Microsoft, Sysadmin

Stay Updated

5 Replies to “Testing PeopleSoft LDAP integration with Active Directory”

  1. Can I assume that in a multi-domain environment, I will not be able to leverage ADLDS or ADAM functionality to deliver passthrough AD authentication to Peoplesoft Financials? Is the version and/or patch level of Peoplesoft and/or PS Tools relevant here as well?

  2. Hi Chris,

    Thanks for the mention.

    One of the messages from my presentation was that ADLDS has a place in production systems as well as dev/test. The ability for ADLDS to sync profile info from a master AD domain (or several), then subordinate password checks back to the original AD source on-the-fly makes the ADLDS product very compelling in integration situations that may be challenging with AD proper.

    Lifting from slides 18 + 19:

    When to Use ADLDS Proxy Objects (i.e., Cached AD Users):
    • When the application employs schema extensions
    • When using application-specific groups
    • When the environment contains multiple Active Directories without cross-domain / cross-forest trusts in place… M&A can tend to bring this on.
    • When you expect significant profile lookup activity; caching user profiles to a directory server near the application reduces network traffic and latency

    When Not to Use ADLDS Proxy Objects:
    • No schema extensions
    • No custom groups
    • Single domain

    Another common use for me is when configuring Active Directory authentication in PeopleSoft. One of the steps in that task is to cache the AD schema, and on more than one occasion, I’ve encountered an issue where the caching load failed (due to a long-named Exchange schema extension attribute overrunning the SQL statement length of the caching process, if memory serves).

    The solve? Set up an ADLDS instance, update the instance with the basic AD schema (this ships with ADLDS, or is easily downloaded from MSFT), then temporarily point PSFT to this directory for the purposes of caching. Once all of the core schema attributes have been loaded (particularly, sAMAccountName), point PSFT back to the *real* AD, and voila! You can set up authentication maps with no problem.

  3. I should also post a link to James LaBrash from BTRG’s presentation on using ADAM (the link is for the slides from the PeopleSoft Southern New England User Group 2007 conference).

  4. Excellent news Greg – thanks for the info. It’s exciting for us (and the audience of this blog 🙂

    Once the OpenWorld content catalog is live we can get some direct links posted for people to register for those.

  5. If you look at any of the PeopleTools 8.50 roadmap sessions, or my security sessions, you’ll see that ADAM (AD LDS) is already part of the LDAP tested integrations for 8.50. There are a number of exciting security related features coming with all the other goodies in PeopleTools 8.50.

    (I know “exciting” has a very narrow focus here!)

Comments are closed.

Request a Demo