All directories have a schema that defines the type of entries (e.g. container, user, group and etc) that the directory can contain and the items (attributes) that each entry can have (e.g. cn, sn, givenname, mail & etc).
You do not want to "port" the AD schema or any other directories schema to another directory. If you want to stand up any directory product, you must learn it so you can have it contain the types of entries and attribute data for your needs. An additional requirement is to understand the security components to protect those entries and attributes. Some vendors, like Microsoft design their directory product so any connected user can see all entries and attributes in the directory, which might be more data that should be exposed. While other vendor designed their directory product where you (the admin) have to all assign access controls, because nothing is exposed by default.
It would be best to use the ApacheDS admin tool and admin guide to build a similar ou= and dc= container structure in ApacheDS that loosely matches your AD environment. Then using the ApacheDS admin tool and admin guide, create a simple user and group. At which time you can then use any numerous LDAP browser or command line tools (I prefer the OpenLDAP command line tools) to search against your ApacheDS directory and list out your simple user and group entry (into a .ldif file format). Those same tools can also be used to pull data from AD.
There are plenty of sample java code snip-its on the Internet to LDAP auth against a directory service, that you would not have to "develop one".
Some directory vendors do have attribute uniqueness features where the "naming attribute" of a entry's distinguished name can be made "globally unique" like Microsoft did with the sAMAccountName.
A user (David Allen Smith) might as an example be give a login account named smithDA and be part of the engineering department. The directory container structure might look like:
dc=com dc=acme ou=engineering...thus making his distinguished name: cn=smithDA,ou=engineering,dc=acme,dc=com
In this distinguished name, the "naming attribute" is the cn attribute. In some directory products, an attribute uniqueness constant can be applied to the cn attribute so that David's login account is the only one named smithDA.
On 8/16/18 10:45 AM, Lothar Haeger wrote:
Milan Tomic wrote:Now I would like to create as close as possible structure in my local installation of ApacheDS as it is in real ActiveDirectory.I'd rather try to install a Windows Server in VMware and create "real" AD Domain. AD is very much doing stuff just like AD and not like most other LDAP directories, so if you want our app to work properly against all LDAP flavours make sure to test and develop against all (main) flavours. Even if you get the schame ported over, the backend server behaviour will not be the same. E.g. most LDAP directories use loginDisabled to lock accounts, AD uses a single binary attribute storing lock status together with a couple of different status bits and not all of them can be flipped though LDAP at all. Another one is the sAMAccountName, which AD enforces to be globally unique, but any "standard" LDAP won't do that and you could create JDOE accounts in several different containers.
smime.p7s
Description: S/MIME Cryptographic Signature
