Want to win a PS4? Go Premium and enter to win our High-Tech Treats giveaway. Enter to Win

x
?
Solved

Exchange Trusted Subsystem  - Cant find real reason why i shouldnt use domain controller for witness

Posted on 2012-04-04
10
Medium Priority
?
2,233 Views
Last Modified: 2012-06-21
Hi

Im trying to understand why its not recommended to use a win2008 r2 domain controller as a witness server in a dag. - I understand that the group has to then be in the domain admin group of the domain. But Im struggling with the reason why this poses as a problem. The group just contains the ex2010 exchange server accounts right? - so with just computer accounts in the dom admin group - what security threat is that???
0
Comment
Question by:philb19
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 5
  • 4
10 Comments
 
LVL 17

Expert Comment

by:Anuroopsundd
ID: 37805709
It is not recommended to use a domain controller as the witness server because this way you grant the Exchange Trusted Subsystem group many permissions in the Active Directory domain.
0
 
LVL 1

Author Comment

by:philb19
ID: 37805728
thanks - yes if i add the group to dom admin they have ALL rights in the domain - as stated I understand this - but the group just has the exchange server accounts added. - so what ris is having an exch server account in the domain admins -what damage to the domain can a computer account do? - what is the real risk? - its not like your adding Joe Bloggs (standard user account) to the domain - i need an explanation please?
0
 
LVL 17

Expert Comment

by:Anuroopsundd
ID: 37805730
why is adding the machine account to the Exchange Trusted Subsystem group a security hole? The answer lies in Exchange 2010’s shift to Role Based Access Control (RBAC). In previous versions of Exchange, you delegated permissions directly to Active Directory and Exchange objects, allowing users to perform actions directly from their security context. If they had the appropriate permissions, their actions succeeded.

In Exchange 2010 RBAC, this model goes away; you now delegate permissions by telling RBAC what options given groups, policies, or users can perform, then assigning group memberships or policies as needed. When the EMS cmdlets run, they do so as the local machine account; since the local machine is an Exchange 2010 server, this account has been added to the Exchange Trusted Subsystem group. This group has been delegated the appropriate access entries in Active Directory and Exchange databases objects, as described in the Understanding Split Permissions TechNet topic. For a comprehensive overview of RBAC and how all the pieces fit together, read the Understanding Role Based Access Control TechNet topic.

By improperly adding a non-Exchange server to this group, you’re now giving that server account the ability to read and change any Exchange-related object or property in Active Directory or Exchange databases. Obviously, this is a hole, especially given the relative ease with which one local administrator can get a command line prompt running as one of the local system accounts.

http://www.thecabal.org/2009/12/busting-the-exchange-trusted-subsystem-myth/
0
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

 
LVL 1

Author Comment

by:philb19
ID: 37805776
ok this throws me a bit "By improperly adding a non-Exchange server to this group, you’re now giving that server account the ability to read and change any Exchange-related object or property in Active Directory or Exchange databases"

the reading ive done says - recommend is just to use a win2008 r2 file server" - so not necessary a server running exchange and not a dc - so are you saying not only should i not use a domain controller as witness server - i shouldnt use a non-exchange server?
0
 
LVL 17

Expert Comment

by:Anuroopsundd
ID: 37805796
You can do it on a exchange server actually Hub server. you can install on  file server also as it does not have permission related to DC stuff.....
0
 
LVL 1

Author Comment

by:philb19
ID: 37806008
im not convinced by "Busting the Exchange Trusted Subsystem Myth" of problem with the group being in domain admin group  - the local system account have dom admin rights? so what - we are small org - were exchange admin is same person as domain admin - thats me! for both
0
 
LVL 17

Accepted Solution

by:
Anuroopsundd earned 2000 total points
ID: 37806032
Ohh.. in your case it will not make any difference. it makes the difference where we have different members for each task. Like for backup of AD, Managing AD, Account Creationg, Patching, Exchange Management.

But in your case you can use DC as the witness server as the you already have permissions for both.
0
 
LVL 1

Author Closing Comment

by:philb19
ID: 37806175
Great - exactly answer I needed
0
 
LVL 58

Expert Comment

by:tigermatt
ID: 37806224
Computer accounts can still cause damage. It's remarkably easy to gain Command Line access as one of the System accounts, rather than under your local user token. From there, if that computer account has elevated rights on a DC, you can just about go anywhere and do anything.

A lot of concern on security matters is indeed threats from inside - allowing admins of the Exchange environment to elevate their rights to a level which may not be appropriate. In your case, you have all rights over both systems, so it's not of concern for you -- but this could pose issues in the future if your organisation structure were to change, and you wanted to delegate control of Exchange only, for example. There's also the concern of any malicious activity or infections taking control of a server which has permissions at the Administrators/Domain Admins level. By keeping the FSW off a DC, you don't need to grant domain-wide Administrators privileges, so the level of damage is restricted.

Chances of it happening? These things can and do happen. Services get compromised, especially with public-facing services like Exchange. The DCs are the keys to the kingdom, though, and you should do what you can to protect them.

-Matt
0
 
LVL 1

Author Comment

by:philb19
ID: 37806303
awesome thanks tigermatt - gives me a much better understanding -

its also something that needs explaining to auditors - when they check who is a domain admin
0

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

The core idea of this article is to make you acquainted with the best way in which you can export Exchange mailbox to PST format.
It’s time for spooky stories and consuming way too much sugar, including the many treats we’ve whipped for you in the world of tech. Check it out!
Microsoft Active Directory, the widely used IT infrastructure, is known for its high risk of credential theft. The best way to test your Active Directory’s vulnerabilities to pass-the-ticket, pass-the-hash, privilege escalation, and malware attacks …
This video shows how to use Hyena, from SystemTools Software, to update 100 user accounts from an external text file. View in 1080p for best video quality.
Suggested Courses

609 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question