Thanks ~Eric. Seriously, I understand you are busy and sincerely appreciate
the effort you put into the list here and the other lists and the
newsgroups. Anyway, now I will beat on your for a bit, because you like it.
:o)


1. No perms to an attribute. I would agree, this would be self evident I
think.

2. Ditto for GC attribs in a partial set.

3. Well yes and no on constructed. Some will throw an ops error on anything
but a base query and others won't and will return just fine [1]. It depends
on some specific hard coding. I guess I understand not returning them by
default as they may be more expensive than normal and I even agree with not
allowing queries based on them. Possibly you are simplifying it but you are
enforcing the myth that because something is constructed, it can only be
returned in a BASE query. See below for more info. 

4. Understood on the operational attribs as well. It would actually be nice
to see a single documented list of the operational attribs and what they do
and how they are used. The only ones that seem to be seriously doc'ed are
the *visible* rootdse ones and the ones with some documentation are the FSMO
moving ones. None of these are in the schema so it isn't like we can dump
the list ourselves.

5. ANR I consider to be a type of operational attribute. It just keys the QP
(I think) to expand that into a larger query. Not sure I really follow why
MS stuck it in the schema as a constructed attribute. Possibly they had to
because it is searchable. 

6. dn is special case. I don't consider it an attribute. It isn't in the
attribute set returned, it requires a separate special LDAP call
(ldap_get_dn) to retrieve from the result packet. 


Sakari pointed out in a separate offlist email that nTSecurityDescriptor is
handled specially. This is true, if you aren't an admin (or more correctly I
think, someone with permissions to access security info) you have to enable
certain options via LDAP_SERVER_SD_FLAGS_OID coupled with a BER sequence
including *_SECURITY_INFORMATION flags [2] to see parts of the attribute
that you have access to. The overhead involved probably makes it a candidate
to not be displayed for every object unless specifically called for. 

For some more attributes, look at say the CN=Aggregate object in the schema,
huge differences in what 2K and K3 return by default. From what I have seen,
that was a silent change. Haven't seen any docs on it out of MS but man did
it blow up some apps. I had several folks that I responded to posts to or
who emailed me directly asking about it. These are apparently constructed
but 2K returned them in a default query of the schema and you can get them
in a non-Base query. 

Getting back to the original... whenChanged and modifyTimeStamp. whenChanged
is a normal attribute, modifyTimeStamp is constructed. Yet modifyTimeStamp
can be returned with an explicit request on a subtree search.... It seems
from external observation there are different levels of "constructed"? Not
many can go look at the source code to prove this or disprove this and I
don't think I have ever seen any documentation to that effect. Simply adding
a constructed attribute to the schema for each attribute definition
indicating what can and can't be gathered in a non-base search or document
it in MSDN under the attribute listing in the library. Some other attributes
I have checked manually that are constructed attribs that can be retrieved
on non-BASE queries are are canonicalName, structuralObjectClass,
createTimeStamp, sdRightsEffective, msDS-Auxiliary-Classes, etc... Basically
anything that doesn't return an operations error when you submit the query
say like the tokenGroups or primaryGroupToken attribute. 

Basically we seem to have a bunch of hard coded functionality with no
documentation on what you can and can't depend on. For instance, say I write
code to query the aggregate object. Bam MS changes it between 2K and K3 to
not return all of the same attributes. How am I supposed to know that except
by running smack into it? I would assume since the attribute was returned
under 2K, that MS wouldn't just go and hide it under K3. Is there docs
saying, don't depend on any attributes returned in a default return set and
that you should specifically always declare the exact attributes you want
returned? That adds considerable overhead especially as the schema is
extensible and you may want to return every attribute the object has.

Or say I use modifyTimeStamp in a subtree query and I specifically ask for
it. But then later MS decided, oh wait, that should only be returned in a
BASE query... I am not sure you guys clearly understand the danger to third
parties who develop on your platform with some of the documentation
available as to what is happening. If you looked at the schema,
createTimeStamp and tokenGroups are identical for systemFlags. 


   joe 


[1] I think I hear the heads of various LDAP programmers exploding at this
statement or even thinking in their head, this guy is crackers.

[2] Generally I think anyone should be able to get everything but the SACL
Info (SACL_SECURITY_INFORMATION        (0x00000008L))


 

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman
Sent: Wednesday, December 29, 2004 12:30 AM
To: [email protected]
Subject: RE: [ActiveDir] LDP does not return modifyTimeStamp attribute...

So this is a tough question to answer, by virtue of a lot of caveats.
Clearly things you don't have perms to don't get returned (for whatever
reason you don't have access). Attr's with
isMemberOfPartialAttributeSet==FALSE don't get returned on connections to
the GC port. Constructed attributes are only returned when explicitly
requested in a base search. Operational attrs are typically only set, not
returned. unicodePwd is an exception, and can't be read (thus always appears
null even though it isn't). userPassword is an exception like unicodePwd,
depending upon dsHeuristics. ANR is an exception, and is used in searches
but not returned even in base searches (despite being constructed, but
perhaps one could argue it is just a special case of null-ness). Then the
attribute 'dn' itself isn't defined in the schema to start with (and it
might be considered constructed if it was, but is still returned on any type
of search). Attr's with only null don't get returned at all of course.

I am hesitant to outline a high level algorithm here without spending some
hours research this further, as I fear there is a corner case I miss. Those
are just the ones I thought of off of the top of my head +
~1 hr of looking at this.

To answer your question more precisely:
> > How about the overall more general question, is there a way to 
> > ascertain what would and wouldn't be displayed? For instance, is 
> > there something "query-able" that tells me ntsecuritydescriptor 
> > would or wouldn't be displayed.

One could probably craft a query to get _most_ of the attributes, and it
would contain a few extras. It would be those that are not constructed or
operational, assuming you have access to them. But there are exceptions
you'd need to take in to acct that the query would not address, like the few
I thought of above.

~Eric



-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman
Sent: Tuesday, December 28, 2004 9:23 PM
To: [email protected]
Subject: RE: [ActiveDir] LDP does not return modifyTimeStamp attribute...

Yes this is on my short to-look at again list, ETA of tonight, assuming the
4 items above it for the evening get done. I hope to reply back around 1am
CST, for those that will still be awake, pending on-time completion of other
tasks.

Everyone is probably glad to know I had a good dinner. Interesting burger I
have not had (it had pinaple on it...it was good), cooked medium. I am now
back at work, let the good times roll.

BTW, Brett, you also have 2 bugs for ADAM R2. Don't forget.

~Eric


-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Tuesday, December 28, 2004 9:02 PM
To: [email protected]
Subject: RE: [ActiveDir] LDP does not return modifyTimeStamp attribute...

LOL. Actually I posted a response on their website about an article Derek
Melber wrote that had an issue. Some people were asking me about it as it
contradicted things I had mentioned previously so I made comments about it.
Later I got an email asking if they could print my response, I was like,
sure, knock yourself out.

On the point of Brett's opinion... I agree. Most of the fun with Brett's
responses is visualizing his hair flaring in 140 different directions with a
red face as he pounds on the keyboard telling people to zark off because
they asked exactly the wrong question at exactly the wrong time or possibly
asking a slightly wrong question at any time. I don't believe him though
when he talks about not recalling how to check replication, he was far to
proud of that "brilliant" code in repadmin he was telling us about last
April.

   joe 



-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan
Sent: Tuesday, December 28, 2004 9:50 PM
To: [email protected]
Subject: RE: [ActiveDir] LDP does not return modifyTimeStamp attribute...

Dean, joe - you were right.  Brett did, and does - have an opinion.  His
opinion, as it seems from this is, that you should bloody well go stuff
yourself elsewhere, and do the job yourself. 

However, I *might* have read it out of context...

Regardless, Brett - it's always great to hear from you....if it was of value
or not.  ;-)

On a completely different note, I noticed that there is some sorry ass out
there that is using joe's e-mail address for letters to Redmond magazine.  I
know that this was *NOT* joe as he wouldn't be caught dead writing letters
to a magazine.

Just letting you know, joe, that there is some poser out there using your
(well - I use this rather loosely) good name.



-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley
Sent: Tuesday, December 28, 2004 7:29 PM
To: [email protected]
Subject: RE: [ActiveDir] LDP does not return modifyTimeStamp attribute...

I have bugs assigned to me across effectively 5 products (E2k3 SP1, MSN
Desktop Search, Exch 12, WinXP, Longhorn) ... I'll get right on trying to
figure that out for you guys who are MVPs with ?source access?

Technically, my job responsibilities don't entail caring about obscure AD
schema choices anymore, sorry Dean.  In about 6 months I probably won't even
remember how to check replication is progressing? or even what "an object"
is?  I only have to care if your DB is corrupt.

>From The Love,
BrettSh


On Tue, 28 Dec 2004, joe wrote:

> LOL. I think I have it already. I rather see him think it out and type

> the response. It was part in jest, I know he is pretty busy right now.
> He IM's me every few hours to tell me how busy he is and to tell me 
> how much he hates that I have my IM set to always online. :o)
> 
> As Dean mentioned though, I wouldn't mind hearing your (Brett's) two 
> cents on this as well.
> 
>   joe
> 
>  
> 
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells
> Sent: Tuesday, December 28, 2004 7:52 PM
> To: Send - AD mailing list
> Subject: RE: [ActiveDir] LDP does not return modifyTimeStamp
attribute...
> 
> I'm guessing he would (be mad)... and, more to the point, why don't 
> you chime in and toss out your 2 cents worth ... you know you have 
> _an_ opinion on it ... ;-)
> 
> --
> Dean Wells
> MSEtechnology
> * Email: [EMAIL PROTECTED]
> http://msetechnology.com
> 
> 
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley
> Sent: Tuesday, December 28, 2004 7:47 PM
> To: [email protected]
> Cc: 'Eric Fleischman'
> Subject: RE: [ActiveDir] LDP does not return modifyTimeStamp
attribute...
> 
> Listed on my cell phone is "Online Help", it is a direct line to Eric,

> it will even find Eric at dinner (which is his current wherabouts).
> 
> Do you want his cell phone?  :>
> 
> Cheers,
> -Brett
> 
> P.S. - Debating if he'd be mad at me ...
> 
> 
> On Tue, 28 Dec 2004, joe wrote:
> 
> > ping ~Eric
> >  
> > 
> > Pinging ~Eric.texas.cpr.microsoft.com [xx.xx.xx.xx] with 32 bytes of
data:
> > 
> >  
> > 
> > Request timed out.
> > 
> > Request timed out.
> > 
> >  
> > 
> > 
> >   _____
> > 
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of joe
> > Sent: Tuesday, November 16, 2004 12:42 PM
> > To: [email protected]
> > Subject: RE: [ActiveDir] LDP does not return modifyTimeStamp
attribute...
> > 
> > 
> > Well that's why I did the ping. :o)
> > 
> >   _____
> > 
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Eric 
> > Fleischman
> > Sent: Monday, November 15, 2004 3:37 PM
> > To: joe; [email protected]
> > Subject: RE: [ActiveDir] LDP does not return modifyTimeStamp
attribute...
> > 
> > 
> > 
> > 3 words: blah, blah and blah
> > 
> >  
> > 
> > :)
> > 
> >  
> > 
> > I'll try and revisit this sometime this week. Sorry, I lost track of
it.
> > 
> >  
> > 
> > ~Eric
> > 
> >  
> > 
> >  
> > 
> >  
> > 
> >   _____
> > 
> > From: joe [mailto:[EMAIL PROTECTED]
> > Sent: Monday, November 15, 2004 11:16 AM
> > To: [email protected]
> > Cc: Eric Fleischman
> > Subject: RE: [ActiveDir] LDP does not return modifyTimeStamp
attribute...
> > 
> >  
> > 
> > ping ~Eric
> > 
> >  
> > 
> > Pinging ~Eric.texas.cpr.microsoft.com [xx.xx.xx.xx] with 32 bytes of
data:
> > 
> >  
> > 
> > Request timed out.
> > 
> > Request timed out.
> > 
> >  
> > 
> >  
> > 
> >  
> > 
> > :o)
> > 
> >  
> > 
> >   _____
> > 
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Eric 
> > Fleischman
> > Sent: Tuesday, November 09, 2004 7:44 PM
> > To: [email protected]
> > Subject: RE: [ActiveDir] LDP does not return modifyTimeStamp
attribute...
> > 
> > Let me digest a bit and report back. The answer is probably yes, I 
> > just need to think about it.
> > 
> >  
> > 
> > <aside>
> > 
> > Have you noticed that every ldp snip I do is from a different
domain? 
> > Yes, I have that many forests in virtual machines. I just noticed 
> > that I'm not sure if I've used the same one twice on this list...
> > 
> >  
> > 
> >  
> > 
> >   _____
> > 
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of listmail
> > Sent: Tuesday, November 09, 2004 5:30 PM
> > To: [email protected]; [email protected]
> > Subject: RE: [ActiveDir] LDP does not return modifyTimeStamp
attribute...
> > 
> >  
> > 
> > Understood on the constructed. Though it makes you wonder why that 
> > one is and whenChanged isn't. :o)
> > 
> >  
> > 
> > How about the overall more general question, is there a way to 
> > ascertain what would and wouldn't be displayed? For instance, is 
> > there something "query-able" that tells me ntsecuritydescriptor 
> > would or wouldn't be displayed.
> > 
> >  
> > 
> >   joe
> > 
> >  
> > 
> >   _____
> > 
> > From: [EMAIL PROTECTED] on behalf of Eric 
> > Fleischman
> > Sent: Tue 11/9/2004 6:19 PM
> > To: [email protected]
> > Subject: RE: [ActiveDir] LDP does not return modifyTimeStamp
attribute...
> > 
> > In this case:
> > 
> >  
> > 
> > >> Dn:
> > CN=Modify-Time-Stamp,CN=Schema,CN=Configuration,DC=corp,DC=microsoft
> > ,D
> > C=com
> > 
> >             1> lDAPDisplayName: modifyTimeStamp;
> > 
> > 1>     systemFlags: 0x8000014 = ( FLAG_ATTR_IS_CONSTRUCTED |
> > FLAG_SCHEMA_BASE_OBJECT | FLAG_DOMAIN_DISALLOW_RENAME );
> > 
> >  
> > 
> > Constructed attributes are only returned 1) If requested AND 2) if 
> > requested in a base search against the object
> > 
> >  
> > 
> > ~Eric
> > 
> >  
> > 
> >  
> > 
> >  
> > 
> >   _____
> > 
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of listmail
> > Sent: Tuesday, November 09, 2004 5:16 PM
> > To: [email protected]; [email protected]
> > Subject: RE: [ActiveDir] LDP does not return modifyTimeStamp
attribute...
> > 
> >  
> > 
> > Nope. Not every attribute is returned. I don't know personally what 
> > the logic is that specifies what is returned and what isn't. I would

> > like to think it is something you can query out of the schema but I 
> > have never seen anything to substantiate that thought.
> > 
> >  
> > 
> > It is easy to see it in action though, query the schema on 2K and do

> > the same on K3. You will certain attribs on certain objects returned

> > in 2K but not in K3, you have to ask for them meaning that MS backed

> > out the default return set. Why I don't know but helped someone with

> > an App that blew up because of it. I don't recall exactly what the 
> > attribute was though, I purposely forgot it so I could have enough 
> > room in my head to remember the thing about ntsecuritydescriptors...
> > 
> >  
> > 
> > What about ntsecuritydescriptors you ask? ntsecuritydescriptor 
> > should be on every object but when have you seen a query where you 
> > didn't specifically specify you needed it that it did get returned?
> > Answer, you have to ask for it.
> > 
> >  
> > 
> > With adfind you would do something like
> > 
> >  
> > 
> > adfind -b <somebase> -f <somefilter> * ntsecuritydescriptor
> > 
> >  
> > 
> > That will return what I call the * set (star set) and also the 
> > ntsecuritydescriptor attribute.
> > 
> >  
> > 
> > I started to talk to ~Eric about this once before but I don't think 
> > we ever got to the part of the discussion concerning how it was 
> > determined what is returned and what isn't.
> > 
> >  
> > 
> >   joe
> > 
> >  
> > 
> >   _____
> > 
> > From: [EMAIL PROTECTED] on behalf of AD
> > Sent: Tue 11/9/2004 6:00 PM
> > To: [email protected]
> > Subject: RE: [ActiveDir] LDP does not return modifyTimeStamp
attribute...
> > 
> > Hmm, I am a little bit confused joe. I did not ask for 
> > msExchAlObjectVersion but it returns it anyways. Isn't LDP suppose 
> > to return every attribute that is set for a an object?
> > 
> >  
> > 
> > Thanks
> > 
> >  
> > 
> >   _____
> > 
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of listmail
> > Sent: Tuesday, November 09, 2004 4:31 PM
> > To: [email protected]; [email protected]
> > Subject: RE: [ActiveDir] LDP does not return modifyTimeStamp
attribute...
> > 
> > Because you didn't request it. That one needs to be specifically 
> > requested, you can instead use whenChanged which is returned in the
> default * set.
> > 
> >   
> > 
> >   joe
> > 
> >  
> > 
> >   _____
> > 
> > From: [EMAIL PROTECTED] on behalf of AD
> > Sent: Tue 11/9/2004 4:24 PM
> > To: [email protected]
> > Subject: [ActiveDir] LDP does not return modifyTimeStamp
attribute...
> > 
> >   
> > 
> > Does anyone know why LDP does not return the modifyTimeStamp
attribute? 
> > 
> > 

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/

Reply via email to