problem with GPO Policy after rename

[itdept_head]

On 31/01/2023 14:49, David Mulder via samba-technical wrote:
> On 1/30/23 11:46 PM, itdept_head via samba-technical wrote:
>> Samba 4.14.4
>> Migrated a domain. with a Rename.
>> The domain is up and resolving correctly and logs in etc. (seems to 
>> function totally correctly)
>>
>>
>>
>>
>> As stated in documents the GPO point to the old domain.
>>
>> Old: ns01.Jim.com
>> New: org.bob.com
>>
>>
>> However this hangs the windows 10 gpmc.msc tool.
>>
>> Forest: org.bob.com
>> Domains: org.bob.com
>> org.bob.com
>>
>> as soon as you select the “org.bob.com” to maintain the tree of 
>> users/gpo ,etc you get into an endless loop since “ns01.jim.com” 
>> cannot be found (also you might not want it referencing the old domain)
>>
>> “Domain: ns01.Jim.com”
>> “The specified domain either does not exist or could not be contacted.”
>> This then puts the MS tools into a tight loop with no cancel options.
>>
>>
>> QUESTION:
>> Where is this reference to “Domain: ns01.Jim.com”. kept in the LDAP.
>> Totally deleting the GPO from SYSVOL AND going into 
>> CN=Policies.CN=System. To delete any used GPO links , and restarting 
>> the samba does not remove the references.
> IIRC, these are kept in 'CN=Policies,CN=System' in ldap. I think the 
> objectClass is 'groupPolicyContainer'. I'm just skimming through code to 
> see these. You should be able to do a subtree search for 
> '(objectClass=groupPolicyContainer)' to find all your GPOs.
> 


The problem is, if I understand it correctly, Samba doesn't support 
renaming a domain in the long term.


The 'rename' tool was added at the 4.9.0 release and it states this in 
the release notes:


Note that the renamed tool is currently not intended to support a 
long-term rename of the production domain.


It also says this:


Currently renaming the GPOs is not supported and would need to be done 
manually.


I haven't seen anything that says differently (there might be something, 
but I haven't seen it if there is.)


It would be great if renaming a domain does work, but I wouldn't 
recommend trying it in production.


Has anyone renamed a Samba domain and if so, does it work long term ?


Rowland


We are about to find out........., no point in having a tool if no one is going to test it.
Yes your understanding is almost correct.... this is related to the GPMC tool not even getting to the GPO files & crashing even if they are all deleted from the sysvol.

The main problem  is documentation saying thing like ", Samba doesn't support  renaming a domain in the long term.", which, this statement  IS in the documentation
But then not qualifying the statement, with a version number or why.... , seriously an extra sentence from the documentation writer on their thoughts would go a long way......

So here is what I have found out.

1. at the LDAP path "CN=Domain-DNS,CN=Schema,CN=Configuration,DC=.....", there is a string value  called gplink, this contains a record  of all the GPO's in the domain, and it is this that blocks the MS tools, since it still refers to the old domain.

As in:
[LDAP://cn={FEA0E187-4CF8-44E3-B319-3F7713FDEC21},cn=policies,cn=system,dc= {old domain before re-name}, still here AFTER the rename.

When the GPMC tool hits this and cannot resolve these strings it goes into a software loop with modal dialogs, and being MS there is no "cancel" on the final modal dialog only "ok"
AND due to some of these records NOT allowing delete.. it get stuck.

So a fix:

Simply using an LDAP editor &  changing these references to the new domain, suddenly allow the GPMC  tool to start working , until it hit any subdivision container UNDER the renamed schema, that contains a GPO with an old domain reference.. & the MS tool loops again.
*note.. what is meant is NOT any reference INSIDE the GPO, but if ANY GPO was attached to this container, then the LDAP record at that container WILL have a "gplink" record referring to the old domain.

If there are no GPO then there is no problem (samba-tool, could easily  go thru each of these containers looking for gplink records & print them out, during the migration.)

However since this container is nested and not a critical part of the domain structure  the MS GPMC tool now allows these  GPO links to be removed with the GPMC tool ( just it won't allow you to remove any critical top level  GPO  because one is the default domain & config policy)

Furthermore you can go into any  record using an LDAP editor and fix the gplink record as per previously noted, by replacing the string values of the old domain with the new one (the path I choose to follow)

Now clearly this does NOT fix the content of the actual GPO , the content of which may  configure things based on the old domain record for file paths/folder paths etc., stuff which sits in GPO XML files & not the LDAP....'

As in:
" [Warning] The application deployment script (.aas file) for [\\ad01.nn01.xxx.xxx-xx.com\Software-Share\7z2201-x64.msi] cannot be regenerated but the task will continue.
Details: This installation package could not be opened. Contact the application vendor to verify that this is a valid Windows Installer package."


BUT MS supply a tool that will go thru each GPO and allow string substitution with new values. (backup),(scan)(import & substitute strings)
Since they have a fantasy of developers working on GPO's off line under differently named systems then " backup" & restore to the production domain.
 I say fantasy, because even this MS tool is bugged and misses some embedded GPO strings ,but you do get errors you can fix, and this is a MS problem not a SAMBA problem so you can get MS support.


Once you complete these fix ups, the domain allows computers to join AND it applies the new GPO correctly, infact I was pleasantly surprised at how easy it was.

So all of this is doable in an emergency with the existing tools , as long as....... the  " CN=Domain-DNS,CN=Schema,CN=Configuration,DC=..." blocking bug is cleared, (which is something the samba-tool could actually do.)
NO need to go as far as cleaning up all the  child containers & GPO, but cleaning this initial record (even if it is zeroing it out!!!!), so that the existing MS tools can then work.

Infact finding the "gplink" data field & fixing that took longer than scanning & re-importing all the GPO's from the old domain & getting them working.


My main question of "what was blocking the GPMC tool" was actually just answered by myself, the rest of this post is here as a record for other people wishing to do a rename.


So... I'm at the stage of having a renamed domain that appears to be totally functional for several days so far after the above fixes, and the GPO's all appear to be working without errors.(they set desktop pictures /config registry entries & refer to  paths correctly)

So it appears to be possible to get a totally renamed & functional domain, including GPO,..... and quite fast if only it were documented better.

Next thing is to work on printers, which might be faster to just delete & re-create...
Then the major task of how to get existing NAS to use the  {new-domain} instead of the {old-domain}, without destroying all the file references ( this might actually works as a trust relationship back to the old domain.)

long term, I will report back on the findings....either way...