Hi everyone, I currently have a sharepoint list which includes a lookup column, whereby a scanner scans in a [code] into the “Add new item” form, and it will return a [name] in a seperate column in the list. There are currently about 1K – 2K items in the lookup list.

When i press the lookup column, it is able to generate the full list without issue.

However, if i try to search for the exact [code], the search/filter function in the dropdown list is not able to find the exact code (see below image). Previously there wasn’t any issue with this, but it seemed to appear after the new UI update of sharepoint list.

If edit using grid view, the list is able to search/filter without any issues

Does anyone have any potential solution to the long search times when using the “add new item” button/form? Much appreaciated! 

​Hi everyone, I currently have a sharepoint list which includes a lookup column, whereby a scanner scans in a [code] into the “Add new item” form, and it will return a [name] in a seperate column in the list. There are currently about 1K – 2K items in the lookup list.When i press the lookup column, it is able to generate the full list without issue.  However, if i try to search for the exact [code], the search/filter function in the dropdown list is not able to find the exact code (see below image). Previously there wasn’t any issue with this, but it seemed to appear after the new UI update of sharepoint list.  If edit using grid view, the list is able to search/filter without any issues Does anyone have any potential solution to the long search times when using the “add new item” button/form? Much appreaciated!     Read More

​

In November 2023, Microsoft’s Brad Smith and Charlie Bell announced the Secure Future Initiative (SFI), a new initiative to pursue our next generation of cybersecurity protection. At Microsoft and Windows, we have a unique responsibility and leading role to play in securing the future for our customers and our community. As you saw in David Weston’s blog post on Windows 11 security, we have a longstanding commitment to security in Windows. We introduced the Secured-core PC to help secure from chip to cloud and that critical layer of computing. In Windows 11, hardware and software work together to help shrink the attack surface, protect system integrity, and shield valuable data. Windows 11 comes with several security advances that protect our customers from Credential and identity theft, such as Local Security Authority protection, Advanced key protection using VBS, Windows Hello hardening etc.

Along with credential protection, we also prioritized helping app developers better protect people from phishing attacks and malware. One of the key advances we have made in this area is a feature called VBS enclaves. With Windows 11 and Windows Server 2025, VBS enclaves are now available to third-party application developers.

The next sections of this blog post will describe VBS Enclaves, its internals and how to use VBS Enclaves as a developer.

VBS enclaves

A VBS enclave is a software-based trusted execution environment (TEE) inside a host application. This is a revolutionary change in our security model for the application, allowing an app to protect its secrets using the power of VBS, from admin-level attacks.

Some background: Virtualization Based Security (VBS) is the core feature of Windows used to the high value secrets stored within Windows (e.g., Credential Guard). VBS utilizes the Hyper-V hypervisor to create an environment that is higher privileged than the rest of the system kernel. Like VM isolation, the hypervisor sets memory protections in the second level address tables and IOMMU tables to isolate this environment from the rest of the system kernel. The secure kernel (part of VBS) can also provide memory integrity protection to the system kernel, ensuring the system loads only signed drivers that are not tampered with.

We are now extending the isolated user mode in the VBS environment to allow developers to protect portions of application data in a software-based trusted execution environment (TEE) known as a VBS enclave.

As mentioned, a VBS enclave is a software-based TEE inside the address space of a host application. It is a Dynamic Link Library (DLL) loaded by a standard Windows application. VBS enclaves can help secure secrets and sensitive operations in memory. The basic premise is that a VBS enclave can isolate a portion of your application that you want to secure while it is in memory – for example, to securely decrypt and process sensitive information. To understand how a VBS enclave isolates secrets, you’ll need to understand the underlying technology it leverages, VBS. As mentioned earlier, VBS uses the Windows Hyper-V hypervisor to create an isolated, privileged virtual environment known as Virtual Trust Level 1 (or VTL1) that becomes the root of trust of the OS. The traditional Windows environment is called VTL0. VTL1 is further split into isolated user mode and the secure kernel. Windows uses VTL1 to host many of its security features. The hypervisor uses the second level address tables to maintain access and privileges for these virtual trust levels. The higher the number, the higher the privilege level. This means everything in a higher VTL is isolated from everything in a lower VTL.

The isolation provided by VBS is the core technology that allows a VBS enclave to isolate a portion of an application in higher-privilege VTL1, inaccessible to VTL0. Let’s look at what an application hosting a VBS enclave looks like: 

The enclave hosting application lives in VTL0 and calls into the enclave when it needs to perform sensitive operations. Control is transferred to the VBS enclave, and the CPU register state is cleaned (except for specific parameter and result registers). Note that code and data inside a VBS enclave is inaccessible to VTL0 (including its own host application) and to other processes in VTL1. Code and data inside of a VBS enclave is visible only to the enclave itself, the VTL1 secure kernel, and the hypervisor.

At this point, you might be thinking “What’s stopping an attacker from exploiting the enclave in VTL1?” Good question! Though there is usually a process boundary between a non-Enclave application and a malicious actor in VTL0, by moving part of the application into VTL1, we add an additional boundary for the attacker to cross. This additional boundary is enforced by the hypervisor and is designed to be much more rigid. Think of VBS enclaves as a way to further harden your applications. VTL1 is a privileged space, aThe boundary between VTL0 and VTL1 is much more rigid to ensure that we can maintain this high bar.

This strong boundary doesn’t come for free. Accessing VTL1 is – at least more expensive than accessing VTL0 (we’re talking fractions of a millisecond here). Additionally, unlike VTL0 which has a lower barrier to entry, VTL1 requires all code to be signed. So, although VTL1 is a higher-privileged space, this privilege is maintained by requiring additional efforts by developers who wish to leverage VTL1. The nature of these efforts can be illustrated through some of the tenets VBS enclaves were designed with:

Limited API Surface

This is by design and serves a couple of purposes. Firstly, the smaller the range of functionality is within an enclave, the smaller the attack surface becomes. This ensures we can maintain the integrity of VTL1. Secondly, having a small API surface requires that you, the developer, think about how to best design your application so you only isolate what is critical in VTL1. Again, accessing VTL1 is comparatively expensive, so design your application wisely.

Code Integrity

Only code signed by Microsoft using a Trusted Signing VBS enclave certificate profile is permitted to run in an enclave. This includes loaded DLLs into the enclave. When control is handed from the VTL0 host application to the enclave, the VTL1 secure kernel will first verify that all the enclave code and data are authentic and are authorized to run inside of an enclave using image signature verification on the enclave image. This allows us to maintain our high bar for what we allow into VTL1.

This requirement means that developers are required to use Trusted Signing to obtain a certificate to production-sign their enclaves.

Attestation

Together with code integrity, VBS enclaves can generate attestation reports to attest to the state of the host system, the enclave itself, all DLLs that may have been loaded into the enclave, and whether the enclave is executing in debug mode. Note that once an enclave is initialized by the host application, the host can no longer modify the enclave and , to maintain the attestation state of the enclave throughout its lifetime. Attestation ensures that the code running in the enclave is exactly what you expect. Using a VBS enclave-generated attestation report and the MAA attestation service, you can attest to the state of the Enclave.

How do I use a VBS enclave?

You can use VBS enclaves to store secrets, seal data and perform decrypt operations, all in an isolated environment. The first step, as with any security feature, is thinking about secure design. VBS enclaves limit what you can do to maintain their security guarantees, so it isn’t as simple as moving the bulk of your application to live inside one.

Some considerations as you design an enclave:

A VBS enclave can be loaded by any application, not just the intended host application. Design your enclave without placing trust in the host .
VBS enclaves operate by isolating from VTL0. To maintain the security promises of a VBS enclave, treat VTL0 as an untrusted environment. This includes not sending sensitive data outside of a VBS enclave. Only trust the enclave itself.
Ensure you understand the APIs available to you from within the enclave. Networking, for example, is not supported.

A sample use case of a VBS enclave is in Azure SQL or SQL Server (AE with secure enclaves).

AE protects the confidentiality of sensitive data from the database engine and administrators, placing trust only in the database clients to whom the data belongs. In the database, the sensitive data exists in an encrypted state. The data is only decrypted on the client side, where operations can be performed on it. In the database engine, operations are limited to equality checks.

AE with secure enclaves, however, adds a VBS enclave to the database engine. When the database engine encounters computations on encrypted data, it delegates these computations to a VBS enclave, where the enclave decrypts the data and performs computations on plaintext. Employing a VBS enclave here makes it so database administrators cannot see the data inside the VBS enclave. With the use of VBS enclaves, AE with secure enclaves can perform richer confidential queries and in-place cryptographic operations than AE without secure enclaves, all without having to place trust in the database administrators.

The database client establishes a secure channel with the database engine containing the VBS enclave and identifies which columns are encrypted and manages encryption of these parameters in both directions. Now, when the database engine encounters operations on encrypted columns, it can delegate these to the VBS enclave. In the enclave the data can securely be decrypted if needed, and the operation can be performed.

SQL AE with secure enclaves is a fantastic use case of VBS enclaves:

The VBS enclave never reveals the decrypted information to the host application – the database engine in this case. It only trusts itself.
The database engine hosting t.
By utilizing VBS enclaves, the database client no longer  performs all of the operations on sensitive data client-side after decrypting them.

The SQL AE with secure enclaves use case illustrates the importance of secure design when thinking about how to employ VBS enclaves in your application. When used effectively, VBS enclaves are a powerful tool.

Now that you understand VBS enclaves and all that they can do, jump into the docs here, or read on for a guide on how to build your first VBS enclave by following the development guide here

We hope this blog has you as excited as we are to begin developing secure applications with VBS Enclaves on Windows 11 and Windows Server 2025! We look forward to your feedback! Also take a look at the Windows Security Book to learn more about Windows Security technologies.

Hilal Asmat, Akash Trehan, and Hari (on behalf of the enclaves team) 

​Microsoft Tech Community – Latest Blogs –Read More 

(Written on May 30th, 2024)

If you come across a credential named something like ‘https://xxyyzz.blob.core.windows.net/sqldbtdlogs‘ in the sys.database_scoped_credentials table of your Azure SQL Database and are unsure of its purpose. it is likely related to the Threat Detection feature. This feature monitored and detected threats to your Azure SQL Database, generating reports stored in the sqldbtdlogs container in the storage account xxyyzz.

You can further verify this by checking the container for a folder named like ‘SqlDbThreatDetection_Audit_xxxxx’:

Previously, this credential was automatically added to the sys.database_scoped_credentials table when Threat Detection was enabled and removed when it was disabled. However, Threat Detection has been deprecated and replaced by Microsoft Defender for Azure SQL, which offers more extensive and holistic monitoring and threat detection capabilities.

If you find this credential still present in your Azure SQL Database, it might have been missed during the transition from Threat Detection to Microsoft Defender for Azure SQL. If you confirm it is no longer in use and want to remove it, note that you cannot simply use the DROP DATABASE SCOPED CREDENTIAL command, as it will result in an error:

This design likely prevents the unintended removal of the credential, which would cause Threat Detection to fail. The credential should automatically be dropped once Threat Detection is disabled.

Since Threat Detection can no longer be enabled or disabled through the Azure Portal due to its deprecation, you can use the following command to disable it: az sql db threat-policy.

Here’s a demonstration:

1. Confirm the Credential Exists:

2. Check Threat Detection Status:

(If it shows ‘Disabled’, but the credential is present, you can still proceed to the next step to disable the feature again to drop the credential.)

3. Run the command to disable the feature to drop the credential:

4. Confirm the credential is no longer present:

(The end of this post)

​Microsoft Tech Community – Latest Blogs –Read More