Or Universal Groups! Apparently the therapy is working....
-------------------------------------------------------------- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. > -----Original Message----- > From: Michael B. Smith [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 22, 2004 9:31 AM > To: [EMAIL PROTECTED] > Subject: RE: [ActiveDir] User to InetOrgPerson Class > > 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/ > 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/
