Jump to content

Service Accounts and Credentials


Recommended Posts

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.

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.

Link to comment

Glossary type info for the original post.

 

Active directory is the user login database for Windows. Similar to if you have a FTP server up with various users and their passwords. Plenty of non-windows systems interact with AD. Unix, Linux, QNAP devices and Printers are common devices that integrate with Active Directory on one level or another. Think Users and Groups as this is the primary use. Lots of domain data and system info also lives in active directory as well.

 

Service account is a login on the network, dedicated to a service or services, as opposed to using One or more of the top-level domain administrator accounts. Essentially, instead of running as root (domain admin level in windows), using a dedicated account for services

Link to comment
×
×
  • Create New...