On the topic of someone replacing an executable with a Trojan Horse, since this is not airtight anyway, it is incumbent upon network administrators to place these apps in NETLOGON or a subdir with read only access for the users. If that is done, they won't have the permissions to replace the files in question.
Still, though, I keep coming back to a method of encryption that doesn't rely on packaging the script into an executable. Certainly not as a replacement but as another option for admins out there.
The big sticking point seems to be how to stop the users from decrypting the passwords themselves.
I currently have an object working on my testbed
that I think satisfies this. I'm sure you'll all let me know how reasonable (or unreasonable) this sounds.
As mentioned earlier, encryption can only be done if you are a member of the Domain Admins group.
Decryption only works if:
-You are a member of Domain Admins
-You are currently logging on (via logon script) to the domain (I finally cracked the nut on this one)
Further, the key to create the encryption is based in part upon the SID of the domain itself. Therefore, someone couldn't create their own "dummy" domain, and as a domain admin, decrypt the password. Since the decryption is based off information tied directly to the original domain. (I'm using more than just the domain SID so spoofing the SID will not work).
Having said all that, how would this be circumvented? Of course there are probably a dozen ways to do it but what would the easiest exploits be? Or have we decided that there is no way to safely implement this?
Steve B
_________________________
Stevie
