Merge pull request #29 from xebia/6.2-GitHub-Administration

6.1 Authentication and Security + 6.2 GitHub administration

Author: Chukslord1

learn-pr/github/authenticate-authorize-user-identities-github/includes/5-team-synchronization.md

@@ -17,19 +17,28 @@ Team sync is ideal for enterprises looking to streamline membership management w
 
 > ⚠️ To use team sync, your IdP admin must enable **SAML SSO** and **SCIM**.
 
+## Enterprise Managed Users and GitHub Enterprise Server
 
-## Enterprise Managed Users
+Team synchronization is also available for organizations and enterprise accounts that use GitHub Enterprise Cloud or [GitHub Enterprise Server (GHE.com)](https://github.com/enterprise), which is the preferred solution in regions where it is available or required for compliance reasons.
 
-If you're using **Enterprise Managed Users** in GitHub Enterprise Cloud, all members are provisioned through your IdP. Users don't self-manage GitHub accounts and can't access resources outside the enterprise.
+**Enterprise Managed Users (EMUs)** are a GitHub Enterprise Cloud feature that gives enterprises complete control over user identity and account lifecycle. With EMUs, GitHub accounts are fully managed by the enterprise’s identity provider (IdP). This means users do not sign up for GitHub manually—all user provisioning, access, and offboarding is automated through tools like Microsoft Entra ID or Okta.
 
-With this model, you can:
+EMUs are ideal for organizations with strict compliance, audit, or user governance needs. They help ensure that:
 
-- Manage organization/team membership directly through your IdP
-- Ensure GitHub users are enterprise-scoped and isolated
+* All accounts are owned by the enterprise
+* Access is automatically granted or removed based on IdP membership
+* No external collaboration happens unintentionally
 
-For more, see [Getting started with GitHub Enterprise Cloud](https://docs.github.com/get-started/onboarding/getting-started-with-github-enterprise-cloud).
+When using EMUs:
 
+* Managed users cannot push code to or fork repositories outside the enterprise
+* They can only interact with other users and resources inside the enterprise
 
+You can manage EMU-based organization and team membership using groups in your IdP, and optionally integrate [team synchronization](#enable-team-synchronization) to automate group-to-team mapping.
+
+For organizations with requirements around self-hosting or specific regional regulations, **GitHub Enterprise Server (GHE.com)** offers an on-premises solution that allows you to maintain full control of your GitHub environment.
+
+For more details, see [Getting started with GitHub Enterprise Cloud](https://docs.github.com/get-started/onboarding/getting-started-with-github-enterprise-cloud) and [About GitHub Enterprise Server](https://docs.github.com/en/enterprise-server@latest).
 
 ## Team Synchronization vs. SCIM for GHES 
 

learn-pr/github/github-introduction-administration/includes/3-how-github-authentication-works.md

@@ -1,12 +1,12 @@
-In the previous unit, you learned about typical administration tasks at the team, organization, and enterprise level. In this unit, you'll deep dive into one of the most common administrative tasks performed by organization owners, which is setting up and controlling users' authentication to GitHub.
+In the previous unit, you learned about typical administration tasks at the team, organization, and enterprise level. In this unit, you’ll explore one of the most common administrative tasks performed by organization owners, which is setting up and controlling users' authentication to GitHub.
 
 ## GitHub's authentication options
 
 There are several options for authenticating with GitHub:
 
 ### Username and password
 
-Administrators can allow users to continue using the default username and password authentication method, sometimes known as the "basic" HTTP authentication scheme. In recent years, basic authentication has proven to be too risky when dealing with highly sensitive information. We strongly recommend using one (or several) of the other options listed in this unit.
+Administrators can allow users to continue using the default username and password authentication method, sometimes known as the "basic" HTTP authentication scheme. **Note: GitHub no longer supports password authentication for Git operations or API usage.** We strongly recommend using one (or several) of the other options listed in this unit.
 
 ### Personal access tokens
 
@@ -26,41 +26,54 @@ You can even use SSH keys with a repository owned by an organization that uses S
 
 Deploy keys are another type of SSH key in GitHub that grants a user access to a single repository. GitHub attaches the public part of the key directly to the repository instead of a personal user account, and the private part of the key remains on the user's server. Deploy keys are read-only by default, but you can give them write access when adding them to a repository.
 
+To configure fork settings:
+
+1. Go to the repository’s **Settings**.
+1. In the left sidebar, under Security, click **Deploy keys**.
+1. Locate the **Add deploy key** option to create a new key.
+
+:::image type="content" source="../media/deployment-keys.png" alt-text="Screenshot showing the Add deploy key on the Deploy keys option." border="false":::
+
 ## GitHub's added security options
 
-GitHub also offers the following extra security options.
+GitHub provides a range of security options to help protect accounts and organizational resources.
 
 ### Two-factor authentication
 
 :::image type="content" source="../media/2-factor-authentication.png" alt-text="Screenshot of the two-factor authentication screen.":::
 
-Two-factor authentication (2FA), sometimes known as multifactor authentication (MFA), is an extra layer of security used when logging into websites or apps. With 2FA, users have to sign in with their username and password and provide another form of authentication that only they have access to.
+Two-factor authentication (2FA), sometimes known as multifactor authentication (MFA), adds an extra layer of protection to your GitHub account. With 2FA, users sign in with their username and password, and then provide a second form of authentication.
 
-For GitHub, the second form of authentication is a code generated by an application on a user's mobile device or sent as a text message (SMS). After a user enables 2FA, GitHub generates an authentication code anytime someone attempts to sign into their GitHub account. Users can only sign into their account if they know their password and have access to the authentication code on their phone.
+GitHub supports several second-factor options:
+- Authenticator apps (like Microsoft Authenticator, Google Authenticator, or Authy) that generate time-based one-time codes.
+- Hardware security keys (such as YubiKey or Titan Security Key) that support FIDO2/WebAuthn.
+- Passkeys for passwordless, phishing-resistant authentication.
+- SMS-based codes, which are supported but considered less secure than other options and are not recommended as a primary method.
 
-Organization owners can require organization members, outside collaborators, and billing managers to enable 2FA for their personal accounts. This action makes it harder for malicious actors to access an organization's repositories and settings.
+**2FA enforcement:**
 
-Enterprise owners can also enforce certain security policies for all organizations owned by an enterprise account.
+- For organizations on GitHub Team and GitHub Enterprise Cloud, organization owners can require members, outside collaborators, and billing managers to enable 2FA for their personal accounts.
+- Enterprise Managed Users (EMUs) and GitHub Enterprise Server (GHE.com): Admins can require 2FA for enterprise-managed accounts only, but cannot enforce 2FA on users’ personal GitHub.com accounts.
 
-### SAML SSO
+Enforcing 2FA helps protect organizations from unauthorized access and strengthens the security of repositories and sensitive data.
 
-If you centrally manage your users' identities and applications with an IdP, you can configure SAML SSO to protect your organization's resources on GitHub.
-
-This type of authentication gives organization and enterprise owners on GitHub a way to control and secure access to organization resources like repositories, issues, and pull requests. Organization owners can invite GitHub users to join the organization that uses SAML SSO, which allows those users to contribute to the organization and retain their existing identity and contributions on GitHub.
+### SAML SSO
 
-When users access resources within an organization that uses SAML SSO, GitHub will redirect them to the organization's SAML IdP for authentication. After they successfully authenticate with their account on the IdP, the IdP redirects to GitHub to access the organization's resources.
+If you centrally manage your users' identities with an identity provider (IdP), you can configure SAML single sign-on (SSO) to protect your organization’s resources on GitHub. SAML SSO allows organization and enterprise owners to control and secure access to repositories, issues, pull requests, and more. When accessing resources, GitHub redirects users to authenticate with the organization’s IdP.
 
-GitHub offers limited support for all identity providers that implement the SAML 2.0 standard with official support for several popular identity providers including:
+GitHub supports all identity providers that implement the SAML 2.0 standard, with official support for several popular providers, including:
 
 - Active Directory Federation Services (AD FS).
 - Microsoft Entra ID.
 - Okta.
 - OneLogin.
 - PingOne.
 
-### LDAP
+### LDAP (GitHub Enterprise Server)
+
+LDAP (Lightweight Directory Access Protocol) is a widely used protocol for accessing and managing user directory information. On GitHub Enterprise Server, LDAP integration allows you to authenticate users against your existing company directory and manage repository access centrally.
 
-Lightweight directory access protocol (LDAP) is a popular application protocol for accessing and maintaining directory information services. LDAP lets you authenticate GitHub Enterprise Server against your existing accounts and centrally manage repository access. It's one of the most common protocols used to integrate third-party software with large company user directories.
+GitHub Enterprise Server integrates with major LDAP services such as:
 
 GitHub Enterprise Server integrates with popular LDAP services like:
 

learn-pr/github/github-introduction-administration/includes/4-how-github-organization-permission-works.md

@@ -7,24 +7,53 @@ In the previous unit, you explored the different ways that users can authenticat
 
 ## Repository permission levels
 
-You can customize access to a given repository by assigning permissions. There are five repository-level permissions:
+You can customize access to each repository by assigning specific permission levels. There are five standard repository-level permissions:
 
 - **Read**: Recommended for non-code contributors who want to view or discuss your project. This level is good for anyone that needs to view the content within the repository but doesn't need to actually make contributions or changes.
 - **Triage**: Recommended for contributors who need to proactively manage issues and pull requests without write access. This level could be good for some project managers who manage tracking issues but don't make any changes.
 - **Write**: Recommended for contributors who actively push to your project. Write is the standard permission for most developers.
 - **Maintain**: Recommended for project managers who need to manage the repository without access to sensitive or destructive actions.
 - **Admin**: Recommended for people who need full access to the project, including sensitive and destructive actions like managing security or deleting a repository. These people are repository owners and administrators.
 
-You can give organization members, outside collaborators, and teams different levels of access to repositories owned by an organization. Each permission level progressively increases access to a repository's content and settings. Choose the level that best fits each person or team's role in your project without giving more access to the project than necessary.
+You can assign different permission levels to organization members, outside collaborators, and teams for repositories owned by your organization. Each permission level increases access to the repository’s content and settings. Always choose the minimum level of access required for each person or team’s responsibilities.
 
-After you create a repository with the correct permissions, you can make it a template so that anyone who has access to the repository can generate a new repository that has the same directory structure and files as your default branch. To make a template:
+Administrators can also create custom roles in GitHub Enterprise, extending one of these base roles with additional permissions as needed.
 
-1. On GitHub.com, go to the main page of the repository.
-1. Under the repository name, select **Settings**. If you can't see the **Settings** tab, open the dropdown menu, and then select **Settings**.
+### What is repository forking?
 
-    :::image type="content" source="../media/repository-actions-settings.png" alt-text="Screenshot showing where to locate the settings button in your GitHub repository.":::
+Forking is a way to create a personal copy of someone else's repository under your own GitHub account. When you fork a repository, you get your own version that you can freely modify without affecting the original project. This process is a common workflow for contributing to open source or experimenting with changes safely.
 
-1. Select **Template repository**.
+You can also keep your fork up to date by pulling in changes from the original repository, often called the “upstream” repo.
+
+Here’s how to fork a repository:
+
+1. On GitHub.com, navigate to the main page of the repository you want to fork.
+2. In the upper-right corner, select **Fork**.
+3. Choose an owner for the fork (your personal account or an organization).
+4. Optionally, rename the forked repository or include all branches.
+5. Select **Create fork**.
+
+    :::image type="content" source="../media/fork-repo-option.png" alt-text="Screenshot showing the fork button in the top-right corner of a GitHub repository." border="false":::
+
+### Managing fork permissions (for admins)
+
+For organization-owned repositories, administrators can control whether repositories can be forked:
+
+- **Public repositories**: Forking is always allowed.
+- **Private repositories**: Forking can be disabled or restricted to organization members only.
+- **Internal repositories**: These can only be forked within the same enterprise account.
+
+To configure fork settings:
+
+1. Go to the Organization repository’s **Settings**.
+1. In the left sidebar, under Access, click **Member privileges**.
+1. Locate the **Repository forking** options and update them as needed.
+
+    :::image type="content" source="../media/fork-repo-manage.png" alt-text="Screenshot showing the fork permissions of a GitHub Organization." border="false":::
+
+**Tip:** If you disable forking for a private repository, no one (including organization members) will be able to fork it.
+
+To learn more, see the GitHub Docs article on [Fork a repo](https://docs.github.com/en/get-started/quickstart/fork-a-repo).
 
 ## Ways Users Receive Repository Access
 

learn-pr/github/github-introduction-administration/media/deployment-keys.png

@@ -1,7 +1,7 @@
 Here, we discuss some of the essential security tools and techniques available to GitHub repository administrators. 
 
 >[!Note]
-> The following content doesn't cover the fundamentals of writing secure code, but rather important security considerations, tools, and features to use within a GitHub repository.
+> This content focuses on **important security considerations, tools, and features to use within a GitHub repository.
 
 ## The importance of a secure development strategy
 
@@ -51,6 +51,7 @@ From the Security tab, you can add features to your GitHub workflow to help avoi
 - **Dependabot alerts** that notify you when GitHub detects that your repository is using a vulnerable dependency or malware.
 - **Security advisories** that you can use to privately discuss, fix, and publish information about security vulnerabilities in your repository.
 - **Code scanning** that helps you find, triage, and fix vulnerabilities and errors in your code.
+- **Secret scanning** that detects tokens, credentials, and secrets committed to your repo and can block them before the push. **Push protection** is enabled by default on public repositories.
 
 For more information, see [GitHub security features](https://docs.github.com/code-security/getting-started/github-security-features).
 
@@ -116,6 +117,26 @@ You can use the workflows that protect the branch to:
 - Run automated tests to check for any behavior changes of the code;
 - And so on.
 
+## Required reviewers in pull requests
+
+You can improve repository security by requiring reviews before code is merged into important branches. Required reviewers help enforce quality, security, and accountability.
+
+To configure required reviewers:
+
+1. Navigate to the repository on GitHub.
+2. Under the repository name, click **Settings** > **Branches**.
+3. Next to the branch you want to protect, click **Add rule** or edit an existing rule.
+4. Select **Require pull request reviews before merging**.
+5. Optionally, check:
+   - **Require review from Code Owners**
+   - **Dismiss stale pull request approvals when new commits are pushed**
+   - **Require approval from someone other than the last pusher**
+
+Required reviews can’t be bypassed without admin permissions. They ensure that proposed changes are reviewed by another contributor or designated code owner before being merged.
+
+For more details, see [About protected branches](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches).
+
+
 ## Add a CODEOWNERS file
 
 By adding a [CODEOWNERS](https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners#codeowners-syntax) file to your repository, you can assign individual team members or entire teams as code owners to paths in your repository. These code owners are then required for pull-request reviews on any changes to files in a path for which they're configured.