Logging on to ADAM

A number of common login settings can be found in the Site Settings. Navigate to the “Security” tab.

Active Directory Authentication

If your school has an Active Directory server, you can capture its details here. The LDAP module may need to be installed before this will work.

If ADAM will communicate via the public internet with your AD server, you must use a Secure LDAP Connection to prevent your users’ login credentials from being visible.

This can allow your users to authenticate to ADAM if they are signed in with their school-issued Google account. Please contact help@adam.co.za before you enable this setting.

Internal Password Administration

Here you can set the minimum password length required. Note that passwords shorter than 8 characters are not permitted.

The “Allow External Authentication Failover” feature allows users who would normally log into ADAM by authenticating against their Active Directory Server to still log in, even if their Active Directory Server is not available. Note the following:

The failover service works by storing an AD-validated encrypted hash of the user’s password as if it were an internally managed password. On future login attempts if the AD server is not available, ADAM will check the supplied password against the stored hash.

This is no less safe than having ADAM manage user passwords itself. On a successful login, ADAM will verify the users password against the hash stored in the database and, if necessary, update the password with a new hash.

This is not password synchronisation, rather password caching. ADAM can only remember passwords it has seen itself and which the AD server has verified as being correct. ADAM cannot “fetch” passwords from AD.

Users who have never logged into ADAM before will not be able to login during an AD outage for the first time.
Users who logged into ADAM a log time ago and who have subsequently changed their password will still have their old passwords cached on ADAM and thus may need to use an old password to get into ADAM if logging in during an AD outage.
Take note here of “remember me” type logins which do not require a user to enter their password. Should a user need to login with a password, they may find that they have to enter their previous password which might have changed some time ago.

If Active Directory blocks a user’s login attempt for any reason (e.g. account disabled, incorrect password used), ADAM erases the password hash stored.

This prevents the user from being able to log in later when the AD server is unreachable and is therefore unable to deny the login.
Such a user will not be able to login until the connection to AD is restored.

While ADAM is not able to communication with the AD server, user accounts that may be disabled on AD but which have not attempted a login on ADAM since they were disabled, will still be allowed to log into ADAM during an outage.

It is important that user accounts in ADAM are also suspended and that AD is not relied upon.

LDAP Authentication

In Linux based networks it is possible to have ADAM use a pure LDAP server for authentication. Note that while the Active Directory logins are conducted over LDAP, many of the settings for the AD LDAP implementation have been preconfigured.

The Login time out is the amount of time in minutes that must elapse between any two page loads on ADAM before the user account is considered logged out. Note that typing a message (especially in the Messaging Centre) is not considered activity because there is no information going between the server and the client computer.

The setting for Remember logged-in machines will set a long-term cookie on a computer which ADAM will then use to determine whether a user has logged in from that machine or not. If no user logs in on that machine within that length of time, ADAM will “forget” the machine and the user will consider to be logged in from a new machine. This has implications for Two-Factor Authentication settings (see below!)

Some schools may chose to Allow “Remember Me” Logins. This will prevent the login time-out from affecting the user. Schools should be cautioned against allowing this if the computers that staff use are often left unsupervised and unlocked (consider a desktop computer in a classroom which may have pupils in unsupervised, as opposed to a laptop which is more likely to be turned off and locked). The number of days that ADAM can remember a user for can be set with the Remember Me Duration setting.

The Two Factor Authentication Window allows users a more gracious sliding window with which to use their one-time PINs. Each window is 30s and is defined by the current time of day as determined by the server. OTPs require the time windows to align on the server and client devices. This can cause issues where users are using devices that may not be synchronised accurately to network time, or, indeed, the server is not accurately synchronized.

When the setting is set to 1, for example, ADAM will check both the current window as well as the 1 window before and 1 window after to check if the OTP supplied would be valid in any of them. This allows for approximately 30 seconds leeway in terms of time slippage. A window setting of 3 would allow 90 seconds of time slippage.

Where device and server times are accurate, a setting more than 2 is discouraged.

ADAM can enforce a number of different Two Facor Authentication Method policies. Administrators can require OTPs from users at each login, once per computer per day or, the most lenient, once per computer. Where staff make use of shared computers without unique user accounts, the “once per computer” option is strongly discouraged.

Finally, ADAM can ensure that all staff make use of Two Factor Authentication by setting the Two Factor Authentication Forced for Staff setting to “Yes”. When staff login for the first time not having previously set up their two factor authentication, ADAM will prompt them to do so and not permit them to proceed with their logins until they have correctly setup their authentication app to generate one time PINs.

POP3 Authentication

ADAM can use a POP3 server as an external authentication source. Provide the necessary settings here to communicate with your POP3 server. This method is not commonly used because generally schools will have another more commonly used authentication source available to them.

Staff Logins

Staff logins are governed by a number of different settings in ADAM.

Site Settings

Within the Site Settings, navigate to the “Security” tab. Here, a number of settings will affect staff logins.

Pupil Logins

ADAM Administrators may also want to see Understanding Pupil Login.

Enabling and Disabling Pupil Logins

Pupil logins can be disabled from within the Site Settings. On the Security tab under the heading “Pupil and Family Login”, change the setting “Allow pupil logins” to “No”.

Default Settings

Within the Site Settings, navigate to the “Security” tab. Under the heading “Pupil and Family Login”, ADAM has two settings which dictate the default login options for pupils.

The “Default Login Method” and “Default pupil & family login privileges” settings are automatically applied to any pupils when they are first added to the database. Note that changing these settings will not change any pupils’ login details: they are only used at the moment that the pupil is added to the database for the first time.

Parent Logins

Parents may wish to refer to the section on Logging on to ADAM: A Guide for Parents.

ADAM Administrators may also want to see Understanding Parent Logins.

Parent logins can be disabled from within the Site Settings. On the Security tab under the heading “Pupil and Family Login”, change the setting “Allow family logins” to “No”.

Trouble Shooting Logins

The most likely reason is that ADAM is implementing a login delay which is based on a sudden influx of failed logins.

If ADAM detects a large number of failed login attempts, it begins to implement a delay before it attempts the login. This is done in an attempt to thwart anyone who may be trying to try lots of different passwords in very quick succession using automated tools. This is a technique commonly employed by hackers.

This login delay will resolve over time, assuming that the failed login attempts stop.

ADAM administrators should check the logs for information related to these possible login failures.

A second reason, specifically for schools who use remote authentication mechanisms is that the communication between the ADAM server and the authentication server is being delayed. This could be because of network congestion or a performance issue with the authentication server.