Ed,
I can speak to this a bit by giving a bit of history and my work and the
gotchas we have run into. I work for a school district with 20K kids
and around 4000 staff (full and parttime). When we started with AD a
long time ago we had 2 separate domains (academic for students and staff
for staff). We did this to make sure kids could not access staff
computers and resources.
Then folks started wanting to share data and applications between staff
and students so we created a third domain called proxy and set up trusts
between it and the staff and between it and the academic domains. We
put applications used by both staff and students and the shared file
server in the proxy domain. The file server permissions were setup like:
- if the share was staff only, we used a group in the staff domain
- if the share was student only, we used a group in the academic domain
- if the share was used by everyone, we used a group in the proxy domain
This worked, but was more effort and as folks wanted more sharing, more
integration, and as we kept finding more apps that broke because of the
trusts, we found that this was not a sustainable approach going forward.
So now we are moving everything back into one domain. Yes it is a pain,
but it has turned out to be less a pain than what we thought. Users can
easily be migrated via Microsoft tools (keeps all their information and
profile). Apps need to be rebuilt in the new domain. The biggest
problem we have run into is migrating over the data on the file server
into the new domain as we could not do that at once so we ended up
creating trusts between the new domain and the old ones and applying
permissions such that even if a person logged into the new domain they
could access files on the file server in the old domain.
I guess what I am trying to say, is that in our case, multiple domains
with trusts worked, but were not worth the effort. I feel that they are
really only worth it when you can delegate the management of domains to
other groups (e.g. divisions in a company) and they need to share a
relatively small about of stuff between them. In our case with one IT
department that manages everything, it was a several year long detour
from where we should be.
cheers,
ski
On 01/20/2013 08:39 AM, Edward Ned Harvey (lopser) wrote:
Company was built up, including some acquisitions, which means there's a
disparate and geographically disperse set of independent AD domains.We
want to make things "better" basically meaning more centralized, easier
to understand and manage consistently.
Option 1, create a new domain and force everybody onto it (or force
everyone onto one of the existing domains).Obviously includes both
administrative headache and also user impact, as anybody who's forced to
change domains will be essentially logging in with new credentials and
getting a new user profile.Which they won't like.But might be forced into.
Option 2, build trusts between the domains ... This is the option I'm
more interested in talking about, because I've never done this before.
How is this different from a forest?I guess that's question #1:What's
the difference between multiple domains in a forest, versus trust
relationships between domains?
I'm familiar with the idea, when you login to your laptop, you specify
the domain you're logging into.But your laptop can only be joined to one
domain, right?So, can a different user from a different domain also
login to that laptop, by specifying a different domain?
Can you make group policy applied to the forest, which will consequently
be applied to all the domains simultaneously?
Based on my understanding, in Option 1, there is no graceful way to
change from one domain to another while preserving the user id and
profile.Yes, you can script something to make new user accounts in a new
domain, based on usernames and properties of users in an old domain ...
But the new user accounts are in fact new user accounts, so when the
user logs into the new domain, they lose all their profile settings, etc.
_______________________________________________
Tech mailing list
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
--
"When we try to pick out anything by itself, we find it
connected to the entire universe" John Muir
Chris "Ski" Kacoroski, Director of LOPSA, [email protected],
206-501-9803 or ski98033 on most IM services
_______________________________________________
Tech mailing list
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
