I agree with what everyone else has posted on this subject. Apps that auto-update the schema without the admin specifically choosing that option are a complete no-no and the sign of a poorly behaved app and vendor.
I would also suggest to vendors that they allow their application to be flexible enough to allow the admins to specify an alternate attribute versus requiring a schema mod for every attribute they need. This covers the cases where the data needed is already in the directory and the admins don't want to have to populate another attribute with duplicate data. The application should verify that the parameters of the alternate attribute are sufficient for its needs and then simply use it. For example, say a company extended the directory with a dept code or some company specific attribute and then later bought an App that manages that kind of data and it wanted to extend the schema to hold the info. Instead the app should allow the admin to point at the prexisting attribute. Another thing I recommend is to not pack data into magical formats. Just use simple easy formats, you almost certainly aren't going to prevent someone from figuring out the attribute format anyway if they really want to know, so why bother? Assume that admins will modify attributes outside of your application. Your app should not trust that data that is read from the directory is only in the format that the app writes it in. Expect carriage returns or numbers or special characters or too large of values (buffer size or integer size) or any number of things that you specifically disallow your app from writing. Handle the cases that it is encountered. Document, document, document. Along with the app should be documentation explaining exactly what the attributes are and their valid values and how they are interconnected, etc. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chuck Chopp Sent: Friday, September 23, 2005 10:30 AM To: [email protected] Subject: [ActiveDir] Applications that extend the schema... Given the # of variations that may exist in AD deployments, anywhere from a small business with a single forest/tree/domain all the way up to a large enterprise with multiple forests each containing multiple trees with each tree having numerous domains, there may be many differences of opinion on the part of administrators regarding schema extensions and applications the create them. I'm interested in hearing those opinions in regards to an enterprise type of resource provisioning application that will run primarily as a service under a specific domain account, with the caveat that the application does require some schema extensions in order to run properly. In particular, the question pertains to whether or not the main application should attempt to perform the schema extension work when it detects that they are not present, and if so, should it want/need to do so under it's own set of credentials used to perform the service logon by the service control manager when the service is started, or should the application's UI request an elevated set of credentials in order to perform the schema extension. Alternatively, should the schema extension be performed using an additional program provided with the application so that it would be relatively easy for an administrator to logon, run the schema extension tool, and then be done with their part so that the application's "owner" could continue with the installation & configuration of the application. I'm familiar with many of the issues in terms of Novell's eDirectory, but with AD there may be some other concerns due to differences in the two directory services and how they are implmented. It's the AD-specific concerns that interest me. TIA, Chuck -- Chuck Chopp ChuckChopp (at) rtfmcsi (dot) com http://www.rtfmcsi.com RTFM Consulting Services Inc. 864 801 2795 voice & voicemail 103 Autumn Hill Road 864 801 2774 fax Greer, SC 29651 "Racing to save lives" The Leukemia & Lymphoma Society - Team in Training http://www.active.com/donate/tntsc/tntscCChopp Do not send me unsolicited commercial email. List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
