The claims to windows token service account gets set to the shared service account (spservice) and the account also gets added to the local administrators.
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"/>
```
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"/>
```
