Active Directory Authentication and Authorization in Orchard CMS

Since Orchard CMS doesn’t (yet) support authentication and authorization of domain users against an Active Directory, you have to install a module to achieve this. There are handful of modules which could help. I decided to use ActiveDirectoryAuthorization by Moov2 because it was the only one which had a decent number of downloads, reviews and a project site.

If you decide to use this module, you’ll first notice that there isn’t any complete documentation how to adapt your system so that the authentication and authorization works over an Active Directory. But there is a blog article which gives some instructions. Unfortunately, the instructions seem not to be complete.

Basically when it comes to the changes to be made in your web.config, the blog post says you should “simply replace the current Forms authentication settings with the authentication settings shown below”:

    <authentication mode="Windows" />
    <roleManager enabled="true" defaultProvider="AspNetWindowsTokenRoleProvider"/>

Unfortunately, only with this change, whenever I entered my credentials, I used to get the same dialog over and over. What’s missing here, is that you also need to add an authorization tag, thus replacing:

    <authentication mode="Forms">
      <forms loginUrl="~/Users/Account/AccessDenied" timeout="2880" />


    <authentication mode="Windows"/> 
    <roleManager enabled="true" defaultProvider="AspNetWindowsTokenRoleProvider"/> 
	    <allow roles="aw001\Domain Users"/>
	    <deny users="?"/>

Of course, you have to replace aw001 by your domain name.

The question mark in the deny tag basically means that anonymous users will be denied access and the allow tag that all Domain Users of this particular domain will be granted access.

After that, Orchard just gave me a white page. So at least something was activated… In the logs, I found the following exception:

2014-09-25 11:36:01,653 [6] Orchard.Environment.DefaultBuildManager – Error when compiling assembly under ~/Modules/ActiveDirectoryAuthorization/ActiveDirectoryAuthorization.csproj.
System.Web.HttpCompileException (0x80004005): c:\inetpub\wwwroot\orchard\Modules\ActiveDirectoryAuthorization\Core\Authorizer.cs(144): error CS1061: ‘Orchard.ContentManagement.IContentManager’ does not contain a definition for ‘Flush’ and no extension method ‘Flush’ accepting a first argument of type ‘Orchard.ContentManagement.IContentManager’ could be found (are you missing a using directive or an assembly reference?)
at System.Web.Compilation.AssemblyBuilder.Compile()
at System.Web.Compilation.BuildProvidersCompiler.PerformBuild()
at System.Web.Compilation.BuildManager.CompileWebFile(VirtualPath virtualPath)
at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate)
at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate)
at System.Web.Compilation.BuildManager.GetVPathBuildResult(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean ensureIsUpToDate)
at System.Web.Compilation.BuildManager.GetCompiledAssembly(String virtualPath)
at Orchard.Environment.DefaultBuildManager.GetCompiledAssembly(String virtualPath) in Orchard\Environment\IBuildManager.cs:line 53

I could see the line of code where this was done but still wasn’t sure what I had to do. So I googled for it. There was exactly one hit. Somehow, it looks like someone had the same problem with a completely unrelated module. This problem was solved in this module and I checked what was the code change. It turns out they only removed the call to ContentManager.Flush(). So I gave it a try, editing ActiveDirectoryAuthorization\Core\Authorizer.cs and commenting out the following line in the CreateUser method:


After that I could log in.

The other problem I had was that my domain user didn’t have the permissions I thought I had assigned. The problem is that I created a role with the same name as a group of this user in Active Directory but didn’t add the domain name to it i.e. I called my role myusergroup instead of aw001\myusergroup. After correcting it, it worked fine.

When logging in with a domain user, an Orchard User is created. You do not see in the Orchard administration that this user has the role you’ve created (which is called the same as an Active Directory group) but when considering the roles of the user for checking the permissions, now Orchard will use both the roles assigned in Orchard and the groups assigned to the user in the Active Directory. Great !


Leave a Reply

Your email address will not be published. Required fields are marked *