Azure CLI, Azure Powershell, CloudShell

  • Azure CLI and the PowerShell package use the REST API of Azure.
  • Azure CloudShell – Browser based cmd line

Why Use VNETs?  (for hybrid use case – for VPN setup – VNET is a virtual subnet in Azure – you can extend your on prem IP address space to Azure)

  • VNET – Gateway Subnet (e.g. 10.1.0.X  – 16 Ips)
  • Next – you may need a Private Subnet and a Public Subnet – these are all routable within the same VNET.
  • Custom Routes help you route traffic between subnets through a Virtual Appliance

Should you use Multiple Subscriptions or Single Subscription with multiple RGs?

Common reasons for dividing between separate subscriptions, rather than resource groups within a single subscription, are

  • Department groupings on billing statements,
  • Grouping resources into silos,
  • Separating access control between environments

How do you access / tag resources across Subscriptions?

  • Now, you can tag resources with name/value pairs to categorize and view resources across resource groups and, within the portal, across subscriptions.

Subscriptions VERSUS Resource Groups

  • Resource Groups are CONTAINERS for resources
  • Azure Portal also allows role-based access control (RBAC) for more fine-grained access in Azure Resource Manager deployments.
  • RBAC can be applied at the subscription level to be inherited by resource groups, or to individual resource groups for more granular delegation.

Resource Groups for Individual Applications VERSUS ‘Common Resource Groups’

Common Resource Groups

  • Used across app portfolio
    • Common Log Analytics workspace
    • Common Blob Storage accounts where files are dumped for processing by the other services
    • An ExpressRoute VNet

Individual resource groups – can be ‘per environment’ or ‘per application’ – production resource groups (applications)

  • Storage Accounts
  • SQL Database
  • Log Analytics
  • Application Insights
  • Azure HDInsight cluster

 

Set up a Site to Site VPN Tunnel (need Public IP V4 address of On Prem VPN Device, and the device needs to be compatible with IPSEC IKE v1 or v2)

The Azure VNET Piece

  1. The virtual network gateway uses specific subnet called the gateway subnet.
  2. The gateway subnet is part of the virtual network IP address range that you specify when configuring your virtual network.
  3. It contains the IP addresses that the virtual network gateway resources and services use.
  4. The subnet must be named ‘GatewaySubnet’ in order for Azure to deploy the gateway resources. You can’t specify a different subnet to deploy the gateway resources to. If you don’t have a subnet named ‘GatewaySubnet’, when you create your VPN gateway, it will fail.

The On Prem Piece

  1. You must specify the IP address range prefixes that Azure will route to your on-premises location.
  2. None of the subnets of your on-premises network can over lap with the virtual network subnets that you want to connect to.
  3. DNS is not required to create a Site-to-Site connection. However, if you want to have name resolution for resources that are deployed to your virtual network, you should specify a DNS server.

 

 

Site-to-Site VPN Gateway cross-premises connection diagram

 

Monitoring (real time alerts based on metrics) vs. Diagnostics (logging errors, troubleshooting)

  • Monitoring  – Azure Monitor – VMs, Apps, to inside app code
  • Azure Monitor will now provide near real-time alerting in public preview for platform metrics from Azure services such as Virtual Machines, Networking, ServiceBus, EventHubs
  • Azure Monitor is enabling integration with your IT Service Management (ITSM) tool of choice (System Center Service Manager, Service Now, Provance or Cherwell) through the new ITSM action in Action groups. The ITSM action enables users to automatically create work items (incidents, events or alerts) in their ITSM tool when an Azure alert fires. This ITSM action is built on top of ITSM Connector Solution in Azure Log Analytics.

Diagnostics

AD versus AAD versus ADFS – Directory Services? Identity Services?

SSO for SaaS Apps? (e.g. blackboard)

This is possible, it may depend on how the SaaS was provisioned to begin with. If it was added via the Azure marketplace, there’s a few steps to ensuring that SSO works with it.

https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/blackboard-learn-tutorial


Feature 2 – Enable Password Write Back to on prem AD

This is definitely possible – and it has two steps (each with a few sub steps):

  — Enable Password Writeback option in AAD Connect (need to be Global Admin to do this)

  — Enable password Writeback option in Self Serve Password Reset (need to be global admin to do this)

Both Directory Services and Identity Services? – Azure AD Connect integrates your on prem directory with AAD.

  • Either Use Azure AD to create an Active Directory domain in the cloud and connect it to your on-premises Active Directory domain (need Azure AD Connect)

    • The Azure AD directory is not an extension of an on-premises directory. Rather, it’s a copy that contains the same objects and identities.

    • Changes made to these items on-premises are copied to Azure AD, but changes made in Azure AD are not replicated back to the on-premises domain.

    • So, what if you need full, 2 way sync?

  • OR Extend your existing on-premises Active Directory infrastructure to Azure, by deploying a VM in Azure that runs AD DS as a domain controller. This architecture is more common when the on-premises network and the Azure virtual network (VNet) are connected by a VPN or ExpressRoute connection. Several variations of this architecture are possible:

    • Create a domain in Azure and join it to your on-premises AD forest

        Deploy AD Domain Services (AD DS) servers to Azure. Create a domain in Azure and join it to your on-premises AD forest.

        Consider this option if you need to use AD DS features that are not currently implemented by Azure AD.

        Benefits

        • Provides access to the same identity information that is available on-premises.
        • You can authenticate user, service, and computer accounts on-premises and in Azure.
        • You don’t need to manage a separate AD forest. The domain in Azure can belong to the on-premises forest.
        • You can apply group policy defined by on-premises Group Policy Objects to the domain in Azure.

        Challenges

        • You must deploy and manage your own AD DS servers and domain in the cloud.
        • There may be some synchronization latency between the domain servers in the cloud and the servers running on-premises.
    • Create a separate forest in Azure that is trusted by domains in your on-premises forest.

        Deploy AD Domain Services (AD DS) servers to Azure, but create a separate Active Directory forest that is separate from the on-premises forest. This forest is trusted by domains in your on-premises forest.

        Typical uses for this architecture include maintaining security separation for objects and identities held in the cloud, and migrating individual domains from on-premises to the cloud.

        Benefits

        • You can implement on-premises identities and separate Azure-only identities.
        • You don’t need to replicate from the on-premises AD forest to Azure.

        Challenges

        • Authentication within Azure for on-premises identities requires extra network hops to the on-premises AD servers.
        • You must deploy your own AD DS servers and forest in the cloud, and establish the appropriate trust relationships between forests.
    • Replicate an Active Directory Federation Services (AD FS) deployment to Azure,

Extend AD FS to Azure

Replicate an Active Directory Federation Services (AD FS) deployment to Azure, to perform federated authentication and authorization for components running in Azure.

Typical uses for this architecture:

  • Authenticate and authorize users from partner organizations.
  • Allow users to authenticate from web browsers running outside of the organizational firewall.
  • Allow users to connect from authorized external devices such as mobile devices.

    Benefits

    • You can leverage claims-aware applications.
    • Provides the ability to trust external partners for authentication.
    • Compatibility with large set of authentication protocols.

    Challenges

    • You must deploy your own AD DS, AD FS, and AD FS Web Application Proxy servers in Azure.
    • This architecture can be complex to configure.

    Identity Services

    • Where is your identity store (central store)? What is your use case (authentication SSO or extending on prem AD?)
    •  SSO ? If on prem AD is store of identity, then use either Pass Thru Authentication of Full Sync. Spoiler – Pass thru also requires full sync of identities (minus the password)
    • Extend AD? AD DS can be hosted on prem or on Azure (recommended). AD DS goes in it’w own subnet and has at least 2 servers.
    • Azure AD is an IAM (Identity and Access Management) – Things like dynamic groups to automatically assign users to a SaaS apps based on attributes of that user.

    Azure Security

    • Azure Firewall – PaaS
    • Azure Security Center – Security Center alerts you of threats to your environments, such as remote desktop protocol (RDP) brute-force attacks and SQL injections.
    • and ‘Build your own DMZ’

    Windows Virtual Desktops

    Desktop Type – Personal (each user gets their own VM) vs. Pooled (users are directed to best available session host in the pool)

    Anuj holds professional certifications in Google Cloud, AWS as well as certifications in Docker and App Performance Tools such as New Relic. He specializes in Cloud Security, Data Encryption and Container Technologies.

    Initial Consultation

    Anuj Varma – who has written posts on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.