Use Active Directory to store data

I'm wondering if it's a sane idea to use Active Directory to store entities related to an application, when not all entity types are the traditional AD-entities such as organizational unit, user, group, etc.

At the moment, I have a database schema consisting of things such as customers and users. Each customer can have their own departme开发者_如何学运维nts. Each department can have a set of users. Each user can have a name, authentication details, etc. A colleague reminded me that Active Directory already has infrastructure to support this kind of hierarchies, so rebuilding this from scratch may not be optimal.

Now, my problem is that I will need much more entities than just customers, users and so on. I will have to store statistics, documents, contacts (which aren't users in the sysetm) and other information as well. To pick a number out of thin air, there may be 10-20 additional entity types which does not already exist in Active Directory. These entity types will be 'linked' to customers, users, and so on. The users in this system is not users in my local network but will be accessing my software over the internet.

I have only a very vague understanding of Active Directory, but as I understand it I would have to extend the AD schema to store my own entities. I would have to add properties to "Organizational unit" such as "document list".

An alternative method could be to rely on the organizational units, users and groups in AD and have a separate MSSQL database to store the remaining data. My MSSQL database would then have to link entities such as 'contact' to a specific OU or user using it's unique identifier or whatever it's called.

Any thoughts on this? Is it wise to store complex types in AD rather than in a MSSQL database?

(The entities are most likely few enough to make performance a non-issue in either case)

What you are describing can certainly be done. I have seen it. You will probably find that AD is very heavy, and overboard for a use like this. The management and long term maintainence will be very costly. I would not reccommend it. Using a Database is probably the right solution for you.

Alternatively, if you don't have an existing database or dont want to impliment one, you could use Active Directory Lightweight Directory Services (AD LDS, formerly ADAM). This was designed to be a more lightweight directory, and operates in its own schema so you do not have to change your existing AD infrastructure. I have used that in the past, and it is much easier to maintain. The other advantage is that it uses the same framework and SDK as AD.