How to Use Profiles With GCDS

Most of the topics that I choose for blog posts come from direct real-world questions or issues that come from customers. This is one of those. 

For the most part, I have very few customers using profiles, but there are some benefits from using them that you might like. This is more easily leveraged when you have an automated system keeping your local directory up to date with information from your Student Information System, but that isn’t  a requirement.

How to Use Profiles With GCDS

Profiles can be beneficial, but as one customer learned, they can make it easier for students to be more mischievous with each other. This is especially true if you use the StudentID as all or part of the password for student accounts. This is a simple and easy choice, but it doesn’t take other students long to figure out each other’s passwords. It is even easier when you put the information right in their hands. I’ll show you how to avoid this situation completely.

If you open up your GCDS configuration xml file with Configuration Manager, you have the option under General Settings to check “User Profiles”. When you do this, it opens another tab to configure what to do with “User Profiles”.

Once these settings have been enabled, there are a few more steps to configure them properly. Our starting point is to select “User Profiles” and select “Use Defaults” to populate the default values on the “User Profile Attributes” tab. This will use the defaults for Active Directory. If you are using eDirectory or some other LDAP directory, these values will be different. This allows you to map the most common fields that appear in your MMC console to corresponding values in the Google user profile. The first page is fine with all default settings:

It is the second page that can present an issue. Student Provisioning Services uses the employeeID attribute in Active Directory to store the studentID field. We use this as an index so that we can always search and find a student and be sure that it is the right student. This allows us to do things like rename an account if a child was adopted and their last name changed. We must allow for this and can’t rely on username or email address to be correct. We want to be able to change the email address and username if it should change based on the districts naming standard.

We have a number of districts that either use the studentID as the initial password when a new student account is created or they use it as part of the password. It is because of this, that we don’t want to make this readily available to other students.

If we click on “Use Defaults” and don’t change anything, we will make this information very easily visible to all students in G-Suite. There are several ways to address this:

• We can remove the employeeID value from this attribute mapping so that it won’t populate it with anything in Google.
• We can map this to another attribute that isn’t really the employeeID and allow that value to appear here.
• We can pick a dummy attribute and populate it with the string “Confidential” and then put this attribute in this mapping, so that the word “Confidential” will show when any student goes looking for this value in G-Suite.

There is one last thing to configure and then we will be able to sync this to Google and populate G-Suite with our additional information. The “User Profiles” section also contains a “Search Rules” tab. This allows us to define an LDAP query that will control which users will have their user profile updated. Any valid LDAP query is possible here. Please note that this can only be done for accounts that are enabled, or only accounts with an email address of a particular domain name (if staff and students use a different email domain or students are a sub-domain). Mine is the same as the search rule that I use under “User Accounts”/”Search Rules”. It would look something like this:

(&(objectClass=user)(mail=*)(|(userAccountControl=512)(userAccountControl=544)(userAccountControl=66048)(userAccountControl=66080)))

You can use any LDAP query that properly selects the users where you want to have these attributes populated.

I chose to map the employeeID to a field where I had the building name, so the results look like this:

We hope you find this blogpost useful. You may want to check out our blog post: Tips and Tricks to using GAM to Manage Student G-Suite Accounts

Would you like to automate provisioning for your district?