Joe, as usual, your posts are both informative and entertaining. This one gets filed for the next time someone comes to me asking for another half-baked schema extension because the app wasn't designed right in the first place. Should be in the next hour or so if history would predict...
<mc> -----Original Message----- From: joe [mailto:[EMAIL PROTECTED] Sent: Thursday, April 22, 2004 9:11 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] User to InetOrgPerson Class We aren't even considering converting or making our 200k+ user objects inetorgperson objects. We have had no requirement to do so and if someone came forth with one at this point we would ask why their product wasn't written to be flexible enough to account for the de facto most popular LDAP server out there. LDAP is a pretty flexible system yet you get vendors coming along hard coding dependencies in on their own and try to make the directories fit their apps, this is obviously not correct. Vendors (including Microsoft) take note, if you are using LDAP for anything, make your attributes/objects required mappable. Saying someone has to have an attribute with a certain name or an object with a certain name or class is not flexible and you can do better. LDAP is extensible and people do do things sometimes before Vendors write code to do the same things. Most Vendors aren't coming up with cool new things no one else never thought up, they are just polishing, implementing, and trying to sell the solutions as ready made. I, for instance, may have at some point put UIDs into an attribute called BobToy. Does it make sense, maybe not to you, maybe to me it makes all the sense in the world. You coming in saying I have to use something else means I have to change all of my stuff, repopulate the fields, possibly schema extend for you, probably do syncing (or rewriting) for now on because I am probably already using that attribute - how rude and pretentious of you as a vendor. Ditto for objectclassing for what objects I want to use for various things. Again, LDAP is extensible, AD very easily so. Schemas are easy to modify and have data populated. As a vendor, don't sit back and think you are the only one that needs to use certain data and that it wouldn't be there already unless your app was there. From the start define the data that you need but don't assume the data isn't there in an attribute already. Actually assume it is and you just have to use it. Then once you have accomplished that by making your app flexible in how it gathers data from the directory, define the schema addons/changes someone may need with a raw schema that they haven't done any extensions to. As we get further along into using LDAP I think you will find that methodology fundamentally better for your sales. Is it harder? Yes. But if it were easy everyone would be doing it already. Oh to add one final thing, don't assume where in the directory the object is either.... Saying groups have to be in one certain OU or container or things break is just plain silly. You know who you are. Oh, one other final thing... MS LDAP Servers have this great ability to not require the FULL DN of an object for a bind... You can use domain\userid or [EMAIL PROTECTED] (i.e. [EMAIL PROTECTED]). Use it. This way when someone moves your bind ID (because they can), your application doesn't go down in flames with your help desk standing there going, hmmmm, we have no idea why our application can't authenticate Mr. X. Not only use it, but put it in your documentation... Even if you say something like.... Well you know, our own Directory Server is far superior to the MS one, however, if you do use the MS one, they have this cool feature we can't touch (and frankly don't need to because we don't have the flexibility required to need this additional flexibility) that allows you to not hardcode the DN of the bind ID. Yes, yes, that is pretty cool, so use it if you find yourself on that directory. Oh, and one last last final thing which is one major thing for MS before I close.... Document the default schema and the schema mods you make for your apps completely. Put in dependency information. I have asked for this multiple times and hear, that would be impossible, do you know all of the interconnections blah blah blah. Sure... But you guys figure out new items one at a time. Document them then. In the meanwhile, go clean up as it doesn't appear you even kjnow what is out there or what it should be. Every attribute should be documented in terms of what it is used for, what subsystems use it (dependencies), what the valid range of values are, if you ever intend to use it and what time frame if so (logoffTime, operatingSystemHotfix, etc). This would be helpful to your own people let alone everyone trying to use your product. I have had more than one bluescreen or stopped replication because of bad data in the directory and the fun thing is I have no way in the world to know if data is good or not because I have no clue what is supposed to be valid for the fields. joe List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
