[Samba] Evaluation of the Samba-tools rename functionality

[itdept_head]

On 15/2/2023, 1:56 PM, "Andrew Bartlett" <abartlet at samba.org <mailto:abartlet at samba.org>> wrote:


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.

* yep a fix for this, whilst not a requirement, would bring the MS GPO tools back on line.
*Interestingly.. this does not just apply to  renaming domains for samba..


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


What it is, is that the MS patch can mess up a rename that worked prior to this MS patch...
Where a non- domain admin  added a workstation (perhaps a user with  admin rights?, but not domain rights)
Then this field prevents smooth rejoin, and even an LDAP editor cannot remove this field. It's protected in the LDAP.
So logically you have 2 options:
1. modify the registry on  each & everyl computer , prior to rejoin, in case this field is in the computers record  (illegal MS solution)
OR
2. samba-tool , assists by removing this in the new export file (before it's loaded back into the LDAP)

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

*Yep.. but it appears a nonsense fix , since it is a client side fix (with an registry flag to turn it off),not an AD side fix, so can be bypassed..
*But also the  LDAP , flag that *might* trigger this is not even filled in for 99.9% of the client computers. (well not on 2008SP2)
*It only gets added if a non-domain admin, binds the computer. (perhaps another security oversight)

> 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?
*Yep., or the user gets deleted.


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?

*Yep... LOL.. first thing I tested..
*if you take the original domain, even the original  2008SP2, and find a computer with 
*The flag: mS-DS-CreatorSID:
*Then  hard disconnect it from the  original AD server , but then try to fix it by adding it back in
*It will NOT add in. IF that MS client patch has been installed...
*However if you do the same to a computer without field: mS-DS-CreatorSID
*It works no problem.. (which would indicate this is a mostly useless MS security fix)
*or they thought they could get away with not mentioning it only works sometimes..



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

* yep and  it's a good-ish choice, there are (as above) some required exceptions...

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

* there are some potentially very interesting MS-AD exploits here, which I won't go into...

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

*If you had a crystal ball for every future MS update, you would be in a different industry...;-)
*This probe into how AD works & this rename to bring back a fully functional MS AD for win 10
*Has revealed some potentially frighting security issues... (NOT SAMBA, but the MS implementation)
*as in wow I never expected you could subvert it like this...