Authenticate with one domain, authorize with another.

November 18, 2008 7:19 AM

In Active Directory, is it possible to direct the act of authenticating a user to one domain, but the subsequent authorization of that user to be handled by another?

Situation: For political, non-technical, and unchangable reasons, the users in our domain (Domain A), must now instead authenticate against Domain B. They are not in a forest together.

We retain control of the machines in Domain A. Domain A will still be used for management of machines, and possibly for authorization if we can find a way to pull it off.

Domain B will contain the users, just a giant mass of identities not separated into OUs. We will have no ability to put these users into groups or otherwise administer to Domain B. Account provisioning, some very light information, and password management is handled via Domain B.

Due to a number of vendor issues, we must put all of our users in a single domain (many of these particular applications can only look at one domain for authentication). Therefore, these users go into Domain B. You know, the domain without OUs or groups we can touch.

This means that in our area, our machines will be in Domain A, but the users will be logging in to the machine using Domain B.

Problem #1: We won't be able to put users into groups within Domain B, but almost all of the security in our various applications depends on group assignments. If we could separate authentication from authorization, users could log on to Domain B, but determining what groups, etc., could come from Domain A.

Problem #2: Domain B will not support roaming profiles, but a subset of our users (in a group in Domain A, not an OU, but that could change) need roaming profiles. We want to give users roaming profiles when they're logged onto our machines. Ideally, we'd like to be able to work it such that the roaming profiles are only triggered for the aforementioned group, perhaps pulling said profiles from Domain A.

Problem #1 is more important that Problem #2. I'm at a loss as to where to start with this, as I'm not really an Active Directory person, aside from the ability to manipulate it programmatically. Yes, I am aware that this scenario does not seem like a particularly great idea on the face of it. I'm just looking for technical solutions to what appears to be a technical problem generated by political issues.

Avenues Already Explored:
* Active Directory Federated Services isn't appropriate, as it is web-only.
* Dual sets of accounts could almost work, except for Domain B controlling the passwords.
* Dropping my jaw and blinking cluelessly has also not been effective.

posted by adipocere to computers & internet (7 comments total)

Time to call a contractor to deal with the political issues here. There is no technical problem! :)
posted by SirStan at 7:26 AM on November 18, 2008

"Due to a number of vendor issues, we must put all of our users in a single domain "

That sounds like your problem. I would do your best to avoid that at all costs. If you were able to fix the authentication iissue, wouldnt everything else fall into place? There MUST be a product that can act as a single bridgehead to the two servers, and allow authentication for all users. Perhaps you could start talking with these guys:

http://symlabs.com/products/ldap-proxy/faq (no relation, no knowledge, google search)
posted by SirStan at 7:37 AM on November 18, 2008

Unfortunately, Active Directory isn't LDAP. There's a claim of Active Directory being LDAPv3, but Active Directory manages (in typical Microsoft fashion) to find a few amusing ways to be just a teensy bit different enough to be a problem. The usual embrace, extend, extinguish routine.

We have some very niche applications wherein substitutes aren't simply appearing when we would like. We have many applications with the "one domain" issue. Replacing all of them, were it even possible, would be a multi-year endeavor.

Treat the prerequisites of the problem as totally unchangeable. I cannot emphasize that enough.
posted by adipocere at 7:48 AM on November 18, 2008

Domain A should establish a non-transitive interforest trust of Domain B. That will resolve #1 by allowing authentication on Domain B and authorization by Domain A.

I haven't the faintest idea how to resolve your #2 problem, I'm afraid.
posted by majick at 8:16 AM on November 18, 2008

majick has it for #1, and #2 can be fixed by forgetting about having roaming profiles. It's hard to tell though, since you only say they "need" them. Why? That is, don't fall into an X-Y problem where you've assumed that problem X (roaming users' needs) can only be satisfied by solution Y (keeping roaming profiles). There may be other ways, if you describe your architecture a little more, and what the constraints are.
posted by rhizome at 9:25 AM on November 18, 2008

I'd like to know more about the non-transitive interforest trust — what are the general steps after that?

As to #2, a portion of users (this would be our staff, rather than our clients), have specialized (and sometimes expensive) software to do their work, as well as, well, roaming workstations, hence the roaming profiles. Different groups within this have different software needs.

Additionally, while we do have network shares for their stuff, there's always the various desktop settings and customizations they require to do their work.

Every time we have attempted to take away roaming profiles, this has not gone over well. I'd rather not support them, but such is life.
posted by adipocere at 10:27 AM on November 18, 2008

A non-transitive interforest trust is one in which Domain A trusts Domain B to perform authentication, but doesn't require B to trust A. Practically speaking it lest you put user@B into groups in Domain A. Microsoft documents trusts on Technet. It requires the cooperation of the administrator of the domain to be trusted, and is a relatively straightforward procedure that takes only a few minutes.

"Every time we have attempted to take away roaming profiles, this has not gone over well."

It's not going to go over well this time, either. But the fundamental problem is the political one, not a technical one. The ability for these users to have roaming profiles exists, but it is being disallowed by a policy that isn't yours. Your users (and their managers) need to make sure that Whoever Is Making Stupid Decisions is aware of their consequences, otherwise more Stupid Decisions are going to get handed down on the assumption that nobody objects to being told to do Stupid Things.
posted by majick at 10:42 AM on November 18, 2008