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.
_images/advanced-settings_1.png
  1. At the end of this form is a text box where group filter can be entered, see figure below.
_images/advanced-settings_02.png

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.

_images/advanced-settings_auth-ticket_01.png

Below is example of the session cookie:

_images/advanced-settings_auth-ticket_02.png

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:

_images/advanced-settings_auth-ticket_03.png

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.

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.

_images/advanced-settings_username-format_01.png _images/advanced-settings_username-format_02.png


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}