And you didn't even mention the "E" word! :-) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe 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 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, April 21, 2004 10:15 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] User to InetOrgPerson Class This thread has gotten my interest. We had IBM in here a couple of years ago talking about their LDAP and that Active Directory was inferior because of it's implementation of the InetOrgUser class instead of InetOrgPerson. We stopped them when we mentioned our intention of going with .NET (was RC2 at the time) and that their implementation of InetOrgPerson appeared to be as compliant as anyone else's implementation. However, I've heard very little about InetOrgPerson since then. In fact, we had a training in-house late last year to train some of our staff and he stated that he's never heard of anyone using or wanting to use InetOrgPerson. I told him that I've been recommending that we need to implement AD using InetOrgPerson instead of User. My concern is compatibility with other organizations (we will be in acquisition mode in a year or so) as well as compatibility with enterprise LDAP directories (we're in need of something that will cover multiple platforms). I would appreciate it if you could comment, offline if you want, as to why you are seeking to migrate to InetOrgPerson or whether you chose InetOrgPerson at the outset for your implementation. I'm curious about the degree of adoption. I'm running in to a great deal of resistance regarding InetOrgPerson here and am concerned that we would end up looking at a migration very shortly after our migration. Thanks, Mike > I have chased Ms on this for an official KB article without success. I > have done this in production without any hassles though on exactly the > same scenario you described: third party kit that like inetorgPerson > better than the user class. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Brent > Westmoreland > Sent: 21 April 2004 02:40 PM > To: [EMAIL PROTECTED] > Subject: Re: [ActiveDir] User to InetOrgPerson Class > > Using pure ldap logic, One would assume that is the case. I guess I > was hoping someone had stumbled across a kb article so that once this > is done in production, I have an endorsed Microsoft methodology to > take to management. > > > On Apr 21, 2004, at 8:12 AM, Ulf B. Simon-Weidner wrote: > > > Hello Brent, > > > > this is very easy to accomblish: you just need to add the > inetOrgPerson > > class to the objectClass attribute of the user using adsiedit or a > > script. > > > > Ulf > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Brent > > Westmoreland > > Sent: Dienstag, 20. April 2004 21:18 > > To: [EMAIL PROTECTED] > > Subject: [ActiveDir] User to InetOrgPerson Class > > > > Does anyone know of a Microsoft endorsed way to change a win2k3 user > > object to an InetOrgPerson object without having to export the > > information > and > > reimport it? There is a potential that some of our clients will > > need to interact with active directory from an alternate client. > > This change would be more easily supported if the user were defined > > as an InetOrgPerson. > > > > 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/ > > > > 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/ > > 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/ > > > 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/ 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/ 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/ 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/
