Fix RPC_S_GRP_ELT_NOT_ADDED 0X00000788 group error

You're in Active Directory Users and Computers, trying to add a user from Domain B to a domain local group in Domain A. Click OK, and boom: RPC_S_GRP_ELT_NOT_ADDED (0X00000788) – The group element could not be added. I've seen this most often with Windows Server 2016 and 2019 domain controllers, especially after a trust was recreated or a domain controller was demoted and re-promoted. The weird part? The user appears to get added, but the operation fails. The culprit here is almost always a mismatch in the service principal name (SPN) on the target domain controller, or stale cached credentials on the source machine.

Root cause in plain English

RPC (Remote Procedure Call) handles group membership changes across domains. The RPC service on the target DC checks the SPN of the source DC to verify it's talking to a legitimate server. When that SPN doesn't match what's in Active Directory — maybe because the DC was renamed, had its IP changed, or a trust relationship got corrupted — the RPC call fails with this error. The second common cause is a cached credential blob on the machine where you're running ADUC that's still pointing at an old DC or trust path.

Step-by-step fix

Don't bother rebuilding the trust or recreating the group. That won't help. Here's what works 9 times out of 10:

Check SPNs on the target domain controller (the one in Domain A)
Open an elevated PowerShell prompt on the target DC and run:
```
setspn -L 
```
Look for entries like HOST/ and HOST/..com. If you see duplicate SPNs or missing SPNs for the machine, that's your problem. Fix duplicates with:
```
setspn -D  
```
Then re-register missing SPNs:
```
setspn -A HOST/ 
setspn -A HOST/..com 
```
Reboot the DC after this.
Flush cached credentials on the source machine
On the server or workstation where you're running ADUC, open a command prompt as administrator and run:
```
net stop rpcss & net start rpcss
```
Then clear the credential cache:
```
klist purge -li 0x3e7
```
This wipes the local service ticket cache. Do this even if you just logged in — cached RPC tickets can linger for hours.
Reset the secure channel to the target domain
If steps 1 and 2 didn't work, reset the machine's trust relationship with the target domain. On the source machine, run this in PowerShell (replace DomainA with your domain FQDN):
```
Test-ComputerSecureChannel -Repair -Credential (Get-Credential DomainA\Administrator)
```
This forces a full re-auth of the secure channel. You'll need domain admin credentials for Domain A.
Retry the group membership add
Now go back to ADUC on the source machine and add the user again. Should work. If not, move to the fallback.

What to check if it still fails

If you're still stuck, look at these three things:

DNS resolution between domains – Can your source machine resolve the domain controller in Domain A by both hostname and FQDN? Use nslookup . Stale DNS records cause this error more than people admit.
Firewall ports – RPC needs ports 135 and the dynamic RPC range (49152-65535 on Windows 2008 and later). Make sure no firewall between the domains is blocking them. I've seen third-party security software on the DC itself cause this.
Replication latency – If you just created or moved the group, changes might not have replicated to all DCs. Force replication with repadmin /syncall and wait 15 minutes before retrying.

One last thing: if you're using a read-only domain controller (RODC) as the target, you can't modify group membership through it. Must use a writable DC. Don't ask me why that still catches people in 2024, but it does.