• Deploy a Windows Server 2016 RDS Farm in Microsoft Azure
• Create Microsoft Azure networks, storage and Windows image
• Deploy the Microsoft Azure Virtual Machines
• Configure Domain Controllers
  
• Deploy the RDS farm
• Configure File Servers for User Profile Disk (UPD)
• RDS final configuration

Prepare the On-Prem Active Directory

In the following screenshot, you can find the current sites and services configuration. I have two sites with a replication link.

Now I’m going to create a new site, subnets, and a new replication link with PowerShell:

$OnPremSite = "Lyon-HyperV"
$AzureSite  = "Azure"
$AzureDesc  = "Azure AD Site"

Try {
    New-ADReplicationSite -Name $AzureSite `
                          -Description $AzureDesc `
                          -ErrorAction Stop

    New-ADReplicationSubnet -Name 10.11.0.0/24 `
                            -Site $AzureSite `
                            -ErrorAction Stop

    New-ADReplicationSubnet -Name 10.11.1.0/24 `
                            -Site $AzureSite `
                            -ErrorAction Stop

    New-ADReplicationSiteLink -Name $($OnPremSite + "-" + $AzureSite) `
                              -ReplicationFrequencyInMinutes 15 `
                              -InterSiteTransportProtocol IP `
                              -SitesIncluded $OnPremSite, $AzureSite `
                              -Cost 200
                              -ErrorAction Stop
}
Catch {
    Write-Output $Error[0].Exeption.Message
}

The following screenshot presents the sites and services configuration after that I have run the script.

Below you can find the subnets configuration.

Azure VM configuration

First of all, I set to static the IP address of my domain controllers:

• AZADS0: 10.11.0.20
• AZADS1: 10.11.0.21

Then I change the DNS configuration. AZADS0 is bound to On-Prem domain controllers.

AZADS1 is bound to AZADS0 and an On-Prem domain controller.

Thanks to this configuration, both domain controllers are able to resolve the On-Prem domain DNS name (called homecloud.net).

Operating system configuration

Now I’m connecting to each domain controller (across the private IP because VPN is established) and I create a new volume on the data disk. I run the following PowerShell cmdlet:

Initialize-Disk -Number 2
New-Volume -DiskNumber 2 -FriendlyName Data -FileSystem NTFS -DriveLetter E

Then I install the domain service and DNS role:

Install-WindowsFeature AD-Domain-Services, DNS -IncludeManagementTools

Next I add promote the server as a domain controller:

Import-Module ADDSDeployment
Install-ADDSDomainController `
-NoGlobalCatalog:$false `
-CreateDnsDelegation:$false `
-Credential (Get-Credential) `
-CriticalReplicationOnly:$false `
-DatabasePath "E:\NTDS" `
-DomainName "homecloud.net" `
-InstallDns:$true `
-LogPath "E:\NTDS" `
-NoRebootOnCompletion:$false `
-SiteName "Azure" `
-SysvolPath "E:\SYSVOL" `
-Force:$true

Once each Azure domain controllers are promoted, I open again the Active Directory Sites and Services. You can see now that both Azure Domain Controllers are located in Azure AD site.

Next topic

In the next topic, I will deploy the RDS Farm with all roles in High Availability. I’ll try to make the most PowerShell possible.

The post RDS 2016 Farm: Configure Domain Controllers appeared first on Tech-Coffee.

Add identity source

To be able to authenticate to vCenter with Active Directory, you have to add an identity source. To add an identity source, navigate to Administration | Single Sign-On | Configuration. Click on the add button.

Then select Active Directory (Integrated Windows Authentication).

In the next screen, the wizard tells you that you cannot add this identity source because the vCenter Single Sign-On server is not joined to a domain. So, click on Go to Active Directory Management to join the vCenter SSO server to the domain.

Next, click on join.

Then specify a domain, an OU and credentials to join the vCenter to the domain.

Next restart the vCenter server. When it is online again, you should be joined to the Active Directory Domain.

Next go back to to Administration | Single Sign-On | Configuration. Click on the add button. Then select Active Directory (Integrated Windows Authentication). Now the wizard sets automatically the domain name. Just click on next.

After you have reviewed the settings, you can click on finish to add the identity source.

Once you have added the identity source, you should have its information in the table as below.

Use Active Directory users and groups in vCenter

Now that vCenter can use Active Directory accounts to authenticate, you can browser users and groups. Navigate to Users and Groups tab. In domain menu, select your domain. You should get all the user of the domain.

In the Active Directory console, I have created a group called GG-VMwareAdmins. The account Romain Serre is a member of this group.

Next go back to vCenter and select groups tab. Select the Administrators group and click on add member.

Then select your domain and specify the name of the group in search field. Once you have found your group, just click on Add and OK.

Now the GG-VMwareAdmins Active Directory group is member of Administrators vCenter group.

From the authentication page, specify an account member of the Active Directory group.

If the configuration is good, you should be logged into vCenter as below.

Activate Windows Session Authentication

VMware provides an authentication plugin to use the Windows session login to authenticate to vCenter. The below screenshots come from Firefox. Open the browser and navigate to the vCenter authentication page. Then in the footer of the page, click on Download Enhanced Authentication plugin.

Once you run the installer, you have a warning saying that all other plug-in instances will be stopped. Just click on OK.

Next the wizard says to you that two plug-ins will be installed: the VMware Enhanced Authentication Plug-in and VMware Plug-in Service installers. Click on OK.

Foreach plug-in, follow the process to install it.

When both plug-ins are installed, close and open the web browser. Next, open again the vCenter authentication page. You should have the below popup. Click on Remember my choice for vmware-plugin links and click on Open link.

Next, you are able to check Use Windows session authentication. When you check the box, the below pop-up appears. Click on Allow.

Now you can use the Windows session credentials to authenticate to vCenter.

Conclusion

The authentication from Active Directory brings a valuable way to manage and segregate rights. Almost all companies have an Active Directory to manage authentication and authorization centrally. Thanks to Active Directory, vCenter authentication and authorization can also be managed from this service. This enables to increase the security level because vCenter is not managed alone anymore and it is integrated into the overall company security policies (such as password length, expiration and so on).

The post Authenticate to vCenter from Active Directory credentials appeared first on Tech-Coffee.

Architecture overview

Currently I have an On-Premise datacenter with two domain controllers which host the int.homecloud.net directory. The network subnet is 10.10.0.0/24. In the Microsoft Azure side, I will deploy a Virtual Network with a subnet 10.11.0.0/24. Two Azure VM will be deployed in this network.

Then I will implement a Site-To-Site VPN based on IPSec to connect my datacenter to Virtual Network hosted in Microsoft Azure. Then I will add Azure domain controllers to my domain.

Prerequisites

To deploy this lab, I have created a resource group called HybridAD with:

• A Storage Account called hybridadstorage (Local Redundant Storage)
• A Virtual Network called HybridADNetwork with a subnet 10.11.0.0/24.
• 2x Basic_A1 VM with an IP in 10.11.0.0/24 network (static IP) and a public IP

In On-Premise datacenter, I have two domain controllers already configured to host the int.homecloud.net domain.

Configure the Site-to-Site VPN

First of all, we have to connect the datacenter to virtual network in Microsoft Azure. First of all, I add the gateway subnet from the virtual network settings. In subnet settings, just click on + Gateway subnet.

Once the gateway subnet is added, you can open the marketplace and look for Virtual Network Gateway.

Then set the network gateway settings. Select your virtual network and create a new Public IP Address as below. Then choose the Gateway type and the VPN type. Route-based refers to dynamic routing and policy-based refers to static routing.

Once the creation of the virtual network gateway is running, open again the marketplace and this time I select local network gateway.

Specify the name, the public IP address of your datacenter and the local address spaces.

Now that both gateways are registered, we can create the connection. Open the virtual network gateway settings. Select connections and click on Add. Specify the name of this connection and then select Site-To-Site (IPSec). Specify your virtual network gateway and the local network gateway. Then give a shared key.

Now you have to configure your gateway. You can refer to this documentation about the gateway. There are validated gateway and the others. In my side I have an Ubiquiti Edgerouter ER3-Lite. This device is not in the validated gateway. I have run this configuration in my gateway:

set vpn ipsec disable-uniqreqids
set vpn ipsec esp-group esp-edgemax
set vpn ipsec esp-group esp-edgemax lifetime 3600
set vpn ipsec esp-group esp-edgemax pfs disable
set vpn ipsec esp-group esp-edgemax mode tunnel
set vpn ipsec esp-group esp-edgemax proposal 1
set vpn ipsec esp-group esp-edgemax proposal 1 encryption aes256
set vpn ipsec esp-group esp-edgemax proposal 1 hash sha1
set vpn ipsec esp-group esp-edgemax compression disable
set vpn ipsec ike-group ike-edgemax
set vpn ipsec ike-group ike-edgemax lifetime 28800
set vpn ipsec ike-group ike-edgemax proposal 1
set vpn ipsec ike-group ike-edgemax proposal 1 dh-group 2
set vpn ipsec ike-group ike-edgemax proposal 1 encryption aes256
set vpn ipsec ike-group ike-edgemax proposal 1 hash sha1
set vpn ipsec ipsec-interfaces interface pppoe0
set vpn ipsec logging log-modes all
set vpn ipsec nat-traversal enable
set vpn ipsec site-to-site peer 13.94.252.98
set vpn ipsec site-to-site peer 13.94.252.98 local-address any
set vpn ipsec site-to-site peer 13.94.252.98 authentication mode pre-shared-secret
set vpn ipsec site-to-site peer 13.94.252.98 authentication pre-shared-secret <Secret>
set vpn ipsec site-to-site peer 13.94.252.98 connection-type initiate
set vpn ipsec site-to-site peer 13.94.252.98 default-esp-group esp-edgemax
set vpn ipsec site-to-site peer 13.94.252.98 ike-group ike-edgemax
set vpn ipsec site-to-site peer 13.94.252.98 tunnel 1
set vpn ipsec site-to-site peer 13.94.252.98 tunnel 1 esp-group esp-edgemax
set vpn ipsec site-to-site peer 13.94.252.98 tunnel 1 local prefix 10.10.0.0/24
set vpn ipsec site-to-site peer 13.94.252.98 tunnel 1 remote prefix 10.11.0.0/24
set vpn ipsec site-to-site peer 13.94.252.98 tunnel 1 allow-nat-networks disable
set vpn ipsec site-to-site peer 13.94.252.98 tunnel 1 allow-public-networks disable
commit
save

Once the connection is established, the status of the connection is connected.

On the gateway side, I have the below status:

Prepare your Active Directory

Now that connection is established, we can configure the Active Directory. First I create a new site called Azure. Then I associate the 10.11.0.0/24 subnet to this site. To finish, I create a site link called OnPrem-Azure. In this way, VMs in the subnet 10.11.0.0/24 will request domain controllers in this network (except when they are both down).

Deploy domain controllers in Azure

Temporarily, I set the DNS Servers to my both local domain controllers. To change the DNS Settings, open the virtual network settings and select DNS Servers. Once the DNS Servers are set, reboot your Azure VMs in order to they take the new configuration.

Then install and configure the Active Directory Domain Service role. For that, I use a PowerShell script:

Install-WindowsFeature AD-Domain-Services
Import-Module ADDSDeployment
Install-ADDSDomainController `
-NoGlobalCatalog:$false `
-CreateDnsDelegation:$false `
-Credential (Get-Credential) `
-CriticalReplicationOnly:$false `
-DatabasePath "D:\NTDS" `
-DomainName "int.HomeCloud.net" `
-InstallDns:$true `
-LogPath "D:\NTDS" `
-NoRebootOnCompletion:$false `
-SiteName "Default-First-Site-Name" `
-SysvolPath "D:\SYSVOL" `
-Force:$true

Once the servers have rebooted, you can refresh the sites and services view. In Azure site, you should have two others domain controllers.

Final modification

Now that Azure domain controller can be managed locally through the site-to-site connection, I remove the public IP. I don’t want these VMs are accessible from the Internet.

Then I changed the DNS Servers settings to the final configuration. I specify both Azure domain controllers IP addresses. In this way, Azure VMs will contact Azure domain controllers for DNS requests.

Test

To test my solution, I deploy a new virtual machine in Azure by using this script:

# Set values for existing resource group and storage account names
$rgName="HybridAD"
$locName="West Europe"
$saName="hybridadstorage"
# Ask for VM credential
$cred=Get-Credential -Message "Type the name and password of the local administrator account."
# Set the existing virtual network and subnet index
$vnetName="HybridADNetwork"
$subnetIndex=0
$vnet=Get-AzureRMVirtualNetwork -Name $vnetName -ResourceGroupName $rgName
# Create the NIC.
$nicName="VMRDS02-NIC"
$pip=New-AzureRmPublicIpAddress -Name $nicName -ResourceGroupName $rgName -Location $locName -AllocationMethod Dynamic
$nic=New-AzureRmNetworkInterface -Name $nicName -ResourceGroupName $rgName -Location $locName -SubnetId $vnet.Subnets[$subnetIndex].Id -PublicIpAddressId $pip.Id
# Specify the name, size, and existing availability set
$vmName="VMRDS02"
$vmSize="Basic_A1"
$vm=New-AzureRmVMConfig -VMName $vmName -VMSize $vmSize
# Specify the image and local administrator account, and then add the NIC
$pubName="MicrosoftWindowsServer"
$offerName="WindowsServer"
$skuName="2012-R2-Datacenter"
$vm=Set-AzureRmVMOperatingSystem -VM $vm -Windows -ComputerName $vmName -Credential $cred -ProvisionVMAgent -EnableAutoUpdate
$vm=Set-AzureRmVMSourceImage -VM $vm -PublisherName $pubName -Offer $offerName -Skus $skuName -Version "latest"
$vm=Add-AzureRmVMNetworkInterface -VM $vm -Id $nic.Id
# Specify the OS disk name and create the VM
$diskName="OSDisk"
$storageAcc=Get-AzureRmStorageAccount -ResourceGroupName $rgName -Name $saName
$osDiskUri=$storageAcc.PrimaryEndpoints.Blob.ToString() + "vhds/" + $vmName + $diskName + ".vhd"
$vm=Set-AzureRmVMOSDisk -VM $vm -Name $diskName -VhdUri $osDiskUri -CreateOption fromImage
New-AzureRmVM -ResourceGroupName $rgName -Location $locName -VM $vm

Then I connect to this server to open a PowerShell session. I run ipconfig to check the dns servers configuration.

Now I join the Active Directory.

It’s working but now I have to check if the server requests an Azure domain controller. I open the below registry key to check the VM current AD site. In the below example, my VM is mapped to the Azure AD site.

Conlusion

An Active Directory extended between On-Premise and Microsoft Azure rely on site-to-site VPN, either IPSec or ExpressRoute. Once the connectivity between both locations is established, you have just to create an Active Directory site, subnet and link. Depending on your VPN throughput, you can increase or decrease the replication frequency. If you have a high speed and low latency link such as express route, you can replicate once changes have occurred as two domain controllers in the same site. Active Directory is often a basic service, so it is convenient to install domain controllers at the closest location of the domain machine (also in Azure).

The post Extend Active Directory to Microsoft Azure appeared first on Tech-Coffee.

Password Settings Object

A Password Settings Object (PSO) is an Active Directory object. This object contains all password settings that you can find in the Default Domain Policy GPO (password history, complexity, length etc.). A PSO can be applied to users or groups. When PSO is applied on some users, there are no longer using password policy from Default Policy Settings GPO. Instead they use the PSO settings.

Because PSO can be applied to a group, a user can be linked to two PSO. However only one PSO can be applied to users. So in this case an RSoP (Resultant Set of Policy) must be calculated to apply one PSO. The RSoP calculation is based on a PSO parameter called Precedence which is a number. The PSO with the lowest number win and is applied. So the lowest Precedence number is always applied.

By default only domain administrators can create and read PSO because only these accounts can create and write object in the Password Settings Container. However only write delegation on users and groups enables to apply PSO.

Deploy Fine-Grained Password Policy

Mock-up Presentation

I have created three users in my Active Directory:

• Glen Moray that belongs no group;
• John Jameson that belongs PSO-Standard Users group;
• Jack Daniel that belongs to PSO-Standard-Users and PSO-PasswordOfTheDeath groups.

 Password Settings Object creation

First open ADAC from Server Manager and Tools menu.

Click on your Domain (mine is called Fabrikam.com) to list containers in your domain. Click on System Container.

In System container, you should have the Password Settings Container. Click on it and select New on the right.

On the PSO creation screen, you can see the password policy parameter such as password length, password history, maximum age, complexity etc. There is also the Precedence parameter. As you can see on below screenshot, I have applied PSO to PSO-Standard Users group. For these examples, I have removed the minimum password age to validate just after account creation my PSO. If I leave this setting to 1 day, I have to wait tomorrow to change password …

Next I create a stronger password policy that I applied to the PSO-PasswordOfTheDeath group.

After PSO creation you can double click on the Password Settings Container to view your PSO. On the below screenshot, you can see that my SuperSecure Password PSO has a stronger precedence.

To view the RSOP and so the PSO that will be applied to users, open your OU where are stored your users object and select an account as below. Click on View Resultant Password Settings on right.

Remove default password policy on Active Directory

To validate my test, I remove the default password policy managed by the Default Domain Policy GPO. Open Group Policy management console, and edit the Default Domain Policy.

Open Software Settings, Windows Settings, Security Settings, Account Policies and Password Policies. Set these policies as below.

First test: user without password policy

My First user called Glen Moray belong no group. So no password policy is applied to this account. To test that, I change the password to aaa as below:

Because no password policy is applied to this account, the password has been changed successfully.

Second test: User with standard users PSO

The user John Jameson is linked to the Standard Users PSO. A 8 chars complex password is required. So I try the aaa password:

Because the PSO is applied, the password can’t be applied because it does not meet the requirement related to the PSO.

So I try a complex password more than 8 chars:

The password meets the PSO requirement so it has been changed successfully.

Third test: User with SuperSecure Password PSO

Now I try Jack Daniel user. This user is a member of all my PSO group. But because SuperSecure Password PSO has the strongest precedence, this is this last that will be applied. Let’s try to validate this assumption. I try the same password than John Jameson user:

Because this password doesn’t meet the SuperSecure Password PSO requirement, the password can’t be changed.

So I generate a strong password with this tool.

Next I Past it to the reset password wizard:

And it is work !

Conclusion

Fine-Grained Password Policy is a great feature that enables to apply different password policies in your domain. For example you can apply a different password policy to administrator, to standard user and to service account. You are no longer forced to use only one password policy. Now that Microsoft has introduced the Active Directory Administrative Console (ADAC), Password Settings Object can be managed easily. So why continue to live without?

The post Fine-Grained Password Policy in Active Directory appeared first on Tech-Coffee.