Azure Cloud Service Connecitivity "Remote Desktop can't find the computer "name.cloudapp.net". This might mean that "name.cloudapp.net" does not belong to the specified network.

Azure Cloud Service Connecitivity "Remote Desktop can't find the computer "name.cloudapp.net". This might mean that "name.cloudapp.net" does not belong to the specified network.

When you try to connect to a VM in a Cloud Service (name.cloudapp.net) it was working until I provisioned an additional 6 VM's into the same Cloud Service. I then tried to RDP to any of the other instances to see if it was a particular VM, or the Cloud Service itself.

The fix was easy login to Azure using the Preview Portal, expand the VM in question and click on the Reset Remote Desktop Settings, and click Yes to confirm. Then reboot the instance, and you should be able to RDP.

Active Directory Ports/Protocols between Firewall's/L3/4 Boundaries

If for whatever reason you have to have Domain Controllers separated by firewalls you will require the following ports and protocols allowed between the DC's to ensure you can A.) join the domain and B.) maintain a healthy Active Directory with replication etc.

LDAP TCP-in - 389
LDAP UDP in - 389
LDAP for Global Catalog TCP in - 3268
NetBIOS name Resolution UDP in - 138
SAM/LSA TCP in - 445
SAM/LSA UDP in - 445
Secure LDAP TCP in -  636
Secure LDAP for Global Catalog TCP in - 3269
W32Time NTP UDP in - 123
RPC - RPC Dynamic
RPC Endpoint Mapper
DNS - TCP and UDP 53
Kerberos V5 UDP in - 88
Netbios Datagram UDP in - 137

There are multiple ways to have Active Directory extended to none-trusted networks. Since Windows Server 2008 R2 the option to have a Read Only Domain Controller (RODC) in an un-trusted network has proved attractive to business. This ensure that if the un-trusted network is compromised, the RODC only holds a replicated copy of the Active Directory database. Even if the RODC was taken offline and attacked, no "write back" to Active Directory is possible so the impact is minimal. 

Depending on your requirements options such as Active Directory Federation Services (AD FS), DirSync, FIM 2010 R2 and Microsoft Identity Manager 2015 (MIM) can all be good solutions for identity and access management in an Active Directory environment.

Azure VM Instance DNS “Default Server” Unknown and Cannot Join the Windows Server 2012 R2 Domain

Today I run into a strange issue related to DNS with my traditional on premise Active Directory and an Azure VM that was to be promoted to a Domain Controller. I was basically extending an Active Directory domain to Azure to test a DR configuration of AD FS.

There is an IPsec Site-to-Site VPN from my corporate network to the Azure tenancy, this is terminated by a Cisco ASA firewall on our site. As you can see the VPN is established and passing traffic without problem. At this stage I will also mention TCP/UDP 53 is allowed both way in the firewall configuration.

In order to promote an Azure VM to a Domain Controller from an already existent Active Directory, Microsoft recommend configuring the Azure vNet to point to one (or more) of the existing DC/DNS servers so that it can join the domain etc. The guidelines are to then change the Azure DNS Servers to the local Azure server, once the VM has successfully became a DC. Microsoft state that DNS Servers should be configured on the vNet themselves instead of statically configured inside the VM’s, this is to ensure the DNS Server settings are retained if the instance is automatically moved to another underlying Hyper-V host by Azure. Azure instances are addressed dynamically by default.

I did just this, under my vNet/Configuration/DNS Servers I configured the entire vNet to look to a Domain Controller which was at 192.168.1.1. The problems started when I logged onto my Azure instance, the DNS Server had been assigned by the internal Azure DHCP as it was my primary name server if I run the nslookup tool.

As you will see from the image above the DNS requested “timed out”, and the Default Server is “unknown”. This is indeed a well-known problem if you do not have reverse lookup’s configured correctly inside your Active Directory DNS. In my case Reverse Lookups were configured and working correctly so that did not solve my problem. It’s worth noting that at this stage I had already defined an Active Directory Subnet and Site for my Azure tenancy.

Obviously without DNS working correctly I could not promote this Azure VM to a Domain Controller, therefore the troubleshooting began. My first port of call was the BPA’s for both Active Directory and DNS, I run both of these and there were no errors returned.

I then decided to check Active Directory’s general health and replication state. The following commands came in handy to do this;

repadmin /replsummary

repadmin /showrepl

repadmin /replsum

repadmin /syncall

dcdiag /a

In this particular environment there was two Active Directory sites, each with a single Domain Controller (it’s a PoC lab). At first I was not paying much attention to the DC in the secondary site, as the VPN from Azure was only terminated to the primary site. Network routes to the secondary site were also not configured. It turns out there was a replication issues between the two DC’s, they had not replicated in over 4 days.

The replication issue was 1722 The RPC Server is unavailable I followed this guide https://technet.microsoft.com/en-us/library/replication-error-1722-the-rpc-server-is-unavailable(v=ws.10).aspx which sorted the problems. I then rebooted the Azure VM and the DNS resolved properly. I suppose it goes without saying before you make any significant changes to an Active Directory always perform a mini-health check on it to ensure it’s working correctly.

AD FS 3.0 Configuring SSO for Multiple Domains/UPN Suffixes

Active Directory Federation Services 3.0 supports SSO for multiple domains by default. In previous versions of AD FS (2.0, and 2.1) a number of updates were required in order for it to support this. At one stage, if an organization required AD FS SSO for multiple domains they had to deploy multiple AD FS infrastructures to support this. 

If you are using Office 365 and currently have multiple UPN Suffixes in your organization, the way in which you convert your domain to a "federated" domain is slightly different than the way you would configure it with a single domain.

At a high level you must have the following configured to ensure you can use SSO with multiple domain names;

⦁ Additional UPN Suffixes defined under Active Directory Domains and Trusts
⦁ Additional Domains configured within Office 365

In my environment my primary domain is domain.com this is the FQDN my Active Directory domain uses. I am going to configure my ADFS/Office 365 to support SSO for domain1.com and domain2.com.

You can add additional domains in Office 365 from the Dashboard then Add Domain.

Once additional UPN's are added to a domain, you can use a user accounts property box under the Account tab, which UPN suffix is the default for that account.

The following commands are required if you have already converted your primary domain to a federated domain and SSO is working for the primary domain only. What this does is, revert the primary domain to a non-federated domain which removes the Office 365 Relay Trust from the AD FS infrastructure. The commands then create the Relay Trust and convert the primary domain back to being federated. The -SupportMultipleDomain is the important switch here.

Connect-MsolService Set-MsolAdfsContext -Computer "adfs.domain.com" Convert-MsolDomainToStandard -DomainName "adfs.domain.com" -SkipUserConversion $True Set-MsolAdfsContext -Computer "adfs.domain.com" Convert-MsolDomainToFederated -Domain "domain.com" -SupportMultipleDomain Convert-MsolDomainToFederated -Domain "domain1.com" -SupportMultipleDomain Convert-MsolDomainToFederated -Domain "domain2.com" -SupportMultipleDomain Update-MsolFederatedDomain -Domain "domain1.com" -SupportMultipleDomain Update-MsolFederatedDomain -Domain "domain2.com" -SupportMultipleDomain

If you have not yet configured your domain to be federated, you can skip the step Convert-MsolDomainToStandard.

You can check if everything has worked correctly by using the following command;

Get-MsolDomain

All of your domains should now be set to Federated.

Configure Office 365 Regional and Language Settings Globally

If you are in the process of adopting or migrating to Office 365, you will probably be looking to automate as much of the process as possible. When a user initially logs in to Office 365 they will be prompted to set their Regional and Language settings.

The following command can be used to set the time zone and language settings across all of the mailboxes. 

Get-mailbox | Set-MailboxRegionalConfiguration -Language en-gb -TimeZone "GMT Standard Time"

By piping the Get-Mailbox string into the command it sets it for all mailboxes, you could of course use the -Identity switch and and point to individual mailboxes/users.

Configuring Azure Site to Site VPN with Cisco ASA 9.x Firewall

It is highly likely you will be required to create a site to site VPN from your on-premises network to the Azure public cloud. In order to do this you must have a compatible VPN peer that is capable of terminating the IPsec VPN. All of the main network vendors have supported devices such as Cisco, Juniper and Palo Alto etc. You can consult the following website to see what devices are supported;

https://azure.microsoft.com/en-us/documentation/articles/vpn-gateway-about-vpn-devices/

Windows Server 2012/2012 R2 is also a supported configuration with the Routing and Remote Access (RRAS) role installed, this however when I tried to do it behind my Cisco ASA I could not get it to work. If you research around some forums etc most people only get RRAS to work with Azure if it is directly connected to the internet without any kind of NAT in-between. Most enterprises won’t be using RRAS anyway.

This example will cover setting up an Azure vNet with an Azure Gateway that is connected to a Cisco ASA 5505 firewall. At the time of writing Azure automatically generated configuration scripts for Cisco and Juniper devices, although these sometimes need tweaking before they work correctly, I cover this further down.

Define Local Network

The first stage is to define the Local Network, which is the network space in which your on premise environment works with. It is with the Local Network you also specify the outside global address that your VPN device has on its outside (or public) interface.

Open the Azure Management console, click New then Network Services, Virtual Network and then Custom Create.

Input a name for the local network, something descriptive is best and then enter the VPN Device IP as stated above.

You must then specify the address space that is being used within your on premise network, the address spaces used on premise and the cloud cannot overlap. Therefore you cannot have 192.168.1.0/24 on site and in the cloud.

Define DNS Servers

The next step is to define the name resolution servers, you require at least one on premise and in the cloud, click New > Network Services > Virtual Network > Register DNS Server and define the DNS servers.

Create Virtual Network

Now create a new Virtual Network click New > Network Services > Virtual Network > Custom Create. The vNet is the logical entity that the VM instances connect to.

Enter a descriptive name for the vNet and set the location. 

From the next pane click the DNS Servers that were defined in the previous step. Tick Configure site-to-site VPN and then select the Local Network object that was defined in a previous step.

Now configure the address spaces you intend to use for your cloud based instances. Also click Add Gateway Subnet this will provision a small subnet to be used for the inter-tunnel communications. 

When the network is created the next step is to create a Virtual Gateway, which is assigned a public address. This process can take around 15-20 minutes to complete.  Click Create Gateway and select the Routing type, the Cisco ASA actually only supports Static Routing. Consult the following document to check if dynamic routing is supported for your VPN device 

https://azure.microsoft.com/en-us/documentation/articles/vpn-gateway-about-vpn-devices/

Click Yes to confirm you want to create a gateway.

The interface will appear like it is below, the VPN cannot be formed until the VPN device is up dated with the configuration script. Unfortunately if you do not have a Cisco or Juniper firewall device you may have to do some manual configuration.

Click Download VPN Device Script from under Quick Glance. You can then select what options suit your environment, I hope Microsoft increase the number of devices and operating systems. The current options do not come close to what Amazon Web Services offers, they have pre-created scripts for almost all of the networking vendors I can name, with multiple different operating system versions.

Something that is not obvious when you download the configuration script for the Cisco ASA is that it assumes your firewall's interfaces are called inside/outside, for example some environments use private/public, this is not obvious if you are not a familiar with firewall scripts. I have highlighted everything below that must be changed to reflect your exact firewall configurations.

! Microsoft Corporation ! Windows Azure Virtual Network ! This configuration template applies to Cisco ASA 5500 Series Adaptive Security Appliances running ASA Software 8.3. ! It configures an IPSec VPN tunnel connecting your on-premise VPN device with the Azure gateway. ! --------------------------------------------------------------------------------------------------------------------- ! ACL and NAT rules ! ! Proper ACL and NAT rules are needed for permitting cross-premise network traffic. ! You should also allow inbound UDP/ESP traffic for the interface which will be used for the IPSec tunnel. object-group network azure-networks  network-object 172.16.0.0 255.240.0.0  exit object-group network onprem-networks  network-object 10.0.0.0 255.0.0.0  exit access-list azure-vpn-acl extended permit ip object-group onprem-networks object-group azure-networks nat (inside,outside) source static onprem-networks onprem-networks destination static azure-networks azure-networks ! --------------------------------------------------------------------------------------------------------------------- ! Internet Key Exchange (IKE) configuration ! ! This section specifies the authentication, encryption, hashing, Diffie-Hellman, and lifetime parameters for the Phase ! 1 negotiation and the main mode security association. We have picked an arbitrary policy # "10" as an example. If ! that happens to conflict with an existing policy, you may choose to use a different policy #. crypto isakmp enable outside crypto isakmp policy 10  authentication pre-share  encryption aes-256  hash sha  group 2  lifetime 28800  exit ! --------------------------------------------------------------------------------------------------------------------- ! IPSec configuration ! ! This section specifies encryption, authentication, and lifetime properties for the Phase 2 negotiation and the quick ! mode security association. crypto ipsec transform-set azure-ipsec-proposal-set esp-aes-256 esp-sha-hmac crypto ipsec security-association lifetime seconds 3600 crypto ipsec security-association lifetime kilobytes 102400000 ! --------------------------------------------------------------------------------------------------------------------- ! Crypto map configuration ! ! This section defines a crypto map that binds the cross-premise network traffic to the ! IPSec transform set and remote peer. We have picked an arbitrary ID # "10" as an example. If ! that happens to conflict with an existing crypto map, you may choose to use a different ID #. crypto map azure-crypto-map 10 match address azure-vpn-acl crypto map azure-crypto-map 10 set peer x.x.x.x crypto map azure-crypto-map 10 set transform-set azure-ipsec-proposal-set ! Note that you can only bind one crypto map to the "outside" interface. You can, however, define ! different peer/transform-set within a crypto map and identify them with different IDs. crypto map azure-crypto-map interface outside ! --------------------------------------------------------------------------------------------------------------------- ! Tunnel configuration ! ! This section defines an IPSec site-to-site tunnel connecting to the Azure gateway and specifies the pre-shared key ! value used for Phase 1 authentication.  tunnel-group x.x.x.x type ipsec-l2l tunnel-group x.x.x.x ipsec-attributes  pre-shared-key xxxxxxxxx  exit ! --------------------------------------------------------------------------------------------------------------------- ! TCPMSS clamping ! ! Adjust the TCPMSS value properly to avoid fragmentation sysopt connection tcpmss 1350 exit

For example if you see my interfaces on my home ASA are inside/outside so the script is fine for me, but if your interfaces are different you will have to edit the script. My ASA is also running IOS 9.3 and the script is for 8.3, the difference is how the static NAT statement is written.

You can use the ASDM or an SSH session to your firewall to input the script, if you are using ASDM click Tools and Command Line Interface...

Select Multiple Lines and copy and paste the lines of code into the box, I have found the exit statements in the script get returned by the ASA as none executable code, so I edit them out.

Return to the vNet page and click Connect. If everything has been completed successfully your VPN should form correctly, all of the routes etc should automatically be in place therefore when you ping an on premise server it should get all the way to your Azure instances.