Tag Archives: Admin Console

Greater protection and control with three Gmail security tools

What’s changing

We’re making three Gmail security features generally available (GA). The features were previously in beta. Check out the linked announcements for more information on each:

  • Security sandbox, which detects the presence of previously unknown malware in attachments by virtually "executing" them in a private, secure sandbox environment. Learn more.
  • Advanced phishing and malware protection, which provides new controls to place emails into a quarantine, protect against anomalous attachment types, and protect your Google Groups from inbound spoofing emails. Learn more.
  • Gmail confidential mode, which provides built-in information rights management controls in your emails by allowing senders to create expiration dates and revoke previously sent messages. Learn more.

Who’s impacted

Admins and end users

Why you’d use it

When you deploy and manage security tools at scale, you can more effectively protect your users from threats. With these features now in GA, everyone in your organization—from admins to end users—is more secure.

How to get started


  • Admins:
    • Security sandbox: Note: available to G Suite Enterprise and G Suite Enterprise for Education editions only. Find and turn on the beta security sandbox feature at Admin console > Menu > Apps > G Suite > Gmail > Advanced settings. Use our Help Center to find more information on how to detect harmful attachments.
    • Advanced phishing and malware protection: Find and control these features at Admin console > Menu > Apps > G Suite > Gmail > Safety. You’ll find new options for anomalous attachment and groups spoofing protections, and see the quarantine option available for all controls. Use our Help Center to learn more about how to enhance phishing and malware protection.
    • Gmail confidential mode: This feature is on by default so no action is required to get started. To disable the feature, navigate to Admin console > Apps > G Suite > Settings for Gmail > User settings.
  • End users:
    • Security sandbox: No action needed.
    • Advanced phishing and malware protection: No action needed.
    • Gmail confidential mode: Follow the steps in this Help Center article to send and open confidential emails.

Helpful links



Availability

Rollout details

  • Security Sandbox
  • Advanced phishing and malware protection
    • Rapid Release domains: Extended rollout (potentially longer than 15 days for feature visibility) starting on June 25, 2019.
    • Scheduled Release domains: Extended rollout (potentially longer than 15 days for feature visibility) starting on June 25, 2019.
  • Gmail confidential mode

G Suite editions

  • Security Sandbox
    • Available to G Suite Enterprise and G Suite Enterprise for Education.
    • Not available to G Suite Basic, G Suite Business, G Suite for Education, and G Suite for Nonprofits.
  • Advanced phishing and malware protection
    • Controls are available to all G Suite editions.
    • Chart to view affected emails available is part of the security center and so is available to G Suite Enterprise edition only.
  • Gmail confidential mode:
    • Available to all G Suite editions.

On/off by default?

  • Security sandbox: This feature will be OFF by default and can be enabled at the OU level.
  • Advanced phishing and malware protection: This feature will be ON by default.
  • Gmail confidential mode: This feature will be ON by default.

Stay up to date with G Suite launches

Use security codes to log in where security keys won’t work directly

What’s changing 

We’re adding an option for G Suite users to log in using security codes. A security code is a one-time use code, generated using a security key, that can be used to log in on legacy platforms where security keys aren’t supported directly.

Security codes will be available by default for some users:

  • Users subject to “Any” or “Any except verification codes via text, phone call” 2-Step Verification policies 
  • Users which are not subject to a specific 2-Step Verification policy, but that have chosen to use a security key. 


If you currently use an “only security key” policy and wish to allow security codes, an admin can choose turn security codes on for specific users (see more below).

Find out more about how to select a 2-Step Verification method to enforce here.

Who’s impacted 

Admins and end users

Why you’d use it 

Security keys increase account security significantly. While most modern systems support the use of security keys, some do not. For example, security keys often don’t work with Internet Explorer and Safari, iOS apps, remote desktops, and legacy applications that don’t support FIDO protocols. With this launch, users can now generate a security code with their security key, which can then be used to authenticate their login attempt where the security key itself won’t work.

For example, a user may need to access a web application that federates their Google identity, but only works on Internet Explorer 11. While the browser can’t communicate with a security key directly, the user can open a Chrome browser and generate a security code, which can then be entered in Internet Explorer to gain access to the application.

Security considerations 
Before enabling this new policy, carefully evaluate if your organization needs security codes. Using security keys without security codes helps to provide maximum protection against phishing. However if your organization has important workflows where security keys can’t be used directly, enabling security codes for those situations may help improve your security posture overall. 

How to get started 

Admins:

  • Domains that currently enforce an “only security key” policy can turn on security codes by going to Admin Console > Security > Advanced security settings and selecting “Users may utilize security code”. Use our Help Center to find out more about security codes. Domains that currently enforce other 2-step verification policies will have the feature turned on by default. 

End users:

  • For users in domains which enforce “Any” or “Any except verification codes via text, phone call” 2-Step Verification policies the feature will be enabled by default. 
  • For users in domains which enforce an “only security key” policy, no action is needed until an admin turns the feature on. 
  • Once enabled, when a user who can use security codes navigates to a page which requires a security key, they will see “Having trouble” or “Try another way.” Once they click on one of those options, they will be able to “Get a one-time security code”. This will link to a page that prompts them to enter their security code, and also tells them where to go (https://g.co/sc) to generate a security code if they don’t have one yet. 



Helpful links 

Help Center: Deploy two-step verification and allow security codes 
Help Center: Security controls and two-step verification

Availability 

Rollout details 

  • Rapid Release domains
    • For domains which currently enforce an “Any” or “Any except verification codes via text, phone call” policy, the feature will be enabled for users in a gradual rollout (up to 15 days for feature visibility) starting on June 24, 2019 
    • For domains which enforce an “only security key” policy, the admin console setting to allow users to utilize security codes will appear in the admin console in a gradual rollout (up to 15 days for feature visibility) starting on July 8, 2019. 
  • Scheduled Release domains
    • For domains which currently enforce an “Any” or “Any except verification codes via text, phone call” policy, the feature will be enabled for users in a gradual rollout (up to 15 days for feature visibility) starting on June 24, 2019 
    • For domains which enforce an “only security key” policy, the admin console setting to allow users to utilize security codes will appear in the admin console in a gradual rollout (up to 15 days for feature visibility) starting on July 8, 2019. 


G Suite editions 
Available to all G Suite editions

On/off by default? 

  • Security codes will be ON by default for domains which currently enforce “Any” or “Any except verification codes via text, phone call” 2-Step Verification policies. 
  • Security codes will be OFF by default for domains which currently enforce an “only security key” policy, security codes will be off by default and admins enable them at the domain, OU, or group level.


Stay up to date with G Suite launches

Five new third-party applications added to G Suite pre-integrated SAML apps catalog

What’s changing 

We’re adding SAML integration for five additional applications:
  • Firstbird
  • Foodee
  • Hive
  • LaunchDarkly
  • RECOG
Use our Help Center to see the full list of SAML apps and find out how to configure SAML applications.

Who’s impacted 

Admins only

Why you’d use it 

With Single-Sign-On (SSO), users can access all of their enterprise cloud applications—including the Admin console for admins—after signing in just one time. Google supports the two most popular enterprise SSO standards, OpenID Connect and SAML, and there are already many applications with pre-integrated SSO support in our third-party apps catalog.

How to get started 

  • Admins: You can find our full list of pre-integrated applications, as well as instructions for installing them, in the Help Center.
  • End users: No action needed.

Additional details 

Note that apart from the pre-integrated SAML applications, G Suite also supports installing “Custom SAML Applications,” which means that admins can install any third-party application that supports SAML. The advantage of a pre-integrated app is that the installation is much easier. Use out Help Center to learn more about installing Custom SAML Applications.

Helpful links 

Help Center: Using SAML to set up federated SSO 
Help Center: Set up your own custom SAML applicationAvailability 

Rollout details 

G Suite editions 
Available to all G Suite editions.

On/off by default? 
This feature will be OFF by default and can be enabled at the OU level.

Stay up to date with G Suite launches

Use an Android phone for 2-step verification on iOS devices

Quick launch summary 

Earlier this year we announced the ability to use your Android phone’s built-in security key for two-factor authentication in G Suite.

Now, you can use devices with Android 7.0+ (Nougat) to verify your sign-in to Google and Google Cloud services on Apple iPads and iPhones.
To learn more about using your Android phone’s built-in security key to verify sign-in on iOS devices, see our Security Blog


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. 

Use an Android phone for 2-step verification on iOS devices

Quick launch summary 

Earlier this year we announced the ability to use your Android phone’s built-in security key for two-factor authentication in G Suite.

Now, you can use devices with Android 7.0+ (Nougat) to verify your sign-in to Google and Google Cloud services on Apple iPads and iPhones.
To learn more about using your Android phone’s built-in security key to verify sign-in on iOS devices, see our Security Blog


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. 

Take action by July 8, 2019, to ensure your users can continue to use third-party apps accessing Gmail data

What’s changing

Security and privacy are extremely important to Google. To better protect your data, we’ve made an important update to our policies governing third-party apps (web, Android, iOS, Chrome, and other apps) accessing Gmail data using G Suite APIs and OAuth2.

We previously announced that apps accessing user data for non-enterprise accounts using certain Gmail APIs had to be verified to ensure compliance with new privacy and security requirements using our OAuth API Application Verification. Starting on July 8, 2019, we’ll apply similar requirements for apps you may use within your domain.

Who’s impacted

Admins and end users

Why it matters

While existing unverified apps will continue to work for users who installed them before July 8, after this date we’ll block new installs for unverified third-party apps that access Gmail data and that you don’t explicitly trust (whitelist) in the G Suite Admin console.

How to get started


  • Admins:
    • Review unverified apps in your environment: Please review the unverified apps currently in use in your organization’s G Suite environment and decide which apps you want to trust and allow users to continue to install. The primary admin contact at your organization will receive an email by June 21, 2019, with a list of those unverified apps, including the number of users and whether or not you have trusted them in API Permissions.
    • Trust apps that you want to allow users to continue to install: To trust an app, use our API Permissions (OAuth apps whitelisting) feature in the Security section of the Admin console. Trusting an app also means that, if users consent, the app will have access to some G Suite user data (OAuth2 scopes) that you’ve otherwise restricted using this same tool. For example, if you’ve generally blocked access to Gmail OAuth2 scopes, trusted apps will have access for accounts where users consent.