RE: [ActiveDir] User to InetOrgPerson Class
I would say it is in the process of happening and will get more and more prevelant. Probably to the great dislike of many a Linux person who until recently has been pushing so hard for Linux to be the mainstream replace everything MS OS. I know many are backing off of that now as they realize what it takes to make it replace MS in a major way, a lot of the things they don't like about MS they have to emulate. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger Seielstad Sent: Thursday, May 06, 2004 7:32 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] User to InetOrgPerson Class That's long since happened, my friend. The particular distro I was installing was Redhat 7.1[1], which is required for one of our soon to be legacy products... -- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. [1] Yeah - so what if it hasn't been supported in years? > -Original Message- > From: joe [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 04, 2004 11:19 PM > To: [EMAIL PROTECTED] > Subject: RE: [ActiveDir] User to InetOrgPerson Class > > Agreed. As Linux tries to become more and more mainstream you will > most likely have dists that bloat more and more in terms of what is > dropped on the disk by default. > > joe > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Sean > Sent: Tuesday, May 04, 2004 10:40 AM > To: [EMAIL PROTECTED] > Subject: RE: [ActiveDir] User to InetOrgPerson Class > > Of course that does tend to be distribution specific ;) > > On Mon, 2004-05-03 at 09:40, Roger Seielstad wrote: > > Actually, close. > > > > Apparently, a "base" install of Linux doesn't include things like > > ping, traceroute, ssh, nor much else in the way of basic tools. > > > > Roger > > -- > > Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator > > Inovis Inc. > > > > > > > -----Original Message- > > > From: joe [mailto:[EMAIL PROTECTED] > > > Sent: Sunday, May 02, 2004 11:17 AM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [ActiveDir] User to InetOrgPerson Class > > > > > > Driver error. Recompile kernel > > > > > > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of Roger > > > Seielstad > > > Sent: Thursday, April 22, 2004 10:42 AM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [ActiveDir] User to InetOrgPerson Class > > > > > > Um, yeah. That's right. > > > > > > If I wasn't spending all day yesterday trying to fix a > Linux box, I > > > would have definitely written the same thing. > > > > > > -- > > > Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator > > > Inovis Inc. > > > > > > > > > > -Original Message- > > > > From: joe [mailto:[EMAIL PROTECTED] > > > > Sent: Thursday, April 22, 2004 9:40 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: RE: [ActiveDir] User to InetOrgPerson Class > > > > > > > > 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... ;) > > > > > >
RE: [ActiveDir] User to InetOrgPerson Class
That's long since happened, my friend. The particular distro I was installing was Redhat 7.1[1], which is required for one of our soon to be legacy products... -- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. [1] Yeah - so what if it hasn't been supported in years? > -Original Message- > From: joe [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 04, 2004 11:19 PM > To: [EMAIL PROTECTED] > Subject: RE: [ActiveDir] User to InetOrgPerson Class > > Agreed. As Linux tries to become more and more mainstream you > will most > likely have dists that bloat more and more in terms of what > is dropped on > the disk by default. > > joe > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Sean > Sent: Tuesday, May 04, 2004 10:40 AM > To: [EMAIL PROTECTED] > Subject: RE: [ActiveDir] User to InetOrgPerson Class > > Of course that does tend to be distribution specific ;) > > On Mon, 2004-05-03 at 09:40, Roger Seielstad wrote: > > Actually, close. > > > > Apparently, a "base" install of Linux doesn't include things like > > ping, traceroute, ssh, nor much else in the way of basic tools. > > > > Roger > > -- > > Roger D. Seielstad - MTS MCSE MS-MVP > > Sr. Systems Administrator > > Inovis Inc. > > > > > > > -Original Message- > > > From: joe [mailto:[EMAIL PROTECTED] > > > Sent: Sunday, May 02, 2004 11:17 AM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [ActiveDir] User to InetOrgPerson Class > > > > > > Driver error. Recompile kernel > > > > > > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of Roger > > > Seielstad > > > Sent: Thursday, April 22, 2004 10:42 AM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [ActiveDir] User to InetOrgPerson Class > > > > > > Um, yeah. That's right. > > > > > > If I wasn't spending all day yesterday trying to fix a > Linux box, I > > > would have definitely written the same thing. > > > > > > -- > > > Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator > > > Inovis Inc. > > > > > > > > > > -Original Message- > > > > From: joe [mailto:[EMAIL PROTECTED] > > > > Sent: Thursday, April 22, 2004 9:40 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: RE: [ActiveDir] User to InetOrgPerson Class > > > > > > > > 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
RE: [ActiveDir] User to InetOrgPerson Class
Agreed. As Linux tries to become more and more mainstream you will most likely have dists that bloat more and more in terms of what is dropped on the disk by default. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sean Sent: Tuesday, May 04, 2004 10:40 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] User to InetOrgPerson Class Of course that does tend to be distribution specific ;) On Mon, 2004-05-03 at 09:40, Roger Seielstad wrote: > Actually, close. > > Apparently, a "base" install of Linux doesn't include things like > ping, traceroute, ssh, nor much else in the way of basic tools. > > Roger > -- > Roger D. Seielstad - MTS MCSE MS-MVP > Sr. Systems Administrator > Inovis Inc. > > > > -Original Message- > > From: joe [mailto:[EMAIL PROTECTED] > > Sent: Sunday, May 02, 2004 11:17 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [ActiveDir] User to InetOrgPerson Class > > > > Driver error. Recompile kernel > > > > > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Roger > > Seielstad > > Sent: Thursday, April 22, 2004 10:42 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [ActiveDir] User to InetOrgPerson Class > > > > Um, yeah. That's right. > > > > If I wasn't spending all day yesterday trying to fix a Linux box, I > > would have definitely written the same thing. > > > > -- > > Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator > > Inovis Inc. > > > > > > > -Original Message- > > > From: joe [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, April 22, 2004 9:40 AM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [ActiveDir] User to InetOrgPerson Class > > > > > > 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 flexi
RE: [ActiveDir] User to InetOrgPerson Class
Of course that does tend to be distribution specific ;) On Mon, 2004-05-03 at 09:40, Roger Seielstad wrote: > Actually, close. > > Apparently, a "base" install of Linux doesn't include things like ping, > traceroute, ssh, nor much else in the way of basic tools. > > Roger > -- > Roger D. Seielstad - MTS MCSE MS-MVP > Sr. Systems Administrator > Inovis Inc. > > > > -Original Message- > > From: joe [mailto:[EMAIL PROTECTED] > > Sent: Sunday, May 02, 2004 11:17 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [ActiveDir] User to InetOrgPerson Class > > > > Driver error. Recompile kernel > > > > > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > Roger Seielstad > > Sent: Thursday, April 22, 2004 10:42 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [ActiveDir] User to InetOrgPerson Class > > > > Um, yeah. That's right. > > > > If I wasn't spending all day yesterday trying to fix a Linux > > box, I would > > have definitely written the same thing. > > > > -- > > Roger D. Seielstad - MTS MCSE MS-MVP > > Sr. Systems Administrator > > Inovis Inc. > > > > > > > -Original Message- > > > From: joe [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, April 22, 2004 9:40 AM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [ActiveDir] User to InetOrgPerson Class > > > > > > 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 anythi
RE: [ActiveDir] User to InetOrgPerson Class
Actually, close. Apparently, a "base" install of Linux doesn't include things like ping, traceroute, ssh, nor much else in the way of basic tools. Roger -- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. > -Original Message- > From: joe [mailto:[EMAIL PROTECTED] > Sent: Sunday, May 02, 2004 11:17 AM > To: [EMAIL PROTECTED] > Subject: RE: [ActiveDir] User to InetOrgPerson Class > > Driver error. Recompile kernel > > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Roger Seielstad > Sent: Thursday, April 22, 2004 10:42 AM > To: [EMAIL PROTECTED] > Subject: RE: [ActiveDir] User to InetOrgPerson Class > > Um, yeah. That's right. > > If I wasn't spending all day yesterday trying to fix a Linux > box, I would > have definitely written the same thing. > > -- > Roger D. Seielstad - MTS MCSE MS-MVP > Sr. Systems Administrator > Inovis Inc. > > > > -Original Message- > > From: joe [mailto:[EMAIL PROTECTED] > > Sent: Thursday, April 22, 2004 9:40 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [ActiveDir] User to InetOrgPerson Class > > > > 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 >
RE: [ActiveDir] User to InetOrgPerson Class
Driver error. Recompile kernel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger Seielstad Sent: Thursday, April 22, 2004 10:42 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] User to InetOrgPerson Class Um, yeah. That's right. If I wasn't spending all day yesterday trying to fix a Linux box, I would have definitely written the same thing. -- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. > -Original Message- > From: joe [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 22, 2004 9:40 AM > To: [EMAIL PROTECTED] > Subject: RE: [ActiveDir] User to InetOrgPerson Class > > 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 onc
RE: [ActiveDir] User to InetOrgPerson Class
If you weren't the size of a Giant Redwood tree I would take offense to that therapy comment. ;o) Instead my response is simply Yes sir, it is working. =) Now that some of you folks know what I look like and actual pictures exist, I have to be nicer... Welcome to the nicer kinder gentler joe... Heh. Yeah right. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger Seielstad Sent: Thursday, April 22, 2004 10:36 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] User to InetOrgPerson Class 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, h, 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 >
RE: [ActiveDir] User to InetOrgPerson Class
Um, yeah. That's right. If I wasn't spending all day yesterday trying to fix a Linux box, I would have definitely written the same thing. -- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. > -Original Message- > From: joe [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 22, 2004 9:40 AM > To: [EMAIL PROTECTED] > Subject: RE: [ActiveDir] User to InetOrgPerson Class > > 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
RE: [ActiveDir] User to InetOrgPerson Class
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, h, 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 wou
RE: [ActiveDir] User to InetOrgPerson Class
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, h, 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 &g
RE: [ActiveDir] User to InetOrgPerson Class
Didn't need to if you are running it, though I did dedicate an entire paragraph to it :o) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael B. Smith 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, h, 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
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, h, 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
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, h, 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...
RE: [ActiveDir] User to InetOrgPerson Class
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... -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, h, 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 director
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, h, 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
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, h, 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 talk
RE: [ActiveDir] User to InetOrgPerson Class
Hi Mike, Here is an MS blurb from one of their workshops on the InetOrgPerson Class... "What Is the InetOrgPerson Object? Most non-Microsoft LDAP and X.500 directory services such as Novell eDirectory and Netscape Directory Server use the InetOrgPerson object class to represent people within an organization. To make those applications more compatible with Active Directory and permit the migration of InetOrgPerson objects to Active Directory, the InetOrgPerson class is added to the Active Directory schema for Windows 2003 Server. Microsoft Windows® 2000 did not support the InetOrgPerson account. Windows Server 2003 includes the InetOrgPerson account, in addition to the standard user account type that Windows 2000 supports. You can use the InetOrgPerson account in Windows Server 2003 in all of the same ways as a standard user account. The InetOrgPerson account is a security principal in Windows Server 2003, so it can be a member of security groups and can be assigned rights and privileges to objects and resources. In Windows 2000, Active Directory uses the unicodePwd attribute to store passwords for user accounts. Most other LDAP-compliant directories use the userPassword property to store passwords for user accounts. In Windows Server 2003, when the domain functional level is set to Windows Server 2003, you can use the userPassword attribute to store the password for InetOrgPerson accounts. This enables you to use InetOrgPerson accounts to provide compatibility with other directory services that your organization uses." My specific interest is in authenticating openldap clients against AD. To my understanding, certain clients expecting to see an inetOrgPersonClass may not respond well to the user class. If one is using pam_ldap it is possible to && some specific values in /etc/ldap.conf and authenticate a user, in order to do this I prefer to use a more standardized person objectClass, and the inetOrgPerson is the best one that ms provides. Before implementing you may want to read some of the following kb articles: http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q307998 http://support.microsoft.com/?id=822591 http://support.microsoft.com/default.aspx?scid=kb;en-us;811656 http://support.microsoft.com/default.aspx?scid=kb;en-us;314649 From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED] Sent: Wed 4/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
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/
Re: [ActiveDir] User to InetOrgPerson Class
Very well, I'm off to perl... Thanks Guys On Apr 21, 2004, at 9:09 AM, Nicolas Blank wrote: 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/
RE: [ActiveDir] User to InetOrgPerson Class
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/
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/
RE: [ActiveDir] User to InetOrgPerson Class
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/
