Neil McDonald's Dynamics CRM Blog

Restricting Hosted CRM Users From Browsing Active Directory

with one comment

When adding users to CRM via the Add Multiple Users wizard, it’s possible to view all users in Active Directory and then add them as CRM users

Screen_shot_2012-12-20_at_17

In a hosted environment, this is not ideal, as admin users for each organisation will be able to see users from all other hosted customers.

With CRM 4, there was a method of restricting users to only browse users in a particular business unit (see here). Unfortunately, this tool does not work with CRM 2011.

By looking at an old CRM 4 instance, I had a hunt around to see which settings were actually changed by the config tool to see if they would still work in CRM 2011. Thankfully, I found where to add the settings and it still appears to work in CRM 2011.

Note: The rest of this post involves making changes directly to the MSCRM_CONFIG database and this is completely unsupported. Please only try this if you have your CRM databases backed up. Please try it on a test environment first.

I’ve created the SQL script below which enters the OU settings into the MSCRM_CONFIG database, just as the tool for CRM 4 used to.

You’ll need the unique name of your organisation (you can get this from settingscustomizationsdeveloper resources).

Uniquename

You’ll also need the LDAP connection string of the Active Directory OU which contains the users for the organisation.

To create this, you can use your domain name. Let’s say “dev.dom” is our domain. That gives us LDAP://dev.com/ so far.

The next part is the fully qualified path of the OU where the users are located. Let’s say you’re using the “User1” account and your domain’s name is “dev.dom”. The “User1” account is in an OU named “TestOU” located one level below the root of the domain.

So, the fully qualified DN of the “TestOU” OU would be:OU=TestOU,DC=dev,DC=dom.

If the user you’re binding with is in a container, instead of an OU, the path would include “CN=container-name”.

You can also create your LDAP connection string if you have a more complex AD setup with sub organisational units.

For example using an account in an OU named “Service” that’s a sub-OU of an OU named “Corp” that’s a sub-OU of a domain named “dev.dom” would have a fully-qualified path of “OU=Service,OU=Corp,DC=dev,DC=dom”.

Combine the LDAP://dev.dom/ with the fully qualified path to the container where the binding user is located (like, say, LDAP://dev.dom/OU=Service,OU=Corp,DC=corp,DC=domain,DC=com`) and you’ve got your “connection string”.

Mine is quite simple and is LDAP://dev.dom/OU=TestOU;DC=dev;DC=dom

Screen_shot_2012-12-20_at_17

Put the LDAP connection string and organisation unique name values into the settings section of the SQL script and then run it against your MSCRM_CONFIG database.

declare @crmOrg nvarchar(max),
@crmId Uniqueidentifier,
@ou nvarchar(max),
@exists uniqueidentifier

--##ENTER SETTINGS HERE
--##This is the unique name of the organisation
SET @crmOrg = 'YourOrgUniqueName'

--##This is the LDAP path to the Active Directory OU containing the users for the organisation
SET @ou = 'LDAP://dev.dom/OU=TestOU;DC=dev;DC=dom'
--##ENTER SETTINGS HERE
set @crmId = (SELECT [ID] FROM [MSCRM_CONFIG].[dbo].[Organization] WHERE UniqueName = @crmOrg)
set @exists = (select [ID] from [MSCRM_CONFIG].[dbo].[OrganizationProperties] where [ID]=@crmId and [ColumnName] = 'UserRootPath')

if(@exists is null)
BEGIN
INSERT INTO [MSCRM_CONFIG].[dbo].[OrganizationProperties] ([id], [columnname], [nvarcharcolumn], [encrypted]) VALUES (@crmId, N'UserRootPath', @ou, 0)
END
ELSE
PRINT 'Setting already exists for organisation'

Once the script has executed, you will need to reset IIS on your CRM server via iisreset /restart at the command line.

Now when you try to add users again via the Add Multiple Users wizard, you will only be able to see users belonging to the OU specified

Screen_shot_2012-12-20_at_17

To remove the restriction, just delete the row which was added to the OrganizationProperties table via the below script

declare @crmOrg nvarchar(max), @crmId Uniqueidentifier

--##ENTER SETTINGS HERE
--##This is the unique name of the organisation
SET @crmOrg = 'YourOrgUniqueName'
--##ENTER SETTINGS HERE

set @crmId = (SELECT [ID] FROM [MSCRM_CONFIG].[dbo].[Organization] WHERE UniqueName = @crmOrg)
DELETE from [MSCRM_CONFIG].[dbo].[OrganizationProperties] where [ID]=@crmId and [ColumnName] = 'UserRootPath'

Remember, you are doing this at your own risk!

Edit: Pogo69 from the Microsoft forums has taken this a step further and implemented it in supported code. See his solution here

Written by neilmcd

December 20, 2012 at 6:14 pm

Posted in CRM 2011

Tagged with , ,

One Response

Subscribe to comments with RSS.

  1. […] are some unsupported methods as well as supported C# code to achieve the result. Considering that administrator’s language […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: