Hi, Just adding this here for others? After a rename and rebuild of the samba using samba-tools You have all the old computer names in the renamed domain. It is a very good idea to NOT to try to directly rejoin the renamed AD as the same computer. Certainly on win 10 later editions Specifically because it appears the process is very MS bug related. There are two possible ways to proceed: 1. Delete the old computer name from the renamed AD & rejoin the workstation, with the same name, this generates new SID in the AD If you want to keep the old computer name for historic reasons, the following works. 1. UNBIND the old domain , by setting a dummy workgroup "WORKGROUP" 2. REBOOT!!!!! 3. REBIND the workstation to the renamed domain using same computer name, and it will pick up the old computer. It seems if you try to directly edit the old AD name with the renamed one without an UNBIND & REBOOT, the caches are NOT flushed correctly on the computer and it all gets mixed up. And whilst it says it successfully "bound to the new domain", it's a lie.... there seems to be some optimisations on the computer side, that do not re-run all the requirements for the rebind to the new domain (SIDS are the same as the cached & registry versions for old domain), but it reports success and ,the LDAP records server side reflect changes.... however the computer side is not processed. After that all sorts of strange things start happening, depending on if there is an existing AD admin account on the rebound computer. Specifically you can sometimes log in as the "renamed" AD admin, but then you get all sorts of rights issues. Also the GPO's behave in some very strange ways, like only parts of them get applied... and some very subtle win 10 bugs come out. Most of this can be cleaned up by re-binding to the old domain, then repeating the process A or B above. steve