Last post Aug 08, 2008 03:34 AM by ssg31415926
Aug 07, 2008 01:59 PM|spatnaik|LINK
Aug 07, 2008 05:49 PM|ssg31415926|LINK
The big difference is that Directories such as ActiveDirectory are optimized for reads, whereas a Database is optimized for read/write. So, if you're expecting to update frequently, SQL Server might be a better repository but if you'll read many times but
update rarely then ActiveDirectory might be a good choice.
Another issue: normally Directory information is readable by any authenticated user of the network so they're not appropriate for confidential information. We had someone in my organization decide to 'secure' AD by removing such access and he broke all
sorts of things. If you need confidential info, stick to SQL server. Or use ADAM (ADLDS) and create your own schema.
I think there are practical limits to the size of an AD but you're talking in excess of 100,000 users, from what I recall. Best to check this yourself if that's the sort of numbers you're talking.
Aug 08, 2008 12:47 AM|spatnaik|LINK
Thanks for replying. I agree with you that Active Directory is optimized for read and database for both read/write. But my question is whats all the fields should be stored as per best practice, there is no confindetails data in it. We have only 500 employee
..no of employee does not matter. Can we store any number of field data in Active Directory?
active Directory design
Aug 08, 2008 03:34 AM|ssg31415926|LINK
I don't believe there are any specific recommendations other than only using fields for what they were intended. E.g. Don't use employeeNumber to store bit-flag that gives application permissions or some such.
You can use any of the fields that ActiveDirectory itself doesn't use. The list is quite long. E.g. givenName, sn, initials, displayName (decide which format you want: http://support.microsoft.com/kb/277717), employeeID, employeeNumber, employeeStatus
You can get a list of all of the built-in attributes here: http://msdn.microsoft.com/en-us/library/ms683980(VS.85).aspx and details on each here: http://msdn.microsoft.com/en-us/library/ms675090.aspx. Be sure to check each one out to make sure there are
no gotches. E.g. employeeID is limited to 16 characters (rangeUpper = 16) whereas employeeNumber is 512.
If you can't find a field that fits what you need, beware of using another field - we've found that new stuff comes along and we've regretted some fields we've used. You can make changes to the Active Directory schema fairly easily. You can add attributes
to existing classes and you can do this in a permanent way or using dynamic auxiliary classes. You can also create new classes which can use existing and/or new attributes and you can link classes together. E.g. the member attribute on a group is linked
to the memberOf attribute on a user - you fill in member and AD takes care of memberOf.
If you decide to do this: (1) do lots of research first and (2) test everything on a separate AD forest - you can't undo changes you've made, not completely, anyway. I recommend getting a virtual machine set up. That way, you can back it up, make loads
of changes, make a mistake, restore it and start again. You can build your LDIF file (to make the changes to the live forest) step by step and test it each time, simply by restoring.