AD links

Configuration

The AD links page is provided to allow the configuration of Insight to work with your Active Directory.

For student accounts, you can use existing Active Directory principals and create Insight accounts for them on first use. The uniquely identifying field by default is the EmployeeID field, but as an alternative you can user the Pager field, if for example the EmployeeID is already used, or it is not practical to make it visible.

For students the contents of this field can be either the SIMS database id, their Admission Number or their UPN. For parents and staff, Insight accounts must be created beforehand, and the uniquely identifying field must be populated with the SIMS database id.

Additionally, Active Directory Security groups should be created for the purpose of allowing and denying access to Insight.

You will need to have licensed the AD Links option to access the page. You can check for this in Reports –Licences, and re-license from here if necessary.

The AD Links menu allows you to configure the link to your Active Directory database, by providing details of your domain and an account which can read it. The most difficult part of configuring this is in getting the format of the options correct. Firstly, make sure the Check in AD when logging in is turned ON! The domain field should be in the form

   mydomain.local

The User Container should be in the form

   CN=Users,DC=mydomain,DC=local

The Domain reading user should be in the form

   mydomain\user

The ...require membership of this Security Group should be the name of the Security Group alone and is sensitive to capitals. If you want to allow a selection of different Security Groups (year based perhaps) separate them with ; (semi-colon) characters.

If all Students are to have identical Roles in Insight, enter the name. The alternative is to use * (asterix) to tell Insight to use the first matching Security Group name from the list that the user belongs to is to be used as the Insight Role

The default behavior of Insight is to use built in methods for obtaining a set of EmployeeID:Security Group records separated by the | (bar) character, but you can implement your own variation by providing an Override web service URL which can use the wildcards {username}, {domain} and {schoolno} in the overall URL. An example URL might look like this: https://internalservices/ADLookup.php?accountname={username}&domainname={domain} The page should return plain text and list the contents of the EmployeeID field (or other lookup value) and relevant Security Group (or other control setting).

If you want to allow staff to use Active Directory based login you will need to turn the Allow staff role users to use delegated login on.

For student users, you will have to tell Insight if the EmployeeID field represents something different than the SIMS database id, either Admission Number or UPN.

If you intend or need to use a different AD Field than EmployeeID, for example the 'Pager' field or 'extensionAttribute4' in place of the, turn the USe alternative AD field in place of EmployeeID' switch, and enter the name of the alternate field.

Insight can also check the given name and last name AD fields against the associated SIMS record to check that the AD record correctly links to the SIMS record - turn on the Check AD names against student names when logging in to perform this check.

Important

After updating the AD links details you will also need to set

  Manage – Preferences – Login – Trust this host as an authentication provider 

to the short name of your domain.

Troubleshooting If you have problems implementing single sign on using Active Directory, temporarily switch on the Embed login trace in page (for testing only) option on the AD Links page. This will do two things – if you view the main login page with a developer tool, you can read debugging information out of the hidden input field with the id delegateresult which can help highlight any issued, and also a file “securewin.log” is written to the (normally) %windir%\TEMP\Insight folder with detailed information about the process. Don’t forget to switch off this option when it is no longer needed.

Seamless login

An additional benefit of using this method to log in is that it supports Integrated Windows Authentication in supported browsers. This means that if the user is logged onto a computer within the domain, their account information can be used to log seamlessly into Insight, without requesting them to enter their account details by hand. To enable this, all of the previous settings must be working correctly.

Where the web domain is the same as the network domain, or you are using an application gateway, you can use either of the methods below. Otherwise you should use only the first.

Method 1

The simplest way to implement seamless login is to direct those users who you expect to be able to login to the ADSSO.aspx page initially. If the user is not already logged into the domain, they will be redirected the the normal login page, where they can still enter their Active Directory username and password. Otherwise, depending on their Security Group membership, they will be passed straight through to Insight. If you do not expect a user to be able to log in this way, they should be directed to the normal login URL.

Method 2

To implement this method, all users are directed to the normal Secure.aspx , you will need to "protect" the SecureWin.ASPX web page with Windows Authentication, whilst denying Anonymous Access. The way to do this is by running the ServiceController program located within the INSIGHT folder of your main shared SIMS folder, and on the Application tab, check the option HTTP401 on SecureWin.

With this enabled, an out-of-band request is made by the main login page to this SecureWin page. This page reacts in the following way:

• If Anonymous Access is enabled, the page returns emptiness, and the normal login screen is displayed.
• If Windows Authentication is enabled instead, a domain credential is sent, checked and an encrypted user credential is returned back to the main login screen, which is automatically submitted, and the login proceeds normally.

The problem with enabling this on its own is that outside the domain, or where Integrated Windows Authentication cannot take place, a HTTP 401 challenge is returned, and a browse specific pop-up is shown, requesting domain based login details. To hide this you will need to make a change to the web.config file, changing the Expect_Authentication_Header_In_First_Request_To_SecureWin value to Yes. This setting will spot that a HTTP 401 status is being returned specifically for SecureWin, and blur this into a HTTP 403 status, which will not provoke the browser popup, but will be enough to show the normal login screen.