Coolio. Glad to help out. Couple of items I didn't seem to
write completely enough on after I reread my response...
> So no attribute will be listed
on an object when you query the object unless it is populated except
> in the
case of looking at allowedAttributes which should show all attributes available
and allowedAttributedEffective
> which
should be attributes you have write access to.
I am referring to LDAP query here. ADSIEDIT will show you
attributes based on what it thinks the schema of the object is.
> The first
issue is with statically bound aux classes. When a class is statically bound,
the class will not show
> up in the
objectclass attribute of any given object that has that aux class as part of
it.
However when dynamically binding, the aux class will show
up in the list of objectclasses. No other way to really handle it at the object
level unless MSFT added a new attribute called auxObjectClass which might have
been a good idea as it could have been used for static and dynamic
binding.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Baudino
Sent: Tuesday, July 11, 2006 2:13 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Question about dynamically binding aux classes
Joe,
Thank you for the detailed reply. I now understand.
Thanks,
Mike
On 7/11/06, joe
<[EMAIL PROTECTED]>
wrote:
Your problem is that your belief is incorrect[1]. :o)First off, LDP and ADSIEDIT look at the world in different ways. LDP is LDAP based, ADSIEDIT is...... well ADSI based which then thunks down to LDAP eventually depending on the call and the provider being used. Things will be and are different between them based on the fact that they use different APIs.So no attribute will be listed on an object when you query the object unless it is populated except in the case of looking at allowedAttributes which should show all attributes available and allowedAttributedEffective which should be attributes you have write access to.So now the dirty secret concerning aux classes. There are "issues" whether you statically bind them or dynamically bind them, completely separate "issues". I keep saying "issues" because I don't really think they are issues but they sure annoy ADSI coders...The first issue is with statically bound aux classes. When a class is statically bound, the class will not show up in the objectclass attribute of any given object that has that aux class as part of it. The idea is, if you need to know that that class is involved, you get to skim through the schema and figure it out. This means you can't do a query like objectclass=myauxclass to find objects that have myauxclass in them. This makes perfect sense to me since it isn't part of the hierarchy, it is just adding some attribs (maybe, if the attribs it includes are already in a given object definition the aux class does nothing).The second issue is with dynamically bound aux classes and specifically ADSI. ADSI reads the schema and keeps an idea of what attributes a given object CAN have. The problem here is that this is implemented in ADSI at the class level... not at the object level. So if you dynamically add an auxclass to a specific object, the list that ADSI maintains of possible attributes will not be complete, it will only be the attributes as specified by the schema and WILL NOT include the aux class attributes added after the dynamic binding of the aux class. So the list that ADSIEDIT shows is the default list of attributes for ANY instance of that class, not the specific instance you are looking at. This can cause other issues in ADSI as well if you depend on the listing of attributes it provides for a given class.A properly written fully functional object browser would query the object for its allowedAttributes attribute and then retrieve those attributes and display them. Essentially two LDAP calls to display any given object.joe[1] After dynamically binding and before populating with a value, I believe that I should be able to see that the attribute from the aux class when looking at the user object in adsiedit and/or ldp
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Mike Baudino
Sent: Tuesday, July 11, 2006 11:46 AM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Question about dynamically binding aux classes
All,We have created an aux class with an optional attribute. We wish to dynamically bind this aux class to a small subset of our user objects.I have a _vbscript_, courtesy of Robbie Allen and the Active Directory Cookbook, that will dynamically bind the aux class to an object. I've also set up an ldf to do this. I've also set up an ldf to populate the attribute associated with the aux class.Here's my issue. After dynamically binding and before populating with a value, I believe that I should be able to see that the attribute from the aux class when looking at the user object in adsiedit and/or ldp -- but I don't. After populating the attribute with a value, I can then see the attribute and the value in ldp but still not in adsiedit. I can also pull the value from the attribute via a _vbscript_.My concern is not being able to see this in adsiedit at all and not in ldp prior to populating the attribute.Any recommendations? I do not have "Allow this attribute to be shown in advanced view" selected on the attribute. This is AD with Server 2003 in 2003 forest and domain mode. Not SP1 nor R2.Thanks,
Mike
