Simplify Your Azure Kubernetes Service Connection Configuration with Service Connector

Simplify Your Azure Kubernetes Service Connection Configuration with Service Connector

This article is contributed. See the original author and article here.

Workloads deployed on an Azure Kubernetes Service (AKS) cluster often need to access Azure backing resources, such as Azure Key Vault, databases, or AI services like Azure OpenAI Service. Users are required to manually configure Microsoft Entra Workload ID or Managed Identities so their AKS workloads can securely access these protected resources.

The Service Connector integration greatly simplifies the connection configuration experience for AKS workloads and Azure backing services. Service Connector takes care of authentication and network configurations securely and follows Azure best practices, so you can focus on your application code without worrying about your infrastructure connectivity.


Service Connector Action Breakdown


Before, in order to connect from AKS pods to a private Azure backing services using workload identity, users needed to perform the following actions manually:

  1. Create a managed identity

  2. Retrieve the OIDC issuer URL

  3. Create Kubernetes service account

  4. Establish federated identity credential trust

  5. Grant permissions to access Azure Services

  6. Deploy the application

Now, Service Connector performs steps 2 to 5 automatically. Additionally, for Azure services without public access, Service Connector creates private connection components such as private link, private endpoint, DNS record,

You can create a connection in the Service Connection blade within AKS.



Click create and select the target service, authentication method, and networking rule. The connection will then be automatically set up. Here are a few helpful links to for you to learn more about Service Connector.






Introducing Rich Reporting and Troubleshooting for Microsoft Playwright Testing

Introducing Rich Reporting and Troubleshooting for Microsoft Playwright Testing

This article is contributed. See the original author and article here.

Today, we’re excited to introduce rich reporting and easy troubleshooting for the Microsoft Playwright Testing service!

Microsoft Playwright Testing is a managed service built for running Playwright tests easily at scale. Playwright is a fast-growing, open-source framework that enables reliable end-to-end testing and automation for modern web apps. You can read more about the service here.

Now, with this new Reporting feature users can publish test results and related artifacts and view them in the service portal for faster and easier troubleshooting.


Quickly Identify Failed and Flaky Tests


In the fast-paced world of web development, applications evolve rapidly, constantly reshaping user experiences. To keep up, testing needs to be just as swift. Playwright automates end-to-end tests and delivers essential reports for troubleshooting. The Reporting feature provides a streamlined dashboard that highlights failed and flaky tests, enabling you to identify and address issues quickly. This focused view helps maintain application quality while supporting rapid iteration.



Screenshot of test results filtered by failed and flaky tests



Troubleshoot Tests Easily using rich artifacts


As test suites grow and the frequency of test execution increases, managing generated artifacts becomes challenging. These artifacts are crucial for debugging failed tests and demonstrating quality signals for feature deployment, but they are often scattered across various sources.

The Reporting feature consolidates results and artifacts, such as screenshots, videos, and traces, into a unified web dashboard, simplifying the troubleshooting process. The Trace Viewer, a tool offered by Playwright, that helps you explore traces and allows you to navigate through each action of your test and visually observe what occurred during each step. It is hosted in the service portal with the test for which it is collected, eliminating the need to store and locate it separately for troubleshooting.



Screenshot of trace viewer hosted in the service portal


Seamless Integration with CI Pipelines


Continuous testing is essential for maintaining application quality, but collecting and maintaining execution reports and artifacts can be challenging. Microsoft Playwright Testing service can be easily configured to collect results and artifacts in CI pipelines. It also captures details about the CI agent running the tests and presents them in the service portal with the test run. This integration facilitates a smooth transition from the test results to the code repository where tests are written. Users can also access the history of test runs in the portal and gain valuable insights, leading to faster troubleshooting and reduced developer workload.



Screenshot of test result with CI information


Join the Private Preview


For current Playwright users, adding the Reporting feature with your existing setup is easy. It integrates with the Playwright test suite, requiring no changes to the existing test code. All you need to do is install a package that extends the Playwright open-source package, add it to your configuration, and you’re ready to go. This feature operates independently of the service’s cloud-hosted browsers, so you can use it without utilizing service-managed browsers.

We invite teams interested in enhancing their end-to-end testing to join the private preview of the Reporting feature. This feature is available at no additional charge during the private preview period. However, usage of the cloud-hosted browsers feature will be billed according to Azure pricing.

Your feedback is invaluable for refining and enhancing this feature. By joining the private preview, you gain early access and direct communication with the product team, allowing you to share your experiences and help shape the future of the product.


Interested in trying out the reporting feature and giving us feedback? Sign up here.


Check out Microsoft Playwright Testing service here. If you are new to Microsoft Playwright Testing service, learn more about it.

Microsoft Copilot in Azure – Unlock the benefits of Azure Database for MySQL with your AI companion

Microsoft Copilot in Azure – Unlock the benefits of Azure Database for MySQL with your AI companion

This article is contributed. See the original author and article here.

Microsoft Copilot in Azure (Public Preview) is an AI-powered tool to help you do more with Azure. Copilot in Azure extends capabilities to Azure Database for MySQL, allowing users to gain new insights, unlock untapped Azure functionality, and troubleshoot with ease. Copilot in Azure leverages Large Language Models (LLMs) and the Azure control plane, all of this is carried out within the framework of Azure’s steadfast commitment to safeguarding the customer’s data security and privacy.


The experience now supports adding Azure Database for MySQL self- help skills into Copilot in Azure, empowering you with self-guided assistance and the ability to solve issues independently. 


You can access Copilot in Azure right from the top menu bar in the Azure portal. Throughout a conversation, Copilot in Azure answers questions, suggests follow-up prompts, and makes high-quality recommendations, all while respecting your organization’s policy and privacy.


For a short demo of this new capability, watch the following video!




Discover new Azure Database for MySQL features with Microsoft Copilot in Azure


MicrosoftTeams-image (7).png



Explore when to enable new features to supplement real-life scenarios


image (1).png


Learn from summarized tutorials to enable features on-the-go




Troubleshoot your Azure Database for MySQL issues and get expert tips


copilot_cpu usage.png


Join the preview


To enable access to Microsoft Copilot in Azure for your organization, complete the registration form. You only need to complete the application process one time per tenant. Check with your administrator if you have questions about joining the preview.


For more information about the preview, see Limited access. Also be sure to review our Responsible AI FAQ for Microsoft Copilot in Azure.


Thank you!

Recover an ADCS platform from compromise

This article is contributed. See the original author and article here.

The crucial role of backup and restore in ADCS

Active Directory Certificate Services (ADCS) serves as a pivotal part within identity and access management (IAM), playing a critical role in ensuring secure authentication and encryption. These functionalities are integral for fostering trust across the enterprise application and service ecosystem. In modern organizations, the significance of Active Directory Certificate Services has grown exponentially, fortifying digital identities, communication channels and data. Given its pervasive role, the potential loss of this service due to systemic identity compromise or a ransomware attack could be catastrophic. Microsoft advocates platform owners adopt an “assume breach” mindset as an initiative-taking measure against these sophisticated cybersecurity threats to ensure and preserve confidentiality, integrity, and availability of IAM based services. 


As part of an “assume breach” approach, organizations must prioritize comprehensive backup and restore strategies within their ADCS infrastructure. These strategies are paramount for ensuring swift recovery and restoration of essential certificate services following a cyberattack or data breach. By keeping up-to-date backups and implementing effective restoration procedures, organizations can minimize downtime, mitigate potential damage, and uphold operational continuity amidst evolving security challenges. 


Let us look at some of the services and features of an ADCS platform which organizations are dependent on: 


  • Certificate enrollment and renewal: ADCS facilitates automated enrolment and renewal processes, ensuring prompt issuance and rotation of cryptographic keys to maintain security. 

  • Key archival and recovery: Organizations can utilize ADCS to archive private keys associated with issued certificates, enabling authorized personnel to recover encrypted data or decrypt communications when necessary. 

  • Certificate revocation and management: ADCS provides mechanisms for revoking and managing certificates in real-time, allowing organizations to promptly respond to security incidents or unauthorized access attempts. 


  • Public Key Infrastructure (PKI) integration: ADCS seamlessly integrates with existing PKI infrastructures, enabling organizations to use established cryptographic protocols and standards to enhance security across their networks. 

  • Enhanced security controls: ADCS offers advanced security controls, such as role-based access control (RBAC) and audit logging, empowering organizations to enforce granular access policies and keep visibility into certificate-related activities.

Now that we know what this service offers, imagine your organization as a fortified stronghold, wherein Active Directory Certificate Services and Active Directory Domain Services form the bedrock of the Identity and Access Management infrastructure. In case of a cybersecurity breach penetrating this stronghold, the backup and restoration process acts as a crucial defensive measure. It is not merely about restoring ADCS services: it is about swiftly and effectively rebuilding the stronghold. This guarantees the continuation of trust relationships and the seamless operation of vital IT services within the stronghold, such as remote access VPNs, consumer web services, and third-party self-service password reset tools—each of which are essential components for operational continuity, customer experience and business productivity. Without effective backup measures, the stronghold is vulnerable, lacking the protective mechanisms akin to a portcullis or moat. 


The significance of thoroughly assessing all backup and recovery procedures cannot be overstated. This is akin to conducting regular fire drills, ensuring that the IT team is adept and prepared to respond to crises effectively. IT administrators must have the requisite knowledge and readiness to execute restoration operations swiftly, thereby upholding the integrity and security of the organization’s IT environment. Additionally, recognizing the potential exploitation of ADCS for keeping persistence underscores the imperative for vigilance in monitoring and securing ADCS components against unauthorized manipulation or access.  

What are the key elements for a successful backup and recovery?

From a technical perspective, Active Directory Certificate Services (ADCS) backups must cover the foundational pillars of the service. These include the private key, the Certificate Authority (CA) database, the server configuration (registry settings) and the CAPolicy.inf file. Let us explain each in detail:

  • CA private key: The most critical logical part of a CA is its private key material. This key is stored in an encrypted state on the local file system by default. The use of devices like Hardware Security Modules (HSMs) is encouraged to protect this material. The private key is static, so it is recommended to create a backup directly after the deployment and to store it in a safe, redundant location.

  • CA database: By default, this repository holds a copy of all issued certificates, every revoked certificate, and a copy of failed and pending requests. If the CA is configured for Key Archival and recovery, the database will include the private keys for those issued certificates whose templates are configured for the feature.

  • Server configuration: These are the settings and configurations that dictate ADCS operations. From security policies to revocation lists settings, safeguarding the server configurations ensures that the ADCS can be restored with identical functionality.

  • CAPolicy.inf: The CAPolicy.inf file is used during the setup of ADCS and then during CA certificate renewal. This file may be used to specify default settings, prevent default template installation, define the hierarchy, and specify a Certificate Policy and Practice Statement.

How is ADCS backed up?

A practical approach to performing a backup involves utilizing ‘certutil,’ a command-line tool integrated into the Windows operating system. This tool offers a range of functions tailored for managing certificates and certificate services. Other methods encompass employing the graphical user interface (GUI) or PowerShell. To start a backup of the CA database using ‘certutil,’ adhere to the outlined example below:


certutil -backupdb -backupkey "C:BackupFolder"


The command syntax is as follows:


  • backupdb: Starts the backup process for the database.

  • backupkey: Safeguards the private key of the CA (requires providing a password).

  • C:BackupFolder: Specifies the path where the backup will be stored. It is important to use a secure location, ideally on a separate drive or device. Note: this folder must be empty.

Running this command starts the creation of a backup encompassing the CA database and the CA’s private key, thereby guaranteeing the safeguarding of the fundamental elements of the CA. Safeguarding these components is imperative, as malevolent actors may exploit the backup for nefarious purposes.


In addition to preserving the CA Database and the CA’s private key, for comprehensive restoration onto a new server, it is crucial to back up the registry settings associated with ADCS using the following command:  


Reg export “HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesCertSvcConfiguration” C:BackupFolderCAConfig.reg


All settings on the earlier location of the CA database, as well as configurations related to certificate validity settings, CRL and AIA extensions, can be utilized during the recovery process.


If the source CA utilizes a custom CAPolicy.inf, it is advisable to replicate the file to the identical backup location. The CAPolicy.inf file is typically found in the %windir% directory (default location being C:Windows).

How can the service be restored?

Remove ADCS role(s)

If the source server is still available and a CA Backup is available, remove the CA role from it. This is required for Enterprise CAs that are domain-joined. If present, remove the “Web Server” based roles/features before the Certification Authority role.


Remove the source server from the domain

Reusing the same host name on the destination server requires that the source server either be renamed or removed from the domain and the associated computer object removed from Active Directory before renaming and joining the destination server to the domain.


Adding ADCS role(s)

After ensuring that the destination server has the correct hostname and is successfully integrated into the domain, continue to assign the CA role to it. If the destination server is already part of the domain, it needs Enterprise Admin permission to configure the ADCS role as an Enterprise CA.

Before advancing, transfer the backup folder to a local drive, and, if accessible, move the original CAPolicy.inf file to the %windir% folder on the destination server.

  • Launch the Add Roles wizard from Server Manager.

  • Review the “Before You Begin” page, then select Next.

  • On the “Select Server Roles” page, select Active Directory Certificate Services, then Next, then Next again on the Intro to ADCS page.

  • On the “Select Role Services” page, ensure only Certificate Authority is selected, then click Next. (Do not choose any other roles)

Configuring ADCS:

Now configure a clean ‘empty’ CA. This is done prior to restoring the configuration and database content:

  • Select the choice to “Configure Active Directory Certificate Services on this server.”

  • Confirm that the correct credentials are in place depending on the installation: Local Admin for Standalone CA, Enterprise Administrator needed for Enterprise certification authority.

  • Check the box for “Certification Authority.”

  • Select the desired option based on the source CA configuration (“Standalone” or “Enterprise”) on the “Specify Setup Type” page, then click “Next.”

  • Select “Root” or “Subordinate CA” on the “Specify CA Type” page, then click “Next.”

  • Select “Use existing key” on the “Set Up Private Key” page, then click “Next.”

  • Import the Private key from the backup folder copied previously. Select the key and click “Next.”

  • Configure the desired path on the “Configure Certificate Database” page, then select “Next,” then “Install.”

At this point we have restored the CA and have an empty database with default server settings.

  • Open “Certificate Authority” manager from Server Manager or from Administrative Tools.

  • Expand “Certificate Authority (Local)” right click “CAName,” and select “All Tasks,” and click on “Restore CA.”

  • Click “OK” to stop the service.

  • Select “Next” on the “Welcome to the Certification Authority Restore Wizard.”

  • Check only “Certificate Database” and “Certificate Database Log,” click “Browse” and target the backup folder. “C:BackupFolder”, click “Next” and click “Finish” then wait until the restore completes.

  • Click “Yes” to continue and start the service.

  • Expand “Certificate Authority (Local)” right click “CAName” and select “Issued Certificates” to verify the database was restored.

Restore registry settings:

After the database is restored, import the configuration settings that were backed up from the source CA’s registry.

  • Create a registry backup of the destination server:

Reg export “HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesCertSvcConfiguration” C:BackupFolderDestinationCAConfig.reg

  • Locate the “C:BackupFolderCAConfig.reg” file and double click on it to merge the settings, click “Yes” to continue and then “OK” on the Registry Editor confirmation window.

  • Restart the ADCS Service to verify the restored settings.

  • After everything is verified, restart the server to ensure it belongs to the “Cert Publishers” group.

Verify server status:

  • Open “Certificate Authority” manager from Server Manager or from Administrative Tools.

  • Expand “Certificate Authority (Local),” then “CAName” right click “Revoked Certificates” select “All tasks” then “Publish.” Select “OK” at the popup.

  • Run ADCSView.msc to verify the health of the destination CA server.

Test certificate issuance:

With the CA restored, test certificate issuance to ensure full functionality.

  • Publish any templates that were published before and ensure the CA issues certificates are issued as expected.

Note! We recommend an assessment be conducted on all certificate templates to confirm security settings and to reduce the number of templates if possible.


This article highlights the necessity of setting up and upholding a robust “back-and-restore” strategy as a primary defence mechanism against cyber threats. it becomes much more likely that recovery for ADCS will not be successful, and a complete rebuild will be required.

In addition to this, adopting a defence-in-depth approach is equally imperative. This involves implementing supplementary protective measures such as endpoint detection and response through Defender for Endpoint (MDE), or monitoring user and entity behaviour analytics with Microsoft Defender for Identity (MDI). These measures empower cybersecurity operatives to swiftly respond across multiple phases of MITRE ATT&CK, thereby safeguarding the organization’s digital ecosystem, particularly the pivotal identity and access management services.

Integrating the strategic management of ADCS (Active Directory Certificate Services) with these advanced security solutions further strengthens organizational defences against the continually evolving landscape of cyber threats. This strategy augments the resilience of the cybersecurity framework and ensures the continuity and integrity of organizational operations, particularly during the transition to a more secure ADCS infrastructure.

In conclusion, the adoption of a robust backup and restoration strategy, complemented by a multi-faceted defence framework that integrates ADCS management with innovative security solutions, creates a formidable shield against cyber threats. This approach bolsters cybersecurity resilience and fortifies organizational continuity and operational integrity in the dynamic landscape of evolving security challenges.

New agent capabilities in Microsoft Copilot unlock business value

New agent capabilities in Microsoft Copilot unlock business value

This article is contributed. See the original author and article here.

Microsoft Copilot is already helping individual employees boost productivity, creativity and time savings. With the announcements at Microsoft Build 2024, we’re delivering an entirely new set of capabilities that unlock Copilot’s ability to drive bottom-line business results for every organization.

The post New agent capabilities in Microsoft Copilot unlock business value appeared first on Microsoft 365 Blog.

Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.