Tag Archives: Admin Console

New Google Groups now generally available

What’s changing 

We’re making the new Google Groups generally available - featuring an updated interface and more streamlined controls that make it easier to create, manage, and use. The modern interface is similar to other G Suite apps, such as Gmail, and makes Groups more efficient for new and existing users. It was previously available in beta.

We’ll introduce new Groups according to this timeline:

  • May 26, 2020: Setting to turn new Groups on or off will begin to appear in the Admin console. This setting will be on by default. If turned off, users will not be able to access the new interface. If left on, users will be migrated to the new interface on the dates below. 
  • June 9, 2020: Users in Rapid Release domains will start seeing new Groups, unless their admin has turned it off. Individual users will have the option to revert to classic Groups. 
  • June 23, 2020: Users in Scheduled Release domains will start seeing new Groups, unless their admin has turned it off. Individual users will have the option to revert to classic Groups. 

See more details on these stages and changes below.

Who’s impacted 

Admins and end users

Why you’d use it 

New Groups has a more efficient, streamlined UI, which makes it easier for users to create and manage groups. It includes the most used features from the classic interface, along with:

  • Read group conversations and write messages 
  • Consolidated settings for improved navigation 
  • Quick, simplified group creation 
  • New filtering and search options to help you find content quickly 
  • Improved group member management and more 

Use our Help Center to learn more about the improvements in new Groups.

Additional details 

Features not available in the new Groups UI 
Most commonly used features are available in new Groups, and the new interface will improve the experience of using Groups for most users. However, not all features from classic Groups are currently available, including collaborative inboxes, tags, and categories. Use the Help Center to see which features aren’t available in the new interface. We’re working to add many of these features to new Groups, but organizations and users that rely on these features should continue to use classic Groups for the moment.

We’ll announce when features are added to new Groups on the G Suite Updates blog.

The new Admin console setting to turn new Groups on or off

If you leave new Groups turned ON in the Admin console 

Starting on June 9, we’ll begin redirecting users in Rapid Release domains to the new interface when they visit groups.google.com. On June 23, users in Scheduled release domains will begin seeing the new experience.

Individual users will have the option to revert to the classic UI by going to Settings > Return to classic Google Groups. If they opt-out, they will see the classic interface when they visit Groups next. Users can switch between classic and new Groups as many times as they like.

If you turn new Groups OFF in the Admin console 

If you turn new Groups OFF in the Admin console, your users will not be able to access the new UI and will see the classic interface whenever they go to Google Groups. Note that users who have new Groups turned off by their admin will also not be able to access any new Groups URL, even if they’re sent a direct link by another user that is using the new interface.

If your organization participated in the beta 

Organizations participating in the alpha or beta will start to see the setting to turn new Groups on or off in the Admin console starting on May 26. If an alpha or beta Admin uses the Admin console setting to turn off new Groups, that will take effect within 24 hours. All users currently using new Groups through the beta would be reverted back to classic Groups.

End users at organizations that are part of the alpha or beta program and who are currently using the new interface will continue to see the new user interface throughout, unless their admin turns off new Groups at a domain level.

End users at organizations that are part of the alpha or beta program who have previously reverted to classic Groups will continue to see the old interface, and will have the option to use new Groups if they want.

Getting started 


  • Admins: The new interface will be ON by default and can be disabled at the domain level by going to Admin Console > Apps > G Suite > Groups for Business > New groups. Visit the Help Center to learn more about managing new Google Groups for your organization
  • End users: The new interface will be ON by default and can be disabled or enabled by the user on each browser. 

Rollout pace 

Admin console setting 


End user rollout: 


Availability 


  • Available to all G Suite customers. 

Resources 


Updated Admin console for 2-Step Verification and SSO for SAML controls

Quick launch summary 

We’re making two updates to the Admin console:

New 2-Step Verification (2SV) controls: 
We’re updating the controls you use to configure 2SV in the Admin console. You may notice:

  • A new “2-Step Verification settings” section of the Security page where you can turn 2SV on or off and control other related settings. You can find this at Admin console > Security > 2-Step Verification
  • The ability to turn 2SV enrollment on or off for each organizational unit (OU). Previously you could only turn it on or off for the whole domain. Once it’s turned on, additional 2SV policies can be adjusted. 
  • New interfaces which prevent admins accidentally locking themselves out of an account by enforcing 2SV without being enrolled in 2SV. 
  • An updated and streamlined interface. 
The new 2-Step Verification settings section in the Admin console

In the 2SV section you can configure 2-Step Verification enforcement by OU


New section for single sign-on settings for SAML applications 
We’re making some updates to the settings you use to set up single sign-on for SAML applications. You may notice:

  • The settings that apply to all SAML applications when Google is the Identity Provider (IdP) are now in their own section in Security settings at Admin Console > Security > Set up single sign-on (SSO) for SAML applications
  • The functionality is not changing but you will find a more streamlined experience for managing certificates and to download IdP metadata. 
The new SSO for SAML settings section in the Admin console

 The new SSO for SAML area where you can control related settings

Getting started 



  • Admins: The new per-OU 2SV enrollment feature will be set to ON at the organization level (root OU) if and only if you had allowed 2SV enrollment for your organization prior to this launch, so that there is no change in behavior for your organization. After the launch, you can now change 2SV enrollment at an OU level. You can also use exception groups for 2SV enrollment settings, similar to how 2SV enforcement settings support them. Visit the Help Center to learn more about how to deploy 2-Step Verification for your organization.
  • End users: There is no end user impact for the feature. 

Rollout pace 



Availability 


  • Available to all G Suite and Cloud Identity customers 

Resources 


Save power by automatically turning off Google Meet hardware displays

What’s changing

We’ve added a setting in the Admin console to allow you to enable power-saving signaling over HDMI from Google Meet hardware. When enabled, this feature can help you save power by turning off Meet hardware displays when they’re not in use.

Who’s impacted

Admins only

Why you’d use it

Some displays, like those in conference rooms and lobbies, are often left on indefinitely, wasting power and shortening their useful lifespan. This setting allows compatible displays to be turned off automatically after 10 minutes of inactivity.

Displays are automatically turned on 10 minutes before a scheduled meeting or if a user interacts with the touch panel controller.

Additional details

You might need to turn on HDMI-CEC, change other advanced settings, or update the firmware on your display. Consult your displays manual for more information.

Getting started

Admins: This feature will be OFF by default and can be enabled at the organizational unit (OU) level. Visit the Help Center to learn more about turning display power saving on or off for your organization.

End users: There is no end user setting for this feature. Rollout pace This feature is available now for all users.

Availability


  • Available to all G Suite customers

Resources



Roadmap




Enhanced security for Windows 10 devices now generally available

Quick launch summary 

You can now manage and secure Windows 10 devices through the Admin console, just as you do for Android, iOS, Chrome, and Jamboard devices. This also means you can enable SSO so users can more easily access G Suite and other SSO-enabled applications on Windows 10 devices. This was previously available in beta.

Now, all G Suite admins can now use Google Credential Provider for Windows to:

  • Enable their organization to use existing G Suite account credentials to login to Windows 10 devices, and easily access apps and services with SSO. 
  • Protect user accounts with Google’s anti-hijacking and suspicious login detection technologies. 

Additionally, G Suite Enterprise, G Suite Enterprise for Education, and Cloud Identity Premium customers can now also:

  • Ensure that all Windows 10 devices used to access G Suite are updated, secure, and within compliance of organizational policies. 
  • Perform admin actions, such as wiping a device and pushing device configuration updates, to Windows 10 devices from the cloud without connecting to corp network. 

This can help simplify device management, help to increase data security, and reduce the hurdles and logins users need to access applications and get work done. See our previous announcement for more details on the Windows 10 management features and benefits.

See our Help Center to learn more about enhanced desktop security for Windows. See our post on the Cloud Blog to learn how this and other launches can help G Suite customers stay secure.


Getting started 




Admin controls available for Windows 10 devices 

Rollout pace 



Availability 

Login and SSO features associated with Google Credential Provider for Windows:

  • Available to all G Suite and Cloud Identity customers 


Device management for Windows 10 devices:

  • Available to G Suite Enterprise, G Suite Enterprise for Education, and Cloud Identity Premium customers 
  • Not available to G Suite Basic, G Suite Business, G Suite for Education, G Suite for Nonprofits, and Cloud Identity Free customers 

Resources 


Context-Aware Access for SAML apps available in beta

What’s changing 

We’re enhancing Context-Aware Access (CAA) with a beta that enables admins to use it to control SAML apps. This gives admins the ability to control access to SAML apps based on the user, the device, and the context they are in when they are trying to access an app.

CAA for SAML apps will work for customers that use Google as the primary identity provider (IdP) to enable access to third party apps from pre-integrated SAML apps or custom SAML apps. It’s available to G Suite Enterprise, G Suite Enterprise for Education, Cloud Identity Premium, and Drive Enterprise customers only. See our post on the Cloud Blog to learn how this and other launches can help G Suite customers stay secure.

Who’s impacted 

Admins only

Why you’d use it 

Using Context-Aware Access, you can create granular access control policies to apps based on attributes including the user, location, device security status, and IP address. This can improve your security posture by reducing the chances that there’s unintended access to specific apps and the data in them. Some ways you could use CAA for SAML include:

  • Only allow access to your CRM app when the user is on the corporate network. 
  • Only allow access to a cloud storage app if the user has an up to date operating system and an encrypted device. 
  • Only permit IT admins to access certain tools from a remote location. 
  • Only permit users in a specific country to access certain apps. 


Additional details 


Builds on the CAA for G Suite infrastructure 
Controlling CAA for SAML apps will use the same infrastructure and admin console interface as CAA for G Suite. That means you can use any pre-configured access levels, user groups, and end-user messaging for CAA to SAML. Use our Help Center to find out more about managing context aware access in G Suite.

CAA for SAML only enforced at time of sign-in 
CAA for SAML apps is only enforced at the time of sign-in. This is different from CAA for G Suite applications, which offers a higher level of control. G Suite applications are built by Google and CAA controls are enabled for continuous evaluation of context (IP, device attribute, etc) during use. As SAML apps are non-Google applications using Google sign-in, we’re only able to evaluate context at the point where a user signs into these applications using Google sign-in. After that sign-in, the context is not evaluated again until the session is terminated and users try to sign-in again with Google.

Getting started 


  • Admins: This is an open beta, so the controls will automatically become available to you if you are a G Suite Enterprise, G Suite Enterprise for Education, Cloud Identity Premium, or Drive Enterprise customer. 
  • End users: No end-user impact until turned on by the admin. 

Availability 


  • Available to G Suite Enterprise, G Suite Enterprise for Education, Cloud Identity Premium, and Drive Enterprise customers. 
  • Not available to G Suite Basic, G Suite Business, G Suite for Education, G Suite for Nonprofits, and Cloud Identity Free customers. 

Resources 


New data exfiltration protections for G Suite data on iOS devices

What’s changing 

We’re adding new security controls that admins can use to protect sensitive company data on iOS devices. Admins can now choose to:

  • Restrict copy and paste on data belonging to G Suite accounts to other accounts. This can prevent corporate data from being exfiltrated to personal accounts. 
  • Restrict the ability for users to drag and drop files from specific apps within their G Suite account. 

At launch, admin controls will apply to five G Suite iOS apps: Gmail, Drive, Docs, Sheets, and Slides. This feature is available to G Suite Enterprise, G Suite Enterprise for Education, and Cloud Identity Premium customers. Users will still be able to copy and paste and drag and drop from personal accounts to G Suite accounts. Protections are available to devices managed with G Suite’s basic or advanced mobile device management, as well as devices with basic mobile management alongside a separate enterprise mobility management (EMM) solution.

Who’s impacted 

Admins

Why it’s important 

Without these features, there are limitations in the controls admins have to prevent users moving corporate data between corporate and personal accounts on the same iOS device. While admins can prevent sharing files between managed and unmanaged apps, users can still share data between accounts when apps support multiple accounts or via cut/copy/paste actions. For example, iOS users can copy the text of a corporate email into a personal account. This introduces the potential for data leaks and reduces the overall security of your corporate data on iOS.

The admin controls introduced in this launch will help increase protections and make it more difficult for corporate data to be accidentally or intentionally shared to a personal account. Similar protections are already available on Android devices through Work Profiles.

See our post on the Cloud Blog to learn how this and other launches can help G Suite customers stay secure.

Getting started 


  • Admins: This feature will be OFF by default and can be enabled at the organizational unit (OU) level. Visit the Help Center to learn more about data protection on iOS devices
  • End users: There is no end-user setting for this feature. If a user tries to perform a restricted copy and paste action, the text “This info can only be shared within your organization’s G Suite apps” will paste instead of the text they copied. 


Admin controls for data exfiltration protection on iOS 

Rollout pace 


  • This feature is already available for all domains. 

Availability 


  • Available to G Suite Enterprise, G Suite Enterprise for Education customers and Cloud Identity Premium customers 
  • Not available to G Suite Basic, G Suite Business, G Suite for Education, G Suite for Nonprofits customers, and Cloud Identity Free customers 

Resources 


Improve email security in Gmail with TLS by default and other new features

What’s changing

Recently, the Google Security blog outlined how the usage of Transport Layer Security (TLS) has grown to more than 96% of all traffic seen by a Chrome browser on Chrome OS. The blog post also highlighted a significant goal: to enable TLS by default for our Google products and services, and to ensure that TLS works out of the box.

Gmail already supports TLS, so that if the Simple Mail Transfer Protocol (SMTP) mail connection can be secured through TLS, it will be. However, in order to encourage more organizations to increase their email security posture, and to further the above goal of enabling TLS by default, we’ve made the following changes:

  • TLS for mail connections will now be enabled by default
  • Admins are now able to test their SMTP outbound routes’ TLS configuration in the Admin console before deployment. They no longer need to wait for messages to bounce.

While admins have always had the ability to require TLS encryption for mail routes, it was previously off by default. Note that existing mail routes will not be impacted by these changes.

Who’s impacted

Admins

Why it’s important

We always recommend that admins enable existing mail security features, including SPF, DKIM, and DMARC, to help protect end users. We also recommend that admins turn on MTA Strict Transport Security (MTA-STS), which improves Gmail security by requiring authentication checks and encryption for email sent to their domains. Enabling TLS by default on new SMTP mail routes enhances the security posture of our customers while enabling admins to test connections before enforcing TLS on existing routes makes it easier for them to deploy best practice security policies.

This change will not impact mail routes that were previously created.

Additional details


TLS enabled by default on new mail routes
With TLS enabled by default for new mail routes, all certificate validation requirements are also enabled by default. This ensures that recipient hosts have a certificate issued for the correct host that has been signed by a trusted Certificate Authority (CA). See more details about how we’re changing the requirements for trusted CAs below.

Admins will still have the ability to customize their TLS security settings on newly created mail routes. For example, if mail is forwarded to third-party or on-premise mail servers using internal CA certificates, admins may need to disable CA certificate validation. Disabling CA certificate validation, or even disabling TLS entirely, is not recommended. We encourage admins to test their SMTP TLS configuration in the Admin console in order to validate the TLS connection to external mail servers before disabling any recommended validations. See more details about how to test TLS connections in the Admin console.

Certificate Authority distrust in Gmail
In the past, the Google Security Blog has highlighted instances where Chrome would no longer trust root CA certificates used to intercept traffic on the public internet and where Chrome distrusts specific CAs.

If these scenarios occur in the future, these certificates will also be distrusted by Gmail. When this happens, mail sent using routes that require TLS with CA-signed certificate enforcement may bounce if the CA is no longer trusted. Although the list of root certificates trusted by Gmail can be retrieved from the Google Trust Services repository, we encourage admins to use the Test TLS Connections feature in the Admin console to confirm whether certificates have been distrusted.

Test TLS connections in Admin console
Admins can now use the new Test TLS Connection feature to verify whether a mail route can successfully establish a TLS connection with full validation to any destination, such as an on-premise mail server or a third-party mail relay, before enforcing TLS for that destination.

Getting started


Admins:

TLS settings
TLS will be ON by default for all new mail routes. We recommend that admins review all of their existing routes and enable all recommended TLS security options for these routes as well.

Testing TLS connections
Admins who want to require a secure TLS connection for emails can now verify that the connection to the recipient's mail server is valid simply by clicking on the “Test TLS Connection” button in the Admin console; they no longer need to wait for emails to bounce.

Learn more about requiring mail to be transmitted via a secure (TLS) connection and adding mail routes in the Help Center.

All certificate validations are now enabled by default when creating a new TLS compliance setting.

TLS and all certificate validations are now enabled by default when creating a new mail route.

End users: There are no end user settings for these features.

Rollout pace



Availability


  • Available to all G Suite customers

Resources




New interface for domain management in the Admin console

Quick launch summary


We’ve updated the interface you use to manage your primary domain, secondary domains, and domain aliases. When you go to Admin console > Domains > Manage domains, you may notice:
  • An updated interface with more complete information and descriptions of items and domain state. 
  • New grouped action buttons which make it easier to see and select the action you want to take, such verifying domains, changing your primary domain, setting up MX records, and more. 
  • A new side panel which shows information about domains registered through Google, enabling you to quickly see and manage renewals and advanced DNS settings. 

Getting started

  • Admins: Find domain management at Admin console > Domains > Manage domains. Use our Help Center to learn more about how to add and manage domains in G Suite
  • End users: There is no end user impact. 


The new domain management interface in the Admin console


The old domain management interface in the Admin console

Rollout pace



Availability


  • Available to all G Suite customers

Resources




Important changes to less secure apps and account recovery management in the Admin console

What’s changing

We’re making some updates to how you manage less secure app (LSA) settings and account recovery (AR) settings in the Admin console. This is part of a wider migration of our Admin console pages to a simplified and more streamlined experience, and will affect the sections at Admin console > Security > Settings > Less Secure Apps and Admin console > Security > Settings > Account Recovery. In those sections you may notice:

  • An updated interface, which reorganizes the settings to make them easier to find and change.
  • A new system to apply group-based policies in these areas. As a result of this change, existing settings will be migrated to the new system. See "Additional details" below for more information.


Who’s impacted

Admins

Why it’s important

The interface updates will make security settings more findable and scannable, reducing the number of clicks it takes to manage these settings. The new group-based policy system is the same one used in other areas of the Admin console and so should be more familiar and intuitive than the legacy system. The new system allows for multiple group based policies to be applied in a single UI view, and makes it possible to manage policies exclusively using groups, instead of a combination of OU-based policy with group-based exceptions.

Additional details

As part of migrating LSA and AR pages to the new UI, we will migrate any currently applied group-based policies to the new groups-based system. This migration will have no functional impact for most customers.

However, for a very small number of organizations (specifically those that currently have group based policies for LSA and AR applied at child-OU levels,) this transition may impact your existing settings. We will email the primary admin at affected domains with more details on how we will do the transition, and instructions for how to prepare. If you don’t receive an email, no action is required.

Getting started

Admins: Existing policies will be migrated to the new group-based policy system automatically unless you’re notified by email (see “Additional details” above). Visit the Help Center to learn more about using groups to manage Admin console settings, controlling access to LSAs, or setting up account recovery for users.

End users: There is no end-user impact unless admins change settings applied to them.
Before

After

Rollout pace




Availability


  • Available to all G Suite customers


Resources


Get a better overview of meetings with visual timelines in the Meet Quality Tool

Quick launch summary

You can now see a timeline of when users joined a call and events that took place during the call in the Meet Quality Tool. The timeline helps with you visually understand how the call developed over time.



The information on the timeline can be adjusted by selecting/deselecting participants and sorting them by name or join time. You can find more information about the timeline tool in the Help Center.

Getting started:

Admins: This feature will be available by default when using the Meet Quality Tool.

End users: There is no end user setting for this feature.

Rollout pace



Availability


  • Available to all G Suite customers

Resources