• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 562
  • Last Modified:

Directory change ldap(Novel) to MS Active directories

 There is directory change in our application.It is changing from ldap(Novel) to MS Active directories.
What kind of change should I expect in our code? so that I can learn about them .Links are welcome.
  • 5
  • 2
3 Solutions
If this is a commercial application, why not keep it LDAP, to provide your customers with a choice?  AD works to a degree with LDAP.  It's not LDAPv3 Certified like eDirectory, but it's "LDAP Compatible" per Microsoft, whatever that means, and you won't lock out other LDAP-accessible directories, including eDirectory as well as the directory services provided by IBM, Oracle, SUN, etc. and, of course, openLDAP (which will grow, guaranteed, as part of the growing Linux presence.)

The big difference with AD is the LDAP notation to get to the context of the object.  AD makes considerable use of the "DC" container type where in a "normal" x.500-based directory you'd expect the customary hierarchy, CN, OU, O, C...

They do use the OU container type but it's not really a hierarchical structural organizational unit  but rather a grouping type added in to make it comply a bit closer to x.500.

If your app is home-grown, then I'd think it'd be easier to continue to use LDAP with AD, as well.  You'd just have to deal with the minor oddments with the structure, which should be no big deal.

If you're using a Java app server platform like Tomcat, JBoss, etc., and you plan to use the directory for authentication,  then you'll also have to make sure you have a usable PKI certificate you can import.  If you plan to use Kerberos, although it's got some proprietary quirks, that doesn't mean you have to scrap LDAP...  Heck, Microsoft uses LDAP lookups in its own utilities...
ManishLeadAuthor Commented:
Client is changing directory structure,so we dont have much control on it.
Our application is using java and websphere (developed on ide wsad).
what is PKI certificate ?
Do I expect that we dont have to change much in code to access AD?
Like in ldap we are using url as ldap://....389.
How the AD is accesible? ANy software should I need to download to access it?
If the AD server is using the default port for unsecure LDAP, then port 389 is still good, even with AD.

The url ldap://servername:389 should still work.

You have to make sure you can a) anonymous BIND, which will give you limited use or b) set up a user that you can use to log in to AD for LDAP access.

If your server internal DNS URL is, for example, server1.mydomain.myforest.local, then the user credentials would be:


If your users folder or user objects or groups or whatever are in an OU folder within your domain, then you'd use the ou= qualifier, but the default "users" folder is a cn object type.  

OU hierarchy begins after the last domain level in a forest.  Up to that point, all qualifiers must be "dc" (domain controller.)  If you want to set a base, use the "dc" heirarchy.

If you can limit your commands to LDAPv2 that'd be great, since AD isnt, as I mentioned, LDAPv3 certified (or even compliant, last I checked.)
Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Also, PKI certificate is if you want to do SSL-secure LDAP (default port 636).  The customer would have to set up PKI services on their server (a Certificate Authority) and mint a public/private key pair.

That would encrypt the password info.

If LDAP isn't being used by your app for user/password authentication, then 389 should be fine, but if you're using LDAP for an authentication vehicle for your app and are using the directory service's user ID and password to authenticate, then you should already be using secure LDAP.

If it's just for lookup/white pages type stuff, then unsecure LDAP should be OK.
ManishLeadAuthor Commented:
Application uses ldap for authentication and getting some attributes.
So what I am understanding is
current code can be used for authentication and getting attibutes...with some changes in
search base .As AD may have different type of hirarchy.
Currently like we have search base
Yep, now the base would be cn=users,dc=domain,dc=forest,dc=dnsroot
users is the built-in users folder where the users/groups reside by default,
domain is the AD domain
forest is the AD forest, if their AD has that type of structure
dnsroot is the TLD they use when they define their AD DNS structure (.com, .net, .local, .lan or whatever they choose...)

If their AD is simple, with only the forest root domain, then you'd only have two DC levels...
If they customize their AD structure, dividing their user objects and group objects into self-defined OU's, you'd have to look in the OUs instead of the default "users" CN.

I don't know how well it does traversing through the structure below the base or dereferencing aliases or such.  In their current eDirectory setup, are all the user objects in their USERS OU, or do they put aliases in the USERS OU that get dereferenced to the actual containers the user objects are in?
You may also have to map some attributes.  You should set up an AD test system to work with, so you can see how the base schema differs as regards attributes.  For example, in eDirectory, a group is type "groupofnames" while AD groups are just type "group."
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

  • 5
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now