This is not best practice, and also implies people should use the shared service account for claims to windows token service which has basically god powers from the "Act as part of the operating system" and "Impersonate a user after authentication" local security policies.
Attached is the changes where I created a secondary function called UpdateClaimsProcessIdentity, in the XML I created a managed account entry with the common name "ClaimsService"
```
<ManagedAccount CommonName="ClaimsService">
<Username>test\C2WTS</Username>
<Password>passjigger</Password>
</ManagedAccount>
```
As it stands today AutoSPInstaller is __introducing critical security flaws__ to installations when users set UpdateAccount = true on the claims to windows token service line.
```
<ClaimsToWindowsTokenService Start="true" UpdateAccount="true"/>
```
Comments: ** Comment from web user: GeekDotNet **
I'm with Brian and would also like to prompt you for an example of that possible exploit. I'm sure in most environments this configuration is less critical than other things. For example installing solutions with full trust permissions (GAC) into ther farms without questioning the source or quality of the software deployed.
I've done some BI flavored SharePoint installations I'm a little aware of the configuration needed for these kind of customizations to the C2WTS. If a farm is doing nothing special with the C2WTS ans the account using it, then I don't see an issue at all. Because the missing AD permissions (contrained delegation with protocol transistion to impersonate ad users using a kerberos ticket) are not in place to really harm someone. But once the AD permissions are in place and in larger environments (or for best practice) the account was switched to an AD service account, the script should let us configure a dedicated user as suggested in the issue of Alexi. If not the default service account would be able to impersonate any user (due to the ad config) to the allowed services. The likelyhood of an exploit is pretty low, but in any auit this issue could rise and cause a lot of trouble. In these specific scenarios are a lot of additionals "non-scriptable" tasks open, but if your script will take care of this it is one pain task less to care about and focus on the other open tasks. Your implmentation of the process for assigning a dedicated ad account for the C2WTS looks pretty good.