[Samba] Evaluation of the Samba-tools rename functionality

[Andrew Bartlett]

On Wed, 2023-02-15 at 05:10 +0000, itdept_head via samba wrote:
> HI,
> 
> Just an update on this  samba-tool  (V4.17.4) ..rename functionality,
> against a 2008SP2 level AD.
> 
> (also in case anyone else is mad enough to want to attempt this.)
> 
> 
> 
> The rename tool, seems to do a fairly good job,
> 
> However there are a couple of other fields that could do with being
> flushed/fixed during the rename.

Thanks so much for your efforts testing Samba's samba-tool domain
backup rename.  We really appreciate hearing back from the 'real world'
on how our features work out.

As each site has different use cases, it is by feedback like this that
we can find out more about our users and their needs.

> This one which breaks MS tools(with continuous looping & modal dialog
> box):
> 
> (because it has the old domain hard coded into a string block,
> updating them fixes the MS maintenance tools.)
> 
> 
> 
> 
> 
> objectCatagory: CN=Domain-DNS,CN=Schema,CN=Configuration,DC={host
> name}
> 
> gPLink:
> 
> 
> 
> and there is one delimited string  in each "OU" that has any GPO set.
> 
> gPLink: [LDAP://cn={59A490CC-59A6-4920-96A2-
> 94A51F8EA1C3},cn=policies,cn=system,DC{old domain ref};0]
> 
> 
> 
> either flushing the string to null or in situ replacement, is a fix,
> 
> null  just means you have to add them to the container again, but
> the  MS tools are functional.
> 
> String replacement ,means all the GPO are correctly in the right
> object on rebuild.

Awesome!  If you could please file a bug for this, that would be
awesome.  I've sent you a bugzilla invite. 

Even better is if you could contribute (or work with someone to
contribute) some patches (with tests) to fix this that would be
awesome.

> Then this one specifically is a pain:
> 
> mS-DS-CreatorSID:
> 
> this  data field is added to a machine record  joined to an AD  in
> certain situations.

This puzzles me.  The reason that this puzzles me is that our rename
doesn't change any SIDs.

> MS issued a client side patch in the name of “security” that checks
> for this data:
> 
> "KB5020276"

This is actually a pretty serious security issue.  MS hasn't made a big
fuss about what failing to check the owning SID enables (and I don't
need to go into it here), but it isn't good.

> The machine  re-join goes pear shaped if it is found and if you have
> NOT  applied an unapproved  local machine registry mod…

Yeah, I've looked at this and the behaviour change: I can imagine this
stopping action fast.

> Which then means you have to delete the old record out of the LDAP OR
> change the name of the machine for the re-join, which is a real pain…

I think something different is happening here, because the SID of our
users doesn't change.  Could it simply be that the user who originally
created these accounts is no longer trusted?

I realise you probably don't want to be testing in production (the
rename tool was created to avoid testing in production), but does this
happen on the original domain?

The reason is that our rename doesn't change any SID (or GUID for that
matter) by deliberate design choice.  

> If there was an option in the “Samba-tool rename”  that prevented
> copy over  of  this field  into the  new  migration data & print any
> workstations it was applied to
> 
> It would go a long way to allowing machines to just be automatically
> re-joined to the old domain & keep all the preconfigured data.
> 
> 
> 
> It seems all the  domain specific data related to the domain name
> gets  “flushed”/updated to the new domain details on re-join.

This may actually be a generic Samba (and AD in general) need, a way to
'bless' accounts as always-having-been secure, so safe to re-use.  

> But important items like the: “primaryGroupID”, “whenCreated”, “
> objectSid”,etc-  that you might have GPO policy attached to or NAS
> access rights remains, which is a good enough reason to not rename
> machines.
> 
> Other that and a very simple script to  do string substitution in the
> LDAP & it seems the tool is perfectly functional.

Awesome.  It would be good to work out this rejoin issue, and figure a
way out of that.  This behaviour change is after our development of
this feature, so the impact of a rejoin wasn't in-scope.

Andrew Bartlett


-- 
Andrew Bartlett (he/him)       https://samba.org/~abartlet/
Samba Team Member (since 2001) https://samba.org
Samba Team Lead, Catalyst IT   https://catalyst.net.nz/services/samba

Samba Development and Support, Catalyst.Net Limited

Catalyst.Net Ltd - a Catalyst IT group company - Expert Open Source
Solutions