When creating a Platform Layer, it's normal to join it to the domain and leave it joined to the domain.  When you add another version to your platform layer, you find that the Computer Name has changed, and that breaks domain trust.

On the packaging machine, when you attempt to log on, you receive the following error:

"The security database on the server does not have a computer account for this workstation trust relationship"

If you log in and remove the machine from the domain before re-adding it, that can temporarily fix the issue.  You do not see this on every layer edit, it depends on whether the OS layer version (or prerequisite list) has changed.
 

When App Layering is initializing the registry for a layer, we set the ComputerName in the registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ComputerName to CITRXAL_something, where "something" is based on the internal layer ID number.  For instance, if you click the (i) for a layer in the Management Console and it says ID 1048581, then the packaging machine while editing that layer would be named CITRXAL_100005. 

However, that naming is not required, and is not guaranteed to remain.  When Layer Caching is enabled, the ComputerName can change.    It's a limitation of how layer caching works that the ComputerName setting is not guaranteed to stay the same.  Since anything that depends on the ComputerName will also have problems in your target machines, this isn't normally a problem.  But it is for domain trust.

The simplest solution is to unjoin and rejoin the Platform Layer to the domain each time you hit this.

Another possibility is available in version 4.12 and later, where the process of Layer Caching is slightly different.  After creating or editing the Platform Layer, manually set the machine name in Computer -> Properties.  Even if you set it to what it already is, the virtualized registry will capture the setting, overriding whatever is in any boot disk.  From then on, that platform layer's machine name will not change, and any negotiated domain trust (as long as the name is unique, of course) will persist.

Finally, if you disable Layer Caching entirely, by editing your connector and setting the cache size to 0, this problem is eliminated.
 

---

Problem Cause

The problem here is complicated.  If you need to use Caching, because it's a significant performance boost when layering, then the machine name will change every time you use a new OS layer version.  If you turn off Caching, then the machine names will stabilize.  You may need to decide which is more important.

The way Caching works in a connector is, the first time you edit any layer, a generic boot disk with that specific version of the OS layer is uploaded.  The Computer Name set in that generic boot disk is the package ID of the layer you happen to be editing.  But we can re-use that generic boot disk for any other layer edits, and we don't bother to change the machine name.  So, as an example:

The first layer you edit with OS revision 5 is called CITRXAL_1000001, because it happens to have layer ID 1000001.  If you create layer 100002 based on OS revision 5, since we already have a copy of OS revision 5 cached in the connector, we'll just re-use it, and the packaging machine for 1000002 will still be named CITRXAL_1000001.

Then I create revision 6 of my OS layer.  There is no cached copy of revision 6.  So immediately after creating R6, I version layer 1000002.  The ELM has to construct and upload a generic boot disk for OS revision 6, and since I happen to be working on 1000002, the boot disk has the machine name CITRXAL_1000002.  If an hour later I go back to edit 1000001 using OS revision 6, it will use the cached copy of OS revision 6, and it will boot up in a machine named CITRXAL_1000002 in Windows.  Since domain trust requires that the machine name match the MachineAccount name in AD, the unexpected ComputerName change breaks domain trust.

Starting in 4.12, cached layers involve an additional small boot disk.  That disk is much smaller than your OS layer.  Previously, each cached layer versin included the layer package disk and a private copy of the OS layer version.  Starting in 4.12, each layer includes the package disk and the smaller local boot disk, and shares  single copy of the OS Layer revision with all other layer versions built with this OS version.  The total space consumed will be considerably smaller as yo accumulate more cached layers.

This new boot disk allows machine names to persist across OS version changes, because the name change is written directly into this boot disk, and it survives changing the OS layer or any prerequisite layers.