views:

14

answers:

1

I have a Windows Service that requires the ability to query AD, as well as open a TCP port.

Previously, I had it running as my own personal domain account that was setup as a local administrator on the server. Later, IT required that it run as it's own account (makes sense), and we tried to duplicate the account setup.

When reconfiguring the service to run as the newly created account, it fails to start. No exceptions thrown, no errors in the logs, nothing. It just refuses to start.

What is the best way to debug this? We're trying to reproduce the issue locally where we can do real-time debugging now.

Any specific requirements or permissions that account needs on the server?

A: 

Answer to this question I think is already here on SO.

However, here is some wise advice from Microsoft:

Run the service in a specific security context. To help secure your system from attacks, run the service with minimal user rights. If you require more user rights than those that are granted to the minimal user accounts, do not run the service as a user with administrative credentials.

Also, do not change the security policy to elevate the user rights of the built-in logons (SYSTEM, Anonymous Logon, Local Service, and Network Service). Instead, create a custom account, and then grant the account the user rights that your service may require. If you require network credentials, use a domain account. If you do not require network credentials, use a local account. You may spend more time creating a custom account with limited user rights, but this is more secure than if you either run the service with too many user rights or when you add user rights to an account that is included with the operating system.

Noel Abrahams
Thanks Noel - yes, we were using a specific AD account in this case, but in the end it turned out to be an issue with the Service itself. It wasn't quite setup correctly, and not necessarily the account. Very weird.
JasonA