Privileged Account Management…
cross forest authenticati…
Active Roles Script Center
7 Dec 2007 12:35 AM
cross forest authentication
Customer has a lab where they want to install VAS. It is a separate entity from their Corporate environment. They are going to set up their own DC so they can have and control the RFC2307 attributes on their dc. When a user comes to the lab and logs in they would log in and authenticate against the LAB dc. What they then want to do is to use Corporate windows resources which would require an identity on the Corporate domain. What has to happen to get Corporate windows resources to allow Lab identities to use them? They want the id and password to be the same between the two environments but Corporate wont have VAS unix attributes populated in the Corporate environment. Do they have to set up a synch (MIIS) between them? Should the LAB dc be a component of the Corporate domain? Has ayone implemented this somewhere?
7 Dec 2007 12:50 AM
Are they able to set up a trust between the two forests? Even if "Corporate" did not have Unix atributes, it would accept "Lab" accounts. I believe that would fix it.
10 Dec 2007 11:11 PM
I don't know if they can have a trust here, but I don't think they can. I will verify. Thanks.
31 Jan 2008 7:03 AM
It seems to me that if the corporate domain cannot/will not trust the LAB, then there isn't a way for accounts in the LAB environment to have access to resources in the corporate environment.
So first of all I would say you have one of two options if you want the users to have access to resources in the corporate domain:
1- The corporate domain must trust the lab domain (not going to happen I am sure).
2- The user must be in the corporate domain.
I think putting the users in the corporate forest could possibly serve your purposes, the reason I say this is that you could still use the second domain (LAB Forest) to store all identity information.
You would need to configure the lab environment for a one way trust (so that it trusts corporate but corporate doesn't trust the lab). If it is a lab environment, I don't see that this would be a problem. You could then join your machine to the lab domain, set the client up for a one way trust, allow all of the accounts to reside in the corporate domain, and create user personality objects in the lab domain (requires the personality schema to be installed in the lab environment). The personality objects aren't actual security principals and they can't login (don't have passwords, etc), but they can hold identity information for another user object.
The Mapped user feature of VAS will then allow you to Map each of these user personalities to an actual security principal in the corporate forest.
There are quite few extra details you will need to know to manage the mapping most easily, but it can be done. And I believe (due to talking to members of the CPR team) that there are at least a few customers who have actually done this.
This would solve the problem where you are unable to manage unix identity information in the corporate environment, but you want access to the corporate environments resources.
31 Jan 2008 7:19 AM
If this sounds like what you/they would want to do, I can fill in more of the details. What we have here should be enough to get you started however.