Something I found rather interesting when setting up Windows authentication on Community Server with the SSO module, was with it failing to map user roles. Nothing unusual about installation problems and such, and generally it's a simple typo in the communityserver.config file that causes it to fail mapping users to CS roles based on their AD grouping. However in a recent situation trying to get this up and running on behalf of a client, there didn't seem to be any obvious reasons why it wouldn't work, I even resorted to having them check their windows roles directly through a tiny exe to see if it was actually a problem with .net connecting to the windows role.
private void button1_Click(object sender, EventArgs e)
{
WindowsPrincipal principal = new WindowsPrincipal(WindowsIdentity.GetCurrent());
if (principal.IsInRole("#UserTestRole"))
{
this.label1.Text = "Role \"UserTestRole\" Found as should";
}
else
{
this.label1.Text = "Role \"UserTestRole\" Not Found when should";
}
}
That really failed to solve the problem though, as it found the role directly. So after some extensive checking, it was discovered that their server also had a pre-windows 2000 group name...although you would think SSO would detect the current role, it failed every time until. So instead of the current role name, a pre-Windows 2000 instance had to be used like below.
<add WindowsGroupName="Domain.com\preWindowsRoleName" AuthorizationRole="Admin" CreateRoleIfNotFound="true" />
Thanks,
Ryan
