Updates

Author: PagelsR

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

@@ -11,26 +11,31 @@ Managing a team via your service provider allows you to save time and resources
 | Custom team/group maps | The team `slug` and group name will be matched automatically, unless you define a custom mapping with `syncmap.yml` |
 | Dynamic Config         | Utilize a `settings` file to derive Active Directory and GitHub settings |
 
-## Enterprise Managed Users
+## Enterprise Managed Users and GitHub Enterprise Server
 
-Team synchronization is also available for organizations and enterprise accounts that use GitHub Enterprise Cloud. Enterprise Managed Users is a feature of GitHub Enterprise Cloud that provides even greater control over enterprise members and resources.
+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.
 
-## Enterprise Managed Users
-
-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.
+**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.
 
 EMUs are ideal for organizations with strict compliance, audit, or user governance needs. They help ensure that:
-- All accounts are owned by the enterprise
-- Access is automatically granted or removed based on IdP membership
-- No external collaboration happens unintentionally
+
+* All accounts are owned by the enterprise
+* Access is automatically granted or removed based on IdP membership
+* No external collaboration happens unintentionally
 
 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.  
+* 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/get-started/learning-about-github/about-github-enterprise-server).
+
 
-For more details, see [Getting started with GitHub Enterprise Cloud](https://docs.github.com/get-started/onboarding/getting-started-with-github-enterprise-cloud).
+Randy
 
 ## Usage limits
 

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

@@ -26,41 +26,50 @@ 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.
 
+
+
+Randy
+
 ## 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,17 @@ 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:
-
-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**.
-
-    :::image type="content" source="../media/repository-actions-settings.png" alt-text="Screenshot showing where to locate the settings button in your GitHub repository.":::
-
-1. Select **Template repository**.
+Administrators can also create custom roles in GitHub Enterprise, extending one of these base roles with additional permissions as needed.
 
 ### What is repository forking?