AD Domain

[admin_2]

Jeff,<br>I was looking into adding Unity to an existing AD Domain at a customers site and then started wondering if it would not be better to add Unity to its own domain and share the same forest with AD. This would allow me to create a seperate domain security policy for unity and not change any of the existing security policies. This would also allow me to isloate unity's accounts for forgotten security policies. Any thoughts on if this would work or not. Is there any thing that I'm over looking...<br><br>Thanks<br><br>

[kechambe]

The simpler way to handle this would be to create an OU for Unity. Then you can apply any custom GPOs you want to just that OU. You can move the Unity machine account object and Unity_servername account object to that new OU.

Keith

Keith Chambers
Diagnostic Engineer
Voice Network Team, San Jose
Cisco Systems, Inc.

[#3]

As was suggested the OU is an excellent method by which to granularly apply GPO's however just realize that Although the password policy branch is available for all Group
Policy Objects it is only implemented for GPO's at the domain level so even if you make settings for a GPO for an OU or a site it will have no effect.

John Messina
Network Engineer
Crimson Technologies Inc.
jmessina@crimsoncti.com
http://www.crimsoncti.com

[kechambe]

John is absolutely correct however I want to point out that only the password policy can't be applies at the OU/Site level. The other security settings such as user rights assignments, etc. can be assigned.

Steven, can you expand on your configuration? Will any of the following services be logging in with a NT account rather than the local system account?

AvCsGateway
AvCsMgr
AvGaenSvr
AvUMRSynchSvr

If not you can run with the OU route. If any of the following login with an NT account you need to do a little more investigating.

The extra domain is a level of complexity that you probably don’t want to implement unless completely necessary but it is possible.

Keith

Keith Chambers
Diagnostic Engineer
Voice Network Team, San Jose
Cisco Systems, Inc.

[#5]

I understand that creating an OU is easy, but it doesn't shield my unity box from any GPO that are set at the domain level. It seems the only way around this would be to block inheritance, but this can always be overridden... I have mocked this up in my lab sense I submitted this post and it seems to work very well. By isolating the Unity domain I can run any security policies within the domain and do not have to worry about changing any policies within the customers domain. This also allows me to have greater control on user accounts by shutting down accounts that aren't needed thus eliminating security holes. Sense there are no other computers or users within my domain then being a DC has no issues. The only hole I have found so far is that Unity can only be allowed to import uses not create them. If Unity were allowed to create users, then it would attempt to create them in the Unity domain, which is not what I want. By having the customer create the account within Exchange first and then importing them into Unity this seems to work fine.