Domain Admin Access...

I work for a bank and we have a guy who is in our Operations department. He runs some software called Fundtech. This software requres domain admin access. I was running some reports and found that he had domain admin access and asked the network Manager about it. He said they tried messing with file permmisions and everything they could and couldnt get it to run without the Domain admin access.
There has to be a registry entry or something i can change? can you gusy help me with this? what can i do to detrmine what needs to change? I am the new (no experiance) security admin and this is a problem in my eyes.

Thanks, J

Did anyone try calling them and asking their Tech staff?

Try here

tigershark, they say they did, yes and its just somehting they dont know how to fix? i dont know that i beleive that...

Have you spent time with the program?
What / Where does the program read/write to or from?

What could it possible do that requires "domain" admin to run..??

I have seen a few software packages that use local admin to cause less problems for
lazy admins.

What platform are you running?

Does something run as a service?

Does it write to AD or system files?

Its just so hard to see a vendor selling such nonsense...

call the vender yourself and find out the scoop, what have you got to loose. they probably have an old version of the software they dont want to pay to update. if your responsibe for what happens there you better find out and get them to state in writing that they have been told/warned about it because if something does go wrong it's you they'll blame...what do they know about security

Ill call the vendor monday morning.. thanks guys

We have a Veritas Backup Solution that requires domain admin access..no getting around it.

but that is just a service acount right? where as this is a persons account.

Quote:

---

We have a Veritas Backup Solution that requires domain admin access..no getting around it.

---

Well if you want to back up all the files you do kinda need to have access to them first :D

if you wanted to, you could disable interactive logon, so then the program can only use the access to what it needs on the network and the privalages won't be abused as easily, that is what we do when we use symntec ghost.

How do you do that?

I had the same problem w/ a piece of software where I work...and I took work at a financial institution. And I can tell you this: there's no way this app will "only" run as a domain admin. Try this:
- If it's win2k/xp...change the security template to "compatible". This will ease the program restrictions a bit while still keeping security.
- Make the user of that workstation a power user and try it out if just the above doesn't work. If that fails, make them a local admin & train them about installing apps & such on this machine.
- Look at what files on the network this app needs access to and give appropriate access.

Like I said, there's no need for this, and I've dealt w/ this and fixed it. The person who set it up in my case (before I worked there) was just too lazy to figure it out. I've since changed it and it worked w/o issue.

Regarding someone saying Backup Exec needs Domain Admin rights: BE doesn't need to be a domain admin either...and by having the account that uses BE as a domain admin, you're leaving a huge security gap wide open. Just give the account it uses the appropriate permissions to the directories it needs to backup. Yes, it'll take a little time but it's a much more secure way of doing it. I fixed this issue as well when I started working where I do. Just make sure you understand file permissions, and you'll be all set.

Good luck.

I think you might be better asking the question following : does he really need to be domain admin or does he only needs to have administrator rights to the servers and workstations where the soft is running?
Also normally in my experiance where an application needs admin rights it is the service that needs them and not the users account.

EDIT:
I wrote the first part last night while a bit drunk after a picnic. Anyway I would suggest that you profile the program. For this I use Filemon and regmon from sysinternals to find out which files and registry keys the soft uses. Then follow this up with depends from the microsoft rescource kit (forget which one) to checks out the different DLL that are used.
As for the person I would insist that he has a strong password and that it expires. Also I would give him a normal user account for his day to day work (this is a good idea for all your domain admins in any case) and when he needs to use the software he logs on with his administrator account. The administrator account he uses would only be allowed to log on to one machine in the domain. Then keep an eye on the security event log to make sure there is no unusual activity on your sensitive accounts.
Just a couple of random ideas i am throwing around.

Sounds to me that this guy needs a good background check to make sure he wont screw around and also set auditing on this guys account to see what type of ativity is going on with this guy. also set a time line on when this person can be logged on as domain admin so this way he cant come in one night and change what he wants. you can also set restritions to a persons account in the DC's. So even if he has Domain Admin Status, the permissions on his account override his admin status. What im saying is if this guy has no buisness being in accounting then add his account name to the deny list in the Domain Controller.

This problem is actually common in environments where alot of software is used of the shelf or vendors are contracts to produce something small. A few things I do to get around this, assuming the vendor doesn't have a clue and states domain access is necessary.

1. Make him a local admin or in Windows XP a power user.
2. Run the software and look for errors, indivdually adjusing access to registry keys or files. VERY TIME CONSUMING
3. Through my own personal experience I have noted that, installing software as a local box admin often sets the correct access rights to files and resources.
4. In rare cases one does have to have domain admin rights to perform some operation. You can individually controll access to the domain controller and lock his ass out of other areas by explicitly tagging file access to deny him by using an account other than "administrator" like BillYBob. Then go into the servers and remove BillYBob from folder access and Lock down the domain controller.

Finally make a written policy that states, administrators who delete logs without permission or access files listed on a "do not enter" list are immediately terminated. Then pay a little closer attention to the logs looking for "privelege escalation" Chances are thoug, he's just a schmuck trying to do his job and a little monitoring may be ok.

Quote:

---

Regarding someone saying Backup Exec needs Domain Admin rights: BE doesn't need to be a domain admin either...and by having the account that uses BE as a domain admin, you're leaving a huge security gap wide open. Just give the account it uses the appropriate permissions to the directories it needs to backup. Yes, it'll take a little time but it's a much more secure way of doing it. I fixed this issue as well when I started working where I do. Just make sure you understand file permissions, and you'll be all set.

---

Have you ever used veritas media master server 5.0? It requires that the service account have domain admin priviligeses if you are backing up a wide variety of data sources such as SQL databases, exchange, AD, etc... Backup exec, by itself, backing up a standalone system does not need domain admin, but that doesn't mean that it doesn't need it in all cases... http://seer.support.veritas.com/docs/237611.htm I myself have worked with Veritas to try and get backups configured across our enterprise on a wide variety of systems, and without giving the service account domain admin privileges you will have problems.

There are also cases in Win2k where the exchange and cluster service accounts need domain admin privileges.

I have an exchange cluster and without domain access it's a bitch. In addition I have software the requires local admin, or box admin privy. Just as dangerous. Those accounts also fall outside normal policy of password changes so they have to be very secure in their makeup. I can think of a dozen systems that need domain admin access, they just don't work without it.