I'm working on an application that will need to utilize a bunch of custom privileges that will be granted to various users of the application. So for instance, there will be privileges in the app like:

• print reports
• update profile data
• create new reports
• delete reports
  
• add users

and so on (there are about 20-30 distinct privileges specific to the application).

We would like to be able to manage these privileges for users in Active Directory by groups or somesuch manner.

What is the best way to implement this in Active Directory?

One idea that has been kicked around was to add these as custom attributes by modifying the active directory schema. Is that really the best way to go, or are there alternatives?

thanks, Bob

Hello,

When I read your post I thought it might not be the best solution to customize the AD to fit your needs.

In the long run, if you keep customizing the AD to suit the needs of X ammount of applications, you'll have a very big AD with a zillion groups. It might be better to handle priviliges in the system itself, perhaps based on settings in the AD. All members of group XY has basic access to the application, from there on you administer the rest in the app.

The second problem of administering the ad, is that the admin usually doesn't prioritize AD-tasks like adding users to the correct group for the application.

In fact, I'm currently writing a module for one of my customers, so they can administer basic Ad-tasks from their intranet, based on the security settings in their Intranet. This way, their Ad-admin can focus on more admin oriented tasks.

Anyhow, my answer might be totally wrong, since this might be the only app ever to have all its priviligies in the AD.

My 2 cents.

Cheers!

>Anyhow, my answer might be totally wrong, since this might be the only app ever to have all its priviligies in the AD.

Thank you for  your response. Your answer is not wrong at all. It raises a good point. Actually though, the app I'm talking about will probably be the only one that would have its privileges added to AD as the application is run in a closed, specialized environment especially for running this app, so that's why we were considering placing the privileges in AD...

So assuming we're going to move forward with that: One thought we had was to modify the schema to contain some new, custom attributes (eg, "print reports", "edit profile", etc). Users could then be assigned some of these attributes and/or place into groups that also had these attributes. That all seems straight-forward enough, the application would then query the AD attributes of the user or his groups to determine permissions.

My only concern is this: we're new to the AD environment, modifying the schema seems to be an "advanced" subject and it seems as though schema changes aren't necessarily reversible once made. Is this really the best way to go about adding these privileges to AD, or is there an easier way to do this that doesn't involve modifying the schema?

It seems like we could also simply do this by just creating groups, and groups of nested groups, or OU's or something like that?

What would be the best way to try this first?

Hello again,

Well, I'll say it again, I wouldn't stuff the AD with information unless someone reall really wants to. The real problem with the AD is that is usually grows beyound control anyhow, with "normal" security configuration. The common approach, or at least what I recommend, is to build the AD-structure to simulate the companys structure. Usually based on the different companies/sub-companies, I prefer that approach before geographic location. This approach alone doesn't work in the long run, since there are always "quick fixes" needed done yesterday. For theese "quick fixes" that aren't permanent I recommend an OU that contains all the exceptions. Exceptions are to be treated as either temporary or perhaps deletable by another person. Fred might need access to a folder and you set this up in 5 minutes to solve his problem. IF you do this any other place than in the Exceptions you pretty soon have a lot of fun trying to figure out who has access to what, although there are programs that could help you with this.

Anyhow, I woulnd't modify the schema with custom attributes, I'd prefer to create groups and manage it all from there. This way you could create a OU named "youNewApp" which would contain all the necessary groups for your App.

Yet again, I'd store this info somewhere else, but sometimes there are special requirements for apps and only you know if that's the case here. So after a lot of scribbling, I'd go with the container approach creating an OU.

This, as I'm far from good at structural questions concerning the Ad, might not be the best approach.

Cheers!

/Eskil

utlandsfantomenno1:

Anyhow, I woulnd't modify the schema with custom attributes, I'd prefer to create groups and manage it all from there. This way you could create a OU named "youNewApp" which would contain all the necessary groups for your App.

This, as I'm far from good at structural questions concerning the Ad, might not be the best approach.

OK. So just to make sure I understand your recommended approach: The only thing you would place in AD would be the users and whatever groups that these users might be members of. The application then would maintain it's own mapping of users to the app-specific privileges, the point being that the mapping of users/groups to privileges in stored in the application, not AD, right?

Actually the application currently does maintain that mapping of users to privileges itself. My only problem with that is that to set up a user to use  the application must be done in two places: 1) create the user in AD, 2) log into the application and give the user his privileges. I had been thinking that placing the privileges in AD could enable the complete configuration of a user in active directory.

anyhow, thanks again.

Hello again,

Well in this case

bdm782:

Actually the application currently does maintain that mapping of users to privileges itself. My only problem with that is that to set up a user to use  the application must be done in two places: 1) create the user in AD, 2) log into the application and give the user his privileges. I had been thinking that placing the privileges in AD could enable the complete configuration of a user in active directory.

What you can do is to keep a primary key, this could be the username or perhaps the uid-id that each created user in the AD is assigned.

What you can do in your case is check against the AD if any new users have been created since the last time your apps user table was updated, if there has been changes (new users added) you simply copy base data from the AD and assign the basic priviliges in you app. This way you don't have to modify the AD and can still make your app work the way you intended.

Cheers!

/Eskil