Converting OpenLDAP to AD... multi-valued CN attributes...

Discussion in 'Active Directory' started by Guest, Nov 12, 2009.

  1. Guest

    Guest Guest

    I've got an existing, heavily-used OpenLDAP directory server right now,
    and I'm experimenting with AD as (initially) a replacement with the
    possibility of allowing easy installation of Exchange and SharePoint
    down the road (heavy upper-management pressure).

    I expected there to be some conversion difficulties, but I didn't expect
    the first tripwire to be something so minor. Our existing LDAP entries have
    multi-valued CN attributes - one for each permutation of the user's
    name, with 'displayName' set to the one they actually commonly use.

    AD doesn't like this. As from what I've seen and researched, AD doesn't
    like multi-valued CNs at all, and it can't be changed.

    Is this correct? Is there another attribute I might use for the same
    purpose? It will probably anger the web-devs who will need to update the
    piles of webapps that currently search CN, but if that's what I have to
    do...
     
    Guest, Nov 12, 2009
    #1
    1. Advertisements

  2. Guest

    Joe Kaplan Guest

    This is correct. AD does not support multivalued RDNs.

    There may be other ways to accomplish your goals without actually using that
    LDAP feature but if you have existing apps that absolutely depend on that,
    you'll need to recode them.

    Hopefully this isn't a total showstopper for you. If you are interested in
    discussing workarounds, feel free to follow up and I'll be happy to help.
     
    Joe Kaplan, Nov 13, 2009
    #2
    1. Advertisements

  3. Guest

    Guest Guest

    Which is sad, particularly considering CN isn't used in the DN for any of
    my "people" objects. (AD is also the first product I've encountered with
    this limitation...)

    I'm noticing other attributes declared 'single-value' that will cause
    problems... ie: 'title' (a person with multiple positions - ie, research
    chair and dean - will have multiple titles). Do you know how hard that
    would be to edit?
    If necessary, what I'll probably do is populate CN from displayName, and
    come up with another attribute to hold the previous CN values... 'fullName'
    or something similar, even if I need to customize it myself.

    Thankfully, most of our webapps are perl and PHP, and can be customized
    without a lot of recompiling.
    "Showstopper" is relative. People need what they want and it's not their
    money nor time. :)
     
    Guest, Nov 13, 2009
    #3
  4. Guest

    Guest Guest

    Actually, that in itself would be a major question... are we FORCED to use
    a real name in the DN?

    Our directory contains students. Because of privacy law, we can't show
    their names... not even to other employees or students. So, we use a
    one-way hash of some of their personal data and generate an 'rdn' from
    this, and build the DN from that. People authenticate by searching on
    their uid, which is searchable but NOT visible, and then bind to the DN
    returned. It's very rare that we've encountered any software that has a
    problem with this authenticate method.

    If we were to use something like 'cn=Brandon Hume', then any vague search
    of the directory would show people's names as part of the DN... which would
    not be kosher.

    I suppose that WOULD be a potential show-stopper.
     
    Guest, Nov 13, 2009
    #4
  5. Guest

    Joe Kaplan Guest

    I'd suggest being careful editing the title attribute (if the directory will
    even let you) as the default GUI for AD may not work well in the case where
    there are multiple title values. I'd instead suggest creating a new schema
    attribute that's a simple MV unicode string and put the title values in
    there. That might not be a bad idea for your additional name values as well,
    but there may already good attribute choices for many of those.

    Another option you could consider is using some type of sync process to sync
    AD to your existing directory so you don't necessarily have to change any of
    the existing apps.
     
    Joe Kaplan, Nov 13, 2009
    #5
  6. Guest

    Guest Guest

    That would be nice, although I'd have to research what software would be
    capable of doing so, assuming we didn't custom-build something. Such a
    software would still need to pick and choose from the multivalued attributes
    and convert others, I'm assuming.

    And would software like Exchange and Sharepoint be at all happy about
    talking to a directory built in that way?
     
    Guest, Nov 13, 2009
    #6
  7. Guest

    Joe Kaplan Guest

    Microsoft's ILM or FIM 2010 would be the MS product to do this type of
    thing. It provides lots of functionality for doing sync and data mapping.

    I don't think there need be any problem with the AD as a result of
    provisioning this way as long as the attribute data in AD turns out fine.
    The devil is in the details there.
     
    Joe Kaplan, Nov 13, 2009
    #7
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.