We're building an intranet in CMS 7 and having some issues when it comes to getting the config in place for authorization.
Anonymous Auth and Forms Auth have been disabled, Windows Auth has been enabled in IIS. We're trying to understand whether WindowsRoleProvider will do it for us or if we need to go with the ActiveDirectoryRoleProvider. No local groups exists.
We've tried to replace all ocurrences of WebAdmins with the corresponding AD group name (in web.config and episerverframework.config) but without luck. It won't authorize.
Do we need to create local WebAdmin group on the server and nest the AD group in that? Or is there a better way?
I have read Fredrik's article (that is commonly refered to) and pretty much all other articles on the subject but I fail to find a good documentation on how to set up Episerver for an intranet, using integrated Windows/AD authentication.
Any help is appreciated!
I should say that authentication is working fine - if I'm on a domain machine I will be automatically logged in, and if I come from outside I will be prompted. Any user that's in the AD can login. So my question is about authorization - how to map the AD groups to permissions in Episerver.
WOOOHOOO! Managed to get it working now. The little thing that I was missing was the deletePrefix attribute on the WindowsMembershipProvider. So with only two changes to web.config and episerverframework.config we managed to get AD authorization going - using Windows*Provider.
Here's what we did:
<membership ...> <providers> <add name="WindowsMembershipProvider" type="EPiServer.Security.WindowsMembershipProvider, EPiServer" deletePrefix="BUILTIN\,DOMAINNAME\" searchByEmail="true" /> </providers> </membership>
<virtualRoles> <providers> <add name="WebAdmins" roles="ADMINGROUP_IN_AD" mode="Any" type="EPiServer.Security.MappedRole, EPiServer.Framework" /> </providers></virtualRoles>
The nice thing about this is that we don't need to make any changes to the location elements in web.config. We simply create a virtual WebAdmins group which points to our AD Admin group. And thanks to deletePrefix this group can be resolved correctly. Nice and clean approach!
We've also tried to nest groups in AD and that works just fine so I don't really know why people say that there is a limitation with nesting when using the Windows*Provider?