It has been a while since I have written a quick “how to”. There have been a lot of changes at Student Provisioning Services, but they have all been good and positive. Look for a press release in January with more specific details.
Updated January 15, 2020
Generally, the school year is slowing down and everyone is getting ready for a break around the holidays. That doesn’t mean the tech department won’t be working, there just won’t be students and quite as many staff around. I have been pushing all kinds of things to get done over winter break, but Microsoft and Google made some changes that have adjusted my priorities a bit. You may have to consider how these changes impact you and do the same thing.
The first is that Google starting down the path to require OAuth instead of usernames and passwords for “less secure apps”. Here is the link from the G-Suite development team for more detail:
https://gsuiteupdates.googleblog.com/2019/12/less-secure-apps-oauth-google-username-password-incorrect.html
Our standard when we setup GCDS for a customer is to use OAuth, so the first part won’t impact any customers, but farther down the road, this may have an impact on the ability to use a Gmail account to send email alerts from within GCDS to technology staff. This function requires the account that is sending to enable “allow less secure apps” for it to work properly.
This appears that it will impact the ability for copiers and other network devices that use the scan to email function to email scanned images to staff via a Gmail service account.
The second change comes from Microsoft because of a security advisory related to LDAP. First, here are the links:
ADV190023 | Microsoft Guidance for Enabling LDAP Channel Binding and LDAP Signing
2020 LDAP channel binding and LDAP signing requirement for Windows
The impact will be for any application that is using unsecure LDAP. I know that many, maybe all things should be encrypted, but some applications make this more difficult than others. GCDS is one of them because it uses its own Java certificate store for certificates instead of using the servers actual certificate store. Historically, if GCDS was running on a domain controller, the traffic never passed onto “the wire”, so it wasn’t necessary to go through the extra hassle to configure LDAPS. Now, you must do it before this patch is rolled out from Microsoft. Although the process isn’t intuitive, it isn’t terribly difficult.
I am assuming that you have already configured Secure LDAP on your Domain Controller. In order to do that, you most likely created a self-sign certificate for your DC and then imported into the local certificate store for the Active Directory Domain Services service and the local computer “Trusted Root Certification Authorities”.
Click here to view the full instructions on how to manage the changes.
You may also find this article helpful if your district is a G-Suite user: How to Use Profiles With GCDS
Would you like to automate provisioning for your district?