Roger, you are just mad because you were typing up the same note and I typed it and sent it out faster...
Oh well I have to get back to unburying myself. Just came in to spot check to see what you all were saying behind my back... I should be back hard core in a week or two. In the meanwhile I am digging out of email and work issues and also during an EMC issue I was looking at I think I figured out something else cool to put into adfind... We shall see. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger Seielstad Sent: Thursday, April 22, 2004 9:27 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] User to InetOrgPerson Class Please - we're trying to not encourage him... ;) Roger -------------------------------------------------------------- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. > -----Original Message----- > From: Jerry Welch [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 22, 2004 9:14 AM > To: [EMAIL PROTECTED] > Subject: RE: [ActiveDir] User to InetOrgPerson Class > > GO JOE !! > > Jerry Welch > CPS Systems > US/Canada: 888-666-0277 > International: +1 703 827 0919 (-5 GMT) > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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/ 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/
