8. Advanced Settings

Note

In this chapter we described more advanced features of “AD-Pro Authentication” module. It’s not necessary to read this in order to configure simple login scenario, but if your users already can sign in, here you can find info how to adjust or optimize that process.

8.1. Group filter

If your Active Directory system contains lot’s of groups, it’s good to narrow that list. Fewer AD groups are easier to manage and speed up login process, because DNN doesn’t need to iterate through all of them. This setting has impact in ‘Role Manager’ tab, where only groups that pass this filter will be displayed. To add or edit “Group Filter” setting, follow these steps:

1. Click on “Connection String” tab, then on “Details” button, see figure below.

2. At the end of this form is a text box where group filter can be entered, see figure below.

Below are some filter examples:

1. (name=MyGroupPrefix*) will takes only groups that starts with MyGroupPrefix.
2. (!name=NotNecessaryGroups*) will takes all AD groups except groups that names starts with NotNecessaryGroups.
3. (|(name=Domain*)(name=Alpha*)) will takes all AD groups that names starts with Domain or Alpha.
4. Empty text box, means no grup filter, in this case all groups will be taken.

8.2. LDAP filters

Note

LDAP syntax filters are used to query Active Directory users or groups.

A filter specifies the conditions that must be met for a record to be included in the recordset (or collection) that results from a query. To implement AND operator please use &. This snippet will take groups that names start with ‘T’ and ends on ‘Z’:

(&(name=T*)(name=*Z))

To implement OR operator please use |. This snippet will take groups that names start with ‘Type1’ or ‘Type2’:

(|(name=Type2*)(name=Type1*))

More info: https://social.technet.microsoft.com/wiki/contents/articles/5392.active-directory-ldap-syntax-filters.aspx

8.3. Authentication ticket management

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:

• session cookie, that is saved in the browser session and deleted when user close the browser. When the browser is restarted the DNN website will not recognize you because cookie and authentication ticket (that is inside it) doesn’t exist. User will have to log back in (if login is required). After that, a new session cookie will be created (with new authentication ticket inside it) and will be active until user leave the site or close the browser;
• persistent cookie, it’s a file that is saved on the user hard disk. It can be deleted manually or browser deletes it based on the duration period contained in the persistent cookie’s file. In that mode user can be signed-in across browser sessions, after browser is reopened, even after one day of inactivity.

Cookie names that are created by “AD-Pro Authentication” are:

• IsWinAuthUser, if value is True currently sign-in user is a SSO user, if value is False currently logged in user was sign-in manually; if cookie doesn’t exist or cookie value is empty, user is not signed-in (or signed-in incorrectly);
• authentication, the cookie value can be equal to string AD-Pro. If cookie doesn’t exist or cookie value is empty, user is not signed-in (or signed-in incorrectly);

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 user 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.

You can help your users to decide where authentication ticket should be saved. Uder the ‘Module Options’ panel there is setting ‘Remember Me’ and if it is on, it does two things:

• the checkbox labeled ‘Remember Login’ that is on the login with two text boxes is by default enabled. User can still uncheck it to save cookie in the session.

  

• for Single Sign On scenario authentication ticket will be saved under persistent cookie. The end user can’t change that.

8.4. Username formats

Note

It’s very important to get familiar with this section, if you are using more that one DNN portal, or more than one Active Directory domain.

The “AD-Pro Authentication” module allows store DNN users in multiple modes. This options can allow to save one AD user in multiple DNN portals, where he can have separate profile. Please remember that in DNN database, in table Users, column username needs to be unique. Username format feature can be specified in “Module Options-> Connection String-> Details”. See figures below.

Possible formats how the DNN username can be saved in database. Example for AD user called Barry, AD domain GS, and DNN portal id 2

Username Format	Output example
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	AdDomainUsername_{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	AdDomainUsername -> 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.

By default “Multi User” mode is working only for newly created DNN users (it’s a DNN limitation), 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}

8.5. FIPS compliant encryption

The Federal Information Processing Standard (FIPS) needs to be enabled in order to save plugin settings. In particular to save encrypted passwords in database. See here for reference.

8.6. DNN iterface - remove ‘Password change’ section

When DNN membership relies on external user data store it could be good reason to suppress password change from DNN level. Below are steps that will remove ‘Password Change’ section from DNN user interface.

1. The page from above screen is rendered from following file: ~\DesktopModules\Admin\Security\EditUser.ascx that we will edit.

2. Around line #140 are following lines that needs to be commented:

   <h2 id="H1" class="dnnFormSectionHead"><a href=""><%=LocalizeString("PasswordSettings")%></a></h2>
   <fieldset>
       <div class="dnnPasswordDetails dnnClear">
           <dnn:Password id="ctlPassword" runat="server"></dnn:Password>
       </div>
   </fieldset>
   

3. Close the editor and reload the DNN website. Now the “Change Password” section shouldn’t be visible, see figure below:

   

8.7. Email white list

You can additionally secure whole authentication process by specifing list of the email domains. Only emails from that list will be validated in the Active Directory. Option is disabled if there are no email domains, in other words list is empty. Each domain should be separated by the semicolon ;.

Simple use case: Let’s say your corp (using the Active Directory system) supports following email domains:

• mycorp.com
• partner1.com

By default users are able to sign in to the DNN by entering their corporate emails (and passwords) in the login box. But if you want restrict DNN login only for a users from domain mycorp.com, enter that domain in the text box field from the figure below. If you need to add more than one separate them like this: mycorp.com;partner1.com.