General information and troubleshooting
Note: Network Provisioning can provision users from one or more RM Unify establishments to a single or shared network. Please contact your Sales representative to find out how we provision multiple RM Unify establishments to a shared network.
Note: For CC4 customers, this is supported on CC4.5 (i.e., where your CC4 First server is 2012R2) and above networks.
What user roles are provisioned to the AD? All users with the Student, Teaching Staff and Non Teaching Staff role, regardless of where these users came from - MIS, CSV, or manual web form. No other user roles will be provisioned.
Are disabled RM Unify users provisioned to AD? Yes, when the Network Agent receives a message from a disabled RM Unify user the AD account is created or updated as usual. Additionally, the AD account will be disabled.
How quickly are changes in RM Unify reflected in my AD? Changes will be synchronised in less than five minutes under normal conditions.
How quickly are password changes in AD reflected in RM Unify? The new password will be synchronised in less than five minutes under normal conditions, as long as the password meets the RM Unify password policy.
See FAQ below for information about the RM Unify password policy.
Does device single sign-on (SSO) work with Network Provisioning? Yes. See TEC4668878 (in the Other Useful Articles section below) for information about device SSO.
What AD attributes are written to? The following table defines how the user attributes are written in AD.
RM Unify Attribute |
AD Attribute |
CC4 User Property |
IdentityGuid |
rmCom-ImmutableIdentityGuid |
Learner Number |
OrganisationGuid |
rmCom-OrganisationGuid |
n/a |
n/a |
rmCom-ManagementInfo |
n/a |
MISId |
rmCom-MisId |
n/a |
Role |
defines location in AD |
defines user type |
UserName |
sAMAccountName |
Username |
cn/Name - Written to on user account creation or rename
In a brownfield scenario where the Agent is matching an RM Unify account to a pre-existing AD account for the first time, the Agent will not update the existing cn/Name attribute values with the RM Unify username. They remain unchanged until the RM Unify user is renamed.
sAMAccountName and UserPrincipalName must be the same and cannot be different values |
FirstName |
givenName |
First Name |
LastName |
sn |
Last Name |
DisplayName |
displayName |
Display Name |
YearOfEntry |
optional |
Year of Entry (Student only) |
UniquePupilNumber |
optional |
UPN (Student only) |
TeacherId |
optional |
Staff ID (Teaching Staff only) |
Deleted Date |
customised (with Network Agent v2) |
n/a |
n/a |
description (optional) |
n/a |
Can the Network Agent populate a user's AD account with their RM Unify email address? No, this is currently not possible but is on our roadmap as a possible future development. If you are interested in this feature, please let us know by submitting feedback via the Ideas link in the Help section of the RM Unify Management Console.
Will the Network Agent move AD user accounts to a different location in the AD? No, the Network Agent can link an RM Unify user to an AD user account but it is not configured to move the AD user account to different location. For example, if the Network Agent links an RM Unify user to an AD user account in OU="Entry2022" and you later move the user to an OU="Entry 2021", the AD user account will remain in OU="Entry 2022", the Network Agent will not move the account back.
Will changing the RM Unify role change the user's role in AD? In CC4, no, there is no change to the user at all. The network administrator will need to change the user's role-based settings manually, including moving the user and updating their description, home and profile folder locations. On a vanilla network, the user's location is not changed but their description and group membership may change depending on the current configuration. The table below summarises some common task outcomes.
Update to RM Unify user |
Outcome on managed non-CC4 AD user |
Outcome on managed CC4 AD user |
|
Attributes modified, e.g. first/last name |
- user updated.
- description updated to current RMUNP configuration file settings, if configured.
- user location (OU/home/profile folder) will not be changed.
|
- user updated.
- user location (OU/home/profile folder) will not be changed.
|
|
Username change |
- user renamed.
- description updated to current RMUNP configuration file settings, if configured.
- user OU location will not be changed.
- where the user's current homedirectory/profilepath AD attributes contain the existing username, a new home/profile folder and share is created in the same path using the new username, contents are copied from the original location and the original location is deleted. Otherwise, they will not be changed.
|
- user renamed.
- user OU location will not be changed.
- a new user home/profile folder and share is created in the same path, contents copied from the original location and the original location is deleted.
|
|
Role changed from Teaching Staff to 'Non-Teaching Staff' |
- description updated to current RMUNP configuration file settings, if configured.
- added to role-based AD groups, if configured.
- user is not removed from existing role-based AD groups.
- user location (OU/home/profile folder) will not be changed.
|
|
|
User disabled |
- user disabled.
- description updated to current RMUNP configuration file settings, if configured.
|
|
|
User deleted |
- user disabled.
- with Network Agent v2, specified AD attribute updated with the deleted information, as per RMUNP configuration file settings.
|
|
|
'Year of Entry' change |
- added to AD groups that include YearofEntry in the group name, if configured.
- description updated to current RMUNP configuration file settings, if configured.
- user is not removed from existing AD groups.
- user location (OU/home/profile folder) will not be changed.
|
- user's 'Year of Entry' value updated in CC4.
- user location (OU/home/profile folder) will not be changed.
- user's group membership will not be changed.
|
|
Local updates to managed AD user |
|
|
|
User disabled in AD |
If the RM Unify user is enabled and the AD user is then disabled locally, it will only be automatically re-enabled if the RM Unify user is disabled and then enabled. |
|
User enabled in AD |
If the RM Unify account is disabled and the AD user is then enabled locally, it will be automatically disabled if any changes are made to the RM Unify user. |
|
How are communications between the Network Agent and RM Unify cloud secured? Every Network Agent MSI that is generated contains a complex, secret API key, which is unique for every deployment of Network Agent. Whenever the Network Agent communicates with RM Unify it provides the API key to identify itself. As all of this communication takes place over a TLS encrypted channel, this provides a secure basis for data transfer between the two parties.
How are passwords secured? Passwords flow in two directions - cloud to network and network to cloud. In both cases we use public key cryptography; the same approach used to secure HTTPS Internet traffic.
- Cloud to network: On the first run, the Network Agent generates a new C2N public-private key pair and securely transmits the public key to RM Unify cloud. The private key stays secure on your server, which makes it the only place that passwords can be decrypted, which is essential if they are to be written into AD. From this point on, all password changes that occur in RM Unify cloud, either new users or password changes, are immediately encrypted using the specific Network Agent public key. These are stored in RM Unify and forwarded to the appropriate Network Agent.
- Network to cloud: On the first run, the Network Agent retrieves a N2C password encryption public key from the RM Unify cloud. This public key is then distributed to the Password Filter component(s). When a password change occurs in AD, this is encrypted using the N2C password encryption public key and the resultant encrypted password sent up to RM Unify.
Once I have my AD synchronised from RM Unify, do all users have to exist in both systems? Once Network Agent is installed, you can control which users you wish to be present only in AD, or only in RM Unify.
Most schools will be using MIS Sync, which automatically creates users in RM Unify once they are added to the MIS.
Person in MIS? |
RM Unify user required? |
AD user required? |
Steps to achieve this |
Yes |
Yes |
Yes |
This is the normal case. A user added to the MIS gets a corresponding RM Unify account, and this is synced to AD.
Direction: Add the user to the MIS.
Example: All student and staff users. |
Yes |
Yes |
No |
Direction: Disable AD user or add username to the blacklist.
If the AD account is disabled, they will only be automatically re-enabled if the RM Unify account is Disabled and then Enabled. See TEC6933539 for information on blacklisting.
Example: Student or staff user who should not have any access to local resources. |
Yes |
No |
Yes |
Direction: Disable RM Unify account, manually enable AD account. AD/CC4 account will be automatically disabled if any change is made to their (disabled) RM Unify account.
Example: Student or staff user who should not have any access to cloud services. |
Yes |
No |
No |
Direction: Mark student/staff record as leaver in MIS if appropriate, or Disable the RM Unify account, which will disable the corresponding AD account.
Example: Erroneous, test, or temporary records in MIS. |
No |
Yes |
Yes |
Direction: Create account in RM Unify.
Example: Staff user who will not be added to MIS, or school governor. |
No |
Yes |
No |
Direction: (1) Create an account in RM Unify with a role of Other or Governor, as these do not get provisioned to AD, or (2) Create account in RM Unify, then disable the AD account. Note: AD account will be automatically re-enabled only if the RM Unify account is Disabled and then Enabled.
Example: Visitor requires access to cloud services only. |
No |
No |
Yes |
Direction: Create account locally in AD.
Example: Local users, service accounts. |
When new users are automatically created in AD, where do I get the initial password from? There are three options, depending on the current status of the RM Unify user:
Login status of RM Unify user |
Action |
New users joining your school, getting a new RM Unify account and who have never signed into RM Unify |
We recommend you use the RM Unify Management Console. Your new users will appear on the Download Passwords page and from there you can download the initial credentials for all users newly created from the MIS sync. https://www.rmunify.com/ManagementConsole/DownloadPasswords
These initial passwords will follow the format: <capital letter><3x lower case letters><4x numbers>. |
New and existing RM Unify users who have never signed into RM Unify |
Monitor the New Students (etc.) folder/OU in AD to identify any new accounts as they arrive. From there you can reset AD passwords and communicate them to the users. This new password will sync and apply to the RM Unify account and, for new users, they will be removed from the aforementioned Download Passwords page. |
Existing RM Unify users who have signed into RM Unify before |
Ask the users to sign into RM Unify via a browser. After signing in, their (hashed) RM Unify password will be synced to the network and applied to their AD account. |
When an RM Unify account is linked to an existing AD account for the first time, will the user's existing AD password be overwritten? When the user is first linked, the RM Unify password is not synced to AD; you can control how the RM Unify password and AD password become in sync. Choose from one of the applicable options in the table above e.g. download password from the Download Passwords page to apply the new RM Unify password to the existing AD account, reset the user's AD password to apply the new AD password to the RM Unify account, ask the user to sign into RM Unify via a browser using their existing RM Unify password in order to apply their existing RM Unify password to the AD account.
What if the password set for a user in RM Unify is not complex enough to meet my AD password policy? It will fail to be written into AD and the password will be out of sync between the school network and the cloud.
If this occurs when a new password is set for an existing RM Unify user, then the failure will be clearly visible from the User Audit page in the RM Unify Management Console.
If a weak password is specified when creating a new RM Unify user (in the RM Unify Management Console or via CSV import), then there will be no indication of the failure.
You can set your own school specific password complexity thresholds in RM Unify. This will reduce the likelihood of any passwords being accepted into RM Unify that will be rejected by your AD policy. See more details on this and the default RM Unify password policies in TEC5943089 in the Other Useful Articles section below.
What if the password set for a user in AD is not complex enough to meet the RM Unify password policy? It will fail to be synced to RM Unify and so passwords will be out of sync between the network and the cloud. This issue will be listed in the User Audit page in the RM Unify Management Console. We suggest that you periodically check the User Audit page for password sync failures and educate users as appropriate.
The current RM Unify password policies are detailed in TEC5943089 in the Other Useful Articles section below and uses heuristics rather than composition rules to determine how strong a user's password is. Therefore, the RM Unify password policy cannot be represented with AD password policy rules, but we do suggest that you set password policies in your AD for students and staff, to increase the chance of passwords being accepted by the RM Unify policy, e.g. a minimum of four characters for students and a minimum of six characters for staff. You can get a feel for the RM Unify password policy by signing into RM Unify, visiting the Change Password page (https://sts.platform.rmunify.com/Account/ChangePassword) and entering a 'New password'.
You may also wish to encourage users to change their passwords in RM Unify rather than on the local school network. |