Forum Search:
Forum.Brain-Cluster.com: Brain Cluster Technical Forum
Ultimate forum for Technical Discussions

Home » Microsoft » Windows Server » Active Directory » Converting OpenLDAP to AD... multi-valued CN attributes...
Converting OpenLDAP to AD... multi-valued CN attributes... [message #315885] Thu, 12 November 2009 13:12 Go to next message
hume.spamfilter  is currently offline hume.spamfilter
Messages: 25
Registered: November 2009
Junior Member
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...

--
Brandon Hume - hume -> BOFH.Ca, http://WWW.BOFH.Ca/
Re: Converting OpenLDAP to AD... multi-valued CN attributes... [message #316114 is a reply to message #315885] Thu, 12 November 2009 17:25 Go to previous messageGo to next message
Joe Kaplan  is currently offline Joe Kaplan  United States
Messages: 88
Registered: July 2009
Member
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-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
<hume.spamfilter@bofh.ca> wrote in message
news:hdhq7o$vr7$1@Kil-nws-1.UCIS.Dal.Ca...
> 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...
>
> --
> Brandon Hume - hume -> BOFH.Ca, http://WWW.BOFH.Ca/
Re: Converting OpenLDAP to AD... multi-valued CN attributes... [message #316561 is a reply to message #316114] Fri, 13 November 2009 06:10 Go to previous messageGo to next message
hume.spamfilter  is currently offline hume.spamfilter
Messages: 25
Registered: November 2009
Junior Member
Joe Kaplan <joseph.e.kaplan@removethis.accenture.com> wrote:
> This is correct. AD does not support multivalued RDNs.

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?

> 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.

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.

> 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.

"Showstopper" is relative. People need what they want and it's not their
money nor time. :)

--
Brandon Hume - hume -> BOFH.Ca, http://WWW.BOFH.Ca/
Re: Converting OpenLDAP to AD... multi-valued CN attributes... [message #316601 is a reply to message #316561] Fri, 13 November 2009 07:03 Go to previous messageGo to next message
hume.spamfilter  is currently offline hume.spamfilter
Messages: 25
Registered: November 2009
Junior Member
hume.spamfilter@bofh.ca wrote:
> 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

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.

--
Brandon Hume - hume -> BOFH.Ca, http://WWW.BOFH.Ca/
Re: Converting OpenLDAP to AD... multi-valued CN attributes... [message #316620 is a reply to message #316561] Fri, 13 November 2009 07:38 Go to previous messageGo to next message
Joe Kaplan  is currently offline Joe Kaplan  United States
Messages: 88
Registered: July 2009
Member
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-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
<hume.spamfilter@bofh.ca> wrote in message
news:hdjlsc$cjl$1@Kil-nws-1.UCIS.Dal.Ca...
> Joe Kaplan <joseph.e.kaplan@removethis.accenture.com> wrote:
>> This is correct. AD does not support multivalued RDNs.
>
> 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?
>
>> 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.
>
> 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.
>
>> 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.
>
> "Showstopper" is relative. People need what they want and it's not their
> money nor time. :)
>
> --
> Brandon Hume - hume -> BOFH.Ca, http://WWW.BOFH.Ca/
Re: Converting OpenLDAP to AD... multi-valued CN attributes... [message #316636 is a reply to message #316620] Fri, 13 November 2009 07:56 Go to previous messageGo to next message
hume.spamfilter  is currently offline hume.spamfilter  United States
Messages: 25
Registered: November 2009
Junior Member
Joe Kaplan <joseph.e.kaplan@removethis.accenture.com> wrote:
> 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.

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?

--
Brandon Hume - hume -> BOFH.Ca, http://WWW.BOFH.Ca/
Re: Converting OpenLDAP to AD... multi-valued CN attributes... [message #316809 is a reply to message #316636] Fri, 13 November 2009 11:36 Go to previous message
Joe Kaplan  is currently offline Joe Kaplan  United States
Messages: 88
Registered: July 2009
Member
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-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
<hume.spamfilter@bofh.ca> wrote in message
news:hdjs29$h84$1@Kil-nws-1.UCIS.Dal.Ca...
> Joe Kaplan <joseph.e.kaplan@removethis.accenture.com> wrote:
>> 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.
>
> 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?
>
> --
> Brandon Hume - hume -> BOFH.Ca, http://WWW.BOFH.Ca/
Previous Topic:AD Account got locking out frequently
Next Topic:Export Global Group Members samacountname(s) to Text File
Goto Forum:
  


Current Time: Fri Jan 19 00:36:57 MST 2018

Total time taken to generate the page: 0.48382 seconds
.:: Contact :: Home ::Sitemap::.

Powered by: FUDforum 3.0.0RC2.
Copyright ©2001-2009 FUDforum Bulletin Board Software