Bug 12204 - Samba fails to replicate schema 69
Samba fails to replicate schema 69
Status: ASSIGNED
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB
4.5.0rc3
All All
: P5 normal
: 4.5
Assigned To: Aaron Haslett
Samba QA Contact
:
Depends on:
Blocks: 10999 13713 13799
  Show dependency treegraph
 
Reported: 2016-09-03 00:05 UTC by Marc Muehlfeld
Modified: 2019-02-25 03:55 UTC (History)
9 users (show)

See Also:


Attachments
Level 10 debug log snippet (1.76 MB, application/x-gzip)
2016-09-03 00:05 UTC, Marc Muehlfeld
no flags Details
Proposed WIP patch for master (1.21 KB, patch)
2016-09-03 10:00 UTC, Andrew Bartlett
no flags Details
Level 10 debug log. Master with patch (4.07 MB, application/x-gzip)
2016-09-03 12:55 UTC, Marc Muehlfeld
no flags Details
WIP patch for master (improved) (1.36 KB, patch)
2016-09-03 20:12 UTC, Andrew Bartlett
no flags Details
WIP patch for master (further improved) (4.96 KB, patch)
2016-09-03 20:39 UTC, Andrew Bartlett
no flags Details
Level 10 debug log from run with improved patch (4.23 MB, application/x-gzip)
2016-09-03 21:35 UTC, Marc Muehlfeld
no flags Details
ldbsearch result (3.41 KB, application/x-bzip2)
2016-09-03 21:50 UTC, Marc Muehlfeld
no flags Details
WIP patch for master (further improved #2) (4.85 KB, patch)
2016-09-04 00:24 UTC, Andrew Bartlett
no flags Details
log.samba (level 10 debug log) (92.53 KB, application/x-bzip)
2017-05-18 15:45 UTC, Marc Muehlfeld
no flags Details
Working patch for master (9.71 KB, patch)
2019-02-18 10:13 UTC, Stefan Metzmacher
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marc Muehlfeld 2016-09-03 00:05:08 UTC
Created attachment 12426 [details]
Level 10 debug log snippet

Description:
Samba fails to replicate the Windows Server 2012 R2 directory schema (69) from a Windows 2008 R2 DC.



Steps to reproduce:
- Set up a Samba AD DC
- Join a 2008 R2 DC to the Samba AD
- Move the Schema Master and Infrastructure Master FSMO role to the 2008 R2 DC
  (This is necessary for the 2012 join, because the directory schema is
  updated using the WMI protocol, that Samba does not support yet)
- Join a 2012 R2 DC to the AD (select the 2008 R2 DC as replication source 
  during dcpromo)



Actual results:
During 2012 R2 updates the schema, Samba looses the connection to the 2008 R2 DC's schema partition:

CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com
	Default-First-Site-Name\WIN2008R2 via RPC
		DSA object GUID: f53c97d9-601c-4e36-94c0-6a91f20d7ddb
		Last attempt @ Sat Sep  3 01:29:34 2016 CEST failed, result 1359 (WERR_INTERNAL_ERROR)
		62 consecutive failure(s).
		Last success @ Sat Sep  3 01:05:50 2016 CEST

The log shows:
[2016/09/03 01:23:37.645846,  0, pid=1135, effective(0, 0), real(0, 0)] ../source4/dsdb/repl/replicated_objects.c:358(dsdb_repl_make_working_schema)
  ../source4/dsdb/repl/replicated_objects.c:358: dsdb_repl_resolve_working_schema() failed: WERR_INTERNAL_ERRORFailed to create working schema: WERR_INTERNAL_ERROR
[2016/09/03 01:23:37.648327,  4, pid=1135, effective(0, 0), real(0, 0)] ../source4/dsdb/repl/drepl_out_pull.c:178(dreplsrv_pending_op_callback)
  dreplsrv_op_pull_source(WERR_INTERNAL_ERROR) for CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com



Expected results:
Samba should be able to receive the schema update from the 2008 R2 schema master.



Additional information:
* Windows Server 2012 R2 DC and schema 69 support in general work with Samba 4.5. If I have a Windows 2012 R2 AD and join a Samba 4.5 DC (see Wiki) to the domain, replication works successfully and Samba receives the version 69 directory schema. It's only not working the other way around.

* Please let me know if you need the full level 10 debug log capture from the join process. It's ~250MB and I can't upload it to the ticket.
Comment 1 Andrew Bartlett 2016-09-03 06:51:32 UTC
The issue is with:

CN=Organizational-Person,CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com

Can you show that to me?

(I'll then compare with the version in the schema samba ships).
Comment 2 Andrew Bartlett 2016-09-03 10:00:18 UTC
Created attachment 12427 [details]
Proposed WIP patch for master

This patch should fix the issue shown in the logs.  Let me know if it resolves the issue!

(We should also bump up the schema in our provision to this version, but that is for another bug).
Comment 3 Marc Muehlfeld 2016-09-03 12:55:42 UTC
Created attachment 12428 [details]
Level 10 debug log. Master with patch

(In reply to Andrew Bartlett from comment #2)

I updated the Samba DCs to master and applied your patch.

When 2012 R2 now joins the domain, it ends in:
CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com
	Default-First-Site-Name\WIN2008R2 via RPC
		DSA object GUID: 14af0be5-f7a5-491e-979f-69cd32698576
		Last attempt @ Sat Sep  3 14:50:44 2016 CEST failed, result 58 (WERR_BAD_NET_RESP)
		13 consecutive failure(s).
		Last success @ Sat Sep  3 14:48:08 2016 CEST


Anyway, the level 10 debug log capture on one Samba DC was now small enough to attach it to the ticket.
Comment 4 Andrew Bartlett 2016-09-03 20:12:56 UTC
Created attachment 12435 [details]
WIP patch for master (improved)

This patch lowers the noise a bit further, but the fundamental issue is:

[2016/09/03 14:49:29.683087,  0, pid=927, effective(0, 0), real(0, 0)] ../source4/dsdb/repl/replicated_objects.c:737(dsdb_replicated_objects_convert)
  Failed to convert object CN=Organizational-Person,CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com: WERR_DS_ATT_NOT_DEF_IN_SCHEMA
[2016/09/03 14:49:29.683309,  0, pid=927, effective(0, 0), real(0, 0)] ../source4/dsdb/repl/drepl_out_helpers.c:908(dreplsrv_op_pull_source_apply_changes_trigger)
  Failed to convert objects: WERR_DS_ATT_NOT_DEF_IN_SCHEMA/NT_STATUS_INVALID_NETWORK_RESPONSE

The issue here is that the Windows 2012R2 schema is larger than the DRS replication page size.  That means that one of the new attributes on the Organizational-Person object hasn't been sent to us yet, when we try to replicate it. 

Fixing this will be harder, but to be sure can you provide the ldbsearch of me that object on all servers?

Also include the replPropertyMetaData exploded with --show-binary.

Thanks!
Comment 5 Andrew Bartlett 2016-09-03 20:39:21 UTC
Created attachment 12436 [details]
WIP patch for master (further improved)

I think this should address the issue, by increasing the replication page size for schema.
Comment 6 Marc Muehlfeld 2016-09-03 21:35:05 UTC
Created attachment 12437 [details]
Level 10 debug log from run with improved patch

(In reply to Andrew Bartlett from comment #5)
I reset my environmet, applied your improved patch, and retried the join:

CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com
	Default-First-Site-Name\WIN2008R2 via RPC
		DSA object GUID: 14af0be5-f7a5-491e-979f-69cd32698576
		Last attempt @ Sat Sep  3 23:31:10 2016 CEST failed, result 1359 (WERR_INTERNAL_ERROR)
		13 consecutive failure(s).
		Last success @ Sat Sep  3 23:26:41 2016 CEST


New level 10 debug log of the process attached.
Comment 7 Marc Muehlfeld 2016-09-03 21:50:41 UTC
Created attachment 12438 [details]
ldbsearch result

(In reply to Andrew Bartlett from comment #4)
> Fixing this will be harder, but to be sure can you provide the ldbsearch of me 
> that object on all servers?
> 
> Also include the replPropertyMetaData exploded with --show-binary.

I'm not sure if the attached is what you requested. If not, can you please tell me the command(s) to run?
Comment 8 Marc Muehlfeld 2016-09-03 21:57:10 UTC
Can we set this bug as blocker for 4.5? This release brings so much stuff for schema 69 support and it would be great if we could announce with 4.5.0, that joining a 2012 DC works (at least as experimental feature). I already wrote a detailed guide for the Wiki (not published yet) about the process and all the things to take care of.
Comment 9 Andrew Bartlett 2016-09-04 00:23:44 UTC
(In reply to Marc Muehlfeld from comment #8)
Our rules don't allow it to be a blocker, but if the wins keep coming as quickly as these patches so far, then it might get in anyway. 

The last patch had a regression, try this one.
Comment 10 Andrew Bartlett 2016-09-04 00:24:37 UTC
Created attachment 12439 [details]
WIP patch for master (further improved #2)
Comment 11 Marc Muehlfeld 2016-09-04 09:59:29 UTC
I made a first try and it seems to work now:


CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com
	Default-First-Site-Name\DC2 via RPC
		DSA object GUID: c14a774f-9732-4ec2-b9fa-2156c95c4e48
		Last attempt @ Sun Sep  4 11:51:33 2016 CEST was successful
		0 consecutive failure(s).
		Last success @ Sun Sep  4 11:51:33 2016 CEST


# ldbsearch -H /usr/local/samba/private/sam.ldb -b 'cn=Schema,cn=Configuration,dc=samdom,dc=example,dc=com' -s base objectVersion
# record 1
dn: CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com
objectVersion: 69




Let me do some further checks...
Comment 12 Andrew Bartlett 2016-09-04 19:39:59 UTC
We can't push this to master, as this seems to causes a failure in another test:

Schema-DN[CN=Schema,CN=Configuration,DC=samba,DC=example,DC=com] objects[1197/1556] linked_values[0/0]
Schema-DN[CN=Schema,CN=Configuration,DC=samba,DC=example,DC=com] objects[1330/1556] linked_values[0/0]
Schema-DN[CN=Schema,CN=Configuration,DC=samba,DC=example,DC=com] objects[1463/1556] linked_values[0/0]
Schema-DN[CN=Schema,CN=Configuration,DC=samba,DC=example,DC=com] objects[1556/1556] linked_values[0/0]
Analyze and apply schema objects
Failed to add prefixMap: operations error at ../source4/dsdb/samdb/ldb_modules/objectclass_attrs.c:355
Delete of machine account smbtorturedc was successful.
A transaction is still active in ldb context [0x2ab2d3a61700] on /home/ubuntu/autobuild/b26068/samba/bin/ab/tmp/smbtortureiynlTQ/libnet_BecomeDC.m2mJ2e/private/sam.ldb
UNEXPECTED(failure): samba4.net.api.become.dc.api.become.dc(ad_dc_ntvfs)
REASON: Exception: Exception: ../source4/torture/libnet/libnet_BecomeDC.c:114: status was NT_STATUS_UNSUCCESSFUL, expected NT_STATUS_OK: libnet_BecomeDC() failed - NT_STATUS_UNSUCCESSFUL (null)

However, we are close, and this should not be too hard to sort out.
Comment 13 Stefan Metzmacher 2016-09-05 10:41:52 UTC
(In reply to Andrew Bartlett from comment #12)

Instead of using more objects per chunk, we should cache the results
similar to libnet_vampire_cb_schema_chunk():

        if (!s->schema_part.first_object) {
                s->schema_part.object_count = object_count;
                s->schema_part.first_object = talloc_steal(s, first_object);
        } else {
                s->schema_part.object_count             += object_count;
                s->schema_part.last_object->next_object = talloc_steal(s->schema_part.last_object,
                                                                       first_object);
        }
        for (cur = first_object; cur->next_object; cur = cur->next_object) {}
        s->schema_part.last_object = cur;

        if (!c->partition->more_data) {
                return libnet_vampire_cb_apply_schema(s, c);
        }

So we only take a look at the replicated objects once we collected all of them.
Comment 14 Marc Muehlfeld 2016-09-05 19:03:50 UTC
(In reply to Marc Muehlfeld from comment #11)
> Let me do some further checks...

From the user perspective it looks good. The schema is updated. Good work.

I saw a few things about replication, but I'm not sure if this is related to this bug report. That's why I sent this to Andrew in an email first for discussion.
Comment 15 Andrew Bartlett 2016-09-05 23:23:27 UTC
(In reply to Stefan Metzmacher from comment #13)
The issue I have with that approach is that I'm not confident to make that change for 4.5 at this point.

I do agree it would be cleaner for master, and may not be that difficult to implement, once we find the right place to hang the object list on.
Comment 16 Marc Muehlfeld 2017-05-18 15:45:15 UTC
Created attachment 13224 [details]
log.samba (level 10 debug log)

(In reply to Andrew Bartlett from comment #10)
I applied your WIP patch to 4.6.3 and it no longer raises further replication problems as on 4.5. It seems 4.6 fixed everything and we are much closer to the goal.


If you follow the latest Wiki documentation
https://wiki.samba.org/index.php/Joining_a_Windows_Server_2012_/_2012_R2_DC_to_a_Samba_AD
and your Samba 4.6 DCs have the WIP patch from this BZ applied, you can now successfully join Win2012R2 and replication no longer fails. "samba-tool drs showrepl" shows no errors, and objects are replicated between all DCs. Hooray! :-)


I only see two errors appearing on the Samba DC every 30 seconds:
[2017/05/18 17:27:18.357005,  0] ../source4/rpc_server/drsuapi/getncchanges.c:2030(dcesrv_drsuapi_DsGetNCChanges)
  ../source4/rpc_server/drsuapi/getncchanges.c:2030: DsGetNCChanges 2nd replication on DN CN=RID Manager$,CN=System,DC=samdom,DC=example,DC=com newer highwatermark (last_dn (null))
[2017/05/18 17:27:18.360985,  0] ../source4/rpc_server/drsuapi/getncchanges.c:864(getncchanges_rid_alloc)
  ../source4/rpc_server/drsuapi/getncchanges.c:864: Failed extended allocation RID pool operation - ../source4/dsdb/samdb/ldb_modules/ridalloc.c:727: Failed to find serverReference in CN=WIN2012R2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com - (null)


Andrew, can you please have a look at the errors and hopefully finalize the patch?

Let me know if I can test a patch or provide further details or logs. I have a prepared test environment here.
Comment 17 Luc Lalonde 2018-01-26 15:52:23 UTC
Hello,

Has there been any updates to this bug?  On the wiki, it still says that joining a Windows2012R2 server is experimental... and it points to this bug report.

Is there any hope that 4.8 will support this?

Thank You!
Comment 18 Luc Lalonde 2018-09-12 19:26:14 UTC
I tried the reverse... 

Joining Samba4 (v4.8.5) to a Win2kr2 domain gave this error (among others):

DsAddEntry failed with status WERR_ACCESS_DENIED info (8567, 'WERR_DS_INCOMPATIBLE_VERSION') 

Would this be resolved in the 4.9rcx?
Comment 19 Andrew Bartlett 2018-09-12 23:41:37 UTC
There is a difference between joining a windows 2012R2 server and a windows 2012R2 functional level domain. 

If the domain were at 2008R2 functional level it would work, but this check is to prevent having a domain with features enabled on some servers and not on others.
Comment 20 Luc Lalonde 2018-09-13 13:59:17 UTC
That's what I was testing...  Joining a Samba4 à 2012R2 functional level domain.

Perhaps if schema level is not something easily detected, we could have an option that explicitly states the schema version:

samba-tool domain join samdom.example.com DC -U"SAMDOM\administrator" --dns-backend=SAMBA_INTERNAL --schema-support 69

Or is there already something like that already included?
Comment 21 Andrew Bartlett 2018-09-14 05:18:43 UTC
(In reply to Luc Lalonde from comment #20)
Please file a two new bugs for the feature request:
 - that attempting to join a domain with a 2012R2 functional level should give a clear error message and describe the available options
 - that we should support FL2012R2

As far as I'm aware, this particular issue is fixed, but I'll check first before we close it.
Comment 23 Stefan Metzmacher 2019-02-18 10:13:48 UTC
Created attachment 14850 [details]
Working patch for master

This passes all existing tests and a very similar patch was tested to fix the replication after samba-tool domain schemaupgrade run on the schema master.

But there's no regression protection test yet.

We should also make sure samba-tool drs replicate --local is also able to recover.
Comment 24 Andrew Bartlett 2019-02-18 18:44:22 UTC
G'Day Metze,

Good news!

Garming and Aaron have been working on this for some time and have a extensive series of tests being finalised to ensure this works in even the most extreme situations. 

I'm sure they will look over your patch (which I understand is similar) with interest. 

Expect good progress soon!
Comment 25 Garming Sam 2019-02-18 22:18:56 UTC
(In reply to Stefan Metzmacher from comment #23)

Comparing your patch, it's much tidier so I think should be used instead but there were some issues which we should've fixed:

memcpy(&sc->linked_attributes[sc->linked_attributes_count], new_las, linked_attributes_count) 

should be linked_attributes_count * sizeof(struct drsuapi_DsReplicaLinkedAttribute)

which should have segfaulted, but there was also a bug with the sc->linked_attributes_count not being set and so links were dropped.

Linked attributes in the schema partition are a bit of a question mark, but it was supported before (I tested my patch originally by setting possSuperiors on OU to dMD and made a managedBy to CN=Administrator). We may wish to stop doing this at some point because I'm not sure it's actually what Windows allows, but for now we should probably not break the existing behaviour.
Comment 26 Stefan Metzmacher 2019-02-18 23:09:53 UTC
(In reply to Garming Sam from comment #25)

Thanks for finding the linked attribute stuff.

We just need to get it right once:-)

Where can I find all the tests?
Comment 27 Aaron Haslett 2019-02-19 00:11:47 UTC
Hi Stefan, the tests are on branch aaron-schema-2012r2-stefanpatch on gitlab.com.

https://gitlab.com/catalyst-samba/samba/commits/aaron-schema-2012r2-stefanpatch
Comment 28 Stefan Metzmacher 2019-02-19 19:02:58 UTC
(In reply to Aaron Haslett from comment #27)

Thanks! I worked from there.

Here's my work in progress 
https://git.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master4-schema
Comment 29 Aaron Haslett 2019-02-20 00:53:18 UTC
Thanks Metze, amazing and very fast work.  I'll merge your 3rd pair patch to add local testing.  Unfortunately, your actual drepl_out_helpers.c patch fails right now.  Run this command on your own wip branch:
make test TESTS=samba4.drs.getnc_schema

To get the following error in the linked attributes test:
*** Error in `samba: task[dreplsrv]': corrupted size vs. prev_size: 0x0000561c395f6300 ***
Comment 30 Aaron Haslett 2019-02-20 03:49:27 UTC
I merged your Samba4.pm changes and added some fixes in my branch required because we're updating default base schema to 2012_R2.  Are you planning to get --local schema repl working or shall I work on it?
Comment 31 Stefan Metzmacher 2019-02-20 19:06:00 UTC
(In reply to Aaron Haslett from comment #29)

I've fixed the 'corrupted size vs. prev_size' problem.

And I fixed the --local replication.

I haven't looked at your test changes yet.

It would be great if you could prepare all tests
and make it possible to have the failures marked as knownfail.

And please hold on with the changing default to 2012_R2,
we can think about it when everything is fixed.
Comment 32 Andrew Bartlett 2019-02-20 21:55:31 UTC
(In reply to Stefan Metzmacher from comment #31)
We are very happy to help, but we do also need to move fairly promptly to checkpoint this into master.  There will always be so much more to do on our schema!

Specifically, we need to move on to other things early next week so if you could have a think about what is WIP and ongoing work and what is stable.

On when to change to 2012_R2 as the default schema, do remember that things are much more stable if Samba is provisioned with the latest schema than if a later live upgrade is done.
Comment 33 Björn Jacke 2019-02-21 06:58:13 UTC
On 20.02.19 22:55, samba-bugs@samba.org wrote:
> On when to change to 2012_R2 as the default schema, do remember that things are
> much more stable if Samba is provisioned with the latest schema than if a later
> live upgrade is done.

reading between those lines looks like you are not certain about the
stability of live upgrades to 2012_R2. This is just one reason more to
leave the default as is. The live upgrade is part of what Metze calls
"everything is fixed", I agree with him completely.
Comment 34 Andrew Bartlett 2019-02-21 07:12:59 UTC
(In reply to Björn Jacke from comment #33)
There is no reason to read between lines, this whole bug is about the challenges in handling live upgrades to new major schema versions!

The codepath used during the provision, and the different codepath again used during the join, is quite different and far more robust.  This is specifically because it can just download the whole schema partition and load it. 

Therefore it is, perhaps paradoxically, safer to upgrade the default schema used at provision time than to require users to exercise the existing live upgrade code to move to the Windows 2012 R2 schema.

I hope this clarifies things,
Comment 35 Garming Sam 2019-02-21 21:14:57 UTC
(In reply to Björn Jacke from comment #33)

Changing the default in this case refers to new provisions using the new schema which is quite different from the expectation that everyone should be running the newer schema versions (and thus people on older versions should be encouraged to upgrade). 

Without any additional work for the functional level, the new schema should just live there untouched once provisioned. As Andrew says, the tricky part is the live upgrade, because unless you set it as the default schema, it needs to handle inter-dependencies within the schema -- but if it's the default anyways, all the problems disappear because it already has the schema to resolve from to begin with. 

Perhaps it could detect 2012 schema and change the join (provision) schema only, but again, I don't see a good reason for not just switching the main provision schema either.
Comment 36 Garming Sam 2019-02-21 21:21:55 UTC
(In reply to Garming Sam from comment #35)

And by detect, I mean what the remote DC is running. Most people don't modify the schema and so a lot of problems just disappear.
Comment 37 Stefan Metzmacher 2019-02-21 22:04:01 UTC
(In reply to Garming Sam from comment #35)

I don't have a problem with changing the default, but that should be completely separate from this bug or be the last patch in the patchset.

I'm also wondering why we don't move to 2016 directly?

Do you have any information how the windows adprep.exe works?

Does it have to run locally on the schema master or is it able
to change things remotely?

I'm asking because I found that our sambaupgrade doesn't change
the schemaInfo attribute, which seems wrong, as it means other DCs
won't be able to detect a schema mismatch.
Comment 38 Garming Sam 2019-02-22 01:31:41 UTC
(In reply to Stefan Metzmacher from comment #37)

Mostly I think the reason is that most of the manual testing was done with 2012 R2 at the time (before 2016 was finalized) and we've inspected a good deal of the schema objects. Just a brief concern was whether or not 2016 servers relied on some 2012 R2 functional level features (or rather just server features), I had seen some people having problems with 2008 R2 -> 2016 Windows migrations at the time. Mostly it was just lack of time to look in detail.

I'm fairly sure adprep runs remotely, and it connects to the master (possibly via wmi, although that might be outer instrumentation -- it's triggered with a dcpromo join on a Windows server to update the schema of the domain if it isn't at the right level).

I wasn't aware of the schemaInfo issues until you raised them, I'm glad you somehow spotted that. I agree it seems wrong, you obviously know more about the issue than I do.
Comment 39 Luc Lalonde 2019-02-22 12:10:49 UTC
I know that Microsoft forces 2008R2 -> 2012R2 -> 2016 for their upgrade path for their Windows Server platform.   You can't go from 2008R2 directly to 2016.  I don't know if this is an Active Directory upgrade path or Operating System, or both requirement.

We use a Samba AD with 2 other Windows 2008R2 AD's for our departement (engineering school).   We get our user passwords encrypted from the school registration system that are subsequently injected into AD with scripts that were inspired by Samba's migration tools.   Native Windows AD only lets you do this with clear-text passwords.

So we're a little nervous with the impending January 2020 Windows 2008 R2 EOL.  Hopefully, 2012 R2 schema support will be working soon for Samba.  If it takes more time, I think we'll be Ok though.  Microsoft offers free extended support for 2008R2 if you migrate your server to Azure.  It gives us an extra 3 years.   So this puts less pressure on us to make a decision this summer before the 2019-2020 school year starts.

Keep up the great work!
Comment 40 Stefan Metzmacher 2019-02-22 23:05:18 UTC
(In reply to Garming Sam from comment #38)

Windows does the schema upgrade via LDAP, the key is that
it use this to bypass the typical constraints:

dn:
changetype: modify
add: schemaUpgradeInProgress
schemaUpgradeInProgress: 1

See [MS-ADTS] 3.1.1.3.3.14 schemaUpgradeInProgress

I'm implemented that in Samba now.

And it also updates schemaInfo 266 times:

schemaInfo:     NDR: struct schemaInfoBlob
        marker                   : 0xff (255)
        revision                 : 0x0000010a (266)
        invocation_id            : c48aaaa7-828e-40ae-8ed3-e83eac3b6c2d

See https://www.samba.org/~metze/caps/adprep/bla.base/
for captures, keytab and other details
Comment 41 Garming Sam 2019-02-25 03:55:24 UTC
(In reply to Luc Lalonde from comment #39)

Thanks for that. It gives a bit more merit to implementing 2012 functional level behaviour (or at least the core part of it) before trying for 2016.