MachineKeys Permissions

[Charles F Sullivan]

Someone (a vendor I believe) decided to add their application's service account with write access to the MachineKeys folder, subfolders and files included. The default, proper perms are

System: Owner

Administrators: FC (this folder only)

Everyone: Read, Write, but not execute (this folder only).

Those permissions exist on the server, but with the addition of the service account entry.

This eventually broke RDP because the server cannot renew its self-signed certificate. (The service account ends up as the only principal with access to its key file.) What does work is to rename the MachineKeys folder. Restarting the RDP service causes a new machine keys folder to get created with the proper permissions, as well as the RDP cert's new machine key. This is not a solution because it breaks the Web server's certs.

Setting the permissions correctly on the RDP key file only results in the permissions getting reset once the RDP service is restarted. The same thing happens if I just delete the key file and let it get recreated by restarting the service. A new file is created but with the bad permissions. When I check the RDP key file permissions on other servers, I see

Administrators: Read

Network Service: Read

System: FC, Owner

So my main reason for posting here is because I'm wondering if anyone can explain why the service account inheriting write access to the key file would essentially strip away any other permissions. That doesn't seem to be typical NTFS permission behavior.

I am afraid to remove the service account ACE from the folder because I can't be certain it won't break something by affecting the contained files' perms. 

--

Charlie Sullivan

Principal Windows Systems Administrator

Boston College

197 Foster St. Room 367

Brighton, MA 02135

617-552-4318