Tag Archives: identity

New option to make security codes more secure

What’s changing 

We’re giving you another option to determine how security codes can be used in your organization. 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.

With this launch we’re adding an option to restrict the use of codes to the same device or network that they were generated on.

Who’s impacted 

Admins and end users

Why you’d use it 

Since we introduced security codes in June 2019, we’ve observed that they’re most commonly used with applications that use legacy authentication on devices that are capable of supporting Chrome or other browsers that allow security keys. The new restricted security code option allows that use case to be satisfied while reducing some potential vulnerabilities. Unrestricted codes will still be available for users who need them (such as those using remote servers or virtual machines).

How to get started 

Admins: Customers can turn this feature on at Admin console > Security > Advanced security settings. Use our Help Center to find out more about security codes
End users: No action needed.

Additional details 

Three security code settings available to G Suite admins 
With this launch, there will be three options for security codes:

  • Don't allow users to generate security codes. Users can’t generate security codes. This was previously available, and was the default setting. 
  • Allow security codes without remote access. Users can generate security codes and use them on the same device or local network (NAT or LAN). This is a new option, and replaces the don’t allow security codes as the default setting for new G Suite customers. 
  • Allow security codes with remote access. Users can generate security codes and use them on the same device or local network (NAT or LAN), as well as other devices or networks, such as when accessing a remote server or a virtual machine. The earlier version of security codes was effectively the same as this. 


No impact to existing users 
This launch won’t change the user experience unless an admin changes a setting in the Admin console. Specifically,

  • Users who are currently assigned “Don’t allow security codes” will now be assigned “Don't allow users to generate security codes” and will still not be able to use security codes. 
  • Users who are currently assigned “Allow use of security codes,” will now be assigned “Allow security codes with remote access” and will be able to use security codes in the same way as before. 

Use our Help Center to learn more about security codes and 2-Step Verification.

Security codes and the Advanced Protection Program for the enterprise 
You can control security code use separately for your users in the Advanced Protection Program for the enterprise. Security code settings for those users are determined by controls at Admin console > Security > Advanced Protection Program. Settings for security code use here will override regular settings for those users. Read more about the Advanced Protection Program for the enterprise.

Helpful links 

Help Center: Allow security codes when security keys aren't supported 
G Suite Updates blog: Use security codes to log in where security keys won’t work directly

Availability 

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 customized on the domain, OU, or group level.


Stay up to date with G Suite launches

Advanced Protection Program for the enterprise generally available to help protect high-risk users

This announcement was made at Google Cloud Next ‘19 UK. Check out Next OnAir to tune into the livestream or watch session recordings following the event.



What’s changing 

The Advanced Protection Program for the enterprise is now generally available. It was previously available in beta.

Who’s impacted 

Admins and end users

Why you’d use it 

The Advanced Protection Program for the enterprise enforces a specific set of high security policies for employees in your organization that are most at risk for targeted attacks. Targeted attacks describe sophisticated, low volume handcrafted attacks that are often carried out by highly motivated professional or government backed groups. Employees at risk of targeted attacks that may benefit from the program include, for example, IT admins, executives, and employees in regulated industries such as finance or government.

The individual policies currently included in the Advanced Protection Program are also available to G Suite admins and users outside of the program. However, the Advanced Protection Program for the enterprise offers a simple bundle of our strongest account security settings for your organization’s high-risk users, and the program is constantly evolving to ensure these users continue to have Google’s strongest account security in place.

How to get started 


  • Admins: 
    • By default, all users will be able to enroll in the program. Admins can turn it off for users on a per-OU basis at Admin Console > Security > Advanced Protection Program. 
    • For beta users: During the beta, the feature was off by default unless admins specifically turned it on. Now, it will be on by default for all users. If you turned it on and then off again for some users during the beta, the setting will remain off for those users and they will not be able to enroll unless you turn it on. 
    • Use our Help Center to find out more about the Advanced Protection Program for enterprise
  • End users: Once enabled, users can complete their self-enrollment by visiting g.co/advancedprotection and clicking on ‘Get Started’. 


Additional details 

Policies enforced for users in the Advanced Protection Program 

Policies enforced for users in the program include:

  • Requiring the use of security keys (such as the Titan Security Key) for maximum protection against phishing. 
  • Automatically blocking access of most third party apps to Drive and Gmail data if those apps are not explicitly trusted by the admin. 
  • Enhanced email scanning for threats. 
  • Download protections from Google Safe Browsing for certain file types when signed into Google Chrome with the same identity. 


Use our Help Center to find out more details about these policies.

Requirements for users in the Advanced Protection Program 

The Advanced Protection Program is available for all users in all G Suite and Cloud Identity organizations unless admins turn it off for some or all users. When users enroll in the Advanced Protection program, they will need:

  • To register two security keys (one as a backup) 
  • To re-sign in on all their devices using a password and security key. They’ll be signed out of all devices when they enroll. 


Details and requirements will be explained to users as they enroll themselves in the program at g.co/advancedprotection.

New default: Allow security codes without remote access 

In the beta, you had an option to allow or not allow the use of security codes for your users who sign up for the Advanced Protection Program. Now, we’re adding a new option in addition to the previous two. The new option, allow security codes without remote access, will mean users can only use security codes they generate on the same device or local network.

This new option, allow security codes without remote access, will be the default for new and existing users. So any users who were not allowed to use security codes during the beta will be allowed to use security codes without remote access when general availability rolls out to your domain. Note that if you chose ‘allow security codes’ in the beta, that choice will persist when the GA version rolls out to your domain.

If you want to change this for all or some users, go to Admin Console > Security > Advanced Protection Program and choose between:

  • Don't allow users to generate security codes. 
  • Allow security codes without remote access (default). 
  • Allow security codes with remote access. 


See our Help Center for more information on the new Security Code options.


Admins can allow or prevent their users from being able to opt-in to Advanced Protection 

Helpful links 

Advanced Protection Program overview and sign up: g.co/advancedprotection 
Help Center: Protect users with the Advanced Protection Program

Availability 

Rollout details 

  • Rapid Release domains: Extended rollout (potentially longer than 15 days for feature visibility) starting on November 20, 2019 
  • Scheduled Release domains: Extended rollout (potentially longer than 15 days for feature visibility)] starting on November 20, 2019 
  • Note: If you see “Beta” when you go to Admin Console > Security > Advanced Protection Program, then the rollout has not yet reached your domain. 

G Suite editions 
Available to all G Suite editions

On/off by default? 
This feature will be ON by default and can be controlled at the OU level

Fundamental device management brings basic coverage to all desktop computers

What’s changing 

With this launch, all desktop devices that log in to G Suite will get fundamental device management by default. This means that when a user logs in to G Suite through any browser on a Windows, Mac, Chrome, or Linux device, the device will be registered with endpoint management. This will happen automatically upon login and does not require any other user actions or software to be installed on the device.

When a device is registered with fundamental device management, admins can see the device type, operating system, first sync time, and last sync time in the Admin console. They can also sign the user out from that device.

This provides the basic benefits of device management without additional costs or requiring installation of agents or profiles. We’re also making enhancements to the filters available in the device list that will strengthen our endpoint verification and Context-Aware Access functionality. See more information below.

Who’s impacted 

Admins only

Why you’d use it 

Fundamental device management provides a base level of security to every desktop device that accesses G Suite data. The device data collected can help admins make more informed security and policy decisions about how to manage the devices in their organization. More specifically, the feature will help admins to:
  • Get a clearer picture of all the devices that are accessing corporate data. 
  • Use more comprehensive data to analyze device access in the organization through reports and the security center. For example, you could use it to identify devices that require OS updates. 
  • Take remedial action to remotely sign out a user when a device is lost, stolen, or compromised.
  • Improve Context-Aware Access controls. The device inventory will be more comprehensive, and admins can use a new “Exclude Endpoint Verification” filter, which will enable admins to see which devices would not be able to access G Suite when context-aware access is deployed. 


How to get started 



Additional details 


Fundamental desktop management provides device information without apps or agents 

When fundamental device management is enabled, the admin will get information about a limited set of device properties: device type, device model, OS version, first sync, and last sync.

This will be visible in two places in the Admin console:

  • The devices list found at Admin console > Device management > Devices > Endpoints
  • The audit section found at Admin console > Reporting > Audit > Devices

Information about devices with fundamental device management will be listed alongside devices that use other agents to provide admins with details about devices accessing corporate data. Admins can filter the endpoint list by “Management Type” to see devices with a specific device management type, such as fundamental, endpoint verification, or Drive File Stream.

You can filter for “Fundamental” managed devices at Admin console > Device management > Devices 

A device page with information provided through fundamental device management 


Limitations of fundamental device management and other endpoint verification options 
Fundamental device management is designed to be an agentless, lightweight information collection tool. Its goal is to provide a basic data set, which can help admins make some decisions and add some controls to devices accessing their data.

Google provides other services, which offer more detailed data and enable more comprehensive controls to admins, including endpoint verification, Chrome device management, Drive File Stream, and Google Mobile Management.

New Endpoint Verification filter helps deploy Endpoint Verification and Context-Aware Access

We’re also adding the ability to filter for devices without endpoint verification in the device list at Admin console > Device management > Devices. This can help admins to identify devices which are accessing corporate data without endpoint verification, and see if they’d like to install endpoint verification on any of them. This can also improve the deployment of Context-Aware Access, which relies on Endpoint Verification. By seeing users and devices without Endpoint Verification installed, admins can identify and avoid potential user disruption before turning on Context-Aware Access. 

Helpful links 



Availability 

Rollout details 

  • Rapid and Scheduled Release domains
    • Extended rollout (longer than 15 days for feature visibility) starting on October 29, 2019. 
    • Rollout could take up to 6 months to reach all domains. 
    • When it reaches your domain, you’ll see the banner pictures below, and there will be a new “Management Type > Fundamental” filter option available in the endpoint devices list. 

When the rollout reaches your domain, you’ll see this banner when you go to Admin console > Device management > Devices 

When the rollout reaches your domain, you’ll see the “Fundamental” management type filter option at Admin Console > Device Management > Devices. 


G Suite editions 
Available to all G Suite editions.

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


Stay up to date with G Suite launches

Dynamic, context-aware access control for G Suite now generally available

What’s changing 

Context-aware access for G Suite is now generally available for G Suite Enterprise and G Suite Enterprise for Education domains. It was previously available in beta.

With context-aware access, you can set up different access levels based on a user’s identity and the context of the request (location, device security status, IP address). This can help you provide granular access controls without the need for a VPN, and give users access to G Suite resources based on organizational policies. For example, you could use it to:

  • Let only certain employees access Gmail outside of the corporate WiFi network. 
  • Allow access to Drive only if a user’s desktop device storage is encrypted. 
  • Permit users from a certain Organizational Unit (e.g. executives) to access apps on any network, but restrict access to apps for other OUs from outside the corporate network. 

Visit our Help Center for more information on how to use context-aware access. For more details on context-aware access and a number of other G Suite security announcements, please read our Cloud Blog post.

Who’s impacted 

Admins only

Why you’d use it

See this video for some ideas about how you could use context-aware access:

How to get started 


  • Admins: Use our Help Center to learn how to start using context-aware access. 
  • End users: No action needed 

Helpful links 

Help Center: Context-Aware Access overview 

Availability 

Rollout details 


G Suite editions

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

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

Use Google 2-Step Verification and risk-based login challenges with 3rd-party identity providers

What’s changing 

We’re making two Google login security measures available to organizations that use 3rd-party identity providers. Admins at these organizations can choose to turn on two features that significantly improve account security against various attacks on user accounts. These features are new for customers using 3-party identity providers:

  • 2-Step Verification, an extra verification step that automatically requests verification when certain conditions are met (for example, when someone tries to log in on a new device or browser). Learn more about 2-Step Verification
  • Risk-based login challenges, which uses machine learning to analyze user access patterns and assess the risk of a malicious attack, and presents additional verification challenges when the behavior looks suspicious. Learn more about risk-based login challenges


Who’s impacted 

Admins and end users

Why you’d use it 

This will allow you to better protect your users' accounts from unauthorized access. You can use this feature to:

  • Increase overall account security, by leveraging Google's risk-based challenges for users authenticating on your 3rd-party identity provider. 
  • Enforce Google 2-Step Verification for certain users only. For example, you can enforce Google 2-Step Verification in combination with your 3rd-party identity provider for users with access to more sensitive information stored within Google. 
  • Use 2-Step Verification without additional costs. You can enforce these policies for users predominantly accessing Google resources at no additional cost. 

How to get started 


  • Admins: You can choose whether to enforce additional 2-Step Verification for users at Admin console > Security > Login challenges > Post-SSO verification. Use our Help Center to learn more about 2-Step Verification with 3rd-party identity providers
  • End users: If turned on, a user will simply have to complete the 2-Step Verification step using a familiar Google sign-in interface after they sign in to the 3rd-party identity provider. Learn more about Google 2-Step Verification


Admin controls available for verification enforcement when using a 3rd-party identity provider 

Helpful links 




Availability 

Rollout details


G Suite editions 
Available to all G Suite and Cloud Identity 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

Control session length for Google Cloud Console and gcloud CLI

What’s changing 

We’re opening a public beta so G Suite, Google Cloud Platform (GCP), and Cloud Identity admins can set a fixed session duration for specific apps and services. After the session expires, users will need to re-enter their login credentials to continue to access:
Settings can be customized for specific organizational units.

Note that this is designed to work on the web. However, the settings will apply to authentication on all platforms, including the web and mobile apps where they exist. As a result, affected mobile apps may not work properly when the feature is enabled.

Who’s impacted 

Admins only

Why you’d use it 

Many apps and services include sensitive data, and it’s important that only specific users can access that information. By requiring re-authentication, you can make it more difficult for the wrong people to obtain that data if they gain unauthorized access to a device.

How to get started 

  • Admins: Find session length controls at Admin console > Security > Google Cloud session control (Beta). See our Help Center to learn more about how to set session length for Google Cloud services
  • End users: If a session ends, users will simply need to log in to their account again using the familiar Google login flow. 

Additional details 

Third-party SAML identity providers and session length controls 
If your organization uses a third-party SAML-based identity provider, the cloud sessions will expire, but the user may be transparently reauthenticated (i.e. without actually being asked to present their credentials) if their session with the IdP is valid at that time. This is working as intended, as Google will redirect the user to the IdP and accept a valid assertion from the IdP. To ensure that the user is rechallenged for authentication, be sure to match the session timeout at the IdP with the session length you’d like to enforce.

Provides fixed-time controls (not activity-based) 
Note that the new session control is a fixed time limit—it does not look for session activity, or ‘idle time’. At this time, Google Cloud and G Suite do not support activity-based session expiry.

Re-authentication options 
When choosing a session length, admins will be able to choose:
  • Between a range of predefined session lengths, or set a custom session length. 
  • Whether users need regular login credentials (password and, if configured, 2-Step Verification), or require a security key to re-authenticate. 


Helpful links 

Help Center: Beta: Set session length for Google Cloud services 

Availability 

Rollout details 


Editions 
Available to all G Suite and Cloud Identity 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

Automatically provision users with five additional apps

What’s changing 

We’re adding auto-provisioning support for five new applications:
  • Adobe 
  • Comeet
  • Foodee
  • RECOG
  • Spoke

Who’s impacted 

Admins only

Why you’d use it 

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.

How to get started 

  • Admins: For more information on how to set up auto-provisioning, check out the Help Center.
  • End users: No action needed.

Helpful links 

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

Availability 

Rollout details 

G Suite 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 

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

Admins can now see and edit user recovery information

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

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