Active Directory Support FAQs
Already in your school there will be an Active Directory domain that contains both the usernames and passwords that your staff use to log into their laptops and/or workstations. What we are doing here is allowing users to log into their Emerge app using that same username and password so that it’s easier to manage users.
Currently when a user is to be added to Emerge the school administrator (or hosted administrator) must open the Emerge Management Console and create a new user manually. The same applies for forgotten passwords; the administrator must open the Emerge Management Console and reset it.
With Active Directory integration the creation of users in Emerge Management Console is automatic and invisible. The school administrator works with Groupcall to set a configuration to help Emerge work out whether a user trying to log in is staff or a student – the latter can’t come in – and whether that staff is SLT or Teaching, which then controls which profile they see.
Teachers then don’t need to remember an extra username and password for their Emerge app and can use the same username and password as any other school device, via the Active Directory.
When using Active Directory, how do you choose which staff can log in and what they can see, and keep students out?
Active Directory keeps its users in folders, like files, which it calls Organisational Units (OUs). Users in Active Directory can also be members of Active Directory Groups. Emerge detects whether a username is an SLT or a teacher by being told what OU an SLT or teacher user is in, and/or which group. If a user logs in from the Emerge app and they meet the rules for SLT then they get that permission; if not then we test to see if they meet the teacher rules; and if not then they get refused login because we don’t know what type of user they are.
Emerge with Active Directory support is an inclusive feature at no extra charge. Please note that your Emerge for Schools licensing still remains as previously with a license required per enabled user unless you have a site license.
We recommend using Active Directory Groups to manage which staff in your school are permitted for Emerge access in order to keep below your licensed limit.
Emerge will only check your Active Directory once a day (first time the user logs in that day) in order to prevent overloading your Active Directory.
If you disable an Active Directory user or if you change their group, e.g so that a teacher becomes an SLT, then this will apply the next morning. You can still open the Emerge Management Console in the meantime where matching usernames will be available for you to manage and alter as you need.
How do I tell Emerge the Staff Code of a teacher so they can see their groups when using Active Directory login?
Emerge will try to work this out for itself by matching the teacher name to your MIS, but if you want to specify the exact value then you can tell the Emerge Server to read a specific Active Directory attribute that contains the staff code already.
If we can’t determine a staff code (for example if there are two staff with similar names) then we mark them as 'Supply' so they don’t see their own groups. You’ll need to either use the Active Directory attribute method above, or edit the user in the Emerge Management Console to correct this.
Yes our Active Directory support allows you to have this mixed model, it’s not an all-or-nothing switch.
With Active Directory support enabled any user that tries to log into Emerge and is not listed in the Emerge Management Console, or who is listed but has an incorrect password, will be tested against your Active Directory too. This means that you can run a mixture of Active Directory and Emerge users, and it also provides a migration method if your Emerge usernames happen to match your Active Directory usernames (which quite often we find they do!)