Welcome to module two.
Hopefully you're now up and running with cloud identity.
Let's begin by talking about the idea of user lifecycle management.
Now that you're in the admin console,
you'll be able to start adding users.
Thoughtfully managing your users allows you to track them from
beginning to the end as they join the organization,
move within the organization,
and leave the organization.
In this module, you'll be introduced to
several key concepts for managing the user's lifecycle.
You'll also practice applying many of them.
By the end of this module,
you'll be able to create Google accounts,
you'll be able to manage user accounts,
you'll be able to explain sinking users to your domain using Google cloud directory sync,
you'll be able to assign roles and apply policies to specific users and groups,
and you'll be able to explain automated user provisioning into third-party applications.
Let's focus on user accounts for a few moments.
Before people in your organization can be managed using cloud identity,
you need to create those user accounts for each person.
An account provides users with a profile,
which gives them a user ID and a password for
signing and to access your organization's services.
The accounts also gives you the ability to manage users in your domain,
from assigning user roles and privileges,
to resetting passwords through admin console.
Your users will also be added to a directory
that serves as the repository for a user account information,
and connect to existing sources of identity information across your organization.
If your organization has an existing directory,
and needs to move users over into cloud identity domain,
you can use Google Cloud Directory Sync or GCDS
to synchronize user's data into your existing directory with your Google account.
With GCDS, you can sync the data in your Google domain
with existing Microsoft active directory or LDAP servers.
The data you move into directory server is never modified.
GCDS is a secure tool that helps you easily sync existing users,
shared users and contact, groups, and licenses.
As an administrator, you can organize users into groups to easily
email everyone without having to enter each person's individual address.
You can assign group roles to a user,
like a group owner,
manager, or a member.
It's easy to create a group for your organization as well,
using either the group control in the admin console,
or the Google groups for business service.
You can migrate to your existing mailing list on
an LDAP server to Google groups to create multiple groups at once.
You can also use sync which will allow your groups
from an LDAP server to be updated on a constant rolling basis.
After you get your users into cloud identity,
you can start applying different users and device policy.
You can limit which users have access to different services,
and tailor those settings by turning services on or off,
and changing service settings for different users or groups.
You can also apply different settings to a group of
users or devices called an organizational unit,
that has specific requirements.
After moving certain users and devices into different organizational units,
apply your design settings to each of those units as needed.
This is the basis of how you quickly turn services on or off,
and apply policies to large group of users.
You can share the responsibility of managing
your Google account by delegating the responsibility to other users.
Assigning administrative privileges grants
the delegated admin access to your admin console.
The easiest way to grant administrator privileges to
another user is to assign pre-built admin roles.
Each role grants one or more privileges that
together allow the user to perform a common business function.
For example, you can make a user a super administrator,
who can then perform all the tasks in the admin console.
Some task that a super admin can do that other roles cannot do are setting up billing,
creating and assigning administrator roles,
restoring deleted users, and performing email logs searches.
Or, you can assign a role that limits which tasks the administrator can perform,
like allowing them to only create groups,
or manage service settings,
or reset a user's password.
Allowing the cloud identities out of the box admin roles,
you can create custom roles.
Each custom role can include one or more admin privileges that let
the delegated admin perform specific management tasks in your admin console.
Now that you have created users,
defined your admin roles,
and moved them into different organizational units,
you can provision them into third-party cloud applications.
This allows you to cut down on the admin overhead
when managing users across your third-party cloud applications.
This means that when you add, modify,
or remove users from your domain,
those changes are automatically sent to all your third-party cloud applications.
You don't have to manage individual user IDs and password tied
to different cloud identity applications for each of those users.
Imagine a user leaves your organization.
By ensuring you're using the auto provisioning and deeper visioning features,
you're reducing the possible security attacks.
When the user leaves the organization and is removed from your directory,
the user will also be automatically deprovision from the other cloud applications.
Wow! that was a lot.
Now that we've gone through the core concept of user lifecycle management,
you're ready to start putting them into practice.
For this first set of exercises,
we're putting you in place of a system administrator,
who needs to ensure that your organization can get to
your small group of users into your new cloud identity instance.
In the following exercises,
let's practice now adding users into your cloud identity instance,
and setting up their roles.