Join or sign in Register for your free TechRepublic membership or if you are already a member, sign in using your preferred method below. Use Your Email Use FacebookUse Linkedin

Keep generic accounts from console

Locked

Our company is mandated by the Healthcare Insurance Portability and Accountability Act. Each domain account has to be held accountable.

What are some suggestions on how to extend accountability to a ?service account?? When I say ?service account? I mean a generic domain account with a password used by an application. We have implemented Active Directory and utilize group policy.

We are running into several issues with applications that require a generic local admin account with logon local rights. It wouldn?t be as major an issue if we could control the account from logging into the console locally. At least, via restricted groups, we could pinpoint the users that can log on locally to the server to install the application utilizing this account. The user could logon locally to the console and begin the installation and insert the account where prompted.

One solution proposed is this: If the app breaks at 3:00am, the user with local admin rights could install theapp and use their account for the service account until someone with the secure password could be available to type it in. Then the user name could be replaced with the service account name and password. That seems a nuisance for all parties. Is that my only option?

Topic

Keep generic accounts from console

In reply to Keep generic accounts from console

Point value changed by question poster.

Keep generic accounts from console

In reply to Keep generic accounts from console

Part 1
Ok, if I am reading your situation correctly, you need domain-wide accounts that can log in and run as Admins, but they can’t log in locally, and you want to know what the accounts are doing. Ok. This is what I would do.

1) Enable auditing of account usage in Group Policy. Turn on Audit Logon Events, Audit Object Access, Audit Process Tracking & Audit Priviledge Use. Run these on the machines that run the application, as well as on your DCs. Keep in mind that this is a lot of auditing; it will have a performance impact. But this way, you will know what the logon accounts (including the account(s) you use for the application(s) ) are doing, when they are doing it, and what happens when they try and do something. Remeber, these audit options are in Policies – Audit Policies.

2)Make your new “domain system account” with the password you want. Set the password on the account to Never Expire. Add this account to the Domain Admins group; that group should give the account the appropriate rights. Also, make sure this account is NOT a member of any other group, including Domain Users.

Keep generic accounts from console

In reply to Keep generic accounts from console

Part 2

3) Under Policies -> User Rights Assignment, there is a policy called Log On Locally. Now as far as I remember, the Everyone group is a member of this policy, as well as every group in your AD. My suggestion here is to remove the account from this right, and apply it in Group Policy. In think in AD, that this policy is not defined. So, let’s define it. Add all groups EXCEPT Everyone to this group. Also, do NOT add Domain Admins to this. Instead, the users who are Domain Admins will (hopefully) be added in from another group. If not, you will have to add them in individually. Now before you ask, yes, the administration of this can get ugly, if you have employees coming and going frequently. If you have a Domain Admin who is not a member of any other group, and if you forget to add them to this list, then the user won’t be able to log in locally. That wouldn’t be good, but this is the best suggestion I can think of.

Keep generic accounts from console

In reply to Keep generic accounts from console

Part 3
Now yes, this is ugly, but it should work. Is it practical? Well, not really.
It would be easier if you could either 1) run the application under each machine’s Local System account, then turn on auditing on each local machine locally. YOu could then sort throught the Event Viewer Security logs and see what Local System is doing. Now,that won’t help with the re-install of the app. You will have to do as you think, to have an Admin log in himself, install the app, and have the app run as Local System.
2) Just set up the “domain system account” as a member of the Domain Admins group, give it a very complex password, and make sure that only the people who need to know the password actually have it. Keep it safe. Don’t give it to a help desk person in a moment of crisis. Protect it. And still, run auditing.

Hope this helps.

Keep generic accounts from console

In reply to Keep generic accounts from console

Something new. I forgot (and I just found it) the option to Deny Logon Locally. It is in the same section as the Log On Locally I mentioned earlier. You could set that in GP for the “domain system account” instead of the whole mess I suggested earlier. Try that, plus auditing, and keeping the password for this account safe. Boy, that is easier!

Keep generic accounts from console

In reply to Keep generic accounts from console

Thanks Joseph. We had already considered most of your suggestions, but your posts confirmed we were on the right track.

Keep generic accounts from console

In reply to Keep generic accounts from console

Your question concerns some basic security issues for all networks, (since we all have various admin-type accounts that perform background tasks), and it also highlights some missing security components in Windows networks. I was much happier with Novell. That said, I’m testing a security package for Windows called ServerBoss. I can’t speak for your situation, but it seems like it may do what you want. http://www.serverboss.com
Hope that helps.

Keep generic accounts from console

In reply to Keep generic accounts from console

Poster rated this answer

Keep generic accounts from console

In reply to Keep generic accounts from console

This question was closed by the author

[Author]

Replies