You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/azure-functions/functions-reference-python.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -216,7 +216,7 @@ When you deploy your project to a function app in Azure, the entire contents of
216
216
217
217
Azure Functions integrates well with [Azure Cosmos DB](../cosmos-db/introduction.md) for many [use cases](../cosmos-db/use-cases.md), including IoT, ecommerce, gaming, etc.
218
218
219
-
For example, for [event sourcing](https://learn.microsoft.com/azure/architecture/patterns/event-sourcing), the two services are integrated to power event-driven architectures using Azure Cosmos DB's [change feed](../cosmos-db/change-feed.md) functionality. The change feed provides downstream microservices the ability to reliably and incrementally read inserts and updates (for example, order events). This functionality can be leveraged to provide a persistent event store as a message broker for state-changing events and drive order processing workflow between many microservices (which can be implemented as [serverless Azure Functions](https://azure.com/serverless)).
219
+
For example, for [event sourcing](/azure/architecture/patterns/event-sourcing), the two services are integrated to power event-driven architectures using Azure Cosmos DB's [change feed](../cosmos-db/change-feed.md) functionality. The change feed provides downstream microservices the ability to reliably and incrementally read inserts and updates (for example, order events). This functionality can be leveraged to provide a persistent event store as a message broker for state-changing events and drive order processing workflow between many microservices (which can be implemented as [serverless Azure Functions](https://azure.com/serverless)).
The Teams user IDs can be retrieved using Graph APIs, which is detailed in [Graph documentation](https://learn.microsoft.com/graph/api/user-get?view=graph-rest-1.0&tabs=http).
130
+
The Teams user IDs can be retrieved using Graph APIs, which is detailed in [Graph documentation](/graph/api/user-get?tabs=http).
Copy file name to clipboardExpand all lines: articles/container-apps/quotas.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,7 +15,7 @@ ms.author: cshoe
15
15
16
16
The following quotas are on a per subscription basis for Azure Container Apps.
17
17
18
-
You can [request a quota increase in the Azure portal](https://learn.microsoft.com/azure/quotas/quickstart-increase-quota-portal).
18
+
You can [request a quota increase in the Azure portal](/azure/quotas/quickstart-increase-quota-portal).
19
19
20
20
The *Is Configurable* column in the following tables denotes a feature maximum may be increased. For more information, see [how to request a limit increase](faq.yml#how-can-i-request-a-quota-increase-).
21
21
@@ -55,7 +55,7 @@ The *Is Configurable* column in the following tables denotes a feature maximum m
55
55
For more information regarding quotas, see the [Quotas roadmap](https://github.com/microsoft/azure-container-apps/issues/503) in the Azure Container Apps GitHub repository.
56
56
57
57
> [!NOTE]
58
-
> For GPU enabled workload profiles, you need to request capacity via a [request for a quota increase in the Azure portal](https://learn.microsoft.com/azure/quotas/quickstart-increase-quota-portal).
58
+
> For GPU enabled workload profiles, you need to request capacity via a [request for a quota increase in the Azure portal](/azure/quotas/quickstart-increase-quota-portal).
59
59
60
60
> [!NOTE]
61
61
> [Free trial](https://azure.microsoft.com/offers/ms-azr-0044p) and [Azure for Students](https://azure.microsoft.com/free/students/) subscriptions are limited to one environment per subscription globally and ten (10) cores per environment.
Copy file name to clipboardExpand all lines: articles/key-vault/general/troubleshooting-access-issues.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -51,7 +51,7 @@ If you're creating an on-premises application, doing local development, or other
51
51
52
52
Give the AD group permissions to your key vault using the Azure CLI `az keyvault set-policy` command, or the Azure PowerShell Set-AzKeyVaultAccessPolicy cmdlet. See [Assign an access policy - CLI](assign-access-policy-cli.md) and [Assign an access policy - PowerShell](assign-access-policy-powershell.md).
53
53
54
-
The application also needs at least one Identity and Access Management (IAM) role assigned to the key vault. Otherwise it will not be able to log in and will fail with insufficient rights to access the subscription. Microsoft Entra groups with Managed Identities may require many hours to refresh tokens and become effective. See [Limitation of using managed identities for authorization](https://learn.microsoft.com/entra/identity/managed-identities-azure-resources/managed-identity-best-practice-recommendations#limitation-of-using-managed-identities-for-authorization)
54
+
The application also needs at least one Identity and Access Management (IAM) role assigned to the key vault. Otherwise it will not be able to log in and will fail with insufficient rights to access the subscription. Microsoft Entra groups with Managed Identities may require many hours to refresh tokens and become effective. See [Limitation of using managed identities for authorization](/entra/identity/managed-identities-azure-resources/managed-identity-best-practice-recommendations#limitation-of-using-managed-identities-for-authorization)
55
55
56
56
### How can I redeploy Key Vault with ARM template without deleting existing access policies?
Copy file name to clipboardExpand all lines: articles/trusted-signing/concept-trusted-signing-cert-management.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -28,7 +28,7 @@ In addition to the standard features, the certificates also include the followin
28
28
29
29
To help reduce the impact of signing misuse and abuse, Trusted Signing certificates are renewed daily and are only valid for 72 hours. These short-lived certificates enable revocation actions to be as acute as a single day or as broad as needed, to cover any incidents of misuse and abuse.
30
30
31
-
For example, if it's determined that a subscriber signed code that was malware or PUA (Potentially Unwanted Application) as defined by [How Microsoft identifies malware and potentially unwanted applications](https://learn.microsoft.com/microsoft-365/security/defender/criteria), the revocation actions can be isolated to only revoking the certificate that signed the malware or PUA. Thus, the revocation only impacts the code that was signed with that certificate, on the day it was issued, and not any of the code signed prior to or after that day.
31
+
For example, if it's determined that a subscriber signed code that was malware or PUA (Potentially Unwanted Application) as defined by [How Microsoft identifies malware and potentially unwanted applications](/microsoft-365/security/defender/criteria), the revocation actions can be isolated to only revoking the certificate that signed the malware or PUA. Thus, the revocation only impacts the code that was signed with that certificate, on the day it was issued, and not any of the code signed prior to or after that day.
@@ -43,7 +43,7 @@ A `1.3.6.1.4.1.311.97.990309390.766961637.194916062.941502583` value indicates a
43
43
A `1.3.6.1.4.1.311.97.1.3.1.29433.35007.34545.16815.37291.11644.53265.56135` value indicates a Trusted Signing subscriber using Private-Trust Identity Validation. The `1.3.6.1.4.1.311.97.1.3.1.` prefix is Trusted Signing's Private-Trust code signing type and the `29433.35007.34545.16815.37291.11644.53265.56135` is unique to the subscriber's Identity Validation for Private Trust. Because Private-Trust Identity Validations can be used for WDAC CI Policy signing, there's also a slightly different EKU prefix: `1.3.6.1.4.1.311.97.1.4.1.`. However, the suffix values match the durable identity value for the subscriber's Identity Validation for Private Trust.
44
44
45
45
> [!NOTE]
46
-
> The durable identity EKUs can be used in WDAC CI Policy settings to pin trust to an identity in Trusted Signing accordingly. Refer to [Use signed policies to protect Windows Defender Application Control against tampering](https://learn.microsoft.com/windows/security/application-security/application-control/windows-defender-application-control/deployment/use-signed-policies-to-protect-wdac-against-tampering) and [Windows Defender Application Control Wizard](https://learn.microsoft.com/windows/security/application-security/application-control/windows-defender-application-control/design/wdac-wizard) for WDAC Policy creation.
46
+
> The durable identity EKUs can be used in WDAC CI Policy settings to pin trust to an identity in Trusted Signing accordingly. Refer to [Use signed policies to protect Windows Defender Application Control against tampering](/windows/security/application-security/application-control/windows-defender-application-control/deployment/use-signed-policies-to-protect-wdac-against-tampering) and [Windows Defender Application Control Wizard](/windows/security/application-security/application-control/windows-defender-application-control/design/wdac-wizard) for WDAC Policy creation.
47
47
48
48
All Trusted Signing Public Trust certificates also contain the `1.3.6.1.4.1.311.97.1.0` EKU to be easily identified as a publicly trusted certificate from Trusted Signing. All EKUs are in addition to the Code Signing EKU (`1.3.6.1.5.5.7.3.3`) to identify the specific usage type for certificate consumers. The only exception is certificates from CI Policy Certificate Profile types, where no Code Signing EKU is present.
Copy file name to clipboardExpand all lines: articles/trusted-signing/concept-trusted-signing-resources-roles.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -53,15 +53,15 @@ Trusted Signing provides five total Certificate Profile types that all subscribe
53
53
54
54
-**Public Trust**
55
55
-**Public Trust**: Used for signing code and artifacts that can be publicly distributed. It's default trusted on the Windows platform for code signing.
56
-
-**VBS Enclave**: Used for signing [Virtualization-based Security Enclaves](https://learn.microsoft.com/windows/win32/trusted-execution/vbs-enclaves) on Windows.
56
+
-**VBS Enclave**: Used for signing [Virtualization-based Security Enclaves](/windows/win32/trusted-execution/vbs-enclaves) on Windows.
57
57
-**Public Trust Test**: Used for test signing only and aren't publicly trusted by default. Consider Public Trust Test Certificate Profile as a great option for inner loop build signing.
58
58
59
59
> [!NOTE]
60
60
> All certificates under the Public Trust Test Certificate Profile type include the Lifetime EKU (1.3.6.1.4.1.311.10.3.13) forcing validation to respect the lifetime of the signing certificate regardless of the presence of a valid time stamp countersignature.
61
61
62
62
-**Private Trust**
63
-
-**Private Trust**: Used for signing internal or private artifacts such as Line of Business (LoB) applications and containers. It can also be used to sign [catalog files for Windows App Control for Business](https://learn.microsoft.com/windows/security/application-security/application-control/windows-defender-application-control/deployment/deploy-catalog-files-to-support-wdac).
64
-
-**Private Trust CI Policy**: The Private Trust CI Policy Certificate Profile is the only type that does NOT include the Code Signing EKU (1.3.6.1.5.5.7.3.3). It's specifically designed for [signing Windows App Control for Business CI policy files](https://learn.microsoft.com/windows/security/application-security/application-control/windows-defender-application-control/deployment/use-signed-policies-to-protect-wdac-against-tampering).
63
+
-**Private Trust**: Used for signing internal or private artifacts such as Line of Business (LoB) applications and containers. It can also be used to sign [catalog files for Windows App Control for Business](/windows/security/application-security/application-control/windows-defender-application-control/deployment/deploy-catalog-files-to-support-wdac).
64
+
-**Private Trust CI Policy**: The Private Trust CI Policy Certificate Profile is the only type that does NOT include the Code Signing EKU (1.3.6.1.5.5.7.3.3). It's specifically designed for [signing Windows App Control for Business CI policy files](/windows/security/application-security/application-control/windows-defender-application-control/deployment/use-signed-policies-to-protect-wdac-against-tampering).
Copy file name to clipboardExpand all lines: articles/trusted-signing/concept-trusted-signing-trust-models.md
+10-10Lines changed: 10 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,7 +17,7 @@ This article explains the concept of trust models, the primary trust models that
17
17
18
18
A trust model defines the rules and mechanisms for validating digital signatures and ensuring the security of communications in a digital environment. In other words, trust models define how trust is established and maintained within entities in a digital ecosystem.
19
19
20
-
For signature consumers like publicly trusted code signing for Microsoft Windows applications, trust models depend on signatures that have certificates from a Certification Authority (CA) that is part of the [Microsoft Root Certificate Program](https://learn.microsoft.com/security/trusted-root/program-requirements). This is primarily why Trusted Signing trust models are designed to support Windows Authenticode signing and security features that use code signing on Windows (e.g. [Smart App Control](https://learn.microsoft.com/windows/apps/develop/smart-app-control/overview) and [Windows Defender Application Control](https://learn.microsoft.com/windows/security/application-security/application-control/windows-defender-application-control/wdac)).
20
+
For signature consumers like publicly trusted code signing for Microsoft Windows applications, trust models depend on signatures that have certificates from a Certification Authority (CA) that is part of the [Microsoft Root Certificate Program](/security/trusted-root/program-requirements). This is primarily why Trusted Signing trust models are designed to support Windows Authenticode signing and security features that use code signing on Windows (e.g. [Smart App Control](/windows/apps/develop/smart-app-control/overview) and [Windows Defender Application Control](/windows/security/application-security/application-control/windows-defender-application-control/wdac)).
21
21
22
22
Trusted Signing provides two primary trust models to support a wide variety of signature consumption (validations):
23
23
@@ -29,14 +29,14 @@ Trusted Signing provides two primary trust models to support a wide variety of s
29
29
30
30
## Public-Trust
31
31
32
-
Public-Trust is one of the models provided in Trusted Signing and is the most commonly used model. The certificates in the Public-Trust model are issued from the [Microsoft Identity Verification Root Certificate Authority 2020](https://www.microsoft.com/pkiops/certs/microsoft%20identity%20verification%20root%20certificate%20authority%202020.crt) and complies with the [Microsoft PKI Services Third Party Certification Practice Statement (CPS)](https://www.microsoft.com/pkiops/docs/repository.htm). This root CA is included a relying party's root certificate program such as the [Microsoft Root Certificate Program](https://learn.microsoft.com/security/trusted-root/program-requirements) for the usage of code signing and timestamping.
32
+
Public-Trust is one of the models provided in Trusted Signing and is the most commonly used model. The certificates in the Public-Trust model are issued from the [Microsoft Identity Verification Root Certificate Authority 2020](https://www.microsoft.com/pkiops/certs/microsoft%20identity%20verification%20root%20certificate%20authority%202020.crt) and complies with the [Microsoft PKI Services Third Party Certification Practice Statement (CPS)](https://www.microsoft.com/pkiops/docs/repository.htm). This root CA is included a relying party's root certificate program such as the [Microsoft Root Certificate Program](/security/trusted-root/program-requirements) for the usage of code signing and timestamping.
33
33
34
34
The Public-Trust resources in Trusted Signing are designed to support the following signing scenarios and security features:
-[/INTEGRITYCHECK - Forced Integrity Signing for PE binaries](https://learn.microsoft.com/cpp/build/reference/integritycheck-require-signature-check?view=msvc-170)
39
-
-[Virtualization Based Security (VBS) Enclaves](https://learn.microsoft.com/windows/win32/trusted-execution/vbs-enclaves)
-[/INTEGRITYCHECK - Forced Integrity Signing for PE binaries](/cpp/build/reference/integritycheck-require-signature-check)
39
+
-[Virtualization Based Security (VBS) Enclaves](/windows/win32/trusted-execution/vbs-enclaves)
40
40
41
41
Public-Trust is recommended for signing any artifact that is to be shared publicly and for the signer to be a validated legal organization or individual.
42
42
@@ -45,12 +45,12 @@ Public-Trust is recommended for signing any artifact that is to be shared public
45
45
46
46
## Private-Trust
47
47
48
-
Private-Trust is the other trust model provided in Trusted Signing. It's for opt-in trust where the signatures aren't broadly trusted across the ecosystem. The CA hierarchy used for Trusted Signing's Private-Trust resources isn't default trusted in any root program and in Windows. Rather, it's specifically designed for use in [App Control for Windows (formerly known as Windows Defender Application Control)](https://learn.microsoft.com/windows/security/application-security/application-control/windows-defender-application-control/wdac) features including:
48
+
Private-Trust is the other trust model provided in Trusted Signing. It's for opt-in trust where the signatures aren't broadly trusted across the ecosystem. The CA hierarchy used for Trusted Signing's Private-Trust resources isn't default trusted in any root program and in Windows. Rather, it's specifically designed for use in [App Control for Windows (formerly known as Windows Defender Application Control)](/windows/security/application-security/application-control/windows-defender-application-control/wdac) features including:
49
49
50
50
51
-
*[Use code signing for added control and protection with WDAC](https://learn.microsoft.com/windows/security/application-security/application-control/windows-defender-application-control/deployment/use-code-signing-for-better-control-and-protection)
52
-
*[Use signed policies to protect Windows Defender Application Control against tampering](https://learn.microsoft.com/windows/security/application-security/application-control/windows-defender-application-control/deployment/use-signed-policies-to-protect-wdac-against-tampering)
53
-
*[Optional: Create a code signing cert for Windows Defender Application Control](https://learn.microsoft.com/windows/security/application-security/application-control/windows-defender-application-control/deployment/create-code-signing-cert-for-wdac)
51
+
*[Use code signing for added control and protection with WDAC](/windows/security/application-security/application-control/windows-defender-application-control/deployment/use-code-signing-for-better-control-and-protection)
52
+
*[Use signed policies to protect Windows Defender Application Control against tampering](/windows/security/application-security/application-control/windows-defender-application-control/deployment/use-signed-policies-to-protect-wdac-against-tampering)
53
+
*[Optional: Create a code signing cert for Windows Defender Application Control](/windows/security/application-security/application-control/windows-defender-application-control/deployment/create-code-signing-cert-for-wdac)
54
54
55
55
For more information on how to configure and sign WDAC Policy with Trusted Signing reference, [Quickstart Guide](./quickstart.md)
0 commit comments