PDC upgrade from beta4 to 2.0 failure

[Jeremy Allison]

Andy Bakun wrote:
> 
> 
> Now, the upgrade of Jupiter from beta4 to 2.0.0 changed the MACHINE.SID
> file from
> 
> S-1-5-21-1510990931-2124561274-451168062
> 
> to
> 
> S-1-5-33-1510990931-2124561274-451168062

Yes - it was designed to do this due to Luke informing
me that the original code in the beta releases
was in error, and that NT used 0x21 instead of decimal 21.

> Marcus Graf had this problem, see the thread at
> http://www.samba.org/listproc/samba-ntdom/3053.html, but it didn't seem to
> ever be resolved.  I remember something about interpreting it as hex rather
> than decimal.  I tried to trick it into reading it as the number it was
> expecting, but this didn't work.  Does this mean that all my workstations
> have to be readded to the domain when upgrading to 2.0.0-final, or is there
> some other change I can make to get this to work?

It is not becoming apparant that he *DIDN'T CHECK THIS*
on NT ! Unfortunately in the rush to ship 2.0 neither
did I - and for that I must unreservedly apologise,
as I added the update code on his recommendation.

I have now done the NT coding tests myself and verified
the new code I'm sending out is correct.

What this means is that 2.0 has broken code when used
as a PDC - and I'm really sorry about it. I know we didn't
advertise 2.0 as being PDC ready but this is an amateurish
mistake and I'm ashamed of it.

The fix is to hand edit your MACHINE.SID back to decimal
21 (replace the 33) and add the following patch to the
2.0 code and re-compile.

Once again I'm *really* sorry for this stupid blunder.

Jeremy Allison,
Samba Team.

---------------------cut here----------------------------
Index: passdb/passdb.c
===================================================================
RCS file: /data/cvs/samba/source/passdb/passdb.c,v
retrieving revision 1.38.2.5
diff -u -r1.38.2.5 passdb.c
--- passdb.c	1998/12/29 01:33:33	1.38.2.5
+++ passdb.c	1999/01/21 18:40:14
@@ -870,19 +870,22 @@
 			close(fd);
 			return False;
 		}
+
 		/*
-		 * Check for a previous bug where we were writing
-		 * a machine SID with an incorrect id_auth[5] of *decimal*
-		 * 21 which should have been hex 21. If so then fix it now...
+		 * JRA. Reversed the sense of this test now that I have
+		 * actually done this test *personally*. One more reason
+		 * to never trust third party information you have not
+		 * independently verified.... sigh. JRA.
 		 */
-		if(global_sam_sid.num_auths > 0 && global_sam_sid.sub_auths[0] == 21) {
+
+		if(global_sam_sid.num_auths > 0 && global_sam_sid.sub_auths[0] == 0x21) {
 			/*
 			 * Fix and re-write...
 			 */
 			overwrite_bad_sid = True;
-			global_sam_sid.sub_auths[0] = 0x21;
-			DEBUG(5,("pdb_generate_sam_sid: Old (incorrect) sid id_auth of decimal 21 \
-detected - re-writing to be hex 0x21 instead.\n" ));
+			global_sam_sid.sub_auths[0] = 21;
+			DEBUG(5,("pdb_generate_sam_sid: Old (incorrect) sid id_auth of hex 21 \
+detected - re-writing to be decimal 21 instead.\n" ));
 			sid_to_string(sid_string, &global_sam_sid);
 			if(sys_lseek(fd, (SMB_OFF_T)0, SEEK_SET) != 0) {
 				DEBUG(0,("unable to seek file file %s. Error was %s\n",
@@ -908,13 +911,7 @@
 		mysid.sid_rev_num = 1;
 		mysid.id_auth[5] = 5;
 		mysid.num_auths = 0;
-		mysid.sub_auths[mysid.num_auths++] = 0x21;
-
-#if 0
-		/* NB. This replaces this older code : */
-		fstrcpy( sid_string, "S-1-5-21");
-		/* which was incorrect - the 21 shoud have been 33 !. JRA. */
-#endif
+		mysid.sub_auths[mysid.num_auths++] = 21;
 
 		generate_random_buffer( raw_sid_data, 12, True);
 		for( i = 0; i < 3; i++)


-- 
--------------------------------------------------------
Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.
--------------------------------------------------------