Tag Archives: identity

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

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. 

SSO + network mask domains can now force Google password reset on next login

What’s changing 

We’re providing more control over user password policies for some customers using third-party identity providers (IdPs) via SAML. Previously, these customers could not enforce the “Require password change” setting for their users. Now, SSO customers who have a network mask defined can turn on this setting and force their users to change their Google password the next time they log in using their G Suite or Cloud Identity credentials.

Who’s impacted 

Admins only

Why you’d use it 

For many customers who use third-party IdPs via SAML, preventing “Require password change” is the desired behavior. Their users only need to know their credentials for their IdP so forcing them to change their Google password is not meaningful.

However, some G Suite admins in domains with a third-party IdP use a network mask to allow some of their users to log in using their G Suite or Cloud Identity credentials. In such deployments, there may be users who sign in using their G Suite credentials. For these users, admins may want to generate a temporary password and then have the user change it on the next login. This update will help admins of domains that use SSO and a network mask to do this.

How to get started 


  • Admins: This update will only impact domains with a SAML IdP configured for SSO and a network mask. To check if you have a network mask, go to Admin console > Security > Network masks and see if there’s information defined. 




  • Admins at domains with SAML IdP configured for SSO and a network mask can turn on the setting in the Admin console (“Require password change”) or via the Admin SDK (“Do Force password change on Next Login”). Once turned on, it will be enforced for that user’s next login. See the sample screenshot below. 




  • If your domain has SSO but does not have a network mask configured, then there will be no change. The required password change option will show as OFF and you won’t be able to turn it on. See the sample screenshot below. 


Helpful links 

Help Center: Set up single sign-on for managed Google Accounts using third-party Identity providers
G Suite Admin SDK documentation for updating user details 

Availability 

Rollout details 


G Suite editions 

  • Available to all G Suite editions 

On/off by default? 

  • The new setting is automatically available depending on whether or not an SSO domain has a network mask configured.

Stay up to date with G Suite launches

Consolidated Google Groups audit logs now available in G Suite and GCP

What’s changing 

Consolidated Google Groups audit logs are now available in the G Suite AdminSDK Reports API and GCP Cloud Audit Logs. Specifically you’ll notice:

  • Changes in the G Suite AdminSDK Reports API: We’re introducing a new consolidated log named groups_enterprise, which includes changes to groups and group memberships across all products and APIs. These were previously split across the groups and admin audit logs. 
  • Changes in GCP Cloud Audit Logging: We’re adding Google Groups information to Cloud Audit Logs (CAL) in Stackdriver. See our Cloud Blog post for more details on how this could help GCP customers. Note that this will not change visibility of these logs in the G Suite Admin console - it just adds them to Cloud Audit Logs (CAL) in Stackdriver as well. 


Who’s impacted 

G Suite and GCP Admins only

Why you’d use it 

These changes will help improve the security and usability of Groups as an IAM tool by streamlining administration, transparency, and access monitoring.

How to get started 


  • Admins: 
    • Changes in the G Suite AdminSDK Reports API: Get started with the AdminSDK Reports API. 
    • Changes in GCP Cloud Audit Logging: This is an opt-in feature that can be enabled at G Suite Admin console > Company profile > Legal & Compliance > Sharing options. 
  • End users: No action needed. 


Additional details 

Changes in the G Suite AdminSDK Reports API 
Changes to groups have historically been logged in either the groups or admin audit logs. Changes made in the Google Groups product are logged in the groups log while changes made through admin tools like the Admin console, AdminSDK, and GCDS are logged in the admin log. As part of our efforts to streamline administration and increase transparency, we’re introducing a new consolidated log named groups_enterprise, which includes changes to groups and group memberships across all products and APIs. This new log is now available through the AdminSDK Reports API and will be available in the Admin console in the future.

Changes in GCP Cloud Audit Logging 
Google Groups are the recommended way to grant access to GCP resources when using IAM policies. GCP customers have told us that having group audit logs available in Google Cloud Audit Logs would help streamline security and access monitoring. With that in mind, we’re adding Google Groups information to Cloud Audit Logs (CAL) in Stackdriver. See our Cloud Blog post for more details on how this can help GCP customers.

Helpful links 

Cloud Blog: Integrated Google Groups Audit Transparency from G Suite to GCP Cloud Audit Logs 
Get started with the G Suite AdminSDK Reports API 

Availability 

Rollout details 


G Suite editions 
  • Google Groups are available to all G Suite editions. 

On/off by default? 
  • G Suite AdminSDK Reporting API for consolidate group events will be ON by default. 
  • GCP Cloud Audit Logging for groups will be OFF by default and can be enabled at the domain level.


Stay up to date with G Suite launches

Automatically provision users with three additional apps

What’s changing 

We’re adding auto-provisioning support for three new applications:
  • Hootsuite
  • Huddle
  • OfficeSpace

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

Android phone’s built-in security key now generally available

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

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

What’s changing 

We’re adding SAML integration for six additional applications:
  • Comeet
  • CyberArk
  • Drift
  • Qmarkets
  • Qualtrics
  • Swrve
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