[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

Update 
September 29, 2023: We're ready to move forward with this change — please refer to this announcement for the latest timeline and information.

March 30, 2020: We have suspended the turn-off detailed here until further notice. We'll announce new timelines on the G Suite Updates blog at a later date. For more details, see this post.
What’s changing Starting in June 2020, we’ll limit the ability for less secure apps (LSAs) to access G Suite account data. LSAs are non-Google apps that can access your Google account with only a username and password. They make your account more vulnerable to hijacking attempts. Instead of LSAs, you can use apps that support OAuth—a modern and secure access method.

This is most likely to impact users of legacy email, calendar, and contacts apps—see below for more details. We’ve also emailed your organization’s primary admin with details around this change. That email includes a list of users who are likely to be affected.

Access to LSAs will be turned off in two stages:

  • After June 15, 2020 - Users who try to connect to an LSA for the first time will no longer be able to do so. This includes third-party apps that allow password-only access to Google calendars, contacts, and email via protocols such as CalDAV, CardDAV, IMAP, and Exchange ActiveSync (Google Sync). Users who have connected to LSAs prior to this date will be able to continue using them until usage of all LSAs is turned off. 
  • After February 15, 2021 - Access to LSAs will be turned off for all G Suite accounts. 


This is a continuation of our previously announced process to limit access to less secure apps to protect G Suite accounts. See below for more details on the possible impact of this change, and some recommendations for change management with users of LSAs.

Who’s impacted End users

Why this matters Many users use non-Google apps, and give those apps permission to access G Suite data. For example, you may give the iOS mail app permission to see your work email. This provides users with more options, and helps users get work done in a way that works well for them.

When account access is provided through an LSA, it puts that account at risk of hijacking. That’s because LSAs provide a non-Google app access to your account through just a username and password, without any other authentication factor. If a bad actor got access to your username and password (for example, if you re-use the password on another site that is subject to a data breach), they could access your account data with just that username and password information through an LSA.

However, when account access is provided through OAuth, we get more details about the login and can validate it the same way we would with any other login to your account. This means we can better identify and prevent suspicious login attempts, preventing hijackers from accessing the account data even if they have your username and password. OAuth also helps us enforce G Suite admin defined login policies, such as the use of security keys, as well as other security controls such as whitelisting apps and offering scope-based account access.

As we’re constantly working to improve the security of your organization’s G Suite accounts, we’ve made the decision to remove LSA access by February 15, 2021. Given the many alternative apps and processes available which do use OAuth (outlined below), we hope that this won’t cause significant disruption while increasing your account security.

How to get started 
  • Admins: 
    • See the “Additional details” section below for more information and recommended actions. 
    •  See the email sent to your organization’s primary admin with a subject line of “Switch to apps that use secure OAuth access, as password-based access will no longer be supported” for a list of users who are likely to be affected by the change. 
  • End users: See the “User information and advice” section below for more details and recommended actions, or use our Help Center to learn more about less secure apps and your Google account. 


Additional details Admin and developer information 

Mobile device management (MDM) configuration - If your organization uses a mobile device management (MDM) provider to configure CalDAV, CardDAV, and Exchange ActiveSync (Google Sync) profiles, these services will be phased out according to the timeline below:

  • June 15, 2020 - MDM push of IMAP, CalDAV, CardDAV, and Exchange ActiveSync (Google Sync) will no longer work for new users. 
  • February 15, 2021 - MDM push of IMAP, CalDAV, CardDAV, and Exchange ActiveSync (Google Sync) will no longer work for existing users. Admins will need to push a Google Account using their MDM provider, which will re-add their Google accounts to iOS devices using OAuth. 


Scanners and other devices - No change is required for scanners or other devices using simple mail transfer protocol (SMTP) or LSAs to send emails. If you replace your device, look for one that sends email using OAuth.

Developer instructions - To maintain compatibility with G Suite accounts, update your app to use OAuth 2.0 as a connection method. To get started, follow our developer guide on using OAuth 2.0 to access Google APIs. You can also refer to our guide on OAuth 2.0 for mobile & desktop apps. 


End User information and advice 

If you are using an app that accesses your Google account with only a username and password, take one of the following actions to switch to a more secure method and continue to access your email, calendar, or contacts. If you do not take one of the following actions, when LSA access is discontinued after February 15, 2021, you will begin receiving an error message that your username-password combination is incorrect.

Email 

  • If you are using stand-alone Outlook 2016 or earlier, you can use G Suite Sync for Microsoft Outlook. Alternatively, move to Office 365 (or Outlook 2019), which support OAuth access. 
  • If you are using Thunderbird or another email client, re-add your Google Account and configure it to use IMAP with OAuth. 
  • If you are using the mail app on iOS or MacOS, or Outlook for Mac, and use only a password to login, you’ll need to remove and re-add your account. When you add it back, make sure to choose Google as the account type to automatically use OAuth. 


Calendar

  • If you use CalDAV to give an app or device access to your calendar, switch to a method that supports OAuth. We recommend the Google Calendar app [Web/iOS/Android] as the most secure app to use with your G Suite account. 
  • If your G Suite account is linked to the calendar app in iOS or MacOS and uses only a password to login, you’ll need to remove and re-add your account to your device. When you add it back, select “sign in with Google” to automatically use OAuth. Read more. 

Contacts 

  • If your G Suite account is syncing contacts to iOS or MacOS via CardDAV and uses only a password to login, you’ll need to remove your account. When you add it back, select “sign in with Google” to automatically use OAuth. Read More. 
  • If your G Suite account is syncing contacts to any other platform or app via CardDAV and uses only a password to login, switch to a method that supports OAuth. 

Other less secure apps 

  • If you use other apps on iOS or MacOS that access your G Suite account information through only a password, most access issues can be resolved by removing then re-adding your account. When you add it back, make sure to select Google as the account type to automatically use OAuth. 
  • For any other LSA, contact your admin or ask the developer of the app you are using to start supporting OAuth. 
  • If the developer won’t update their app, you will need to switch to a client that offers OAuth.  


Helpful links 


Availability Rollout details - all domains 

  • After June 15, 2020 
    • Users who try to connect to an LSA for the first time will no longer be able to do so. This includes third-party apps that allow password-only access to Google calendars, contacts, and email via protocols such as CalDAV, CardDAV, IMAP, and Exchange ActiveSync (Google Sync).. Users who have connected to LSAs prior to this date will be able to continue using them until usage of all LSAs is turned off. 
    • MDM configuration of CalDAV or CardDAV will no longer work for new users. 
  • After February 15, 2021 
    • Access to LSAs will be turned off for all G Suite accounts. 
    • MDM configuration of CalDAV and CardDAV will no longer work for existing users. All existing users will be required to re-add their Google accounts if they wish to sync contacts, calendar, or email. 

G Suite editions 
Applicable to all G Suite editions

On/off by default?
This feature will be ON by default and can’t be turned off.


Stay up to date with G Suite launches
Labels: , , , ,

What’s changing G Suite admins can now view and edit their users’ recovery information, such as backup email addresses and linked phone numbers. We also use this information to verify login requests and increase account security. By making sure your users have accurate and up-to-date information you can help make their accounts more secure.

Who’s impacted Admins only.

Why you’d use it This feature was developed based on customer feedback. Security and recovery information is important for many account verification processes, such as login challenge. To learn more about how adding recovery information can significantly increase the security of your account, see this blog post.

Giving admins the ability to view and edit this information will mean they ensure more accounts have up-to-date recovery information, and increase the accuracy of the recovery information attached to G Suite accounts. This will help:

  • Make it easier for users to access their account if locked out. 
  • Increase challenges and identification of suspicious login attempts to help to keep malicious actors out. 
  • Enable admins to provide direct support to users who are locked out of their account. 


You can still add employee ID as a login challenge for extra security as well.

How to get started 
  • Admins: There are three ways admins can currently manage recovery information: 
    • Individual user accounts: Go to Admin Console > Users > Individual User > Security > Recovery information > Edit. You’ll be able to edit individual user recovery information directly. 
    • Bulk user upload tool (CSV): Use the bulk upload tool at Admin Console > Users to update in bulk. See the edit accounts with a spreadsheet section of this Help Center article for details. 
    • API: Use the Admin SDK Directory API. 
  • End users: No action needed, but can add recovery information by going to myaccount.google.com. 


Helpful links 


Availability Rollout details 



G Suite editions 
Available to all G Suite editions.

On/off by default? 
This feature will be ON by default.

Stay up to date with G Suite launches
Labels: , , , ,

What’s changingOn October 30, 2019, we’ll begin removing the setting to “Enforce access to less secure apps for all users” from the Google Admin console. This setting should disappear from your Admin console by the end of year.


If the “Enforce access to less secure apps for all users” setting is selected for your domain when this change takes place, we’ll automatically select “Allow users to manage their access to less secure apps” instead. You’ll no longer have the option to enforce access to LSAs at the domain level.

Following this change, if you “Allow users to manage their access to less secure apps,” users will still have the option to access LSAs, provided the “Less secure app access” setting is enabled at the individual user account level. To minimize disruption in domains where we’ve automatically changed the setting from “Enforce access” to “Allow users to manage their access,” this account-level setting will be on by default at the time of the change for all active users of LSAs.


If a user has previously opted to let LSAs access their account, but no LSAs have connected to their account in some time, we’ll turn this account-level setting off for them. They can manually reenable this setting at any time at myaccount.google.com/lesssecureapps (provided their admin allows them to do so).

Who’s impactedAdmins and end users

Why it’s importantWe’re making this change to protect your users. LSAs connect to Google accounts using only a username and password, which makes them vulnerable to hijacking. Whenever possible, users should connect to their accounts via OAuth, a more secure method. OAuth allows third-party apps to use Google account information without seeing a user’s password, and it gives admins security controls like the ability to whitelist certain apps and offer scope-based account access.

Visit the Help Center to learn more about managing OAuth-based access to connected apps.

How to get started
  • Admins: No action is required, but we recommend the following:
    • If you currently enforce access to LSAs in your domain, change your setting to disable access or allow users to manage their access as soon as possible, as LSAs can make Google accounts vulnerable to hijackers.
    • Encourage your users to use OAuth-based protocols (like OAuth-based IMAP) to give non-Google apps access to their Google accounts, including their email, calendar, and contacts.
    • Review our list of alternatives to less secure apps.
    • Prepare your users and internal help desks for the change.
    • Update any user guides you’ve previously published to recommend the use of OAuth or to instruct users on how to turn on LSAs. 
  • End users: Visit the Help Center to learn more about LSAs and your account.

Additional details
See below for FAQs.

What is a less secure app (LSA)?
A less secure app (LSA) is an app that connects to Google accounts using only username and password verification for access and not OAuth. Generally, you should only allow your users to use external apps that connect to Google accounts via OAuth, as LSAs make user accounts more vulnerable to hijacking.

I have an app that cannot use OAuth; what do I do?
Choose the “Allow users to manage their access to less secure apps” option in the Admin console, and ensure that users who need to use the app enable the “Less secure app access” setting at myaccount.google.com/lesssecureapps. We also recommend contacting the app’s developer and asking them to provide support for OAuth, as this is the more secure option.

Helpful linksAdmin Help Center: Control access to less secure apps
Admin Help Center: Whitelist connected apps
End User Help Center: Less secure apps & your Google Account
Developer Guide: Using OAuth 2.0 to Access Google APIs

AvailabilityRollout details
  • Rapid Release domains: Extended rollout (potentially longer than 15 days for feature visibility) starting on October 30, 2019
  • Scheduled Release domains: Extended rollout (potentially longer than 15 days for feature visibility) starting on October 30, 2019

G Suite editions
  • Available to all G Suite editions

On/off by default?
  • This setting will be removed for ALL domains by default.
    • If the “Enforce access to less secure apps for all users” setting is selected for your domain when this change takes place, we’ll automatically select “Allow users to manage their access to less secure apps” instead.
    • If the “Allow users to manage their access to less secure apps” setting is selected for your domain when this change takes place, it will remain selected.
    • If the “Disable access to less secure apps for all users” setting is selected for your domain when this change takes place, it will remain selected.

Stay up to date with G Suite launches
Labels: , ,

Quick launch summary At Next 2019, we announced beta functionality to use an Android phone’s built-in security key for 2-step verification. We’re now making this generally available. All phones running Android 7.0+ (Nougat) have a built-in key that can be activated. This means your users can use existing phones for multi-factor authentication in G Suite to protect against phishing.

For more details, see our beta announcement or our Cloud Blog post.

Availability Rollout details



G Suite editions
 Available to all G Suite editions

On/off by default? 
If 2-Step Verification or Security Key Enforcement is turned on for an organization, Android phone will be available as an option for security keys by default.

Stay up to date with G Suite launches
Labels: , , , ,

Instead of using a 2-Step Verification code to sign in to your G Suite account, you can tap a prompt that Google sends to your phone. This prompt is an easier and even more secure way of authenticating your account, and it respects mobile policies enforced on G Suite employee devices.

Until now, in order to receive Google prompts on a new device, you had to explicitly approve that phone when you first signed in with your G Suite account. With this launch, however, you can opt to get Google prompts on all of your devices automatically.


To get Google sign-in prompts on all of your phones, visit the 2-Step Verification page in My Account.

Launch Details
Release track:
Launching to both Rapid Release and Scheduled Release

Editions:
Available to all G Suite editions

Rollout pace:
Full rollout (1–3 days for feature visibility)

Impact:
All end users

Action:
Change management suggested/FYI

More Information
Help Center: Sign in faster with 2-Step Verification phone prompts


Launch release calendar
Launch detail categories
Get these product update alerts by email
Subscribe to the RSS feed of these updates
Labels: , , ,

We’re always looking for new ways to keep your users’ accounts secure and your organization’s data safe. As part of that effort, users may now be asked to verify their identity by providing their employee ID when they sign in to their G Suite account. This will better protect your users from hijacking attempts, as employee IDs are more difficult to guess and phish than many types of identity challenges.


Activate the employee ID login challenge
The employee ID login challenge can only be deployed in domains where a G Suite admin has provided that ID information for their users. You can do this in one of three ways:

  1. Upload employee IDs directly into the Admin console.
  2. Use Google Cloud Directory Sync to pull employee IDs from Microsoft Active Directory or an LDAP server.
  3. Use the G Suite Admin SDK Directory API to populate the “externalIds[].type” “organization” field with employee IDs.

Once you’ve added this employee ID information, you can turn on the login challenge from the Admin console (Security > Login challenges > Use employee ID to keep my users more secure). Note that the employee ID login challenge is OFF by default.

Check out the Help Center for more information on how to add an employee ID as a login challenge.

Notify your users
If you choose to activate this login challenge, we recommend letting your users know where they can find their employee ID and that they may be asked for it when they sign in to their G Suite account. If they’d prefer to verify their identity another way, they should update their phone number and recovery email address.

Please note that this login challenge will not be presented to any user with two-step verification enabled.

Launch Details
Release track:
Launching to both Rapid Release and Scheduled Release

Editions:
Available to all G Suite editions

Rollout pace:
Full rollout (1–3 days for feature visibility)

Impact:
Admins and end users

Action:
Admin action suggested/FYI

More Information
Help Center: Verify a user’s identity with a login challenge
Help Center: Add employee ID as a login challenge


Launch release calendar
Launch detail categories
Get these product update alerts by email
Subscribe to the RSS feed of these updates
Labels: , , , ,

When auto-provisioning is enabled for a supported third-party application, any users created, modified, or deleted in G Suite are automatically added, edited, or deleted in the third-party application as well. This feature is highly popular with admins, as it removes the overhead of managing users across multiple third-party SaaS applications.

We’ve heard continued positive feedback from admins, so we’re adding auto-provisioning support for six new applications:
  • DeskPro 
  • Federated Directory
  • Front App
  • ScreenSteps
  • ThousandEyes
  • Trello

Customers subscribed to G Suite Education, G Suite Business, and G Suite Enterprise editions can enable user auto-provisioning in all supported applications. Customers on G Suite Basic, G Suite Government, and G Suite Nonprofit can configure auto-provisioning for up to three applications from the supported list. For more information on how to set up auto-provisioning, check out the Help Center.

Launch Details 
Release track:
Launching to both Rapid Release and Scheduled Release

Editions: 

  • G Suite Education, Business, and Enterprise customers can enable auto-provisioning for all supported applications 
  • G Suite Basic, Government, and Nonprofit customers can enable auto-provisioning for up to three applications 

Rollout pace: 
Gradual rollout (up to 15 days for feature visibility)

Impact: 
Admins only

Action: 
Admin action suggested/FYI

More Information 
Help Center: Automated user provisioning
Help Center: Using SAML to set up federated SSO

Launch release calendar
Launch detail categories
Get these product update alerts by email
Subscribe to the RSS feed of these updates
Labels: , , ,

If your organization uses SAML to sign users in to G Suite services*, those users will soon see an additional step in the process when using Chrome as their web browser. Starting on May 7th, 2018, after signing in on a SAML provider’s website, they’ll be brought to a new screen on accounts.google.com to confirm their identity. This screen will provide an additional layer of security and help prevent users from unknowingly signing in to an account created and controlled by an attacker.


To minimize disruption for the user, this feature will only be shown once per account per device. We’re working on ways to make the feature even more context-aware in the future, meaning your users should see the screen less and less over time.

Protecting against phishing attacks
This new screen is intended to prevent would-be attackers from tricking a user (e.g. via a phishing campaign) into clicking a link that would instantly and silently sign them in to a Google Account the attacker controls. Today, this can be done via SAML single sign-on (SSO), because it doesn’t require a user interaction to complete a sign-in. To protect Chrome users, we’ve added this extra protection.

Creating a consistent identity
This new security feature is part of a larger project to create a consistent identity across Google web services (like Gmail) and native Chrome browser services (like Chrome Sync). This consistency will make it easier for signed-in G Suite users to take advantage of native Chrome browser features, but it requires additional protection during authentication. This new screen adds that protection and reduces the probability that attackers successfully abuse SAML SSO to sign users in to malicious accounts.

Disabling the new screen
If you wish to disable the new screen for your organization, you can use the X-GoogApps-AllowedDomains HTTP header to identify specific domains whose users can access Google services. Users in those domains won’t see this additional screen, as we assume those accounts are trusted by your users. This header can be set in Chrome via the AllowedDomainsForApps group policy.


*This won't impact individuals who sign in to G Suite services directly and those who use G Suite or Cloud Identity as their identity provider. The screen is also not shown on devices running Chrome OS.

Launch Details
Release track:
Launching to both Rapid Release and Scheduled Release on May 7th, 2018

Editions:
Available to all G Suite editions

Rollout pace:
Extended rollout (potentially longer than 15 days for feature visibility)

Impact:
All end users

Action:
Change management suggested/FYI


Launch release calendar
Launch detail categories
Get these product update alerts by email
Subscribe to the RSS feed of these updates
Labels: , , , , ,

In 2017, we made Google prompt the primary choice for G Suite users turning on two-step verification for the first time. Back then, we noted that users with iOS devices would need to install the Google app in order to use the feature. Today, we’re making it possible for users with iOS devices to receive prompts via their Gmail app as well. This should encourage more people to use Google prompt, which is an easier and more secure method of authenticating an account.


Note that if users have both the Google and Gmail app installed on their iOS device, they’ll see prompts from Gmail.

For more information, visit the Help Center.

Launch Details
Release track:
Launching to both Rapid Release and Scheduled Release

Editions:
Available to all G Suite editions

Rollout pace:
Extended rollout (potentially longer than 15 days for feature visibility)

Impact:
All end users

Action:
Change management suggested/FYI

More Information
Help Center: Sign in faster with 2-Step Verification phone prompts

Launch release calendar
Launch detail categories
Get these product update alerts by email
Subscribe to the RSS feed of these updates
Labels: , , , , ,

A top ask from G Suite admins, we’re now increasing the window of time to restore a deleted user from five to 20 days. This extended window can be especially helpful for customers who manage user accounts through an API or other automated sync tools.

Please note, only those with super admin permissions can restore a deleted user’s account. For the steps on how to restore a user in the Admin console, check out this Help Center article.

Launch Details
Release track:
Launching to both Rapid Release and Scheduled Release

Editions:
Available to all G Suite editions

Rollout pace:
Full rollout (1–3 days for feature visibility)

Impact:
Admins only

Action:
Admin action suggested/FYI

More Information
Help Center: Restore a recently deleted user

Launch release calendar
Launch detail categories
Get these product update alerts by email
Subscribe to the RSS feed of these updates
Labels: , , ,

In February 2017, we revamped Google prompt for 2-Step Verification (2-SV), giving users a better option to keep their accounts safe. In addition to offering 2-SV over an encrypted connection, Google prompt also allows users to block unauthorized access to their account with real-time security information about the login attempt.

Starting next week, 2-SV SMS users will see an invitation to try Google prompts when they sign in. The invitation will give users a way to preview the new Google prompts sign in flow instead of SMS, and, afterward, choose whether to keep it enabled or opt-out.
Overall, this is being done because SMS text message verifications and one-time codes are more susceptible to phishing attempts by attackers. By relying on account authentication instead of SMS, administrators can be sure that their mobile policies will be enforced on the device and authentication is happening through an encrypted connection.
Notes:
  • The notifications to test Google prompts will be shown only to 2-SV SMS users. Security key users are unaffected by this change.
  • A data connection is required to use Google prompt.
  • iOS users will need the Google Search app installed on their phone to use Google prompt.
  • Enterprise edition domains also have the ability to enforce security keys for more advanced security requirements.
  • While users may opt out of using phone prompts when shown the promotion, users will receive follow-up notifications to switch after 6 months.
Launch Details
Release track:
Launching to both Rapid release and Scheduled release

Editions:
Available to all G Suite editions

Rollout pace:
Gradual rollout (potentially longer than 3 days for feature visibility)

Impact:
All end users

Action:
Change management suggested/FYI

More Information
Help Center: Sign in faster with 2-Step Verification phone prompts

Labels: , ,

Posted by Zack Ontiveros, Product Manager, Google Cloud Identity

As an IT administrator, you want to be confident that your users are secure when accessing online services. Millions of G Suite customers already rely on Google Cloud's identity services to secure their online identities with tools like single sign-on, multi-factor authentication, and mobile device management. However, many G Suite organizations have users who do not require G Suite but still need a secure, online identity.

Introducing Cloud Identity support in G Suite
Today we are happy to announce the availability of a new free Cloud Identity license for G Suite customers, which enables your non-G Suite users to get access to Google Cloud's identity services. Using Cloud Identity, you can easily create a unified sign-on for all your users across all enterprise cloud apps, set basic mobile device policies, and enforce multi-factor authentication with security keys.

Once you enable Cloud Identity in your Google Admin console, you will be able to create Cloud Identity users in all the ways you create G Suite users; the only difference is that you will not assign these users a G Suite license.



Try it today
To start using Cloud Identity, head to the Billing page in the Google Admin console. Here you will see a new Cloud Identity card under the "Enable Products" section. Once you enable the Cloud Identity subscription, you will be able to start creating free users without G Suite. For more information, check out our Getting Started Guide for G Suite admins.

Launch Details
Release track:
Launching to both Rapid Release and Scheduled Release
Note: If your domain has been provisioned or you have a billing relationship with a GSuite reseller, an onboarding flow is planned so that your reseller can add Cloud Identity subscriptions to your G Suite domain. This feature will launch in the coming weeks.

Editions:
Available to G Suite Basic, Business, and Enterprise edition domains

Rollout pace:
Gradual rollout (up to 7 days for feature visibility)

Impact:
Admins only

Action:
Admin action suggested/FYI

More Information
Help Center

Labels: , , , ,

When auto-provisioning is enabled for a supported third-party application, any users created, modified, or deleted in G Suite are automatically added, edited, or deleted in the third-party application as well. This feature is highly popular with admins, as it removes the overhead of managing users across multiple third-party SaaS applications.

Today we’re adding auto-provisioning support for six new applications: Asana, Dialpad, Freshdesk, Lucidchart, RingCentral, and Smartsheet. We previously launched auto-provisioning support for Box Enterprise, Salesforce Sandbox, Salesforce, Slack, and Workplace by Facebook, bringing the total number of supporting applications to 11.

G Suite Business, Education, and Enterprise customers can enable auto-provisioning for all eight supported applications. G Suite Basic, Government, and Nonprofit customers can configure auto-provisioning for up to three applications from the supported list. For specific details on how to set up auto-provisioning, check out the Help Center.

Launch Details
Release track:
Launching to both Rapid Release and Scheduled Release

Editions:

  • G Suite Basic, Government, and Nonprofit customers can enable auto-provisioning for up to three applications
  • G Suite Education, Business, and Enterprise customers can enable auto-provisioning for all supported applications


Rollout pace:
Gradual rollout (potentially longer than 3 days for feature visibility)

Impact:
Admins only

Action:
Admin action suggested/FYI

More Information
Help Center: Automated user provisioning (instructions for Smartsheet, Dialpad, and RIngcentral to be added soon)
Help Center: Using SAML to set up federated SSO


Launch release calendar
Launch detail categories
Get these product update alerts by email
Subscribe to the RSS feed of these updates
Labels: , , ,

As the number of global mobile phone users continues to grow, countries have begun modifying their existing telephone numbering plans in order to expand the set of available phone numbers. When this happens, all impacted phone users gain a modified or appended digit on their mobile or landline phone numbers. After a period of time, their old numbers are no longer able to receive messages or calls.

As announced by ANATEL, Brazil recently completed a modification to its telephone numbering plan and affected numbers now contain an extra digit.

To prevent G Suite users with affected Brazilian phone numbers from being locked out of their accounts, Google will be updating their account recovery and two-step verification (2SV) phone numbers to include the extra digit in the coming weeks. These numbers will be updated based on the scheme published by the International Telecommunications Union (ITU). No action is required on the part of the user, and they will receive email and phone notifications describing the changes, including their updated numbers. Note that users can update their phone numbers anytime in their phone number or two-step verification settings.

Moving forward, to ensure continued access to accounts, Google plans to continue to make these modifications on behalf of G Suite users when they are impacted by changes to telephone numbering plans in their countries.

Launch Details
Release track:
Launching to both Rapid release and Scheduled release in the coming weeks. Please monitor the G Suite release calendar for specific timing.

Editions:
Applicable to all G Suite editions

Rollout pace:
Extended rollout (potentially longer than 15 days for feature visibility)

Impact:
All end users with impacted Brazilian phone numbers

Action:
Change management suggested/FYI


Launch release calendar
Launch detail categories
Get these product update alerts by email
Subscribe to the RSS feed of these updates
Labels: ,

We previously announced that a new Google Accounts login page, aimed at giving users an improved experience to sign in to their accounts across devices, would start slowly rolling out on April 5, 2017.

Based on customer feedback, we’ve decided to push the start of that rollout back to April 10, 2017, so we can further clarify how this change will impact G Suite customers.

What’s changing for all G Suite customers
The Google Accounts login page will have a new look and feel, consistent across computers, phones, and tablets. The rollout will start with a small set of users on April 10 and ramp up slowly over the course of several weeks.


Additional changes for customers not using a third-party SSO provider
In addition to the design changes described above, the new Google Accounts login page will also remove the “Stay signed in” checkbox that at certain times appeared for G Suite customers who did not use a third-party SSO provider.


We learned that users didn’t fully understand the implications of interacting with the "Stay signed in" checkbox across all browsers. To mitigate confusion, we're removing the checkbox and users will remain signed in unless they specifically sign out. When using shared or public devices, we recommend using private browsing windows.

Additional changes for customers using a third-party SSO provider when accessing third-party applications that use OAuth

If you’re using a third-party SSO provider to access Google applications, such as Gmail, Calendar, Drive, etc., your G Suite users will not see any differences apart from the newly designed Google Accounts login page described above.

If you’re using a third-party SSO provider to access third-party applications, your G Suite users will see an additional account selection page when they log in. This page will make it clear to them which account they’re authenticating, as well as the permissions they’re granting to applications.


Your G Suite users will be shown the account selection page either before or after being redirected to the third-party application, depending on whether they’re signed in to their browser and the specific third-party application they’re accessing. Please refer to the FAQ below for more details on when the account selection page will be shown.

Additional questions are addressed in the FAQ below.

-- Frequently Asked Questions --

Does this impact G Suite customers who are using Google as their identity provider?
If you’re a G Suite customer whose identity provider is Google, the only change you’ll see is the redesigned Google Accounts login page.

Which third-party SSO providers are included in this launch?
All third-party SSO providers, including Active Directory Federation Services (ADFS) SSO, will use this new Google Accounts login flow.

When will G Suite users see the additional account selection page?
The account selection page will not be shown in either of these cases:
  • when G Suite users are accessing Google applications such as Gmail, Calendar, Drive, etc.
  • if you don’t use a third-party SSO provider.
For customers using third-party SSO providers and accessing third-party applications, the account selection page will be shown in the situations below.

If there are accounts already signed in to the browser:
  • G Suite users will simply be required to confirm the G Suite account that they would like to use before being redirected to the third-party SSO provider, as illustrated in the post above.

If there are no accounts already signed in to the browser:
  • If the third-party application has set the hosted domain (“hd”) parameter, the user will be redirected to the third-party SSO provider and the account selection page will be shown with the G Suite account that is returned.
  • If the third-party application has not set the "hd" parameter, the user must enter the account they would like to use prior to being redirected to the third-party SSO provider.
For more details on the “hd” parameter, please refer to the Google Developers Blog post or reference the developer documentation directly.

Will I need to confirm my account and grant the requested permissions every time I log in to a third-party application with a third-party SSO provider?After being prompted to confirm the correct Google account and granting the requested permissions upon initial login, only the account selection page will be shown again upon subsequent login attempts.

Does this impact SAML-based applications where a third-party cloud application will be the service provider?
SAML is an authentication-only protocol, and SAML apps do not ask for “extra permissions” from the user. If you have third-party SAML-based applications so that your users can use their G Suite credentials to sign in to enterprise cloud applications like Salesforce, Concur, and Zendesk, the only change resulting from this launch will be that the new account selection screen will be shown.

How can I remove my account from the account selection page?
G Suite accounts can be removed from the account selection page by clicking the “Remove an account” link.


Are all browsers impacted?
Yes, newer versions of all supported browsers will have this change applied, including Chrome, Firefox, IE, Edge, Safari, and Opera.

Users of older browsers or those browsers that do not have JavaScript enabled will temporarily continue to see the old Google Accounts login page.

When will my users see these changes?
The rollout will start on Monday, April 10, to a small set of users. It will ramp up slowly over the course of several weeks.



Launch release calendar
Launch detail categories
Get these product update alerts by email
Subscribe to the RSS feed of these updates
Labels: ,

Starting April 10, 2017*, we’re rolling out an update to the Google Accounts sign-in page to give users an improved experience to securely sign in to their accounts. This new design will make browser sign-in flows consistent across computers, phones and tablets.

If you use third-party applications within your organization, or you use a third-party Single Sign-on (SSO) provider, we recommend contacting your developer(s) or SSO provider to see if any updates are necessary. To learn more, visit today’s G Suite Developer blog post.
Launch Details
Release track:
Launching to both Rapid release and Scheduled release

Editions:
Available to all G Suite editions

Rollout pace:
Extended rollout (potentially longer than 15 days for feature visibility)

Impact:
All end users

Action:
Change management suggested/FYI

More Information
Learn about the new Google sign-in page
G Suite Developers Blog

*Note: date adjusted on April 4, 2017


Launch release calendar
Launch detail categories
Get these product update alerts by email
Subscribe to the RSS feed of these updates
Labels: ,

Security Keys are a two-step verification (2SV) method for signing into G Suite accounts that helps keep users secure from phishing attempts. Starting today, if your users have multiple Security Keys, they can rename those Security Keys to make them easier to manage. This was a common request from power users, and we’re happy to make it available. To take advantage of this feature, users who have already added Security Keys can visit their Two-Step Verification settings.


To learn more about all of G Suite’s security offerings, come read our recently updated G Suite Security & Privacy page here.


Launch Details
Release track:
Launching to both Rapid release and Scheduled release

Editions:
Available to all G Suite editions

Rollout pace:
Full rollout (1-3 days for feature visibility)

Impact:
All end users

Action:
Change management suggested/FYI
Labels: , , ,

In June 2016, we introduced phone prompts for 2-Step Verification, giving users another option to keep their accounts safe. Starting this week, users who have opted into receiving phone prompts for 2-SV will notice improvements to the notifications they get when trying to sign in. For instance, when available, they’ll see additional details about the sign-in request, like when and where it was made. These improved prompts will appear on both Android and iOS devices.


Launch Details
Release track:
Launching to both Rapid release and Scheduled release

Editions:
Available to all G Suite editions

Rollout pace:
Gradual rollout (potentially longer than 3 days for feature visibility)

Impact:
All end users

Action:
Change management suggested/FYI

More Information
Help Center: Sign in faster with 2-Step Verification phone prompts


Launch release calendar
Launch detail categories
Get these product update alerts by email
Subscribe to the RSS feed of these updates
Labels: , ,

If your domain has enabled non-admin user password recovery from the Admin console, then you may have decreased your help desk tickets by giving users an automated way to reset their password. Starting October 25, 2016, we’re extending non-admin user password recovery to include email addresses, an extension to our phone numbers launchfrom last year.
Getting Started

  • Non-admin user password recovery launchedover a year ago as default OFF for new G Suite domains, and you can enable the feature by Organizational Unit from the Admin console under Security settings.

Security Best Practices
If you’ve enabled this feature for your domain, we’d like to remind you of the following resources for administrators we’ve updated with this launch:


Note: For G Suite for Education domains that are Primary/Secondary institutions, only administrators will be shown the prompt for email address and phone number.



Launch Details
Release track:
Launching to both Rapid release and Scheduled release on October 25, 2016

Rollout pace:
Gradual rollout (potentially longer than 3 days for feature visibility)

Impact:
All end users

Action:
Change management suggested/FYI

More information
Labels: ,

Google offers useful and simple-to-use security features such as 2-Step Verification and Single Sign-On in order to protect users who connect to their accounts on multiple devices. One equally important component in keeping users secure is educating them on what’s happening with their accounts in real-time.

That’s why today, we’re pleased to release a new feature that notifies Android users of security events on their account: Android notifications for newly added devices.

Here’s how it works

When users add a new device to their account, native Android notifications will tell the user about the newly added device or security event.

If the activity looks suspicious, the user can choose to “Review Account Activity,” and find out what device was added, from what location, and other important information. If the activity is expected, the user can dismiss it as any other notification.
Benefits

Now users are quickly notified on multiple devices when a new device has been added. This increases transparency to the user of what actions they've performed and allows them to flag any suspicious activity they may be seeing on the device. We’ve also found that with Android notifications, users are up to four times as likely to review the information as compared to email notifications.

We hope you find this security feature as useful as we do!


Launch Details
Release track:
Launching to both Rapid release and Scheduled release

Rollout pace:
Gradual rollout (potentially longer than 14 days for feature visibility)

Impact:
All end users

Action:
Change management suggested/FYI


Note: all launches are applicable to all Google Apps editions unless otherwise noted

Launch release calendar
Launch detail categories
Get these product update alerts by email
Subscribe to the RSS feed of these updates
Labels: , ,