none
Restricting access to users in other OUs in a hosted environment

    Question

  • Hi guys,

    With CRM 4, you could stop hosted CRM admin users from browsing every AD user when adding CRM users by following the steps in this post.

    Is there an equivalent for CRM 2011? I've tried looking through the OrgDBSettingsTool but can't see anything applicable.

    Thanks, Neil.


    Neil - My CRM Blog

    Thursday, December 20, 2012 12:23 PM

Answers

  • I've figured this out, so here's what I did in case anyone else finds it useful.

    Note: I'm editing the MSCRM_CONFIG database directly, so this is completely unsupported.

    I've created the script below which enters the 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 settings\customizations\developer resources). You'll also need the LDAP path of the Active Directory OU which contains the users for the org. Mine was quite basic, so the OU is in the root of my AD forest. 

    Put the 2 settings into the settings section of the SQL script and then run it against your MSCRM_CONFIG database.

    Once you've ran the script, you may need to restart IIS on the CRM server before it kicks in via iisreset /restart

    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=YourOU;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'

    To remove the restriction, you just need to delete the row which was added to the OrganizationProperties table.

    Neil.


    Neil - My CRM Blog




    • Marked as answer by Neil McD Thursday, December 20, 2012 5:25 PM
    • Edited by Neil McD Thursday, December 20, 2012 6:16 PM typo
    Thursday, December 20, 2012 5:23 PM
  • Thanks for this, Neil.

    I've been looking for a supported mechanism to achieve this for a while now.  Your post inspired me to figure out how to achieve the same via supported means - I've just finished blogging about it:

    http://pogo69.wordpress.com/2012/12/21/restricting-active-directory-domain-access-in-a-hosted-crm-2011-deployment/


    --pogo (pat) @ pogo69.wordpress.com

    • Marked as answer by Neil McD Friday, December 21, 2012 10:50 AM
    Friday, December 21, 2012 12:23 AM

All replies

  • I've figured this out, so here's what I did in case anyone else finds it useful.

    Note: I'm editing the MSCRM_CONFIG database directly, so this is completely unsupported.

    I've created the script below which enters the 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 settings\customizations\developer resources). You'll also need the LDAP path of the Active Directory OU which contains the users for the org. Mine was quite basic, so the OU is in the root of my AD forest. 

    Put the 2 settings into the settings section of the SQL script and then run it against your MSCRM_CONFIG database.

    Once you've ran the script, you may need to restart IIS on the CRM server before it kicks in via iisreset /restart

    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=YourOU;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'

    To remove the restriction, you just need to delete the row which was added to the OrganizationProperties table.

    Neil.


    Neil - My CRM Blog




    • Marked as answer by Neil McD Thursday, December 20, 2012 5:25 PM
    • Edited by Neil McD Thursday, December 20, 2012 6:16 PM typo
    Thursday, December 20, 2012 5:23 PM
  • Thanks for this, Neil.

    I've been looking for a supported mechanism to achieve this for a while now.  Your post inspired me to figure out how to achieve the same via supported means - I've just finished blogging about it:

    http://pogo69.wordpress.com/2012/12/21/restricting-active-directory-domain-access-in-a-hosted-crm-2011-deployment/


    --pogo (pat) @ pogo69.wordpress.com

    • Marked as answer by Neil McD Friday, December 21, 2012 10:50 AM
    Friday, December 21, 2012 12:23 AM
  • That's great, thank you!

    Neil - My CRM Blog

    Friday, December 21, 2012 10:50 AM
  • Does this still work in CRM 2011 UR 13 ?!

    I've implemented it in our Testsystem, and while it only shows the users in the selected OU when I "Select all users from trusted Domains and Groups", IF I select "Select only users from selected Domain and Group" I still see the complete AD-Tree.

    Is it just me, a Regression in UR 13 or did it never affect the tree? Or is the Problem that we have two Domains?!

    Thursday, May 23, 2013 1:59 PM