The simplest solution is to use the full DN of the object that you are using getobject on. You have the parent DN, prepend the object DN and do a getobject; don't do it in the relative way that it was being done. Shouldn't be an issue then because you don't specify the object type then.
joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Elena Mananova (DSL AK) Sent: Sunday, February 06, 2005 2:52 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] LDAP and Win2003 Question Thanks a lot for all your answers and discussion. The person who wrote the functionality has left the company and I am doing the support. So I don't really want to change too much or to rewrite the code as I am not sure what else it can break. Considering my lack of LDAP knowledge and the time constraints (release next week), I might just go for an ugly solution of checking 2 class objects, as it seems to do the job. It just looks like it will take me a bit longer to find a better solution and to retest the functionality. Thanks to all of you again. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Friday, 4 February 2005 6:52 p.m. To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] LDAP and Win2003 Question The info doesn't stay in ptr format for long. I make the call, check the error codes and then throw the data into some STL containers such as strings or maps or vectors or what not. I agree that it is working as designed but I am not so sure it is working as intended. Sort of like the whole issue around 812499 that I fought with MS on a long while back in order to get 812499 implemented. Basically the intent was to allow users to change passwords on every DC. However as designed what happened was that they simply took out the check to see if a DC was the PDC when processing a change password request. This allowed anyone to change passwords on any DC. The down side is that if you had your password reset on the PDC and flagged to change password on next logon the user will go to logon, the password will be wrong at the local DC, it will pass it to the PDC which will say it is fine but the user needs to change the password. That goes back to the local DC. It sends a message back to the client that says, welcome aboard, now change your password. So you go to the change password dialog and the password you just typed to let you logon is denied. This is because the process to verify the old password doesn't chain to the PDC like the logon does, it is still the old NT4 code which assumes that this machine is the PDC and that the password on the local database is authoritative so it refuses the change because the password hash doesn't match. Exactly as per design but not likely the intent. The fix would have been to chain the password check again or have the original chain process force the new password info back to the local DC so it is authoritative. They implemented the latter. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, February 04, 2005 12:11 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] LDAP and Win2003 Question Crap, that was a typo. :) I actually did test this on real data but failed to copy and paste correctly. Doh! Hopefully that little flub didn't confuse Eric. I can see the point being argued either way. I'll be interested to see what the API guys say. My guess is that it is working as designed. I guess we could look at the source and find out... I'm with you on just doing a search to get what you want, but LDAP API? Pointers are so, like, last century. :) Joe K. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Thursday, February 03, 2005 10:48 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] LDAP and Win2003 Question That looks like it fits the overall issue. Except the user specified should be the same in both, i.e. cn=joe or cn=joeschematest My concern is if you derive from user, you should be able to use the getobject with user to open the object. The trace shows the object being returned ok as it is a simple base query with the objectclasses only, then it looks like adsi looks at it and says, HEY, this isn't a user!!! It is a <insert class that has user as a subclass>. Not sure why they have you specify the object type anyway since the rdn value can't be duped within the container. Honestly, I don't care if it works or not except for when people ask me how come it doesn't work. I don't personally use it. On the designed behavior versus bug, it could be both. :o) joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, February 03, 2005 11:12 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] LDAP and Win2003 Question Ok, I'll take a stab. I'm hoping that this scenario is what we are actually talking about. I'm not really sure if we are still helping the original poster either, but here goes... , given a container: cn=users,dc=joe,dc=com a user (standard AD schema) cn=joe,cn=users,dc=joe,dc=com This works: Set cont = GetObject("LDAP://cn=users,dc=joe,dc=com";) Set usr = cont.GetObject("user","CN=joe") wscript.echo usr.description This fails: Set cont = GetObject("LDAP://cn=users,dc=joe,dc=com";) Set usr = cont.GetObject("person","CN=joeschematest") wscript.echo usr.description Questions: Is this the same basic thing Joe mentioned? Is this the designed behavior or a bug? I still think this is the designed behavior. I just want to make sure I haven't missed the whole point here. Eric, please debug at your leisure. :) Joe K. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Thursday, February 03, 2005 9:22 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] LDAP and Win2003 Question If someone has an active repro, I can debug it. Ideally a repro that could be sent to me (using any class inheritance, I'm not picky, I just want the snip of code to run), second best is a repro in a test environment you don't mind me logging in to. Joe, can you repro with something like 'top' if you target a user specifically? In theory it should repro with any class that appears later in the list, if my understanding of the original issue is correct? ~Eric -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, February 03, 2005 9:12 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] LDAP and Win2003 Question Hmm, Is this: Set cont = GetObject("LDAP://cn=users,dc=joe,dc=com";) Set usr = cont.GetObject("user","CN=joeschematest") wscript.echo usr.description really supposed to work for anything but the "leaf" level object class? I would expect you'd get the desired result if you did: Set cont = GetObject("LDAP://cn=users,dc=joe,dc=com";) Set usr = cont.GetObject("joewarefromuser","CN=joeschematest") wscript.echo usr.description I know if you did the equivalent search with the same filter in ADO/.NET DirectorySearcher, you'd get the same result as your search. I honestly don't know what the behavior of IADsContainer::GetObject is supposed to do. It seems reasonable that it might work either way to me. Like I said to Al, I never use that in .NET, I just search for stuff. We could always run it up the flagpole with the DS API guys if anyone really thinks it is a problem. I'm not sure I do. Joe K. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Thursday, February 03, 2005 12:29 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] LDAP and Win2003 Question Oh I have seen this before. Figured it for an ADSI bug. I think at the time I was having a particularly hard time to get MS to admit to bugs so I never submitted it. Anyway, if the issue is the same, the issue I saw was with classes derived from some other well known base class. For instance, say you derive the joewareFromUser class from user. dn:CN=joewarefromuser,CN=Schema,CN=Configuration,DC=joe,DC=com >objectClass: top >objectClass: classSchema >cn: joewarefromuser >distinguishedName: CN=joewarefromuser,CN=Schema,CN=Configuration,DC=joe,DC=com >instanceType: 4 >whenCreated: 20050203181231.0Z >whenChanged: 20050203181230.0Z >uSNCreated: 70914 >subClassOf: user >governsID: 1.2.840.113556.1.8000.1420.0.0.0.0.0.0.0.0.0.0.10001 >rDNAttID: cn >uSNChanged: 70914 >showInAdvancedViewOnly: TRUE >adminDisplayName: joewarefromuser >adminDescription: Test >objectClassCategory: 1 >lDAPDisplayName: joewarefromuser >name: joewarefromuser >objectGUID: {25ABF0AB-2567-4B0D-9C20-259F8FE6172F} >schemaIDGUID: {4AE060FB-6C2C-43D9-83CE-68409C44FFF7} >systemOnly: FALSE >defaultSecurityDescriptor: D:(A;;RPWPCRCCDCLCLOLORCWOWDSDDTDTSW;;;DA)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW ;;;S Y)(A;;RPLCLORC;;;AU) >objectCategory: CN=Class-Schema,CN=Schema,CN=Configuration,DC=joe,DC=com >defaultObjectCategory: CN=Person,CN=Schema,CN=Configuration,DC=joe,DC=com Then you create an object of this class C:\temp>adfind -default -f name=joeschematest AdFind V01.26.00cpp Joe Richards ([EMAIL PROTECTED]) January 2005 Using server: 2k3dc02.joe.com Directory: Windows Server 2003 Base DN: DC=joe,DC=com dn:CN=joeschematest,CN=Users,DC=joe,DC=com >objectClass: top >objectClass: person >objectClass: organizationalPerson >objectClass: user >objectClass: joewarefromuser >cn: joeschematest >distinguishedName: CN=joeschematest,CN=Users,DC=joe,DC=com >instanceType: 4 >whenCreated: 20050203181412.0Z >whenChanged: 20050203181412.0Z >uSNCreated: 70955 >uSNChanged: 70956 >name: joeschematest >objectGUID: {B13B6BFD-00D9-485A-94AB-41FA33768725} >userAccountControl: 546 >badPwdCount: 0 >codePage: 0 >countryCode: 0 >badPasswordTime: 0 >lastLogoff: 0 >lastLogon: 0 >pwdLastSet: 0 >primaryGroupID: 513 >objectSid: S-1-5-21-1862701446-4008382571-2198042679-6107 >accountExpires: 9223372036854775807 >logonCount: 0 >sAMAccountName: joeschematest >sAMAccountType: 805306368 >objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=joe,DC=com 1 Objects returned This object clearly has user in the set of objectclasses. You can further prove it like this C:\temp>adfind -default -f "&(name=joeschematest)(objectclass=user)" -dn AdFind V01.26.00cpp Joe Richards ([EMAIL PROTECTED]) January 2005 Using server: 2k3dc02.joe.com Directory: Windows Server 2003 Base DN: DC=joe,DC=com dn:CN=joeschematest,CN=Users,DC=joe,DC=com 1 Objects returned However if you run this simple script: Set cont = GetObject("LDAP://cn=users,dc=joe,dc=com";) Set usr = cont.GetObject("user","CN=joeschematest") wscript.echo usr.description You will fail with C:\temp\test.vbs(2, 1) Active Directory: An unknown directory object was requested Interesting note on the return order, when looking at the return order of objectclass I have always seen it returned from the DC in hierarchical order of the classes. I.E. Top is always the top, anything derived directly from top is directly under top, something derived further down the chain is under the object type it is derived from, etc. The order being displayed below is interesting, I expect if you did a <cough>network trace</cough> you would see the order correctly and something else is tossing it around on you. However, ~Eric is 1000% correct in you don't depend on order either of what AD returns for objects (unless server side sort control specified) nor the values in a single attribute. I wonder if the ADSI people are simply looking at the last objectclass value? Otherwise, how can they say my object isn't a user? joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al Sent: Thursday, February 03, 2005 10:31 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] LDAP and Win2003 Question Based on the code presented, it looks more like a bug in .NET. That's exactly how the iadscontainer::getobject method is supposed to be used. If there is any order dependency, it's with .NET, but I would not have expected it to care about the order. I'd post this to a vb.net newsgroup and see what comes back. Unless Joe K. is around and sees something off the bat :) Al -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Wednesday, February 02, 2005 11:58 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] LDAP and Win2003 Question We don't guarantee the order that a set of values in a given attribute is returned to the client. That said, if you depend on order, you'll have problems now or in the future. It's not a matter of if, only when. :) You want to make any code you have which relies on order become order insensitive. That should resolve this issue if I understand it correctly. ~Eric ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Elena Mananova (DSL AK) Sent: Wednesday, February 02, 2005 8:17 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] LDAP and Win2003 Question Hi In the current system we used to have business layer (accessing user details in LDAP) and LDAP running on two servers, both of which were Windows 2000. Recently we have migrated business layer server to Windows 2003 machine. Now we have problem. We can't access data of some of the users. The business layer code retrieving user details is written in VB and as follows: Dim oDS As IADs Dim sDN As String dim moUsers As IADsContainer sDN = "LDAP://ldapserver:389/ou=users,o=abc,c=nz"; Set oDS = GetObject("LDAP:") Set moUsers = oDS.OpenDSObject(sDN, "cn=admin,o=abc,c=nz", "Password", 0) Set oDS = Nothing Dim oPList As IADsPropertyList Dim oUser As User Set oPList = moUsers.GetObject("inetOrgPerson", "cn=myUserName") If oPList Is Nothing Then RaiseError Else Set oUser = New User oUser.Initialise oPList Set GetUser = oUser Set oUser = Nothing End If When viewing user details in LDAP (we are using JXplorer tool) there is a minor difference between the way the users' data is displayed for those users that we can retrieve details for and those that we can't. Besides the standard object classes (top, person, organizationalPerson and inetOrgPerson) we also have custom classes. These are abcOrgPerson, abcOrgPerson2 and nxAccountInfo. The users that we can retrieve data for have these classes displayed in the following order: nxAccountInfo abcOrgPerson2 abcOrgPerson inetOrgPerson top person organizationalPerson For the "non-working" users this order is: inetOrgPerson nxAccountInfo abcOrgPerson2 abcOrgPerson top person organizationalPerson I have tried to manually change the class order but it did work. I am not quite sure why the order is different. The line of code that fails is Set oPList = moUsers.GetObject("inetOrgPerson", "cn=myUserName") If I change "inetOrgPerson" parameter to "abcOrgPerson2" then the "non-working" users' details can be retrieved but not the "working" users' details. So it seems that the class order matters for Windows 2003 (LDAP is still sitting on Wind2000 machine however). This same scenario runs without problems from the Win2000 business layer machine. If anyone can share any advice or ideas it will be highly appreciated. I have not had much experience with Active Directories and it's a mystery for me. Thanks List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
