comments (not for humans)
One of the nifty features ADAM (Active Directory Application Mode) inherits from AD, is the ability to restrict permissions to different parts of the directory structure. In this blog entry I'll try to explain how to setup permissions for your web application membership provider user.

Basic setup
We have created an ADAM instance CN=TestApp,O=Test. Inside this instance we have created (using ADAM ADSI Edit) a container for the users which is called CN=Users. We have also created a CN=ServiceUsers where we store the service user used for connecting our MembershipProvider to the ADAM instance from our web application.

Creating a role
We can assign the permission directly to the service user, but using a role will give us more flexibility later in regard to service users for other applications or low access power users. We can just add or remove them from the role to grant or revoke access.

To create a new role:
  1. Open ADAM ADSI Edit and connect to your instance
  2. Right click the CN=Roles container at the root of you ADAM instance
  3. Select "New\Object..."
  4. Choose "group"
  5. Choose a name ("MembershipProvider" is used in this example)
  6. For groupType type the following number: -2147483646
I don't know the exact meaning of the groupType number, but the other roles (Administrator, Readers, Users) have this groupType.

DSACLS
The tool we will use to set the permissions is called dsacls.exe. It's available from the "ADAM Tools Command prompt" or you can find it in %WINDIR%\ADAM.

Viewing container permissions
To see what permissions are set on a specific container in your tree, use the following syntax:
dsacls.exe \\<hostname>:<port>\<adam container dn>
To view the permissions on our user container we would typically run:
dsacls.exe \\testserver:50000\CN=Users,CN=TestApp,O=Test

Granting general permissions on a container
The general syntax for setting permissions on a container is:
dsacls.exe \\<hostname>:<port>\<adam container dn> /I:T /G <user/group/role DN>:<permission>
There are a couple of things to notice here. "/I:T" sets permissions to the container and its sub objects, while we could've used "/I:S" to include only the sub objects. "/G" means grant ("/D" is deny). The "user or group DN" is the distinguished name of the user, group or role that we grant access to the container. The "permission" part can be GR for read and GW for write (other more specific permissions are also available).

Let's explain by using an example. We want to grant our newly created role read access to the ADAM instance. We achieve this using the following command:
dsacls.exe \\testserver:50000\CN=TestApp,O=Test /I:T /G CN=MembershipProvider,CN=Roles,CN=TestApp,O=Test:GR

Service users having the MembershipProvider role will now be able to read the different containers in our ADAM instance, but we also want our web app to be able to create and update users in the CN=Users container. To achieve this we run the following command:
dsacls.exe \\testserver:50000\CN=Users,CN=TestApp,O=Test /I:T /G CN=MembershipProvider,CN=Roles,CN=TestApp,O=Test:GW

Specific permissions
If we don't want our web app to be able to add any users (users will be added manually), but still want it to be able to update certain properties, we can grant write access to specific properties of the user objects. This is achieved by replacing GW, with WP (write property), the name of the property and the object type (the object type can be omitted). Here is an example where we grant our MembershipProvider role access to update the "lastLoginTime" timestamp of our "user" objects.
dsacls.exe \\testserver:50000\CN=Users,CN=TestApp,O=Test /I:T /G CN=MembershipProvider,CN=Roles,CN=TestApp,O=Test:WP;lastLoginTime;user

Adding our web app service user to the role
We grant the service user of the web application access to our directory by adding it to the newly created MembershipProvider role. The easiest way to do this, is to open ADAM ADSI edit, select the role, and add the distinguished name of the web app service user to the member attribute of the role.
Rasmy

inheriting permission

Hi Erlend,
This article was really helpful. Thanks for sharing this information.
We have a requirment to give the all the roles of the default Adminsitrators role to a new role and then restrict the access of this new role to a particular OU. Is there a command for this?
Deeply appreciated if you can help me on this.
Am giving my id (rasmy.sadanandan@wipro.com) if you would like to drop me a note.

Thanks in advance,
Rasmy
abhishek
hi i appreciate ur article.can you provide a sample java code doing any such operation.
here iam trying to sets permissions remotely using JNDI
Comments closed for this post