Top o the morning (technically about noon). This thread is an outline of life as a Windows Server based admin. Focuses in this thread relate to Active Directory user credentials, system and application services, while also touching on analysis of existing business systems.
Traveling and supporting various systems over the years, one thing that stands out in a windows server topology, is especially how Application and Database servers are configured and secured. I should say ‘secured’ because most often with things like MS SQL Server, you will see those services running as a ‘NETWORK SERVICE’ account, as opposed to being setup with a Service Account. You might ask what a service account is and why would you use it? Allow me to list some reasons for doing so.
- [*]Running services on dedicated service accounts gives better debugging. You know what user is running said service.
[*]Securing Network Shares is easier, as you grant the required Read / (and or) Write access to the service account.
[*]Windows Authentication is better handled for clients in a service environment, as you can define client users as needed, instead of starting with a wide-open access approach, especially when your intent is a limited client base.
[*]Cleaner Management. Running a service account will help keep GUI interface items running and accessible , if you are dealing with fat-client applications and diagnostic tools.
[*]Automation. Using service accounts related to your production environment will enable some more automation related to the user account. Say you want a login script to run, etc.
[*]Anti-Lockout. Tiering your service accounts, you can prevent mis-configured items from locking your production environment by locked accounts / invalid password attempts.
[*]Backup and communication recording. Similar to the Management perk, you can better trend logs for actions performed by ‘x’ user. Vastly more helpful than all app services running with a domain admin level account, solely because it is ‘easier to setup’. Please always avoid granting domain admin, unless it is imperative to the application.
[/list]Along this line, another bad practice I see, is when development is done with a C$ admin share design. Making a mapped drive in the 1st place, allows a ground-up service account testing topology. This is also helpful in preventing user accounts from getting vastly more domain or local server console access than they need. A very good practice in my opinion that goes ignored in the design phase too often. When you have to add security later, you are honestly making more work for yourself.