Child Domain & User Accounts question

[Buffman33]

Hello,

I'd like to create to child domain MFG.COMPANY.COM to COMPANY.COM. Will the child domain be able to use COMPANY.COM's accounts or will I need to manage separate accounts for MFG.COMPANY.COM?

COMPANY.COM isn't an empty root forest; they are using login scripts, home directories, etc for each user. Will these properties be replicated to the child domain? I'd like to manage my own set of properties while still using COMPANY.COMs accounts.

Ideas/Suggestions?

 

[NickFerrar]

Accounts in the parent domain will be able to use resources in the child domain (such as logging onto the computers in the child domain using their parent domain credentials).

As for login scripts/home directories etc. if you move the accounts in the parent domain to a new OU you can make these different via GPOs, your password policy will be common to all accounts though - you'd need the accounts to be in the child domain if you wanted different password policy.

Not sure I understand your reasoning for creating a child domain but having the accounts in the parent domain though.

 

[Buffman33]

Thanks for writing back, Nick.

We have 2 networks at our company - the corporate network and manufacturing network; which has been completely separate. The corporate network uses a domain and the mfg network has been peer to peer.

We're looking into setting up a domain for the manufacturing network - which will have a separate infrastructure; profile directories, logon scripts, GPOs, and the network will all be different than corporate (for security and other reasons)

Some users will however be logging into both networks; Corp & MFG.

I was thinking of setting up a child domain so in the future we can access resources easier if needed.

Is there a way I can use the same account so userA can log into both domains using different profiles, logon scripts, etc?

Is a child domain a reasonable solution for this? Other ideas?

 

[Jpoandl]

There are going to multiple opinions on how you should set this up. My opinion is that you probably don't need a second domain. Having different logon scripts, profiles, etc doesn't really mean you need a different domain.

Windows 2003 is designed in such a way that you can have very large domains. Microsoft's best practice recommends the fewest domain possible. Joining these computers to your existing domain would be much easier then creating a new domain.

If you plan to administer the environemnt centrally (manufacturing group does not have thier own administrative group with different opinions on how the domain should work), a single domain would be best. You can still create security paramaters to protect these manufacturing computers. This would be done using Organizational Units instead of domains.

By organizing your domain in OU's, you can delegate admin authorities to other departmental groups.

- just my thoughts..

Joseph L. Poandl
MCSE 2003

If your company is in need of experts to examine technical problems/solutions, please contact

http://www.NJCOMPUTERNETWORKS.com

(Sales@njcomputernetworks.com)

 

[Buffman33]

Thanks for writing back, Joseph.

So I have a question around setting things up via OUs...

Let's say UserA logs on to his corporate computer, and his account profile is located on \\SERVER1\users\UserA

When UserA logs on to a manufacturing computer, I'll want his profile to be located on \\SERVER2\users\UserA

How would I go about doing this? Can I create a script/GPO that checks to see what OU the computer account is located and map the profile accordingly?

Any other ideas how I can accomplish this?

One of the reasons for having this is because the manufacturing systems are in a regulated environment and we dont' want the users to be able to access data from their corporate profiles...

 

[Jpoandl]

Oh...I see... This sounds like a tricky scenerio....maybe even impossible.

In fact, I bet users have the ability to access thier data on \\server1\users\userA today in your environment from a manufacturing computer.

If a user walks up to a manufacturing computer and logs on locally (say you give him a new account), he would be able to access \\server1\users\userA data. Maybe there would be no direct mapping to allow him to do this...but there is no Windows security preventing him from doing so.

For example, while logged onto the manufacturing computer, he could do this:

Start --> RUN
<type> \\server1\users or \\xx.xx.xx.xx\Users
then enter his domain user name and password when prompted
then browse to his USERA folder and access his data

Alough, this takes some know-how, it can be done. I'm not sure that you goal can be accomplished.



Joseph L. Poandl
MCSE 2003

If your company is in need of experts to examine technical problems/solutions, please contact

http://www.NJCOMPUTERNETWORKS.com

(Sales@njcomputernetworks.com)

 

[Buffman33]

Well, currenty the networks have been physically and logically separate (different IP addressing schemes and the networks are not connected together).

One idea I had was bridging the networks together using an application layer firewall (ISA 2004). That way I can control server access from the mfg network to the corp network and vice versa.

This is the reason I was considering setting up a child domain. I'd be able to specify different profile paths, etc. I was hoping i'd be able to piggy back off the corporate domain and use its accounts rather than managing 2 different domain accounts. But it doesn't look like I can do so.

I keep going back and forth on whether a child domain is a reasonable solution. I dont' like the idea of building a separate domain infrastructre and dealing with password synchronization issues, multiple accounts, etc.

But the requirements of our regulated environment keep pushing me to the idea of a child domain.

I'm open to any ideas people have out there...

 

[Jpoandl]

OK...I got an idea.

Back to single domain with departmental OU's. This will put some overhead on your network.

1) Use IPSEC policy set to REQUIRE on SERVER1
2) On the Corporate OU, create a GPO that enables using IPSEC
3) On the Manufacturing OU, create a GPO that prevents using IPSEC

Seeing how SERVER1 will require IPSEC for communication, only Corporate PC's will be able to communicate (securely) with it. All machines in the Manufacturing OU will not be able to communicate with SERVER1.

However, we will still have a PROFILE problem. A user account can only be linked to ONE home drive. However, you can create a logon script to manually map the appropriate H: depending on what IP segment they are loggin in from. I've done this type of logon script in the past....it's very easy.



Joseph L. Poandl
MCSE 2003

If your company is in need of experts to examine technical problems/solutions, please contact

http://www.NJCOMPUTERNETWORKS.com

(Sales@njcomputernetworks.com)

 

[Buffman33]

Thanks,

I think there's a problem with using IPSEC as a solution. When a user logs onto a system and it's unable to connect to the server specified in the profile path; it'll give an error message when the user logs in and signifcantly increase login time.

To go this route would mean to ditch roaming profiles altogether and use home folders. Not really an ideal solution.

Perhaps a child domain is looking a little better?

 

[Buffman33]

So putting the child domain topic off to the side...

If I went the route of applying a folder redirection GPO instead of using roaming profiles, is there a way I can apply the GPO when userA logs into the manufacturing network, and not the corporate network? Since it's a user-based GPO and not a computer-GPO i'm assuming the answer is no.

In fact, any user-GPO would get applied to both their corporate computer and manufacturing computer. An undesirable effect...

Am I correct in this statement?