Microsoft Client tool expectatations

[Andrew Bartlett]

How do I determine what LDAP values a Microsoft client tool is expecting?

For example, with the attached patch against current GIT, I cannot make
windows 2008 join Samba4 as a 2-way, forest level trusted domain.   It
seems something is wrong with what we return to
cn=partitions,cn=configuration,....

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.  

In both cases, I just have cryptic error messages.  How can I determine
what these tools are expecting?  

Attached please find network traces for both the 2008 server attempting
to join the trust and a WinXP machine trying to open 'Active Directory
Users and Computers'.

(keytab to follow in private mail)

The join fails with:  'unable to read the functional level of the
forest' Cannot convert to/from the native DS datatype.

The ADUC launch fails with: 'unspecified error'.  (This used to work, before I 'fixed' some schema stuff).

Thanks,

Andrew Bartlett
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.




_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Andrew Bartlett]

On Mon, 2008-09-08 at 22:22 +1000, Andrew Bartlett wrote:
> How do I determine what LDAP values a Microsoft client tool is expecting?
>
> For example, with the attached patch against current GIT...

And here I attache the patch...

Andrew Bartlett
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.

[rootdse-2008-functionality.patch]

---

diff --git a/source/dsdb/common/flags.h b/source/dsdb/common/flags.h
index bdd61a3..dd80817 100644
--- a/source/dsdb/common/flags.h
+++ b/source/dsdb/common/flags.h
@@ -111,6 +111,7 @@
 #define SYSTEM_FLAG_CR_NTDS_DOMAIN 0x00000002
 #define SYSTEM_FLAG_CR_NTDS_NOT_GC_REPLICATED 0x00000004
 #define SYSTEM_FLAG_SCHEMA_BASE_OBJECT 0x00000010
+#define SYSTEM_FLAG_ATTR_IS_RDN        0x00000020
 #define SYSTEM_FLAG_DISALLOW_MOVE_ON_DELETE 0x02000000
 #define SYSTEM_FLAG_DOMAIN_DISALLOW_MOVE 0x04000000
 #define SYSTEM_FLAG_DOMAIN_DISALLOW_RENAME 0x08000000
diff --git a/source/dsdb/samdb/ldb_modules/rootdse.c b/source/dsdb/samdb/ldb_modules/rootdse.c
index ebc90d4..84cf74a 100644
--- a/source/dsdb/samdb/ldb_modules/rootdse.c
+++ b/source/dsdb/samdb/ldb_modules/rootdse.c
@@ -33,6 +33,7 @@ struct private_data {
  char **controls;
  int num_partitions;
  struct ldb_dn **partitions;
+ bool is_gc;
 };
 
 /*
@@ -75,6 +76,13 @@ static int rootdse_add_dynamic(struct ldb_module *module, struct ldb_message *ms
  goto failed;
  }
  }
+
+ /* This attribute is written by the provision, but if we are
+ * not a Global Catalog server, we should not advertise
+ * this */
+ if (!priv->is_gc) {
+ ldb_msg_remove_attr(msg, "isGlobalCatalogReady");
+ }
 
  if (do_attribute(attrs, "supportedControl")) {
  int i;
@@ -389,6 +397,8 @@ static int rootdse_init(struct ldb_module *module)
 
  ldb_set_default_dns(module->ldb);
 
+ data->is_gc = samdb_is_gc(module->ldb);
+
  return ldb_next_init(module);
 }
 
diff --git a/source/setup/provision_rootdse_add.ldif b/source/setup/provision_rootdse_add.ldif
index 14e0d71..529a6b3 100644
--- a/source/setup/provision_rootdse_add.ldif
+++ b/source/setup/provision_rootdse_add.ldif
@@ -15,3 +15,12 @@ forestFunctionality: 0
 domainControllerFunctionality: 2
 isSynchronized: FALSE
 vendorName: Samba Team (http://samba.org)
+#We are AD
+supportedCapabilities: 1.2.840.113556.1.4.800
+#Oids to indicate AD versions we are emulating
+supportedCapabilities: 1.2.840.113556.1.4.1670
+supportedCapabilities: 1.2.840.113556.1.4.1791
+supportedCapabilities: 1.2.840.113556.1.4.1935
+domainFunctionality: 3
+forestFunctionality: 3
+domainControllerFunctionality: 3
diff --git a/source/setup/provision_rootdse_modify.ldif b/source/setup/provision_rootdse_modify.ldif
index 1f95017..9a6427b 100644
--- a/source/setup/provision_rootdse_modify.ldif
+++ b/source/setup/provision_rootdse_modify.ldif
@@ -3,3 +3,5 @@ dn: @ROOTDSE
 changetype: modify
 replace: isSynchronized
 isSynchronized: TRUE
+replace: isGlobalCatalogReady
+isGlobalCatalogReady: TRUE

---

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Stefan (metze) Metzmacher]

Andrew Bartlett schrieb:

> How do I determine what LDAP values a Microsoft client tool is expecting?
>
> For example, with the attached patch against current GIT, I cannot make
> windows 2008 join Samba4 as a 2-way, forest level trusted domain.   It
> seems something is wrong with what we return to
> cn=partitions,cn=configuration,....
>
> 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.  
>
> In both cases, I just have cryptic error messages.  How can I determine
> what these tools are expecting?  
>
> Attached please find network traces for both the 2008 server attempting
> to join the trust and a WinXP machine trying to open 'Active Directory
> Users and Computers'.
>
> (keytab to follow in private mail)

Can't you just use wellknown passwords for your test setup
and publish the keytab?

metze



_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Edgar Olougouna]

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

Regards,

Edgar A. Olougouna
DSC Protocol Team, Microsoft | Email: edgaro@... | Tel: [phone] x 57189




-----Original Message-----
From: Stefan (metze) Metzmacher [mailto:metze@...]
Sent: Monday, September 08, 2008 7:35 AM
To: Andrew Bartlett
Cc: Interoperability Documentation Help; pfif@...; cifs-protocol@...
Subject: Re: [Pfif] Microsoft Client tool expectatations

Andrew Bartlett schrieb:

> How do I determine what LDAP values a Microsoft client tool is expecting?
>
> For example, with the attached patch against current GIT, I cannot make
> windows 2008 join Samba4 as a 2-way, forest level trusted domain.   It
> seems something is wrong with what we return to
> cn=partitions,cn=configuration,....
>
> 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.
>
> In both cases, I just have cryptic error messages.  How can I
> determine what these tools are expecting?
>
> Attached please find network traces for both the 2008 server
> attempting to join the trust and a WinXP machine trying to open
> 'Active Directory Users and Computers'.
>
> (keytab to follow in private mail)

Can't you just use wellknown passwords for your test setup and publish the keytab?

metze


_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Richard Guthrie-3]

Stefan,

Can you confirm you are referring to the process of setting msds-SupportedEncryptionTypes during netlogon?  I just want to be sure I understand the question.

Richard Guthrie
Open Protocols Support Team
Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM
Tel: [phone]
E-mail: rguthrie@...
We're hiring http://members.microsoft.com/careers/search/details.aspx?JobID=A976CE32-B0B9-41E3-AF57-05A82B88383E&start=1&interval=10&SortCol=DatePosted

-----Original Message-----
From: Stefan (metze) Metzmacher [mailto:metze@...]
Sent: Monday, September 08, 2008 7:35 AM
To: Andrew Bartlett
Cc: Interoperability Documentation Help; pfif@...; cifs-protocol@...
Subject: Re: [Pfif] Microsoft Client tool expectatations

Andrew Bartlett schrieb:

> How do I determine what LDAP values a Microsoft client tool is expecting?
>
> For example, with the attached patch against current GIT, I cannot make
> windows 2008 join Samba4 as a 2-way, forest level trusted domain.   It
> seems something is wrong with what we return to
> cn=partitions,cn=configuration,....
>
> 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.
>
> In both cases, I just have cryptic error messages.  How can I
> determine what these tools are expecting?
>
> Attached please find network traces for both the 2008 server
> attempting to join the trust and a WinXP machine trying to open
> 'Active Directory Users and Computers'.
>
> (keytab to follow in private mail)

Can't you just use wellknown passwords for your test setup and publish the keytab?

metze


_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Andrew Bartlett]

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.  

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.


_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Andrew Bartlett]

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.


_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[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@...
Tel:  [phone] x 57027
-----------------------------------------------------------




-----Original Message-----
From: cifs-protocol-bounces+hongweis=microsoft.com@... [mailto:cifs-protocol-bounces+hongweis=microsoft.com@...] On Behalf Of Andrew Bartlett
Sent: Tuesday, September 09, 2008 3:39 AM
To: Edgar Olougouna
Cc: Interoperability Documentation Help; pfif@...; cifs-protocol@...
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.
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Andrew Bartlett]

On Mon, 2008-09-22 at 14:31 -0700, Hongwei Sun wrote:
> Andrew,
>
>    Does this  mean that you cannot duplicate the issue any more ?  

Correct.  However, my original reporter still reproduces the issue.

>  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 ?

That shows the original failure - but as this could be any part of the
whole schema that is incorrect, it is hard to tell what is wrong.

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.com



_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Hongwei Sun]

Andrew,

>> Andrew,
>>
>>    Does this  mean that you cannot duplicate the issue any more ?

>Correct.  However, my original reporter still reproduces the issue.

Could you explain a little bit more about this ?   If you put everything back to original condition, you can still see the problem with XP ADCU.  After some changes made to schema, the problem doesn't occur any more.  Is my understanding right ?

Should I still concentrate on the original condition under which we have a capture ?

Is it possible for you to send us a network trace for the current successful condition so we can compare ?

Thanks

----------------------------------------------------------
Hongwei  Sun - Sr. Support Escalation Engineer
DSC Protocol  Team, Microsoft
hongweis@...
Tel:  [phone] x 57027
-----------------------------------------------------------





-----Original Message-----
From: Andrew Bartlett [mailto:abartlet@...]
Sent: Monday, September 22, 2008 5:22 PM
To: Hongwei Sun
Cc: pfif@...; cifs-protocol@...
Subject: RE: [cifs-protocol] RE: [Pfif] Microsoft Client tool expectatations

On Mon, 2008-09-22 at 14:31 -0700, Hongwei Sun wrote:
> Andrew,
>
>    Does this  mean that you cannot duplicate the issue any more ?

Correct.  However, my original reporter still reproduces the issue.

>  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 ?

That shows the original failure - but as this could be any part of the whole schema that is incorrect, it is hard to tell what is wrong.

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.com

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Andrew Bartlett]

On Tue, 2008-09-23 at 12:36 -0700, Hongwei Sun wrote:

> Andrew,
>
> >> Andrew,
> >>
> >>    Does this  mean that you cannot duplicate the issue any more ?
>
> >Correct.  However, my original reporter still reproduces the issue.
>
> Could you explain a little bit more about this ?   If you put
> everything back to original condition, you can still see the problem
> with XP ADCU.

For me, I now have success all the time.  Presumably the client cached
something, or is simply non-deterministic.

>  After some changes made to schema, the problem doesn't occur any
> more.  Is my understanding right ?

I wish :-).  According to my reporter, he still gets failures, in old
versions and new.  I've CC'ed him so he can clarify the situation.

> Should I still concentrate on the original condition under which we have a capture ?
>
> Is it possible for you to send us a network trace for the current successful condition so we can compare ?

I think the trace is the same (as I get success regardless of new or old
code), but I'll see what I can do.

The bug tracking this (with a few distractions) is:

https://bugzilla.samba.org/show_bug.cgi?id=5713

Andrew Bartlett

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.com



_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Hongwei Sun]

Andrew,

  The product team is analyzing the network trace for trusted domain join problem.   We have several questions regarding the test.

(1) What was the exact error message and when did it show ?   Did you see  message (" Unable to read the functional level of the specified forest." & "The directory datatype cannot be converted to/from a native DS datatype") displayed from "Active Directory Trust and Domain" ?

(2) Which frame(s) in the trace are related to the error ?   at the end ?
   We can see error STATUS_OBJECT_NAME_NOT_FOUND returned LsarQueryTrustedDomainInfoByName() in frame 111 & 113,Is that a downstream effect of not reading the right data from AD?

(3) What is your Windows Server 2008 domain name ?  Is it AD2008 ?   Do you actually have a Netbios name different then the DNS name?
   Is 2008.naomi.abartlet.net the name of Samba4 domain ?


Thanks

----------------------------------------------------------
Hongwei  Sun - Sr. Support Escalation Engineer
DSC Protocol  Team, Microsoft
hongweis@...
Tel:  [phone] x 57027
-----------------------------------------------------------




-----Original Message-----
From: Andrew Bartlett [mailto:abartlet@...]
Sent: Monday, September 08, 2008 7:22 AM
To: Interoperability Documentation Help
Cc: pfif@...; cifs-protocol@...
Subject: Microsoft Client tool expectatations

How do I determine what LDAP values a Microsoft client tool is expecting?

For example, with the attached patch against current GIT, I cannot make
windows 2008 join Samba4 as a 2-way, forest level trusted domain.   It
seems something is wrong with what we return to cn=partitions,cn=configuration,....

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.

In both cases, I just have cryptic error messages.  How can I determine what these tools are expecting?

Attached please find network traces for both the 2008 server attempting to join the trust and a WinXP machine trying to open 'Active Directory Users and Computers'.

(keytab to follow in private mail)

The join fails with:  'unable to read the functional level of the forest' Cannot convert to/from the native DS datatype.

The ADUC launch fails with: 'unspecified error'.  (This used to work, before I 'fixed' some schema stuff).

Thanks,

Andrew Bartlett
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Andrew Bartlett]

On Tue, 2008-09-23 at 14:33 -0700, Hongwei Sun wrote:

> Andrew,
>
>   The product team is analyzing the network trace for trusted domain
> join problem.   We have several questions regarding the test.
>
> (1) What was the exact error message and when did it show ?   Did you
> see  message (" Unable to read the functional level of the specified
> forest." & "The directory datatype cannot be converted to/from a
> native DS datatype") displayed from "Active Directory Trust and
> Domain" ?

We got both - the first we we don't set magic values in the rootdse to
pretend we are windows 2008, the second when we fake that much up.

> (2) Which frame(s) in the trace are related to the error ?   at the
> end ?

Presumably.  

>    We can see error STATUS_OBJECT_NAME_NOT_FOUND returned
> LsarQueryTrustedDomainInfoByName() in frame 111 & 113,Is that a
> downstream effect of not reading the right data from AD?

No, the trusted domain has not yet been found, so this is correct.  Your
tool is checking to see if it exists, before trying to create it.

> (3) What is your Windows Server 2008 domain name ?  Is it AD2008 ?
> Do you actually have a Netbios name different then the DNS name?
>    Is 2008.naomi.abartlet.net the name of Samba4 domain ?

They are the names of the 2008 domain.  s4.naomi.abartlet.net is the
Samba4 domain.

Andrew Bartlett

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.com



_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Andrew Bartlett]

On Tue, 2008-09-23 at 20:56 -0700, Andrew Bartlett wrote:

> On Tue, 2008-09-23 at 14:33 -0700, Hongwei Sun wrote:
> > Andrew,
> >
> >   The product team is analyzing the network trace for trusted domain
> > join problem.   We have several questions regarding the test.
> >
> > (1) What was the exact error message and when did it show ?   Did you
> > see  message (" Unable to read the functional level of the specified
> > forest." & "The directory datatype cannot be converted to/from a
> > native DS datatype") displayed from "Active Directory Trust and
> > Domain" ?
>
> We got both - the first we we don't set magic values in the rootdse to
> pretend we are windows 2008, the second when we fake that much up.

Patch (against GIT eba7f1032d79fe5dcbc1902e3af1087399f67a5a) for magic
values attached.

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.com


[look-like-2008.patch]

---

diff --git a/source4/setup/provision_rootdse_add.ldif b/source4/setup/provision_rootdse_add.ldif
index 14e0d71..dd1ab86 100644
--- a/source4/setup/provision_rootdse_add.ldif
+++ b/source4/setup/provision_rootdse_add.ldif
@@ -12,6 +12,12 @@ ldapServiceName: ${DNSDOMAIN}:${NETBIOSNAME}$@${REALM}
 serverName: ${SERVERDN}
 domainFunctionality: 0
 forestFunctionality: 0
-domainControllerFunctionality: 2
+domainControllerFunctionality: 3
 isSynchronized: FALSE
 vendorName: Samba Team (http://samba.org)
+supportedCapabilities: 1.2.840.113556.1.4.800
+supportedCapabilities: 1.2.840.113556.1.4.1670
+supportedCapabilities: 1.2.840.113556.1.4.1791
+supportedCapabilities: 1.2.840.113556.1.4.1935
+isSynchronized: TRUE
+isGlobalCatalogReady: TRUE

---

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Hongwei Sun]

Andrew,

  Richard and the product team informed me that it has been found during IOLab event that the  ditContentRules in subschema element was the root cause of the domain trust problem.  They think that it might also address ADCU problem too.   I would just like to confirm with you whether this is true and I can close the case.  If not,  please let me know the current status on this issue after the IOLab event and how you like us to proceed.   If the problem still exists, you  could send us proper data (network trace and/or logs) for further investigation.


Thanks

----------------------------------------------------------
Hongwei  Sun - Sr. Support Escalation Engineer
DSC Protocol  Team, Microsoft
hongweis@...
Tel:  [phone] x 57027
-----------------------------------------------------------



-----Original Message-----
From: Andrew Bartlett [mailto:abartlet@...]
Sent: Tuesday, September 23, 2008 3:19 PM
To: Hongwei Sun
Cc: pfif@...; cifs-protocol@...; Matthias Dieter Wallnöfer
Subject: RE: [cifs-protocol] RE: [Pfif] Microsoft Client tool expectatations

On Tue, 2008-09-23 at 12:36 -0700, Hongwei Sun wrote:

> Andrew,
>
> >> Andrew,
> >>
> >>    Does this  mean that you cannot duplicate the issue any more ?
>
> >Correct.  However, my original reporter still reproduces the issue.
>
> Could you explain a little bit more about this ?   If you put
> everything back to original condition, you can still see the problem
> with XP ADCU.

For me, I now have success all the time.  Presumably the client cached something, or is simply non-deterministic.

>  After some changes made to schema, the problem doesn't occur any
> more.  Is my understanding right ?

I wish :-).  According to my reporter, he still gets failures, in old versions and new.  I've CC'ed him so he can clarify the situation.

> Should I still concentrate on the original condition under which we have a capture ?
>
> Is it possible for you to send us a network trace for the current successful condition so we can compare ?

I think the trace is the same (as I get success regardless of new or old code), but I'll see what I can do.

The bug tracking this (with a few distractions) is:

https://bugzilla.samba.org/show_bug.cgi?id=5713

Andrew Bartlett

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.com

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol