AD-Pro Authentication v3 - User Guide

     

AD-Pro Authentication v3

User Guide

Version 3.0.4

Last Updated 18th August, 2017


TABLE OF CONTENTS

Introduction

Overview

Release Notes

Installation

Requirements

Before you start

Installation process

Environment configuration

Overview

IIS configuration - General config

IIS Configuration - SSO config

AD user permissions

File System configuration

Changes made during the module installation process

AD-Pro Authentication Configuration

New login page

Settings for Evoq

Connection String - configuration

Group filter

Authentication ticket management

Photo sync

DNN user - saving modes

Activating the product

One license for Dev & Prod

Role Manager

Overview

Role Manager - configuration

When module creating roles in DNN Platform

When module revoking DNN user from a role

Single Sign On - Configuration

Overview

Requirements

IIS Configuration

File permissions

Internet Explorer - web browser configuration

Chrome - web browser configuration

Firefox - web browser configuration

SSO for all DNN pages

SSO & anonymous users

Windows authentication fails when using hosts file

SPN & Kerberos

Migrating from “DNN® Auth: Active Directory” to “AD-Pro Authentication v3”

Overview

Setting correct username format

Adjusting web.config file

Troubleshooting

SSO not working

A dependent package is not installed

The user name or password is incorrect

The server is not operational

Diagnostic Mode

Java Script errors

Edit & Delete buttons doesn’t work

500.19 Internal server error

Error 0x800050000

SSO & login screen after user inactivity

SSO may not work under the domain name address

I can’t sign in to DNN and AppPool is restarting

Performance


Introduction

Overview

AD-Pro Authentication is the most powerful Active Directory (AD) authentication provider for DNN Platform©. Leverage the power of Windows®  Active Directory® (‘AD’) by integrating DNN®  (‘DNN’) to seamlessly allow your users to login to DNN Platform with their AD credentials. Ideal for corporate intranets, Internet sites, secure extranets, schools, colleges and universities.

Release Notes

Version 03.05.00

Version 03.03.00

Version 03.02.00

Version 03.01.00

Installation

Requirements

If you get an error described on the figure above, please make sure that the “Connection Manager” module is already installed.

Before you start

<location path="DesktopModules/AuthenticationServices/ActiveDirectory/WindowsSignin.aspx">

<!-- Disable Forms Authentication →

<formsAuthenticationWrapper enabled="false" />

<system.webServer>

<security>

<!-- Enable IIS Windows authentication for the login page →

<authentication>

<windowsAuthentication enabled="true" useKernelMode="false">

        <providers>

                <clear/>

                <add value=”NTLM”/>

        </providers>

</windowsAuthentication>

                           <anonymousAuthentication enabled="false" />

</authentication>

</security>

</system.webServer>

</location>

DNNv722 - DotNetNuke.HttpModules.dll

DNNv733 - DotNetNuke.HttpModules.dll

DNNv734 - DotNetNuke.HttpModules.dll

DNNv740 - DotNetNuke.HttpModules.dll

Installation process

Installation process is the same as for other DNN Platform modules.

Environment configuration

Overview

The “AD-Pro Authentication” configuration process is tricky. You must configure the following components:

IIS configuration - General config

The DNN Platform website should have set authentication as follows:

IIS Configuration - SSO config

The “AD-Pro Authentication” module allows Single sign-on (SSO). It does that through a special broker site “WinAuthSignIn.aspx” that must have special config in Internet information Service (IIS). WinAuthSignIn.aspx file is located in DNN Platform “DesktopModules\GS_ADProAuthentication” folder and must have only “Windows Authentication” access. Rule responsible for that behavior should be at the end of the web.config file and it’s automatically added at the module installation process. See code below describes that rule:

<location path="DesktopModules/GS_ADProAuthentication/WinAuthSignIn.aspx">

    <!-- Disable Forms Authentication -->

    <formsAuthenticationWrapper enabled="false" />

    <system.webServer>

      <security>

        <!-- Enable IIS Windows authentication for the login page -->

        <authentication>

          <windowsAuthentication enabled="true" />

          <anonymousAuthentication enabled="false" />

        </authentication>

      </security>

    </system.webServer>

 </location>

This code is automatically added to the web.config file during the module installation process. However, user intervention is required in IIS config to make this work.

To do that please “Run As Administrator” the Command Line tool, and execute following commands on the server where is the IIS:

%systemroot%\system32\inetsrv\APPCMD unlock config /section:anonymousAuthentication

%systemroot%\system32\inetsrv\APPCMD unlock config /section:windowsAuthentication

If these commands returns an error like:

Object ' UNLOCK CONFIG /SECTION:ANONYMOUSAUTHENTICATION' is not supported

the changes in the applicationHost.config file located in the %windir%\system32\inetsrv\config\ folder needs to be done. More info:

 http://www.iis.net/learn/get-started/planning-for-security/how-to-use-locking-in-iis-configuration

AD user permissions

The Active Directory user specified in “Module options->Connection String” tab, must have special permissions to read AD groups, users, and user properties.

To add those permission follow steps below:

File System configuration

In this step you will set correct file permissions for your DNN website. To do that you need to know:

To obtain the "Name" of  application pool please go to:

IIS server,

To obtain the "Identity" of application pool, please go to:

To set file system permissions for the main DNN website directory, for Application Pool Identity, please go to:

To set the correct file permissions you can also execute this command:

icacls c:\inetpub\vhosts\[DNN-SITENAME] /grant "IIS APPPOOL\[AppPoolNAME]":(OI)(CI)(M)

Changes made during the module installation process

At the module installation process, following modifications will be automatically  done:

<remove name="FormsAuthentication" />

<add name="FormsAuthentication" type="Mvolo.Modules.FormsAuthModule" />

<add name="AdProAuthenticationModule"  type="GS.ADProAuthentication. AdProAuthenticationModule, GS.ADProAuthentication" />

<location path="DesktopModules/GS_ADProAuthentication/WinAuthSignIn.aspx">

    <!-- Disable Forms Authentication -->

    <formsAuthenticationWrapper enabled="false" />

    <system.webServer>

      <security>

        <!-- Enable IIS Windows authentication for the login page -->

        <authentication>

          <windowsAuthentication enabled="true" useKernelMode="false">

            <providers>

              <clear />

              <add value="NTLM" />

            </providers>

          </windowsAuthentication>

          <anonymousAuthentication enabled="false" />

        </authentication>

      </security>

    </system.webServer>

  </location>

AD-Pro Authentication Configuration

New login page

In this step we will create new DNN login page, next we inform DNN about this new login page. After this step DNN will be using this new page to login users. Below are list of steps that needs to be done:

  1. Create new DNN page, with permissions “View page” for “All users”, let’s call this page: ADLogin.aspx

  1. Put the "Account Login" module on ADLogin.aspx page, set the permissions for that module: "View module" only for "Administrators", see figure below.

  1. Put the "AD-Pro Authentication" on the ADLogin.aspx page, leave default module permissions ("View Module" to “All Users”), see figure below.

  1. Now we set page created in first step as a default DNN login page, if user clicks “login” button he will be redirected to the ADLogin.aspx. Go to Admin-> Site Settings-> Advanced Settings->Page Management and set the new login page, see figure below.

Settings for Evoq

If you are using Evoq please remember to publish page where the “AD-Pro Authentication” module is placed. See images below:

Connection String - configuration

If you get message like on the figure above, go to the “Connection Manager” module, and set the permission for the module, more info 

To set the new connection between DNN Platform and Active Directory, please follow next steps:

Group filter

“Group filter” can be specified in “AD-Pro Authentication-> Module Options-> Connection String”. If you want to disable this feature, leave it blank. The “group filter” affect on the following things:

The “group filter” is a simple LDAP filter, below is list of examples:

Authentication ticket management

The “authentication ticket” is used to tell ASP.NET application who you are. The “AD-Pro Authentication” saves authentication ticket in the cookie. There are two kinds of cookies:

List of the cookies that are created by “AD-Pro Authentication”:

The “AD-Pro Authentication” creates session cookies when a user took advantage of SSO or when a user was signed-in manually and “Remember me” was unchecked.

Below is example of the session cookie:

The “AD-Pro Authentication” creates persistent cookies when a was signed-in manually and “Remember me” was checked. In that case cookie can look like this:

If “Remember me” mode is enabled, there is possibility to control the time when the user session will expire. On the figure above user will be signed-off after 30 min of inactivity. The expiration time can be controlled from the web.config file. The module first checks the “PersistentCookieTimeout” variable, if it’s empty or equal to “0”, number of minutes will be taken from variable "timeout" that is in "configuration/location/system.web/authentication/forms" or, if it's also empty, from "configuration/system.web/authentication/forms". If all variables will be also equal to 0, timeout will be set to 30 min.

Photo sync

The “AD-Pro Authentication” module allows to push Active Directory user photo to the DNN user profile. Please make sure that in the “Properties” tab is the following mapping:

More info on the figure below:

DNN user - saving modes

The “AD-Pro Authentication” module allows store DNN users  in multiple modes. This feature can be specified in “Module Options-> Connection String-> Details”. See figures below.

Options to save user in DNN

Username format

Output example [for AD user: Barry, portal id: 2, AD domain: GS]

Default

Username -> Barry

Active Directory user can exit only in one (specified) DNN portal (in one portal across DNN install).  In this situation AD user Barry is able  to login to only one DNN portal (portal id = 2).

Default with Domain

AdDomain\Username -> GS\Barry

Active Directory user can exit only in one (specified) DNN portal (in one portal across DNN install).  In this situation AD user Barry is able  to login to only one DNN portal (portal id = 2).

Portal Suffix

Username_{Portal ID} -> Barry_2

Active Directory user Barry can exist in each portal and it will be separate user instance. In fact every DNN portal contains his own DNN user, that points to one Active Directory user.

Portal Suffix with Domain

AdDomain\Username_{Portal ID} -> GS\Barry_2

Active Directory user Barry can exist in each portal and it will be separate user instance. In fact every DNN portal contains his own DNN user, that points to one Active Directory user.

Cross Portal User

Username -> Barry

Active Directory user can exist in each DNN portal, his username will be the same, with independent user profile. AD user Barry is able to login to any DNN portal. To enable this mode all “AD-Pro Authentication” instances across DNN install, should have “Username format” set to “Cross portal User”. More info about the “Multi User” feature that allows to re-use username, can be found at this location:

http://www.dnnsoftware.com/wiki/page/Users-in-multiple-portals-in-a-single-DNN-Instance

Cross Portal User with Domain

AdDomain\Username -> GS\Barry

Active Directory user can exist in each DNN portal, his username will be the same, with independent user profile. AD user Barry is able to login to any DNN portal.

List of username formats

By default “Multi User” mode is working only for newly created DNN users, that’s because members must have the same password across all DNN portals. This condition is not fulfilled for already existing users that already have “some” password. To enable “Multi User” feature for already created users please execute following SQL query, that will reset password for group of users:

UPDATE aspnet_Membership SET

Password = {New Password},

PasswordSalt = {New Password Salt}

WHERE UserId =  {list of the users to update}

Activating the product

To use “AD-Pro Authentication” you need first activate it. To do that you need a license, there are two kinds of licenses:

When you change the license (from trial to full) you won't lose any of your changes or configuration settings. To activate product you need:

  1. Obtain the unique Install Key from the “AD-Pro Authentication” module.
  2. Obtain the Invoice ID from the DNN Store.
  3. Generate License Key.
  4. Apply License Key in the AD-Pro Authentication module.

Below is a detailed instruction how to do that. First to obtain the license key you need your unique Install Key. To get a Install Key please go to page where “AD-Pro Authentication” is located, go to “Edit mode” and after that go to “Module options” and “License” tab, see images below:

The invoice number string you will get from an email, that you get from DNN Store when you purchase the “AD-Pro Authentication” extension. Now, when you have a Invoice and Install Key, you are ready to acquire the License Key. Go to http://glanton.com/license enter the Invoice ID and Install Key, click “Get License” button. Copy the License Key string and paste it to the “License” tab in “AD-Pro Authentication” module.

That’s all, now you have activated “AD-Pro Authentication” module. See images below:

One license for Dev & Prod

The license key is hardly connected with the machine key that is located in the web.config file that is in the DNN web application. The same license key can be used in multiple DNN, if these DNN web applications are exact copies. In particular the machine key must be the same. Machine key can be found in the following node:

<configuration>

<system.web>

<machineKey validationKey="00D14E46AE5D05C620"  decryptionKey="E4A11872A3925EA" />

</system.web>

</configuration>

The same full (or trial) license key can be used in Production and Development DNN as long as they using the same machine key.

Role Manager

Overview

At the login process Active Directory groups belongs to currently logged in user  are pushed to DNN. To execute that operation “AD-Pro Authentication” based on mapping in “Role Manager”. To display the “Role Manager” please go to “AD-Pro Authentication-> Module options-> Role Manager” tab. The “Role manager” allows to:

Role Manager - configuration

Please remember to click on the “Update role mapping” button to save changes.

To set Active Directory group as a “Authorization Group” go to “AD-Pro Authentication->Module options-> Role Manager” tab and tick selected role in “Authorization Group” column.

To set mapping between AD group and DNN Platform role, that allows to push AD groups to DNN Platform go to “AD-Pro Authentication->Module options-> Role Manager” tab. From the “DNN role mapping” column expand drop down list and tick DNN role(s).

From the figure above we can conclude that:

Note: “DNN role mapping”  a is relation one to many 1:n. For example Active Directory group “Domain Users” can be connected with the DNN Platform role “Registered Users” and “My custom Role”.

When module creating roles in DNN Platform

From the “Role manager” you can create role in “DNN Platform” that’s name is equal to AD group. To do that go to “AD-Pro Authentication->Module options-> Role Manager” tab and click on “Create it” link that is under the AD group name. This link will be only displayed if corresponding DNN Platform role doesn’t exist in current portal.

The “AD-Pro Authentication” module will not create role at the login process. At the login process already existing DNN Platform role can be only assigned to the DNN Platform user.

When module revoking DNN user from a role

The “AD-Pro Authentication” will unassign DNN user from a DNN role at the login process if:

Consider following scenario where we have:

and:

  1. DNN user 'bob" was manually assigned to the DNN role "Role_1".
  2. Corresponding AD user "AD\Bob" doesn't belongs to AD group "Role_1"
  3. In "AD-Pro Authentication" in "Role Manager" following mapping is created: if AD user belongs to AD group "Role_1", add to the corresponding DNN user role "Role_1"
  4. User "AD\Bob" is trying to login to DNN using "AD-Pro Authentication" module.
  5. DNN user "Bob" is removed from DNN role "Role_1", because "Role_1" has a mapping in "Role Manager" and AD user AD\'Bob" doesn't belong to AD group "Role_1".

Single Sign On - Configuration

Overview

The “AD-Pro Authentication v3” module allows you to login to DNN without entering any credentials. Before you start configuring SSO make sure that manual login is working properly. SSO is best suited for an intranet environment for the following reasons[1]:

Integrated Windows authentication includes the Negotiate, Kerberos, and NTLM authentication methods. Negotiate, a wrapper for Kerberos v5 and NTLM, allows the client application to select the most appropriate security support provider for the situation. Kerberos v5 and NTLM have the following restrictions[2]:

NTLM can get past a firewall, but is generally stopped by proxies because NTLM is connection-based, and proxies do not necessarily keep connections established.

Kerberos v5 requires that the client have a direct connection to Active Directory, which is generally not the case in Internet scenarios.

Kerberos v5 requires that both the client and the server have a trusted connection to a Key Distribution Center (KDC) and be Active Directory–compatible.

Kerberos v5 requires SPNs for multiple worker processes. If your Web site uses multiple worker processes, you can use Kerberos authentication, but you must manually register service names.

Integrated Windows authentication has the following limitations:

Integrated Windows authentication is supported by only Internet Explorer 2 and later.

Integrated Windows authentication does not work over HTTP proxy connections.

Therefore, Integrated Windows authentication is best suited for an intranet environment, where both user and Web server computers are in the same domain and where administrators can ensure that every user has Internet Explorer 2 or later.

Requirements

Following conditions must be meet for SSO:

IIS Configuration

The “Authentication” tab in IIS Manager for main web application folder must be configured as described on figure below:

Note: optionally “ASP.NET Impersonation” can be enabled

The configuration for the broker page “DesktopModules\GS_ADProAuthentication\WinAuthSignIn.aspx” is set in web.config file. Following entries in the web.config file are responsible for the broker page.

<location path="DesktopModules/GS_ADProAuthentication/WinAuthSignIn.aspx">

    <!-- Disable Forms Authentication -->

    <formsAuthenticationWrapper enabled="false" />

    <system.webServer>

      <security>

        <!-- Enable IIS Windows authentication for the login page -->

        <authentication>

          <windowsAuthentication enabled="true" />

          <anonymousAuthentication enabled="false" />

        </authentication>

      </security>

    </system.webServer>

 </location>

In result broker page ‘WinAuthSignIn.aspx’ should be configured as on figure below:

File permissions

The currently logged in network Active Directory user must have read write permission to the ‘DNN Platform’ root folder.

Internet Explorer - web browser configuration

To execute SSO your DNN Platform website must be added to the “local intranet” site list. Please follow steps below to do that:

Figure 7 Adding website to local intranet list

Figure 8 Automatic logon

Figure 9 Enable Integrated Windows Authentication

Chrome - web browser configuration

Chrome uses the same intranet settings as IE, so if it's working in IE it should also work in Chrome (without any additional config).

Firefox - web browser configuration

To configure Firefox browser with “Windows Authentication” please follow steps below:

SSO for all DNN pages

The SSO process is initiated in two cases:

By default the DNN “Home” page is visible for all DNN users, including guests. In that case when user first time open DNN home page, the SSO process will be not initiated and user will be not signed-in to DNN.

If you want to be sure that all your network users will be always automatically signed in when they are opening DNN website, you must set correct page permissions for the landing page (DNN Home page). To do that please untick the “All Users” role, and enable “View Page” for “Registered Users”. See figure below. This behavior causing that the SSO process will be automatically executed when you load DNN website.

SSO & anonymous users

If the SSO is properly configured all your Intranet/corporate user can login automatically. Unfortunately Internet users (non Intranet users) will get a popup when they first time go to login page. That issue is caused by the IIS behavior.

Popup displayed in Chrome

Popup displayed in Internet Explorer

When user click on the “cancel” button it can be automatically redirected to the DNN login page, all you need to do is set up a custom error page. Below are the steps:

<httpErrors errorMode="Custom">

<remove statusCode="401" />

<error statusCode="401" path="401.htm" responseMode="File" />

</httpErrors>

Windows authentication fails when using hosts file

By default SSO will not work for sites that are specified in: C:\Windows\System32\drivers\etc\hosts IE will not auto log you into the site, nor will you be able to login by providing the correct credentials. The reason for this is  that in Windows Server 2003 SP1 a new security functionality called “loopback check” was added, this blocks the authentication request and so for your site to work with the new-host name locally you need to disable the loopback check.

To disable loopback check functionality for CNAME = dnn720.com follow steps:

  1. Click Start, click Run, type regedit, and then click OK.
  2. Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
  3. Right-click MSV1_0, point to New, and then click Multi-String Value.
  4. In the Name column, type BackConnectionHostNames, and then press ENTER.
  5. Right-click BackConnectionHostNames, and then click Modify.
  6. In the Value data box, type the dnn720.com.
  7. Exit Registry Editor, and then restart the computer.

Type each host name on a separate line. If the BackConnectionHostNames registry entry exists as a REG_DWORD type, you have to delete the BackConnectionHostNames registry entry.

More info in post: Error message when you try to access a server locally by using its FQDN or its CNAME alias after you install Windows Server 2003 Service Pack 1: "Access denied" or "No network provider accepted the given network path"

SPN & Kerberos

To use SSO which is in fact Kerberos authentication, the following conditions must be met:

To use Kerberos authentication, a service must register its service principal name (SPN) under the account in the Active Directory directory service that the service is running under. The service principal name (SPN) is a multivalue attribute. It is usually built from the DNS name of the host. The SPN is used in the process of mutual authentication between the client and the server hosting a particular service. The client finds a computer account based on the SPN of the service to which it is trying to connect. The SPN can be modified by members of the Domain Admins group. By default, Active Directory registers the network basic input/output system (NetBIOS) computer name. Active Directory also permits the Network Service or the Local System account to use Kerberos.

A SPN is nothing more fancy than an alias (or pointer) for a domain account, e.g. If You have a Windows Server 2012 server called WebServ (with IIS) that is member of the Active Directory domain cloudapp.net On the web server you have DNN application that is using url http://webserv.cloudapp.com below is output of a setspn -l command

HOST/WEBSERV

HOST/webserv.cloudapp.net

More info:

https://blogs.msdn.microsoft.com/autz_auth_stuff/2011/04/28/what-is-a-spn-and-why-should-you-care/

https://msdn.microsoft.com/en-us/library/ms191153.aspx

Migrating from “DNN® Auth: Active Directory” to “AD-Pro Authentication v3”

Overview

The “DNN Auth: Active Directory” is a open source DNN Platform module that authenticate users in DNN Platform portal using Active Directory credentials. The “AD-Pro Authentication v3” offer much more features like: user profile sync, Active Directory groups sync and many more. In this chapter we will describe how to replace the “DNN Auth: Active Directory” with the “AD-Pro Authentication v3”.

Setting correct username format

The “DNN Auth: Active Directory” module usually saves usernames in database (table “Users”) in format “DomainName\Username”. If in your case is the same situation, please make sure that the username format is set to “Default with domain”, it can be done under “AD-Pro Authentication-> Module options-> Connection String-> Username format”. More info in chapter DNN user - saving modes

Adjusting web.config file

Please make sure that following node in web.config file is commented or removed:

<location path="DesktopModules/AuthenticationServices/ActiveDirectory/WindowsSignin.aspx">

<!-- Disable Forms Authentication →

<formsAuthenticationWrapper enabled="false" />

<system.webServer>

<security>

<!-- Enable IIS Windows authentication for the login page →

<authentication>

<windowsAuthentication enabled="true" useKernelMode="false">

        <providers>

                <clear/>

                <add value=”NTLM”/>

        </providers>

</windowsAuthentication>

                           <anonymousAuthentication enabled="false" />

</authentication>

</security>

</system.webServer>

</location>

Troubleshooting

SSO not working

Things to check when Kerberos authentication fails using IIS/IE…

http://blogs.msdn.com/b/friis/archive/2009/12/31/things-to-check-when-kerberos-authentication-fails-using-iis-ie.aspx 

A dependent package is not installed

If you get an error like on the figure below, please make sure that the “Connection Manager” module is already installed.

The user name or password is incorrect

If you get the following warning: “Can’t load Active Directory groups. The user name or password is incorrect”, please go to “Connection Manager” module and change the username or user password.

In some scenarios when you change IP address in LDAP to local IP it can help. For Example change LDAP://104.45.188.138 to LDAP://10.0.0.5

The server is not operational

If you get the message like “Can’t load the Active Directory groups. The server is not operational”.

Diagnostic Mode

The “Diagnostic Mode” displays info about “AD-Pro Authentication” work and helps to diagnose issues that can occur like: failed login process, unable to get AD groups, etc.

To enable “Diagnostic Mode” follow steps below:

<root>

    <level value="ALL" />

    <appender-ref ref="RollingFile" />

</root>

The output logs can be found in folder “Portals\_default\Logs”. Logs file names are in format YYYY.MM.DD.logs.resources.

Below is a simple figure with three steps to enable “Diagnostic Mode”.

dm.png

Java Script errors

The “AD-Pro Authentication” user interface is based on the JavaScript and html templates. If there are any issues it’s worth to check are there any JavaScript errors. Please check following articles that are describing how to display these errors in your browser:

If you have any problems with “AD-Pro Authentication v3” module, please send error messages to support@glanton.com

Edit & Delete buttons doesn’t work

When you can’t update the module settings, and in web browser console you get the message like “Method Not Allowed” or 405 HTTP error code, please make sure that WebDAV is disabled. To disable WebDAV please add following lines to the web.config file:

<modules>

<remove name="WebDAVModule"/> <!-- add this -->

...

</modules>

<handlers> 

<remove name="WebDAV" />

... 

</handlers>

<handlers>

...

<remove name="ExtensionlessUrl-Integrated-4.0" />

  <add name="ExtensionlessUrl-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />

...

</handlers>

You can read more about WebDAV here: http://www.iis.net/learn/get-started/whats-new-in-iis-7/what39s-new-for-webdav-and-iis-7

500.19 Internal server error

If you get HTTP 500.19 error at the login process, like on the figure below. Please make sure that the following commands was executed:

%systemroot%\system32\inetsrv\APPCMD unlock config /section:anonymousAuthentication

%systemroot%\system32\inetsrv\APPCMD unlock config /section:windowsAuthentication

More info in chapter IIS Configuration - SSO config

Error 0x800050000

The error code 0x800050000 usually is displayed when module can’t access to the ADSI provider in IIS. If the permissions matched up, just to be sure force the directory to propagate the permissions to the files again. So even though the permissions appeared correct that was the choke point, resetting those permissions solved the issue.

Reference:

https://blogs.msdn.microsoft.com/jpsanders/2009/05/13/iis-7-adsi-error-system-runtime-interopservices-comexception-0x80005000-unknown-error-0x80005000/

SSO & login screen after user inactivity

In SSO mode, users can get login popup after certain period of inactivity. Usually it’s because cookie is expired. As a workaround please:

<add key="PersistentCookieTimeout" value="7200" />

This setting will set cookie expiration time for 5 days (7200 min.), more info: Authentication ticket management

SSO may not work under the domain name address

If the DNN website address is equal to Active Directory domain for example: http://MyCompany.intranet the SSO may not work. In that case please use IIS server website address for example http://MyCompany.com

I can’t sign in to DNN and AppPool is restarting

There could be an issue where you can’t sign in to DNN using AD user identity. Additionally in DNN logs is message that the Application Pool is resetting, right after unsuccess sign in process. This could be caused by the AD groups that are referenced each other in a loop. For example:

To workaround that make sure that AD groups doesn’t referencing mutually.

Performance

To increase DNN performance, please set “Load user profile” to “true” in application pool advanced settings, see figure below.

Copyright © 2015 Glanton Solutions Limited

www.glanton.com                                                

Copyright © 2015 Glanton Solutions Ltd.                                                 Page  of


[1] https://technet.microsoft.com/en-us/library/cc754628(v=ws.10).aspx

[2] https://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/523ae943-5e6a-4200-9103-9808baa00157.mspx?mfr=true