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.
