[unisog] Threat vector of running a service using a domain account

[Harley, Chay]

Okay, so answers:

1) Sort of. You don't want to use a domain admin account though because
a domain admin account is for domain administration, not for service
management.

2) Yes, don't use a domain admin account. Create a domain user account
and give rights to run services.

3) ... Subjective answer.

4) Service accounts are for local process execution unless you're
running cluster/enterprise apps ie. Exchange cluster or SQL Cluster.
Even then, they are not domain admin but a domain user/special rights to
run as a service.
Further permissions are typically inside the application such as dbo as
database admin, or exchange messaging admin/etc.

5. Change the password every 30 days (as usually someone can bruteforce
any windows password in that time). 
Script/automate the process. Remember - no one should need to use this
type of account interactively other than clicking "start" "stop"
"restart" on the console.

Furthermore, don't use paper to keep passwords on. They have a nasty
habbit of ending up in the trash for people to begin figuring out a
pattern to your passwords. 
Use a password file that has public/private key system attached to the
file. When someone changes their passphrase, update the file with their
new public key. 

For further security, make the access to the file an RSA process, and
give everyone tokens attached to their keys or mobile phones. It means
there are two steps to accessing the password file (passphrase/pin +
sequence generated number).

Good luck. 

Chay Harley.
MCSE+I

-----Original Message-----
From: unisog-bounces at lists.dshield.org
[mailto:unisog-bounces at lists.dshield.org] On Behalf Of Ali, Saqib
Sent: Wednesday, September 12, 2007 1:47 PM
To: UNIversity Security Operations Group
Subject: [unisog] Threat vector of running a service using a domain
account

i would like to understand the threat vector of using a "dedicated"
Active Directory account to run a service. Here are some details:

1) This particular account will have domain admin privileges.
2) The account will NOT be used to perform interactive logon to the
machines.
3) The password for the account will be stored in a safe-box

The brute-force attack risk is mitigated by the fact that the account
will lockout after X number of unsuccessful attempt. Also any attempt to
use the account for interactive logon will show up in the audit logs.

My questions:
1) Is the risk manageable?
2) Or should we completely avoid this application?
3) Is this kind of scenario common?
4) What other popular apps require such domain admin privileges for
service accounts?
5) What other Controls can we put in place to prevent misuse of the
account?

saqib
http://security-basics.blogspot.com/
_______________________________________________
unisog mailing list
unisog at lists.dshield.org
https://lists.sans.org/mailman/listinfo/unisog

-- 
This message may contain confidential, proprietary, or legally privileged information. No confidentiality or privilege is waived by any transmission to an unintended recipient. If you are not an intended recipient, please notify the sender and delete this message immediately. Any views expressed in this message are those of the sender, not those of any entity within the KBC Financial Products group of companies (together referred to as "KBC FP"). 

This message does not create any obligation, contractual or otherwise, on the part of KBC FP. It is not an offer (or solicitation of an offer) of, or a recommendation to buy or sell, any financial product. Any prices or other values included in this message are indicative only, and do not necessarily represent current market prices, prices at which KBC FP would enter into a transaction, or prices at which similar transactions may be carried on KBC FP's own books. The information contained in this message is provided "as is", without representations or warranties, express or implied, of any kind. Past performance is not indicative of future returns.