[cifs-protocol] RE: [Pfif] Microsoft Client tool expectatations

[Hongwei Sun]

Andrew,

   Does this  mean that you cannot duplicate the issue any more ?   Can you give us some clarification at your earliest convenience ?   The only information I have been using for my investigation  is winxp-aduc-fail.cap attached in your original e-mail ?  Is it still relevant ?

Thanks

----------------------------------------------------------
Hongwei  Sun - Sr. Support Escalation Engineer
DSC Protocol  Team, Microsoft
hongweis at microsoft.com
Tel:  469-7757027 x 57027
-----------------------------------------------------------




-----Original Message-----
From: cifs-protocol-bounces+hongweis=microsoft.com at cifs.org [mailto:cifs-protocol-bounces+hongweis=microsoft.com at cifs.org] On Behalf Of Andrew Bartlett
Sent: Tuesday, September 09, 2008 3:39 AM
To: Edgar Olougouna
Cc: Interoperability Documentation Help; pfif at tridgell.net; cifs-protocol at samba.org
Subject: [cifs-protocol] RE: [Pfif] Microsoft Client tool expectatations

On Tue, 2008-09-09 at 16:29 +1000, Andrew Bartlett wrote:
> On Mon, 2008-09-08 at 09:24 -0700, Edgar Olougouna wrote:
> > Good morning Andrew,
> >
> > Thank you for your request concerning the Windows Client tool
> > expectations. I have created a case for this (see info below); one
> > of my colleagues will be in touch with you.
> >
> > SRX080908600475 - ProtoDoc 99999: [MS-ADTS]: Microsoft Client tool
> > expectations
>
> This should probably be split into two cases.
>
> > > Similarly, against our current GIT tree, the Win2k3 admin pack on
> > > WinXP won't launch 'Active Directory Users and Computers' against
> > > Samba4.  The error seems to be in response to our return value for
> > > the cn=aggregate schema.
>
> While we still have the problem of 'how do I get past cryptic client
> messages', the particular case here was easily solved by a comparative
> trace with windows.

It turns out that this did not solve the issue - I now can't reproduce the issue with or without this fix.  Further clarification is required.

> The issue is that we would include an entry:
>     objectClasses: ( 2.5.6.0 NAME 'top' SUP top ABSTRACT..
>
> The MMC Active Directory Users and Computers snap in presumably
> objected to the 'loop' this would present. The fixed entry is:
>
>     objectClasses: ( 2.5.6.0 NAME 'top' ABSTRACT...
>
> Now, the new resolution I would like is for this someone to find where
> this should be documented in MS-ATDS and to call out the semantics
> here very carefully (that top must not be SUP 'top', despite being so
> indicated in the full schema).
>
> Also, an indication of the semantics of modifyTimeStamp on this entry
> would be worthwhile.  I generate these attributes on the fly, so this
> value will not normally change (even with schema updates) - but ADUC
> very specifically reads this value.  Does it implement a cache of some
> kind, and therefore how must this change after schema updates?
>
> Thanks,
>
> Andrew Bartlett
>
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.