With Enterprise Managed Users, you can control the user accounts of your enterprise members through your identity provider (IdP). Users assigned to the GitHub Enterprise Managed User application in your IdP are provisioned as new user accounts on GitHub and added to your enterprise. You control usernames, profile data, team membership, and repository access for the user accounts from your IdP.
In your IdP, you can give each managed user account the role of user, enterprise owner, or billing manager. Managed user accounts can own organizations within your enterprise and can add other managed user accounts to the organizations and teams within. For more information, see "Roles in an enterprise" and "About organizations."
When your enterprise uses OIDC SSO, GitHub will automatically use your IdP's conditional access policy (CAP) IP conditions to validate user interactions with GitHub, when members change IP addresses, and each time a personal access token or SSH key is used. For more information, see "About support for your IdP's Conditional Access Policy."
You can grant managed user accounts access to and the ability to contribute to repositories within your enterprise, but managed user accounts cannot create public content or collaborate with other users, organizations, and enterprises on the rest of GitHub. For more information, see "Abilities and restrictions of managed user accounts."
The usernames of your enterprise's managed user accounts and their profile information, such as display names and email addresses, are set by through your IdP and cannot be changed by the users themselves. For more information, see "Usernames and profile information."
Enterprise owners can audit all of the managed user accounts' actions on GitHub. For more information, see "Audit log events for your enterprise."
To use Enterprise Managed Users, you need a separate type of enterprise account with Enterprise Managed Users enabled. For more information about creating this account, see "About enterprises with managed users."
Note: There are multiple options for identity and access management with GitHub Enterprise Cloud, and Enterprise Managed Users is not the best solution for every customer. For more information about whether Enterprise Managed Users is right for your enterprise, see "About authentication for your enterprise."
Organization memberships can be managed manually, or you can update memberships automatically using IdP groups. To manage organization memberships through your IdP, the members must be added to an IdP group, and the IdP group must be connected to a team within the organization. For more information about managing organization and team memberships automatically, see "Managing team memberships with identity provider groups."
The way a member is added to an organization owned by your enterprise (through IdP groups or manually) determines how they must be removed from an organization.
- If a member was added to an organization manually, you must remove them manually. Unassigning them from the GitHub Enterprise Managed User application on your IdP will suspend the user but not remove them from the organization.
- If a user became a member of an organization because they were added to IdP groups mapped to one or more teams in the organization, removing them from all of the mapped IdP groups associated with the organization will remove them from the organization.
To discover how a member was added to an organization, you can filter the member list by type. For more information, see "Viewing people in your enterprise."
Enterprise Managed Users supports the following IdPs and authentication methods:
|Azure Active Directory|
Managed user accounts can only contribute to private and internal repositories within their enterprise and private repositories owned by their user account. Managed user accounts have read-only access to the wider GitHub community. These visibility and access restrictions for users and content apply to all requests, including API requests.
- Managed user accounts cannot be invited to organizations or repositories outside of the enterprise, nor can the managed user accounts be invited to other enterprises.
- Outside collaborators are not supported by Enterprise Managed Users.
- Managed user accounts cannot create issues or pull requests in, comment or add reactions to, nor star, watch, or fork repositories outside of the enterprise.
- Managed user accounts can view all public repositories on GitHub.com, but cannot push code to repositories outside of the enterprise.
- Managed user accounts and the content they create is only visible to other members of the enterprise.
- Managed user accounts cannot follow users outside of the enterprise.
- Managed user accounts cannot create gists or comment on gists.
- Managed user accounts cannot create starter workflows for GitHub Actions.
- Managed user accounts cannot install GitHub Apps on their user accounts.
- Other GitHub users cannot see, mention, or invite a managed user account to collaborate.
- You can choose whether managed user accounts are able to create repositories owned by their user accounts. For more information, see "Enforcing repository management policies in your enterprise."
- If you allow managed user accounts to create repositories owned by their user accounts, they can only own private repositories and can only invite other enterprise members to collaborate on their user-owned repositories.
- Os Managed user accounts não podem criar fork de repositórios de fora da empresa. Managed user accounts pode criar fork de repositórios privados ou internos pertencentes a organizações da empresa em seu namespace de conta de usuário ou em outras organizações pertencentes à empresa, conforme especificado pela política corporativa.
- Only private and internal repositories can be created in organizations owned by an enterprise with managed users, depending on organization and enterprise repository visibility settings.
- Managed user accounts are limited in their use of GitHub Pages. For more information, see "About GitHub Pages."
Before your developers can use GitHub Enterprise Cloud with Enterprise Managed Users, you must follow a series of configuration steps.
To use Enterprise Managed Users, you need a separate type of enterprise account with Enterprise Managed Users enabled. To try out Enterprise Managed Users or to discuss options for migrating from your existing enterprise, please contact GitHub's Sales team.
Your contact on the GitHub Sales team will work with you to create your new enterprise with managed users. You'll need to provide the email address for the user who will set up your enterprise and a short code that will be used as the suffix for your enterprise members' usernames. O código curto precisa ser exclusivo da sua empresa, uma cadeia de caracteres alfanumérica de três a oito caracteres e não deve conter caracteres especiais. For more information, see "Usernames and profile information."
After we create your enterprise, you will receive an email from GitHub inviting you to choose a password for your enterprise's setup user, which will be the first owner in the enterprise. Use an incognito or private browsing window when setting the password. The setup user is only used to configure single sign-on and SCIM provisioning integration for the enterprise. It will no longer have access to administer the enterprise account once SSO is successfully enabled. The setup user's username is your enterprise's shortcode suffixed with
Caso precise redefinir a senha para o usuário de instalação, entre em contato com o Suporte do GitHub por meio do Portal de suporte do GitHub.
After you log in as the setup user, we recommend enabling two-factor authentication. For more information, see "Configuring two-factor authentication."
To get started, configure how your members will authenticate. If you are using Azure Active Directory as your identity provider, you can choose between OpenID Connect (OIDC) and Security Assertion Markup Language (SAML). We recommend OIDC, which includes support for Conditional Access Policies (CAP). If you require multiple enterprises with managed user accounts provisioned from one tenant, you must use SAML for each enterprise after the first. If you are using Okta as your identity provider, you can use SAML to authenticate your members.
To get started, read the guide for your chosen authentication method.
Once you have configured SSO, you can configure SCIM provisioning. SCIM is how your identity provider will create managed user accounts on GitHub.com. For more information on configuring SCIM provisioning, see "Configuring SCIM provisioning for enterprise managed users."
Once authentication and provisioning are configured, you can start managing organization membership for your managed user accounts by synchronizing IdP groups with teams. For more information, see "Managing team memberships with identity provider groups."
If members of your enterprise must use one workstation to contribute to repositories on GitHub.com from both a managed user account and a personal account, you can provide support. For more information, see "Supporting developers with multiple user accounts on GitHub.com."
Managed user accounts must authenticate through their identity provider. To authenticate, a managed user account can visit their IdP application portal or use the login page on GitHub.com.
By default, when an unauthenticated user attempts to access an enterprise that uses Enterprise Managed Users, GitHub displays a 404 error. An enterprise owner can optionally enable automatic redirects to single sign-on (SSO) instead of the 404. For more information, see "Enforcing policies for security settings in your enterprise."
Se um erro de configuração do SAML ou um problema com o IdP (provedor de identidade) impedir que você use o SSO do SAML, use um código de recuperação para acessar sua empresa. For more information, see "Managing recovery codes for your enterprise."
- Navigate to https://github.com/login.
- In the "Username or email address" text box, enter your username including the underscore and short code. When the form recognizes your username, the form will update. You do not need to enter your password on this form.
- To continue to your identity provider, click Sign in with your identity provider.
GitHub Enterprise Cloud automatically creates a username for each person by normalizing an identifier provided by your IdP. For more information, see "Username considerations for external authentication."
A conflict may occur when provisioning users if the unique parts of the identifier provided by your IdP are removed during normalization. If you're unable to provision a user due to a username conflict, you should modify the username provided by your IdP. For more information, see "Resolving username problems."
Note: Because GitHub adds an underscore and short code to the normalized identifier provided by your IdP when creating each username, conflicts can only occur within each enterprise with managed users. Managed user accounts can share IdP identifiers or email addresses with other user accounts on GitHub.com that are outside the enterprise.
The profile name and email address of a managed user account is also provided by the IdP. Managed user accounts cannot change their profile name or email address on GitHub, and the IdP can only provide a single email address.
People on your team may need to contribute to resources on GitHub.com that are outside of your enterprise with managed users. For example, you may wish to maintain a separate enterprise for your company's open source projects. Because a managed user account cannot contribute to public resources, users will need to maintain a separate, personal account for this work.
People who must contribute from two user accounts on GitHub.com using one workstation can configure Git to simplify the process. For more information, see "Managing multiple accounts."