User Profile
josequintino
MCT
Joined 5 years ago
User Widgets
Recent Discussions
Re: Azure AD Connect - One forest - Two tenants - Same OUs
Hello Brad13, I hope that you are doing well. Using Azure AD Connect with one on-premises AD forest and synchronizing to two different Azure AD tenants is a supported scenario, as Microsoft allows a single forest to sync to multiple tenants. However, using the same Organizational Units (OUs) in both sync configurations can create conflicts if not managed carefully. When the same user object is synchronized to two tenants, it’s crucial to ensure that each Azure AD Connect instance is configured to manage the user objects uniquely for each tenant. If the same OUs are used in both syncs without differentiation, you may encounter issues with object conflicts, especially if the same user is intended to be in both tenants. To avoid these conflicts, consider placing users that are intended to sync to each tenant in separate OUs or using attribute-based filtering to control which objects are synchronized to each tenant. This ensures that there is no overlap or duplicate synchronization, which can lead to unexpected behavior or errors in Azure AD. In scenarios where the same users need to exist in both tenants, leveraging attribute-based filtering, custom synchronization rules, or creating separate OUs for each tenant would be a safer approach to ensure that each Azure AD Connect instance synchronizes the intended users without causing duplication or conflicts in attributes. This way, each tenant receives a distinct subset of users, and you maintain clear separation between the synchronization scopes. If separation at the OU or attribute level is not feasible, you may need to evaluate whether the same users are required to be fully synchronized to both tenants or if a different strategy, such as selectively syncing only certain attributes to one of the tenants, would work better for your scenario. Kind regards.1.2KViews0likes3CommentsRe: Conditional access policy not recognised
Hello HidMov, The issue you’re experiencing is likely due to a synchronization delay or configuration misalignment between Entra ID Conditional Access and the Cloud App Security portal. When creating Conditional Access policies, it’s important to ensure that they have the appropriate session control settings enabled, specifically the Use Conditional Access App Control option. If using the Monitor Only (Preview) mode, there may be limitations or inconsistencies, as preview features can sometimes behave differently. It would be advisable to switch the session control to a more stable setting like Block or Monitor and Enforce to see if this resolves the problem. Additionally, verify that the integration between Entra ID and Cloud App Security is correctly configured by navigating to the Defender for Cloud Apps portal and checking the integration status under Settings - Conditional Access App Control. If the status is not connected or shows any errors, re-establish the connection. Also, check if the targeted applications in your Conditional Access policies match those you’re trying to control through Cloud App Security, as a mismatch can cause policies to not be recognized. Since you also mentioned using a custom policy configuration, ensure that the newly created policies are correctly targeting the users and applications for which you want to enforce session controls. If the issue persists, try creating a fresh Conditional Access policy, assigning it to a different test user, and seeing if it is recognized by Cloud App Security. If none of these steps resolve the issue, there may be a backend synchronization problem or a bug in the current implementation of these features, and opening a support case with Microsoft would be recommended for further investigation. Kind regards.1.3KViews1like3CommentsRe: LDAP 389 - Can we disable it
Hello aditya333 The process of disabling LDAPv2 and enabling LDAPv3 in Active Directory (AD) is inherently managed by the AD system itself, as it natively supports LDAPv3. In fact, modern Active Directory installations do not support LDAPv2 out of the box due to its outdated and less secure nature. Here are the steps to ensure that LDAPv3 is used and to restrict the use of LDAPv2: 1. Verify LDAPv3 Support: - Active Directory supports LDAPv3 by default. You can confirm the LDAP version by examining the RootDSE using a tool like `ldp.exe` or `adsiedit.msc`. - To view the supported LDAP versions, you can connect to your AD LDAP service using `ldp.exe`, bind to the server, and then view the `supportedLDAPVersion` attribute in the RootDSE. 2. Disable LDAPv2 (if necessary): - It is unlikely that you will need to disable LDAPv2 explicitly as it is not supported in modern AD environments. However, if you are using an older version of AD and need to disable LDAPv2, you might need to make registry changes or apply group policy settings. Since modifying the registry can be risky, it is highly recommended that you back up your registry before proceeding and ensure that you are working on a test environment first. - You would need to navigate to `HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters` and ensure that the `LDAPServerIntegrity` is set to enforce LDAP signing, which inherently requires LDAPv3. 3. Enforce LDAP Signing: - To improve security, you should enforce LDAP signing. This can be done through Group Policy: - Open `Group Policy Management Console` (gpmc.msc). - Navigate to `Default Domain Controllers Policy`. - Go to `Computer Configuration` -> `Policies` -> `Windows Settings` -> `Security Settings` -> `Local Policies` -> `Security Options`. - Find and enable the policy `Domain controller: LDAP server signing requirements` and set it to `Require signing`. 4. Test Your Configuration: - After you have made the changes, test your LDAP clients to ensure they can connect and authenticate using LDAPv3. - Use tools like `ldp.exe` on a Windows machine or `ldapsearch` on Linux to verify that the connection is successful and that no clients are attempting to use LDAPv2. 5. Monitor and Review Logs: - Check your Directory Service logs in the Event Viewer for any warnings or errors that might indicate an issue with the LDAP service. - Look for event IDs related to LDAP such as 1220, 2886, 2887, 2888, and 2889 which can give you more information about LDAP signing and binding. Please note that making these changes can affect any applications or services that are dependent on LDAP. Ensure that you inform your stakeholders about the changes and that your applications support LDAPv3 before making these modifications. If you have legacy applications that require LDAPv2, you will need to plan to update or replace these applications as they will not be compatible with these security settings. Kind regards.8.2KViews0likes1CommentRe: Defender for End Point adding home assets
Hello Auror1968. In Microsoft Defender for Endpoint, to ensure only company assets are monitored and personal devices are excluded, you can implement device management policies that restrict the network scope to company-owned assets. Specifically, you can: - Configure Onboarding Policies: Ensure that the onboarding policies for Defender for Endpoint are applied only to company devices. This can be achieved by using group policies, configuration profiles in mobile device management (MDM) solutions, or management tools like Microsoft Endpoint Manager. - Network Segmentation: Apply network segmentation to separate company devices from personal ones. This prevents personal devices from being inadvertently added to your monitored asset list. - Access Control: Implement access control lists (ACLs) to limit the network accessibility of the Defender for Endpoint to recognize only the devices within the company's IP range or VLANs. - Manual Review and Removal: Regularly review the devices listed in Defender for Endpoint and manually remove any that are identified as personal or non-company assets. This can be a more hands-on approach but ensures accuracy. By focusing on these strategies, you can maintain a clear distinction between company and personal devices within Defender for Endpoint, ensuring your security posture remains focused and effective.595Views1like0CommentsRe: Entra ID Identity Protection - MFA registration policy
Hello john66571 Your situation involves implementing an MFA enrollment policy in Azure, specifically using Entra ID Identity Protection and dealing with challenges related to licensing and technical restrictions. I will address the issue in parts to offer a clearer solution. Understanding Entra ID P2 License and MFA Registration Policy Azure AD Identity Protection, a part of Microsoft Entra, provides advanced identity protection features, including the MFA registration policy, which requires Azure AD Premium P2 licenses. This means that only users with this license can directly benefit from the identity protection policies, including the mandatory MFA registration. Activating MFA Registration Policy for Licensed Users When you activate the MFA registration policy for "all users," the system will not automatically filter out users based on the presence of a valid Azure AD P2 license. This means the policy will attempt to be applied to all users, but will only be effective for those with the necessary licenses. Recommended Solution: Dynamic Groups The most effective solution is to create dynamic groups in Azure AD to segment users based on license types, including those with Azure AD Premium P2. This allows for the MFA registration policy from Entra ID Identity Protection to be specifically applied to licensed users, avoiding license compliance issues. Steps to Implement: 1. Create Dynamic Groups: - Use rules in dynamic groups to include users with specific Azure AD Premium P2 licenses. You can use rule expressions based on user license attributes. 2. Apply MFA Registration Policy: - Apply the Entra ID Identity Protection MFA registration policy to these dynamic groups. This ensures only users with the appropriate licenses are required to register for MFA. 3. Monitoring and Adjustments: - Monitor the effectiveness of the policy and make adjustments as needed, especially if there are changes in license distribution or security requirements. Considerations Regarding SSPR (Self-Service Password Reset) You mentioned the inability to utilize combined user registration with SSPR, which might be a limitation in some scenarios. However, focusing on the MFA registration policy through Identity Protection is a solid approach to enhancing security. Conclusion For mixed-license environments like yours, using dynamic groups to segment users based on P2 license availability and applying targeted security policies is the recommended strategy. This maximizes MFA registration policy coverage within the limitations of available licenses and maintains compliance with Microsoft's licensing policies.1.9KViews0likes1CommentRe: Password reset/change activity alert not working
Hello Ryan, Setting up activity alerts for critical actions like password resets for a break glass admin account is essential for maintaining security and monitoring. It's good to hear that you have successfully set up an alert for user login activities, but troubleshooting the issue with the password reset alert can be a bit more complex. Here are some steps you can take to troubleshoot and potentially resolve the issue: 1. Check Alert Configuration: Double-check the alert configuration for both the PowerShell and the GUI setup. Ensure that the conditions are set correctly to trigger the alert for a password reset. Sometimes, minor configuration errors can lead to alerts not being triggered. 2. Review Email Settings: Verify that the email addresses configured for receiving the alerts are correct. Also, check the spam or junk folders of the email account to ensure the alerts are not being misdirected. 3. Examine Alert Triggers: Ensure that the alert is set to trigger on the exact event you are interested in. For example, there might be a difference between a password "reset" and a password "change," and your alert might be set up for one but not the other. 4. Test with Manual Trigger: Try manually resetting the password for the break glass account (if feasible) to see if the alert is triggered. This can confirm whether the issue is with the alert setup or with the event not being captured properly. 5. Check Logs and Audit Trails: Review the logs and audit trails to see if the password reset events are being logged correctly. If they are not appearing in the logs, the issue might be with the event logging rather than the alert system. 6. Update and Patch Management: Ensure that your systems, including the alert management system, are up-to-date with the latest patches and updates. Sometimes, bugs in older versions can cause such issues. 7. Consult Documentation or Support: Review the official documentation for the alert system you are using. It might have specific instructions or known issues related to password reset alerts. If the problem persists, consider reaching out to the support team for the software or service you are using. 8. Permissions and Access Control: Make sure that the account or service used to set up and manage alerts has the necessary permissions to monitor password reset events. 9. Third-Party Monitoring Tools: If all else fails, consider using a third-party monitoring tool that specializes in such alerts. These tools often provide more flexibility and detailed monitoring capabilities. 10. Community and Forums: Sometimes, community forums or user groups for the specific software or service you are using can provide insights or solutions from other users who might have faced similar issues. Remember, when working with break glass accounts, always proceed with caution and ensure that all actions are well-documented and follow your organization's security protocols.1.4KViews0likes1CommentRe: AVD network printer redirection
Hi Tomaz9x. Here's the corrected steps: Open the Group Policy Management Console (GPMC) on your Active Directory server. Navigate to Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Printer Redirection. In this location, you should find the "Do not allow client printer redirection" policy. Configure it according to your needs. Enabling this policy will prevent printer redirection for all printers, including local and network printers. If you want to redirect only the default client printer, you can use the "Redirect only the default client printer" policy, which is also located in the same section under Computer Configuration.20KViews0likes0CommentsRe: LDAP 389 - Can we disable it
Hi aditya333 Certainly, here are more detailed steps for disabling LDAPv2 and enabling LDAPv3 on the server side, using the example of OpenLDAP, which is a popular open-source LDAP server software. Please adapt these steps to your specific LDAP server software as needed: Note: Always make sure to backup your LDAP server configuration files before making any changes to them, and thoroughly test changes in a non-production environment before applying them to a production system. 1. Identify OpenLDAP Configuration Files - OpenLDAP typically uses a configuration file named `slapd.conf` or `slapd.conf.d` (for newer versions). - The location of the configuration file can vary depending on your system and how OpenLDAP was installed. 2. Edit the Configuration File - Use a text editor to open the `slapd.conf` or relevant configuration file for your OpenLDAP installation. 3. Locate Protocol Configuration - Inside the configuration file, locate the section that deals with protocol configuration. This section may be named something like `# Global Directives` or `# LDAP Backend Configuration`. 4. Disable LDAPv2 - To disable LDAPv2, you can add or modify the following directive: allow bind_v2 false 5. Enable LDAPv3 - By default, LDAPv3 is typically enabled in OpenLDAP. However, you can ensure that it's enabled by verifying that there are no directives explicitly disabling it. 6. Save the Configuration File - Save your changes to the configuration file. 7. Restart OpenLDAP - Restart the OpenLDAP server to apply the new configuration. The command to do this depends on your operating system but might look something like: systemctl restart slapd 8. Test LDAPv3 - To verify that LDAPv2 has been disabled and LDAPv3 is active, you can use an LDAP client that supports LDAPv3. - Attempt to connect to the LDAP server using LDAPv2. The server should either reject the connection or negotiate the use of LDAPv3. - You can use command-line tools like `ldapsearch` to test the connection. 9. Monitor Logs and Access - Continuously monitor the server logs for any unexpected behavior. - Ensure that all LDAP client applications are configured to use LDAPv3 as well. 10. Documentation and Support - Refer to the official OpenLDAP documentation for more details on configuration options and troubleshooting. - Join the OpenLDAP community or forums for support and guidance from experienced users. Please note that the steps and configuration file locations can vary based on your specific OpenLDAP version and the operating system you're using. Always refer to the documentation for your LDAP server software for the most accurate and up-to-date information on configuration options.13KViews1like3CommentsRe: Azure ATP Sensor Setup - service not starting - missing dependency
Hello Marthin2770 The WMI Performance Adapter service (wmiApSrv) is a standard service provided with the Windows operating system. It's unusual for it to be missing from a Windows Server 2019 installation, so you might want to first verify if the service is actually missing or if it's just disabled or not running. Here are steps to check the status of the service: 1. Open the Services console by typing `services.msc` in the run dialog (Win + R). 2. Look for "WMI Performance Adapter" in the list of services. If the service is there but is just not running or is disabled, you can right-click on it, select Properties, and then change the startup type to Automatic or Manual, then start the service. If the WMI Performance Adapter service is indeed missing, it might be an issue with the operating system itself. The WMI Performance Adapter service is part of the Windows Management Instrumentation (WMI) which is a core part of Windows. As a next step, you could try to repair the WMI repository. Here's how you do it: 1. Run Command Prompt as an administrator. 2. Type `winmgmt /verifyrepository` and press Enter. 3. If the WMI repository is not consistent, type `winmgmt /salvagerepository` and press Enter. 4. If the WMI repository is consistent, type `winmgmt /resetrepository` and press Enter. After the above steps, check again if the WMI Performance Adapter service is available. Please be careful and consider contacting Microsoft Support or a qualified IT professional, especially when making changes to domain controllers or other critical infrastructure.12KViews0likes0CommentsRe: Remote Credential Guard triggers a Pass-the-Hash alert in MDI
Hi @brigen The way Remote Credential Guard (RCG) operates can indeed trigger a Pass-the-Hash (PtH) attack alert in Microsoft Defender for Identity (previously known as Azure Advanced Threat Protection or Azure ATP). RCG uses a similar approach to a PtH attack to authenticate the user on a remote system - it takes the user's password hash and uses it to authenticate the user remotely. This is a secure and legitimate behavior of RCG, but it may be interpreted as a PtH attack by Microsoft Defender for Identity, which seeks to identify malicious activities and suspicious behaviors in your network, including PtH attacks. Although this is a false positive, Microsoft recommends that all security alerts be checked to ensure they are not indicative of actual malicious activity. If determined that the alert is being caused by the legitimate use of RCG, you may need to adjust the alert settings in Microsoft Defender for Identity to prevent these alerts from being generated in the future. However, any adjustment to the alert setting should be done with care as it could inadvertently lessen the effectiveness of detecting true security attacks. Always consult Microsoft's official documentation or seek advice from an IT security expert when making security changes.3KViews0likes3CommentsRe: Find optimal VM size
Hello pkellner007 Certainly! To find a better VM size that can improve disk performance without requiring Premium disks, we'll consider options with higher disk throughput and lower disk latency. Here are a few recommendations for VM sizes: 1. Standard E8ds v5: This VM size offers twice the CPU and memory resources compared to the E4ds v5, which can help improve disk performance. 2. Standard E16ds v5: With even higher CPU and memory resources, this VM size provides better performance potential for disk operations. 3. Standard E32ds v5: This VM size offers significant compute power and memory, which can contribute to improved disk performance and reduced latency. By upgrading to a larger VM size, you should see improved disk throughput and lower latency, addressing the performance issues you're experiencing. Remember to consider any potential cost implications when choosing a larger VM size.1.2KViews0likes1CommentRe: MDI Alert Suppression in 365 Defender
Hello gurulee73 You can try the following: 1. Rule-Based Email Filtering: Configure email rules in your email client or server to automatically filter MDI-related alerts into separate folders, bypassing the inbox. This way, you can review the alerts at your convenience without being interrupted by email notifications. 2. Email Throttling: Some email clients or servers allow you to configure throttling rules to limit the number of alerts received within a specific timeframe. Check the settings of your email system to see if you can implement such throttling rules. 3. Custom Scripting or Automation: If you have advanced technical skills, you can explore options to automate the email alert management process. For example, you could develop a script or use third-party automation tools to automatically delete or move MDI alerts to a specific folder, reducing the impact on your inbox. 4. Feedback and Feature Request: Provide feedback to Microsoft about your need for alert suppression or customization options in Microsoft 365 Defender. Microsoft actively seeks feedback from users and may consider implementing such features in future updates based on customer demand. It's worth noting that Microsoft may have introduced new features or updates since my knowledge cutoff date. Therefore, I recommend referring to the Microsoft 365 Defender documentation, official support channels, or community forums for the most up-to-date information on managing email alerts in Microsoft 365 Defender.1.3KViews0likes0CommentsRe: Azure VMs stuck at status unknown or updating (solution)
Hello MathieuVandenHautte 1. Verify the Azure Service Health: Check the Azure Service Health dashboard or the Azure status page to see if there are any ongoing service issues or outages that could be affecting the VMs' status. If there are any known issues, wait for the resolution before proceeding. 2. Check the VM Diagnostics: Use Azure Monitor or Azure Diagnostics extension to gather diagnostic information about the VMs. Check the logs and metrics to identify any specific errors or issues that could be causing the VMs to be stuck in an unknown or updating state. 3. Restart the VMs: Try restarting the VMs from the Azure Portal or using PowerShell commands. This can help refresh the VM's state and resolve any temporary issues. Wait for a few minutes to see if the VMs' status changes to running or another appropriate state. 4. Review the VM Extensions: If you have any VM extensions installed, such as custom script extensions or Azure monitoring extensions, check if they are causing any conflicts or errors. Temporarily disable or remove the extensions, restart the VMs, and observe if the status updates correctly. 5. Check the Virtual Machine Scale Sets (VMSS) (if applicable): If the VMs are part of a VMSS, review the scale set configuration, including the health probes, load balancer settings, and autoscale rules. Ensure that the scale set configuration is correct and not causing any issues with the VMs' status. 6. Reimage or Redeploy the VMs: If the above steps don't resolve the issue, consider re-imaging or redeploying the VMs. Reimaging the VM will retain the OS disk and reinstall the OS, while redeploying will recreate the VM instance with a new underlying host. Be cautious as this may result in downtime, data loss, or configuration changes. Make sure to take proper backups before performing these actions. 7. Contact Azure Support: If none of the above steps resolve the issue, contact Azure Support for further assistance. Provide them with the details of the issue, the troubleshooting steps you have already taken, and any relevant diagnostic information you have gathered. Remember to always exercise caution when making changes to your VMs and ensure you have backups or snapshots of critical data before performing any potentially disruptive actions.20KViews0likes0CommentsRe: Azure Policy not supporting for KeyVault Secrets
v-ramepa Azure Policy supports the enforcement of certain configurations and compliance requirements on Azure resources, including KeyVaults. Azure Policy operates at the resource level, which means you can apply policies on the KeyVault resource itself. For example, you can enforce policies on KeyVault properties, such as access policies, SKU, or network settings. However, policies directly targeting individual secrets within a KeyVault are not natively supported. To enforce policies on secrets stored within a KeyVault, you may need to use alternative methods. One approach is to utilize Azure Resource Manager (ARM) templates and define the desired state for your KeyVault secrets within the template. By deploying or updating the KeyVault using the template, you can enforce the desired policies on the secrets. Since my knowledge is not up-to-date, it is possible that Azure Policy has evolved since my last update. I recommend referring to the Azure Policy documentation and checking for any recent updates or features that may have been introduced to support policies on KeyVault secrets directly.778Views0likes0CommentsRe: VPN events in Security.microsoft.com
Hello Mudslideyo To find VPN-related events in the Microsoft Defender for Endpoint portal, you can follow these steps: Sign in to the Microsoft Defender for Endpoint portal at https://security.microsoft.com. Navigate to the "Incidents" or "Threat & Vulnerability Management" section. The exact location of these options may vary depending on the portal's interface. Look for a filter or search bar that allows you to specify event types or keywords. In this case, you can enter "VPN" or related terms to filter the events specifically related to VPN activities. Alternatively, you can also check the "Alerts" section or any other relevant sections where security events and alerts are displayed. Look for events with VPN-related indicators, such as IP addresses, connection status, or authentication failures. If the portal provides an advanced search option, you can use it to create a custom query to filter VPN-related events. For example, you can search for events related to specific VPN protocols (e.g., OpenVPN, IKEv2, L2TP) or events associated with VPN-related keywords (e.g., "VPN connection established," "VPN authentication failed"). It's important to note that the steps provided above are general guidelines, and the actual process may vary depending on the interface and features of the Microsoft Defender for Endpoint portal. If you're unable to find the VPN-related events using these steps, it might be helpful to consult the portal's documentation or contact Microsoft support for further assistance.2.7KViews0likes0CommentsRe: Missing info related to password reset
Hello whipjpv Microsoft Defender for Identity (formerly known as Azure Advanced Threat Protection or Azure ATP, and before that as Microsoft Advanced Threat Analytics or MS-ATA) is a cloud-based security solution that leverages your on-premises Active Directory signals to identify, detect, and investigate advanced threats, compromised identities, and malicious insider actions directed at your organization. In terms of tracking password changes, Microsoft Defender for Identity should be capable of tracking and reporting such events consistently. However, there can be a few reasons why you are not always seeing the actor (the person or system responsible for the change) in the logs: 1. **Permissions**: The account used by Microsoft Defender for Identity to connect to your domain controllers needs sufficient permissions to read the security event logs. If the permissions are not set up correctly, some events may not be fully captured. 2. **Event Log Overwrite**: Windows event logs can overwrite old entries by default, especially if the log size is small and the volume of events is high. If the event is overwritten before Microsoft Defender for Identity can read it, some information might be missing. 3. **Replication Delays**: In environments with multiple domain controllers, there can be replication delays. If a password reset event is written to one domain controller and Microsoft Defender for Identity reads the event from a different domain controller, there can be a delay in capturing the event. 4. **Limitations of the Tool**: While Microsoft Defender for Identity is a powerful tool, it may not capture every single event detail depending on the complexity of the IT environment and the configuration of the tool itself. To troubleshoot this issue, you could start by checking the permissions of the account used by Microsoft Defender for Identity, and the settings for your Windows event logs. If the issue persists, it would be best to reach out to Microsoft Support for more detailed troubleshooting.1.4KViews0likes0CommentsRe: Users asked for 2nd MFA method
Hello colonel_claypoo There are several reasons why users may be prompted to configure a second MFA method. Here are a few possible explanations: 1. Changes in security settings or policies: It's possible that an administrator recently updated the security settings or policies for your organization, requiring users to have a second MFA method configured. Check with your organization's administrators to see if any changes were made to the security settings. 2. Conditional Access policies: If your organization uses Azure Active Directory (Azure AD) and has set up Conditional Access policies, users might be prompted to provide additional authentication methods based on certain conditions (e.g., logging in from an unfamiliar location or device). Review your Conditional Access policies to see if any changes were made recently. 3. User settings: Users might have accidentally triggered the prompt for a second MFA method by changing their own security settings. Instruct the affected users to review their security settings and ensure they are correctly configured. 4. Software update: Microsoft occasionally rolls out updates to Azure AD and its security features. It's possible that a recent update has caused the prompt for a second MFA method. Keep an eye on the Azure AD release notes and announcements for any changes that could have affected MFA. 5. Potential security threat: If the prompt for a second MFA method is unexpected and cannot be traced back to any changes in policies or settings, it could be a sign of a potential security threat. In this case, it's essential to investigate the issue thoroughly and ensure that the affected users' accounts are secure. To diagnose and resolve the issue, start by checking your organization's security settings and policies, as well as any recent changes to Azure AD or Conditional Access policies. If the problem persists, consider reaching out to Microsoft Support for further assistance.2.7KViews1like1CommentRe: azure network setup with vpn, vnet and discrete subnets
Hi @AllenIsntSocial Based on your requirements, it seems that the setup you currently have is more complicated than necessary. Here's a simplified version of what you need: 1. Create a Virtual Network (VNet) in the US West region. 2. Within that VNet, create 4 subnets for dev, qa, staging, and prod. 3. Create Network Security Groups (NSGs) for each subnet, and configure the rules to allow or deny access as needed. 4. Set up an Azure VPN Gateway with Point-to-Site (P2S) VPN configuration, and ensure that users must be connected to the VPN to access resources within the VNet. 5. Configure Azure Private DNS to resolve the names of your resources to their private IP addresses. Here's a step-by-step guide to achieving the above: 1. Create a Virtual Network: - Sign in to the Azure portal. - Click on "Create a resource" and search for "Virtual Network". - Click "Create" and fill in the required details (name, region, address space, etc.). - Choose the US West region for your VNet. 2. Create subnets within the VNet: - Go to your VNet resource in the Azure portal. - Click on "Subnets" and then "Add" to create a new subnet. - Create four subnets for dev, qa, staging, and prod with appropriate address ranges. 3. Create and configure Network Security Groups: - In the Azure portal, click on "Create a resource" and search for "Network Security Group". - Create an NSG for each subnet (dev, qa, staging, and prod). - Configure the NSG rules to allow or deny traffic as needed for each subnet. - Associate the NSGs with their respective subnets. 4. Set up the Azure VPN Gateway: - In the Azure portal, click on "Create a resource" and search for "VPN Gateway". - Choose the appropriate VNet, and configure the gateway with a new public IP address. - Once the VPN Gateway is deployed, configure Point-to-Site VPN by following the instructions in the Azure documentation: https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-point-to-site-resource-manager-portal 5. Configure Azure Private DNS: - In the Azure portal, click on "Create a resource" and search for "Private DNS". - Create a new private DNS zone. - Link the private DNS zone to your VNet. - Add A records (with private IPs) for your resources (databases, app servers, Cosmos DB, etc.). After completing these steps, your setup should be much simpler and more in line with your requirements. You will be using standard Azure services without any unnecessary customizations, and all access to the resources will be through the VPN.1.8KViews0likes0Comments
Recent Blog Articles
No content to show