AD 2003 and AD2008: User works for 2 different OU's and we want to give them different permission depending on where they are working?

Question

I may be on mission impossible:

Setting: Health Care Concern: Restricting Access Based on Job Function of the day.

A person may work 3 days in one of our OU's, and then cover a shift in a different OU for 2 days. I.e. the person is part time in two different departments.

For a single App call it "Patient Record", we want the user restricted to view access to the app when working for OU 1 and only to use Update access on the days they are in OU 2.

I understand that "Member Of" Group is an attribute of the user object, and the typical behaviour for application authorization is to see Member of "View" group, and Member of "Update" group and give the user session one of the levels of access (Most restrictive or most permissive? or just the first one it finds in the list ?

If I asked the user at login with a custom login page to pick the OU (I.e. select their department from a list), is there any way to get an app to give them only the access associated with that OU ?

I know you can do this with two discrete Domains, and with giving the user a different userid in the single domain we have, is their any way to do this and meet the following requirements:

1. User must have only one userid?
2. User must get different permission based on Org Unit
3. User may select which Org Unit
4. We want to do this in a single AD domain, trying to achieve single forest single domain, not head the other direction.
5. I'd prefer not to have to customize the app to make this work.

Thanks in advance for any help.

Answer 1

This sort of thing is far from easy to set up with native AD tools. Active Directory doesn't have the ability to do inheritable rights assignments to an OU and have every member of that OU inherit access from that assignment. In order for AD to do what you're looking for you'd have to automatically modify this user's group-memberships based on their duty-schedule and couple that with forced log-offs so their security token gets refreshed.

However, it sounds like you may be working with a Web-app which introduces an application-logic layer between the user and the actual data. In that case you may be able to add another login field, call it 'authorities' or something where the user has to select a role to log in with, and the application itself proxies access.