Category Archives: EntraID

Intune Connector for Active Directory – What To Know About The Latest Security Update

Posted on by
Reply

Microsoft is offering clients an updated Intune Connector for Active Directory and this connector is what Intune will be using starting from Intune 2501. This connector uses Windows Autopilot to deploy devices that are Microsoft Entra hybrid joined.

The updated version of the connector aims to enhance security and will be using a Managed Service Account (MSA) instead of a SYSTEM account. Customers currently using the old version of the Intune Connector for Active Directory (that uses the local SYSTEM account) should know that this connector will no longer have support, starting in late June 2025.

Therefore, it’s important to start planning for the update because once support ends, enrollments from the old connector build will no longer be acceptable.

Key Features of the Intune Connector

The main role of the Intune Connector for Active Directory is to join computers to an on-premises domain and add them to an organizational unit (OU) allowing for central management and policies.

The Intune Connector also places joined computers within a specific OU, something that helps establish granular control over device configurations and settings. Furthermore, customers will also benefit from hybrid enrollment of devices which offers the convenience of device management by both on-premises AD and Intune.

The Intune Connector plays a key role in leveraging Windows Autopilot to set up and deploy devices. And for all those already using Autopilot, they will know that this feature will have a huge impact in making life easier for customers by simplifying deployment processes.

In addition to all the above, the Intune Connector ensures that the policies defined in both AD and Intune continue to enforce, thus offering compliance and consistency.

Why Switch to Managed Service Accounts?

As the new version of the Intune Connector for Active Directory makes the change to using Managed Service Accounts, it’s important to understand why they are important. The use of MSAs will enable the new connector to follow least privilege principles and thereby strengthen security.

With MSAs, clients enjoy managed domain accounts that have automatic password management. They are also generally permissible with privileges to perform their duties. With such measures in place, there is a reduction in the risk of compromise, intentional or otherwise.

You can only use standalone MSAs on one domain-joined machine and can thus only access resources within that domain. MSAs can easily and securely run services on a computer while simultaneously maintaining the capability to connect to network resources as a specific user principal. When taking all of this into account, it’s not difficult to see why Microsoft views the use of MSAs as better for the Intune Connector moving forward.

Securing The Future

The security update to the Intune Connector for Active Directory fits in seamlessly with Microsoft’s Secure Future Initiative. Microsoft is uniquely ideal within the tech industry to play a key role in safeguarding the future for all its clients.

As such, the tech giant is taking a comprehensive approach to cybersecurity with a key focus on certain areas that are critical to enhancing security across the board. There continues to be substantial progress in these areas:

identity and secret protection

Updates to Entra ID and Microsoft Account (MSA) are live for both public and U.S government clouds to generate, store, and automatically rotate access token signing keys using the Azure Managed Hardware Security Module (HSM) service.

Microsoft has continued to drive broad adoption of its standard identity SDKs, which provide consistent validation of security tokens. As a result, we now see this standardized validation covering more than 73% of tokens issued by Microsoft Entra ID for Microsoft owned applications.

Tenant Protection and Isolation of Production Systems

A full iteration of app lifecycle management for all production and productivity tenants has been performed. This has resulted in the elimination of 730,000 unused apps. Additionally, because of the elimination of 5.75 million inactive tenants, the potential cyberattack surface has become significantly smaller.

Not only that, but a new system to streamline the creation of testing and experimentation tenants with secure defaults is available. It also enforces a strict lifetime management.

Protect networks

More than 99% of physical assets on the production network record in a central inventory system. This enriches asset inventory with ownership and firmware compliance tracking. Virtual networks with backend connectivity are isolated from the Microsoft corporate network, as well. They are additionally subject to complete security reviews to reduce lateral movement.

With the expansion of platform capabilities such as Admin Rules to ease the network isolation of platform as a service (PaaS) resources such as Azure Storage, SQL, Cosmos DB, and Key Vault, Microsoft has made it easier for customers to secure their own deployments.

Protection of engineering systems

We are now experiencing more consistent, efficient, and trustworthy deployments because 85% of production build pipelines for the commercial cloud are now using centrally governed pipeline templates.

Other notable changes include shortening the lifespan of Personal Access Tokens to seven days, disabling Secure Shell (SSH) protocol access for all Microsoft internal engineering repos, and massively reducing the number of elevated roles with access to engineering systems.

Moreover, proof of presence checks for critical chokepoints in software development code flow are now available.

THREAT DETECTION AND MONITORING

A lot of progress continues toward the goal of pushing all Microsoft production infrastructure and services to adopt standard libraries for security audit logs. Additional efforts include those to emit relevant telemetry and to retain logs for a minimum of two years.

A good example is the establishment of central management and a two-year retention period for identity infrastructure security audit logs, including all security audit events throughout the lifecycle of current signing keys. Add to this the fact, that no less than 99% of network devices now have enablement with centralized security log collection and retention.

Accelerate response and remediation

We can now observe improved time to mitigate for critical cloud vulnerabilities because of the recent process updates across Microsoft. Customers will also appreciate the greater transparency provided by the publishing of critical cloud vulnerabilities as common vulnerability and exposures (CVEs). This is especially helpful even when there are no direct customer action requirements.

In addition to this, the establishment of the Customer Security Management Office (CSMO) will go a long way to improve public messaging and customer engagement for security incidents. 

Required Permissions

As we look at the new version of the Intune Connector for Active Directory, one of the key areas that can help us distinguish this new connector from its previous version is doing a comparison of account permissions:

 Old ConnectorNew Connector
Logged On AccountSYSTEMDomain/MSA
Password ManagementSet by user, subject to domain rulesManaged by domain only – automatically reset
Privilege Set SizeMAX5 Privileges:   SeMachineAccountPrivilege – Disabled default SeChangeNotifyPrivilege – Enabled Default SeImpersonatePrivilege  –  Enabled Default SeCreateGlobalPrivilege –   Enabled Default SeIncreaseWorkingSetPrivilege – Disabled default
Registry Access RightsFull, implicitRead write, explicit
Enrollment Certificate RightsFull, implicitFull, explicit
Create Computer Object Rights (required for hybrid Autopilot scenario)Unlimited if connector is on the same machine as domain controller. Delegation is required if connector is not on the domain controller.Explicit delegation required

Pre-requisites

As with any product or application, there are certain requirements that all customers intending to use the Intune Connector for Active Directory will need to meet. So, before proceeding with the set up of the new Intune Connector, you need to verify that you can meet all the pre-requisites. These requirements include:

  • The computer you’re installing Intune Connector for Active Directory to must be running Windows Server 2016 or later.
  •  You should also verify that you have .NET Framework version 4.7.2 or later installed.
  • To facilitate communication with Microsoft’s Intune service, the server hosting the Intune Connector should have internet access.
  • The Intune Connector will need standard domain client access to domain controllers.
  • Customers must verify that they have a Microsoft Entra account with Intune Service Administrator permissions, as this is a requirement to download and manage the connector.
  • Also needed will be a domain account with local administrator privileges and the ability to create msDS-ManagedServiceAccount objects.
  • Verify that the Windows Server configuration aligns with the Desktop Experience and, for versions 2019 or earlier, install the Microsoft Edge browser manually before connector setup.
  • The Microsoft Entra account should have an Intune license assigned to it.
  • For those that will be using Hybrid Azure AD Join, they should check that it’s configured via Azure AD Connect tool.
  • Lastly, the Intune Connector machine must have the appropriate delegated permissions to create computer objects in the target OU.

Setting Up The Connector

To setup the new Intune Connector for Active Directory, you need to start by uninstalling the existing connector. You can do this by uninstalling from the Settings app on Windows and then, uninstalling using the ODJConnectorBootstrapper.exe (select Uninstall). With that done, you can download the connector build from Intune and then perform the installation (as described in detail in my previous blog).

Configuring organizational units (OUs) for domain join

Customers should be aware that by default MSAs won’t have access to create computer objects in any Organizational Unit (OU). Thus, if you intend to use a custom OU for domain join, you’ll need to update the ODJConnectorEnrollmentWiazard.exe.config file. Fortunately, this is something you can do before or after connector enrollment:

  • Update ODJConnectorEnrollmentWizard.exe.config:
  • Default location is “C:\Program Files\Microsoft Intune\ODJConnector\ODJConnectorEnrollmentWizard”
  • Add all the OUs required in OrganizationalUnitsUsedForOfflineDomainJoin
  • OU name should be the distinguished name.
  • You need to be aware that the MSA is only granted access to the OUs configured in this file (and the default Computer’s container). This means that if any OUs are removed from this list, completing the rest of the steps will revoke access.
  • Open ODJConnectorEnrollmentWizard (or restart it if it was open) and select the “Configure Managed Service Account” button.
  •  If successful, a pop up will appear showing success.

Using the Intune Connector with multiple domains

For those who are already using the connector with more than one domain, they will be able to use the new connector by setting up a separate server per domain and installing a separate connector build for each domain.

Configuring the connector

  • Customers should install the Intune Connector for Active Directory on each of the domains that they want to use for domain join. In case a second account redundancy is required, customers must install the connector on a different server (in the same domain).
  • Go through the connector configuration steps meticulously and verify that everything has been done correctly. Also check that the MSA has the appropriate permissions on the desired OUs.
  • Verify that all connectors are present in the in the Microsoft Intune admin center (Devices > Enrollment > Windows > under Windows Autopilot, select Intune Connector for Active Directory) and that the version is greater than 6.2501.2000.5.

Configure Domain Join profile

Follow the steps given below.

  • Start by creating a domain join profile for each domain that you want to use for hybrid joining devices during Autopilot.
  • Target the domain join profile to the appropriate device groups.

Wrap Up

The Intune Connector for Active Directory provides an essential tool for managing hybrid devices in an Intune environment. With its many available features, customers will get centralized management capabilities for their environments thus allowing businesses to operate more efficiently.

But, with security having been a big concern for many, Microsoft has made the switch to using a Managed Service Account instead of a SYSTEM account. This action has effectively tightened security in customers’ environments. Going forward, the previous version of the Intune Connector will no longer be supported. Therefore, if you are yet to download and set up the new Intune Connector for Active Directory, the sooner you do the better.

The Go-To Guide for Setting Up SFTP Access with Azure Blob Storage and Microsoft Entra ID

Posted on by
1

Introduction

In today’s business environment, securely exchanging data with external partners is essential. Azure Blob Storage with native SFTP support offers a scalable, secure solution, while Microsoft Entra ID provides robust identity management. Together, these tools help organizations share data with external users while ensuring security and compliance.

This go-to guide will walk you through configuring Azure Blob Storage for SFTP, managing user access with Entra ID, and showcase three real-world use cases—payment reconciliation, logistics data sharing, and healthcare data exchange.

Why Use Azure Blob Storage with SFTP and Entra ID?

Azure Blob Storage with native SFTP support simplifies secure file transfers without the need for third-party SFTP servers. Integrating Microsoft Entra ID enhances security by enforcing multi-factor authentication (MFA), conditional access, and role-based access control (RBAC).

Benefits at a Glance

  • Scalable and Cost-Effective: Pay only for the storage you use.
  • Secure File Transfer: Use the SFTP protocol for encrypted data transfer.
  • Centralized Access Management: Use Entra ID to control and monitor external access.
  • Automation and Integration: Seamless integration with tools like Azure Logic Apps and Power Automate.

Step 1: Setting Up Azure Blob Storage with SFTP Support

Follow these steps to set up Azure Blob Storage for SFTP access.

1.1 Create an Azure Storage Account

  1. Sign in to the Azure Portal.
  2. Go to Create a Resource and select Storage Account.
  3. Configure the storage account:
    • Subscription and Resource Group: Choose your existing or create new ones.
    • Storage Account Name: Must be globally unique.
    • Region: Select the region closest to your users.
    • Performance: Choose Standard for general use or Premium for high-performance workloads.
    • Replication: Choose Locally Redundant Storage (LRS) or Geo-Redundant Storage (GRS) based on your redundancy needs.
  4. Under the Advanced tab, enable SFTP Support (Preview).
  5. Click Review + Create, then Create the storage account.

Step 2: Configuring SFTP Access for External Partners

  1. Navigate to your newly created storage account.
  2. Under Data Transfer, select SFTP Settings.
  3. Click Add Local User to create an SFTP user:
    • Username: Use a descriptive name like partner1.
    • Authentication: Choose SSH Key-based authentication for enhanced security.
    • Home Directory: Assign a specific container (e.g., /transactions).
    • Permissions: Grant appropriate permissions (Read, Write, List).
  4. Generate an SSH Key if you don’t have one:
    • Use ssh-keygen (Linux/Mac) or PuTTYgen (Windows).
  5. Save the configuration and take note of the SFTP endpoint.

Step 3: Integrating Microsoft Entra ID for Access Control

To ensure only authorized users access your SFTP service, use Microsoft Entra ID to manage identity and access.

3.1 Conditional Access Policies

  1. Go to the Azure AD Portal.
  2. Create a new Conditional Access Policy to enforce MFA and restrict access based on location.

3.2 Role-Based Access Control (RBAC)

Assign roles to external users to limit their access to only the relevant Azure Blob containers.

Step 4: Real-World Use Cases

Case 1: Payment Reconciliation – Mastercard Data Exchange

A retail company needs to securely exchange Mastercard transaction data with an external payment processor for daily reconciliation.

Workflow:

  1. The payment processor uploads transaction data to the SFTP endpoint.
  2. Azure Blob Storage receives and stores the files.
  3. Business Central or an ERP system processes the data for reporting and reconciliation.

Security Measures:

  • Use MFA and Conditional Access for external user authentication.
  • Configure audit logging to monitor access and activity.

Case 2: Logistics Data Sharing – Real-Time Inventory Updates

A manufacturing company needs to share real-time inventory data with its logistics partner.

Workflow:

  1. The logistics partner downloads inventory files and uploads shipping updates to the SFTP server.
  2. An Azure Function processes these updates and integrates them into the company’s ERP.

Security Measures:

  • RBAC ensures the logistics partner only accesses relevant files.
  • Data encryption protects information in transit and at rest.

Case 3: Healthcare Data Exchange – Secure File Transfers with External ClinicsA hospital exchanges patient data with external clinics, ensuring compliance with GDPR and HIPAA regulations.

Workflow:

  1. Clinics upload test results and patient data to the hospital’s SFTP endpoint.
  2. An Azure Logic App validates and integrates the data into the hospital’s EMR system.
  3. Doctors receive automatic notifications for new updates.

Security Measures:

  • Conditional Access restricts access by IP and enforces MFA.
  • Data masking during processing protects sensitive information.

Step 5: Automating Data Processing

Azure Logic Apps

Automate file processing with Logic Apps to trigger workflows when a file is uploaded.

Azure Functions

Run custom code to process files and integrate them with external systems.

Power Automate

Create simple automation workflows for notifications and approvals.

Step 6: Security Best Practices

  1. Enforce Multi-Factor Authentication for all external users.
  2. Use Conditional Access Policies to limit access by device and location.
  3. Encrypt Data at Rest and in Transit.
  4. Rotate SSH Keys Regularly.
  5. Audit and Monitor Access Logs for unusual activity.

Conclusion

Azure Blob Storage with SFTP support and Microsoft Entra ID provides a powerful and secure platform for exchanging data with external partners. Whether you are exchanging financial data, inventory files, or healthcare records, this setup ensures security, compliance, and scalability.

By following this step-by-step guide and using the real-world use cases as inspiration, you can create a secure, reliable solution for your organization’s external data exchange needs.

Further Reading: