Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have always been a big advocate of complete separation of environments where you manage credentials for all environments separately. Recently I have been asked to think about the ramifications of creating trusts between our prod and non prod Active Directory environments such that a single production ID could manage DEV and QA environments but not the other way around.

I understand the technical details of doing this, but something just doesn't feel right from a best practices perspective for me. Does anyone currently have one way trusts in place for administration purposes between production and non prod environments? Have you encountered issues or reasons not to do this?

share|improve this question
    
Slightly off the question, but have you looked into Read-Only Domain Controllers? –  Hyppy Mar 24 '11 at 20:39
    
I have. This issue is more of is it ok for a prod user to be authenticated in non prod environments. It's not so much about where the DC's are located or the fact that I think they are vulnerable. –  BoxerBucks Mar 24 '11 at 20:43
    
That's an organizational decision, I suppose. For us, the edge-case security considerations are outweighed by the productivity savings. –  Hyppy Mar 24 '11 at 20:45
    
I understand, but I still think that as IT professionals, one of our responsibilities is to manage multiple credentials across different systems and environments. It's not that difficult. The funny thing is that the big push is coming from other IT departments and not business tester or users. –  BoxerBucks Mar 24 '11 at 21:01
    
Trust, in essence is just a way for 2 systems to recognize each-other. Unless REALLY pushed into it, same as you, I would avoid this. –  Vick Vega Mar 24 '11 at 21:04
add comment

1 Answer 1

up vote 1 down vote accepted
  1. If the DEV and QA environments trust the PROD environment then business/end users and admins have a single username and password to access all environments. +1 for user experience.
  2. When a user leaves the organization, s/he can be disabled in one environment rather than three. +1 for security/control.
  3. If DEV, QA and PROD environments are isolated, I assume that users have the same consistent username across all three environments. They are likely to manually synchronize their passwords if they log on frequently. If they log on infrequently (e.g. business users who only log on to the QA environment when they need to perform application testing as part of an application release), they are likely to forget their password in the non-PROD environments, requiring password resets. This increases the helpdesk costs. -1 for user experience, -1 for helpdesk/support.
  4. If the DEV and QA environments trust the PROD environment, and the PROD environment is compromised, then so are the DEV and QA environments. -2 for security.
  5. However, refer to point 3 above. A user with access to all three environments is likely to synchronize his/her passwords, so if this person's password is compromised in one environment the other two are probably compromised as well. Especially is the person synchronizing his/her passwords works in IT. So in an isolated design you'd need to look at unenforcable policy-level controls stating that users must have different passwords for different environments.
  6. Any vulnerabilities (patches not installed, configuration weakenesses, etc.) that allowed PROD to be compromised are likely systemic and would allow DEV and QA to be compromised even if isolated from PROD.
  7. Expanding on point 4, if the PROD environment is compromised, it's game over whether or not DEV and/or QA have been compromised.

Scenarios off the top of my head where I would want to keep the three environments separated:

  1. If network level separation is in place and integrating the three environments would result in losing or undermining this network level separation.
  2. If infrastructure or application architecture required the three environments to be kept separated. For example, if an Identity & Access Management provisioning engine was in use, I'd want to be able to develop and test thoroughly and representatively in DEV and QA before making the same changes in PROD. In this case, DEV and QA should look as close to PROD as is reasonably possible, which they wouldn't if DEV and QA both trusted PROD.

Basically, you should document the requirements, architectural / operational / user advantages and disadvantages, risks, benefits, etc. and be able to take a decision that can stand scrutiny either way. Approaching this issue in a more formal manner will help you move past "something just doesn't feel right from a best practices perspective for me" to a justifiable and defensible position. As Eugene Spafford says: “Best practice” is intended as a default policy for those who don’t have the necessary data or training to do a reasonable risk assessment.

Good luck with whatever approach you adopt.

share|improve this answer
    
Thanks for the ideas. I agree with most everything. –  BoxerBucks Mar 25 '11 at 16:51
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.