Managed Service Accounts folder was deleted and recreated in AD, but still doesn't work right.

I have a similar issue but someone recreated the MSA(Instead of restoring it from the recycle bin) as an OU and not a CN. In LDP.exe the information for MSA is in otherWellKnownObjects. I am going to follow what VPHAN has suggested in editing it.

You are very close, but the error 0x2035 (Unwilling To Perform) is telling us that you hit a logic constraint, not a permission wall. You generally do not need to be a Schema Admin or Enterprise Admin for this specific operation (Domain Admin is sufficient).

The error occurs because the wellKnownObjects attribute is a list of specific "GUID-to-DN" mappings, and you can’t have duplicate GUIDs. Currently, your Active Directory still contains the old mapping for the MSA GUID (1EB...), likely pointing to a "Deleted Object" (\0ADEL:...). The system refuses to "Add" your new mapping because that GUID slot is already taken, and it often refuses a simple "Replace" on this specific system attribute.

To fix this, you must perform a Delete operation for the old line first, and then Add the new line.

You need the exact string currently stored in AD to delete it. You can’t guess it because it likely contains the specific GUID of the deleted folder.

1. Run this command in PowerShell as Administrator to see the current list:

Get-ADObject "DC=yourdomain,DC=com" -Properties wellKnownObjects | Select-Object -ExpandProperty wellKnownObjects

2. Look for the line starting with B:32:1EB93889E40C45DF9F0C64D23BBB6237:.... It will likely end with something like ...CN=Managed Service Accounts\0ADEL:xxxxx....
3. Copy that entire string exactly.

Next, do not try to do this in one "Replace" operation.

Step A: Delete the Old Link

1. Back in LDP.exe, right-click the domain root -> Modify.
2. Attribute: wellKnownObjects
3. Operation: Select DELETE.
4. Values: Paste the Old/Zombie string you copied from PowerShell.
5. Click Enter (to add it to the entry list on the right).
6. Click Run.

=> Result: This should return "Success". The GUID is now free.

Step B: Add the New Link

1. Clear the entry list in the Modify window.
2. Attribute: wellKnownObjects
3. Operation: Select ADD.
4. Values: Enter your New string format: B:32:1EB93889E40C45DF9F0C64D23BBB6237:CN=Managed Service Accounts,DC=yourdomain,DC=com (Make sure the DN matches your new folder exactly).
5. Click Enter.
6. Click Run.

Alternative: The “Nuclear” Option (ADPREP)

If LDP continues to fight you (sometimes specific AD versions are very stubborn about editing this attribute manually), there is a supported “Reset” method using adprep.

1. Open ADSI Edit, connect to the Configuration partition.
2. Navigate to CN=Configuration,DC=... > CN=Services > CN=Windows NT > CN=Directory Service > CN=Domain Updates > CN=System.
3. Delete the two containers related to MSA updates (GUIDs 5e1574f6... and d262aae8...).
4. On your Domain Controller (with Server install media mounted), run adprep /domainprep.

Because you deleted the update history for MSAs, adprep will think it has never created the MSA container before. It will mistakenly "re-run" that logic, creating the container (or finding the existing one) and forcing the WKO link to update correctly.

Anyway, I recommend trying the LDP "Delete then Add" method first as it is less invasive.

If this answer helps you get more insight into the issue, it's appreciated of you to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

It sounds like you're encountering an issue with the New-ADServiceAccount cmdlet where it requires the Path parameter due to the Managed Service Accounts (MSA) folder not being recognized correctly in Active Directory after it was recreated. Here are some steps you can take to troubleshoot and resolve this issue:

1. Verify the MSA Folder: Ensure that the Managed Service Accounts folder has been correctly recreated in Active Directory. You can use Active Directory Users and Computers (ADUC) to check if the folder exists and is properly configured.
2. Specify the Path Parameter: Since the cmdlet is requiring the Path parameter, you can explicitly specify the path to the MSA folder when you run the New-ADServiceAccount cmdlet. For example:

      New-ADServiceAccount -Name "YourServiceAccountName" -Path "OU=Managed Service Accounts,DC=yourdomain,DC=com"
   

   Replace the OU and DC values with the appropriate values for your environment.
3. Default Path Check: If you want to set a default path for future service accounts, you may need to ensure that the default container for managed service accounts is correctly configured in your domain. Unfortunately, there is no direct cmdlet to set a default path for MSAs, but ensuring the folder is correctly set up and accessible should help.
4. Permissions: Make sure that you have the necessary permissions to create managed service accounts in the specified path. Lack of permissions might also cause issues when trying to create new accounts.
5. Replication: If your Active Directory environment has multiple domain controllers, ensure that the changes have replicated across all controllers. You can use the repadmin command to check the replication status.

If these steps do not resolve the issue, you may want to consider checking the event logs for any errors related to Active Directory or the creation of service accounts, as they might provide more insights into what is going wrong.

References:

• New-ADServiceAccount