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: [email protected]
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: [email protected]
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: [email protected]
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/
