Enforcing security settings in your enterprise account

Enterprise owners can enforce certain security policies for all organizations owned by an enterprise account.

Enterprise accounts are available with GitHub Enterprise Cloud and GitHub Enterprise Server. For more information, see "About enterprise accounts."

In this article

Requiring two-factor authentication for organizations in your enterprise account

Enterprise owners can require that organization members, billing managers, and outside collaborators in all organizations owned by an enterprise account use two-factor authentication to secure their personal accounts.

Before you can require 2FA for all organizations owned by your enterprise account, you must enable two-factor authentication for your own account. For more information, see "Securing your account with two-factor authentication (2FA)."

Warnings:

  • When you require two-factor authentication for your enterprise account, members, outside collaborators, and billing managers (including bot accounts) in all organizations owned by your enterprise account who do not use 2FA will be removed from the organization and lose access to its repositories. They will also lose access to their forks of the organization's private repositories. You can reinstate their access privileges and settings if they enable two-factor authentication for their personal account within three months of their removal from your organization. For more information, see "Reinstating a former member of your organization."
  • Any organization owner, member, billing manager, or outside collaborator in any of the organizations owned by your enterprise account who disables 2FA for their personal account after you've enabled required two-factor authentication will automatically be removed from the organization.
  • If you're the sole owner of a enterprise account that requires two-factor authentication, you won't be able to disable 2FA for your personal account without disabling required two-factor authentication for the enterprise account.

Before you require use of two-factor authentication, we recommend notifying organization members, outside collaborators, and billing managers and asking them to set up 2FA for their accounts. Organization owners can see if members and outside collaborators already use 2FA on each organization's People page. For more information, see "Viewing whether users in your organization have 2FA enabled."

  1. Navigate to your enterprise account by visiting https://github.com/enterprises/ENTERPRISE-NAME, replacing ENTERPRISE-NAME with your enterprise account's name.
  2. In the enterprise account sidebar, click Settings.
    Settings tab in the enterprise account sidebar
  3. In the left sidebar, click Security.
    Security tab in the enterprise account settings sidebar
  4. Under "Two-factor authentication", review the information about changing the setting. Optionally, to view the setting's current configuration for all organizations in the enterprise account before enforcing the setting, click View your organizations' current configurations.
    Link to view the current policy configuration for organizations in the business
  5. Under "Two-factor authentication", select Require two-factor authentication for all organizations in your business, then click Save.
    Checkbox to require two-factor authentication
  6. If prompted, read the information about members and outside collaborators who will be removed from the organizations owned by your enterprise account. To confirm the change, type your enterprise account's name, then click Remove members & require two-factor authentication.
    Confirm two-factor enforcement box
  7. Optionally, if any members or outside collaborators are removed from the organizations owned by your enterprise account, we recommend sending them an invitation to reinstate their former privileges and access to your organization. Each person must enable two-factor authentication before they can accept your invitation.

Managing allowed IP addresses for organizations in your enterprise account

Enterprise owners can restrict access to assets owned by organizations in an enterprise account by configuring an allow list for specific IP addresses. For example, you can allow access from only the IP address of your office network. The allow list for IP addresses will block access via the web, API, and Git from any IP addresses that are not on the allow list.

You can approve access for a single IP address, or a range of addresses, using CIDR notation. For more information, see "CIDR notation" on Wikipedia.

To enforce the IP allow list, you must first add IP addresses to the list, then enable the IP allow list. You must add your current IP address, or a matching range, before you enable the IP allow list.

You can also configure allowed IP addresses for an individual organization. For more information, see "Managing allowed IP addresses for your organization."

Adding an allowed IP address

  1. Navigate to your enterprise account by visiting https://github.com/enterprises/ENTERPRISE-NAME, replacing ENTERPRISE-NAME with your enterprise account's name.
  2. In the enterprise account sidebar, click Settings.
    Settings tab in the enterprise account sidebar
  3. In the left sidebar, click Security.
    Security tab in the enterprise account settings sidebar
  4. Under "IP Address", type an IP address, or range of addresses, in CIDR notation.
    Key field to add IP address
  5. Under "Description", type a description of the allowed IP address or range.
    Key field to add name for IP address
  6. Click Add.
    Add allowed ip address button

Enabling allowed IP addresses

  1. Navigate to your enterprise account by visiting https://github.com/enterprises/ENTERPRISE-NAME, replacing ENTERPRISE-NAME with your enterprise account's name.
  2. In the enterprise account sidebar, click Settings.
    Settings tab in the enterprise account sidebar
  3. In the left sidebar, click Security.
    Security tab in the enterprise account settings sidebar
  4. Under "IP allow list", select Enable IP allow list.
    Checkbox to allow IP addresses
  5. Click Save.

Editing an allowed IP address

  1. Navigate to your enterprise account by visiting https://github.com/enterprises/ENTERPRISE-NAME, replacing ENTERPRISE-NAME with your enterprise account's name.
  2. In the enterprise account sidebar, click Settings.
    Settings tab in the enterprise account sidebar
  3. In the left sidebar, click Security.
    Security tab in the enterprise account settings sidebar
  4. Under "IP allow list", to the right of the entry you want to edit, click Edit.
    Edit allowed IP address button
  5. Type an IP address, or range of addresses, in CIDR notation.
    Key field to add IP address
  6. Type a description of the allowed IP address or range.
    Key field to add name for IP address
  7. Click Update.

Deleting an allowed IP address

  1. Navigate to your enterprise account by visiting https://github.com/enterprises/ENTERPRISE-NAME, replacing ENTERPRISE-NAME with your enterprise account's name.
  2. In the enterprise account sidebar, click Settings.
    Settings tab in the enterprise account sidebar
  3. In the left sidebar, click Security.
    Security tab in the enterprise account settings sidebar
  4. Under "IP allow list", to the right of the entry you want to delete, click Delete.
    Delete allowed IP address button
  5. To permanently delete the entry, click Yes, delete this IP allow list entry.
    Permanently delete IP allow list entry button

Using GitHub Actions with an IP allow list

Warning: If you use an IP allow list and would also like to use GitHub Actions, you must use self-hosted runners. For more information, see "Hosting your own runners."

To allow your self-hosted runners to communicate with GitHub, add the IP address or IP address range of your self-hosted runners to the IP allow list. For more information, see "Adding an allowed IP address."

Enabling SAML single sign-on for organizations in your enterprise account

SAML SSO gives organization owners and enterprise owners on GitHub a way to control and secure access to organization resources like repositories, issues, and pull requests. For more information, see "About identity and access management with SAML single sign-on."

Enterprise owners can enable SAML SSO and centralized authentication through a SAML IdP across all organizations owned by an enterprise account. After you enable SAML SSO for your enterprise account, SAML SSO is enabled by default for all organizations owned by your enterprise account. All members will be required to authenticate using SAML SSO to gain access to the organizations where they are a member, and enterprise owners will be required to authenticate using SAML SSO when accessing an enterprise account.

To access each organization's resources on GitHub, the member must have an active SAML session in their browser. To access each organization's protected resources using the API and Git, the member must use a personal access token or SSH key that the member has authorized for use with the organization. Enterprise owners can view and revoke a member's linked identity, active sessions, or authorized credentials at any time. For more information, see "Viewing and managing a user's SAML access to your enterprise account."

We offer limited support for all identity providers that implement the SAML 2.0 standard. We officially support these identity providers that have been internally tested:

  • Active Directory Federation Services (AD FS)
  • Azure Active Directory (Azure AD)
  • Okta
  • OneLogin
  • PingOne
  • Shibboleth

If you're participating in the private beta for user provisioning for enterprise accounts, when you enable SAML for your enterprise account, SCIM provisioning and deprovisioning is enabled by default in GitHub. You can use provisioning to manage organization membership by configuring SCIM in your IdP. If you're not participating in the private beta, SCIM is not supported for enterprise accounts. For more information, see "Managing user provisioning for organizations in your enterprise account."

Note: Enabling authentication with SAML single sign-on for your enterprise account will override any existing organization-level SAML configurations.

For more detailed information about how to enable SAML using Okta, see "Configuring SAML single sign-on and SCIM for your enterprise account using Okta.

  1. Navigate to your enterprise account by visiting https://github.com/enterprises/ENTERPRISE-NAME, replacing ENTERPRISE-NAME with your enterprise account's name.
  2. In the enterprise account sidebar, click Settings.
    Settings tab in the enterprise account sidebar
  3. In the left sidebar, click Security.
    Security tab in the enterprise account settings sidebar
  4. Optionally, to view the setting's current configuration for all organizations in the enterprise account before enforcing the setting, click View your organizations' current configurations.
    Link to view the current policy configuration for organizations in the business
  5. Under "SAML single sign-on", select Enable SAML authentication.
    Checkbox for enabling SAML SSO
  6. In the Sign on URL field, type the HTTPS endpoint of your IdP for single sign-on requests. This value is available in your IdP configuration.
    Field for the URL that members will be forwarded to when signing in
  7. Optionally, in the Issuer field, type your SAML issuer's name. This verifies the authenticity of sent messages.
    Field for the SAML issuer's name
  8. Under Public Certificate, paste a certificate to verify SAML responses.
    Field for the public certificate from your identity provider
  9. To verify the integrity of the requests from your SAML issuer, click . Then in the Signature Method and Digest Method drop-downs, choose the hashing algorithm used by your SAML issuer.
    Drop-downs for the Signature Method and Digest method hashing algorithms used by your SAML issuer
  10. Before enabling SAML SSO for your enterprise, click Test SAML configuration to ensure that the information you've entered is correct.
    Button to test SAML configuration before enforcing
  11. Click Save.

Managing user provisioning for organizations in your enterprise account

Enterprise owners can manage organization membership in an enterprise account directly from an identity provider (IdP).

Note: User provisioning for enterprise accounts is currently in private beta and subject to change. To request access to the beta, contact our account management team.

If you use Okta as your IdP, you can use SCIM to manage organization membership in your enterprise account. SCIM automatically invites people to or removes people from organizations in your enterprise account based on whether they are members of the group that corresponds to each organization in your IdP.

If you're participating in the private beta for user provisioning for enterprise accounts, when you enable SAML for your enterprise account, SCIM provisioning and deprovisioning is enabled by default in GitHub. You can use provisioning to manage organization membership by configuring SCIM in your IdP. Optionally, you can also enable SAML provisioning and, separately, deprovisioning.

If you configure SCIM in your IdP, each time you make changes to group membership in your IdP, your IdP will make a SCIM call to GitHub to update the corresponding organization's membership. If you enable SAML provisioning, each time an enterprise member accesses a resource protected by your enterprise account's SAML configuration, that SAML assertion will trigger provisioning.

For each SCIM call or SAML assertion, GitHub will check the IdP groups the user belongs to and perform the following operations:

  • If the user is a member of an IdP group that corresponds to an organization owned by your enterprise account, and the user is not currently a member of that organization, add the user to the organization (SAML assertion) or send the user an email invitation to join the organization (SCIM call).
  • Cancel any existing invitations for the user to join an organization owned by your enterprise account.

For each SCIM call and, if you enable SAML deprovisioning, each SAML assertion, GitHub will also perform the following operation:

  • If the user is not a member of an IdP group that corresponds to an organization owned by your enterprise account, and the user is currently a member of that organization, remove the user from the organization.

If deprovisioning removes the last remaining owner from an organization, the organization will become unowned. Enterprise owners can assume ownership of unowned organizations. For more information, see "Managing unowned organizations in your enterprise account."

To enable user provisioning for your enterprise account using Okta, see "Configuring SAML single sign-on and SCIM for your enterprise account using Okta."

Managing team synchronization for organizations in your enterprise account

Enterprise owners can enable team synchronization between an IdP and GitHub to allow organization owners and team maintainers to connect teams in the organizations owned by your enterprise account with IdP groups.

When you synchronize a GitHub team with an IdP group, changes to the IdP group are reflected on GitHub automatically, reducing the need for manual updates and custom scripts. You can use an IdP with team synchronization to manage administrative tasks such as onboarding new members, granting new permissions for movements within an organization, and removing member access to the organization.

You can use team synchronization with your enterprise account with Azure AD.

After you enable team synchronization, team maintainers and organization owners can connect a team to an IdP group on GitHub or through the API. For more information, see "Synchronizing a team with an identity provider group" and "Team synchronization."

Warning: When you disable team synchronization, any team members that were assigned to a GitHub team through the IdP group are removed from the team and may lose access to repositories.

You can also configure and manage team synchronization for an individual organization. For more information, see "Managing team synchronization for your organization."

Prerequisites

Before you can enable team synchronization for your enterprise account:

Managing team synchronization for Azure AD

To enable team synchronization for Azure AD, your Azure AD installation needs the following permissions:

  • Read all users’ full profiles
  • Sign in and read user profile
  • Read directory data
  1. Navigate to your enterprise account by visiting https://github.com/enterprises/ENTERPRISE-NAME, replacing ENTERPRISE-NAME with your enterprise account's name.
  2. In the enterprise account sidebar, click Settings.
    Settings tab in the enterprise account sidebar
  3. In the left sidebar, click Security.
    Security tab in the enterprise account settings sidebar
  4. Confirm that SAML SSO is enabled. For more information, see "Managing SAML single sign-on for your organization."
  5. Under "Team synchronization", click Enable for Azure AD.
    Enable team synchronization button on security settings page
  6. To confirm team synchronization:
    • If you have IdP access, click Enable team synchronization. You'll be redirected to your identity provider's SAML SSO page and asked to select your account and review the requested permissions.
    • If you don't have IdP access, copy the IdP redirect link and share it with your IdP administrator to continue enabling team synchronization.
      Enable team synchronization redirect button
  7. Review the identity provider tenant information you want to connect to your enterprise account, then click Approve.
    Pending request to enable team synchronization to a specific IdP tenant with option to approve or cancel request
  8. To disable team synchronization, click Disable team synchronization.
    Disable team synchronization

Managing your enterprise account's SSH certificate authorities

Enterprise owners can add and delete an enterprise account's SSH certificate authorities (CA).

By adding an SSH CA to your enterprise account, you can allow members of any organization owned by your enterprise account to access that organization's repositories using SSH certificates you provide. You can require that members use SSH certificates to access organization resources,. For more information, see "About SSH certificate authorities."

Adding an SSH certificate authority

When you issue each client certificate, you must include an extension that specifies which GitHub user the certificate is for. For more information, see "About SSH certificate authorities."

  1. Navigate to your enterprise account by visiting https://github.com/enterprises/ENTERPRISE-NAME, replacing ENTERPRISE-NAME with your enterprise account's name.
  2. In the enterprise account sidebar, click Settings.
    Settings tab in the enterprise account sidebar
  3. In the left sidebar, click Security.
    Security tab in the enterprise account settings sidebar
  4. To the right of "SSH Certificate Authorities", click New CA.
    New CA button
  5. Under "Key," paste your public SSH key.
    Key field to add CA
  6. Click Add CA.
  7. Optionally, to require members to use SSH certificates, select Require SSH Certificates, then click Save.
    Require SSH Certificate checkbox and save button

Deleting an SSH certificate authority

Deleting a CA cannot be undone. If you want to use the same CA in the future, you'll need to upload the CA again.

  1. Navigate to your enterprise account by visiting https://github.com/enterprises/ENTERPRISE-NAME, replacing ENTERPRISE-NAME with your enterprise account's name.
  2. In the enterprise account sidebar, click Settings.
    Settings tab in the enterprise account sidebar
  3. In the left sidebar, click Security.
    Security tab in the enterprise account settings sidebar
  4. Under "SSH Certificate Authorities", to the right of the CA you want to delete, click Delete.
    Delete button
  5. Read the warning, then click I understand, please delete this CA.
    Delete confirmation button

Ask a human

Can't find what you're looking for?

Contact us