Author: TheSleepyAdmin

Deploying Microsoft LAPS Part 3

In the last post we went through deploying the LAPS agent using a script, GPO or SCCM. The next step is to configure the GPO settings to apply LAPS management policy’s

First, we create a new GPO to apply the LAPS management policy’s, the LAPS policy’s are under Computer Configuration > Polices > Administrative Templates > LAPS (If this doesn’t show the ADMX template is probable missing and will need to be installed. This can be done using the LAPS installer)LAPSGP1Password settings policy used to set the password complexity, length and ageLAPSGP2Specify the account that the password policy will apply to if this is the default administrator account this should be left at defaultLAPSGP3LAPSGP4Enabled management of local admin accountLAPSGP5Once the policy is configured apply the policy against the required OULAPSPass1To confirm that all settings are working, run a gpupdate on a test device. Once applied we can check the password in a few different ways

First way is to run PowerShell command:LAPSPass

Second way is to use the LAPS UI , this can be either used from the management server or installed on local computer using the LAPS installer and selecting the LAPS management tools

LAPSPass2LAPSPass3

The third method is to check the AD computer attribute ms-Mcs-AdmPwd:LAPSPass4

Last step is to set delegated access to a security group or set of users to view and reset the local administrator password. Use the below command to verify the current rights

Find-AdmPwdExtendedRights -identity:OU distinguishedName

LAPSPass5There are two command to set the rights, one for read and one for reset rights

Set-AdmPwdReadPasswordPermission -OrgUnit OU distinguishedName -AllowedPrincipals “HelpDesk_LAPS_Access”

Set-AdmPwdResetPasswordPermission -OrgUnit OU distinguishedName -AllowedPrincipals “HelpDesk_LAPS_Access”

LAPSPass6Last step is to verify the permission have been appliedLAPSPass7

LAPS is now deployed and ready to use.

 

Deploying Microsoft LAPS Part 2

In the last post we went through installing LAPS management tools, extending the AD schema and setting the delegation rights for computer OU to allow computer to write back to the LAPS password attribute.

The next step is to install the LAPS client this can be done either by using a script, group policy or SCCM.

I used the below the script to install remotely just need to create the complist with host name of devices and update the sharename and verions of LAPS that is required

$Computers = Get-Content “C:\Temp\complist.txt”
foreach ($Computer in $Computers){
Write-Warning “installing LAPS on $Computer”
$command = “msiexec /i C:\windows\temp\LAPS.x64.msi /quiet”
$Remotecmd = “CMD.EXE /c ” + $command
Copy-Item \\sharename\LAPS.x64.msi -Destination \\$Computer\c$\windows\temp\
Invoke-WmiMethod -class Win32_process -name Create -ArgumentList $Remotecmd -ComputerName $Computer | Out-Null
}

The second option is to deploy using GPO software install

Craete a new GPO > Policies > Software settings > software installtion > New packageLAPS6Add the installerLAPS7LAPS8LAPS9Next apply the policy agaist the OU or use security filtering to apply to specific devices once the policy is applied logon to the device and run gpupdate /force to apply LAPS10

Third option is to use a tool like SCCM to package the application and deploy to devices. This would be my preferred way as its gives the best reporting.

We won’t go through the process but the command line install will  msiexec /i C:\windows\temp\LAPS.x64.msi /quietLASCCMLASCCM1

Deploying Microsoft LAPS Part 1

In this post we will be going through deploying and configuring Microsoft LAPS (Local Administration Password Solution).  LAPS is a solution to automate the changing of a local administrator account on every computer in the domain.

To install LAPS will require a management server / workstation I will be installing on my domain controller.

Supported Operating System

Windows 10, Windows 7, Windows 8, Windows 8.1, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019, Windows Vista

Active Directory: (requires AD schema extension)
• Windows 2003 SP1 or later.
Managed machines: 
• Windows Server 2003 SP2 or later, or Windows Server 2003 x64 Edition SP2 or later.
Note: Itanium-based machines are not supported.
Management tools: 
• .NET Framework 4.0
• PowerShell 2.0 or later

First step is to download the install files for LAPS

https://www.microsoft.com/en-us/download/details.aspx?id=46899

Next install the full deployment of LAPS on the designated management server / workstation.

Run LAPS installer for operating system verisonLAPS1LAPS2LAPS3

Install full management tools LAPS4LAPS5

After the management tools have been installed the next step is to extend the AD schema

The LAPS PowerShell module is called AdmPws.PSLAPSAD1

To update the Schema first add the LAPS module and then run

Update-AdmPwdADSchemaLAPSAD2

Last step is to delegate right to computer objects to allow them to write to the ms-MCS-AdmPwd and ms-Mcs-AdmPwdExpirationTime AD attributes.

Set-AdmPwdComputerSelfPermission -OrgUnit “OU=Computers,DC=Domain,DC=local”LAPSAD4

In the next post we will go through delegating access to specific users to allow them read the ms-MCS-AdmPwd attribute and to deploy the LAPS client through SCCM , script and GPO.

 

Configure Azure Site Recovery for VMware

Azure site recovery (ASR) is a DR / Migration tool from Microsoft and can be used to configure DR between data centers or Azure.

In this post we will be going through setting up ASR to replicate a VM from VMware to Azure.

There are some limitations for ASR these are listed the below link

https://docs.microsoft.com/en-us/azure/site-recovery/vmware-physical-azure-support-matrix

The main limits for VMware are guest disk need to be less than 4TB and vCenter needs to be at least 5.5.

I have a previous post on how to configured a recovery service vault so I wont be going over that again but if you need to configure here is the previous post.

https://thesleepyadmins.com/2018/11/23/azure-vm-backup-using-azure-recovery-service-vault/

Logon to Azure

Go to Recovery Services vaults

ASR1Go to the already configure vault, select Site Recovery and click on prepare infrastructureASR2Once the wizard has started select the require goalsASR3I am not running the planning tools as this is a test but it is recommended to run before starting a deployment to verify the required bandwidth. ASR4Next we will download the OVA appliance that will be imported to VMwareASR5Once the OVA has been downloaded and imported to VMware on boot up the server will require you to read / accept a licence agreement and provide an administrator password.

Give the server a name (this will show up in as the configuration server in Azure after the setup as been completed)ASR6Next step is to sign in to Azure tenant that the server will connect to for replicationASR8Next we will go through the configuration steps first step is to set the interface that will be used to connect to on-prem devices & connection back to Azure there can be two different NIC’s assigned if required. ASR9Next is to configure the Recovery vault that will be used, select the subscription, the recovery vault RG and recovery service vault that has been configured. ASR10Install the MySQL software ASR11Next a validation test will run. (I am getting a warring for memory and CPU as I didn’t have enough memory / CPU and had to edit the VM to run on less resource but it will still complete)ASR12Next is to connect to the vCenter server that is running the VM’s that are to be replicated to Azure. ASR13Last step will configure the configuration server in Azure.ASR15Once this has been completed we can go back to the Azure portal and we should now see the configuration server show under prepare infrastructure setupASR16

Select the subscription and deployment model to be used for failover I am using Resource ManagerASR17Next create a replication policy to apply to the ASR configuration server. ASR18ASR19Once the configuration is done we can now protect and replicate our on-prem VM’s , go back to site recovery and select step 1: Replicate Application ASR20Select source, source location (Configuration server on-prem)Machine type (Physical / virtual), vCenter (If virtual) and the process serverASR21Select the subscription, RG that the VM will replicate too and the deployment modelASR22Next select the server that will be replicated the VM must be powered on and be running VMware tools be available for replication other wise they will be grey-outASR23Select the required disk type, storage account ASR24last step is to assign the policy required (Multiple policy can be created base on the recovery time requirements and retention times)ASR25

Last step is to enabled replication

ASR26

Once enabled check the site recovery jobs to see the progressASR27Once replication has completed we can create a recovery plan, go to recovery Plans (Site Recovery and select Recovery planASR28Give the plan a name, select source, target , deployment type and select the VM’s that will be added to the recovery.ASR29ASR31

Azure Migrate Services Setup

With more companies looking to move workloads from on-prem to cloud providers, it can be difficult to work out the cost for current workloads.

In Azure we can utilize Azure Migrate Services.

At the time of this post VMware is only supported, this will be extended to Hyper-v in future releases. VMware VMs must be managed by vCenter Server version 5.5, 6.0, 6.5 or 6.7.

In this post we will be going through the process off assessing the on-prem VMware environment and view the assessment report.

The environment we will be assessing is VMware vCenter 6.7 and ESXi 6.7 and a VM running Windows Server 2016.

The architecture of the Azure Migrate Service is shown in the following diagram

AZMIG

Below is the process

  • Create a project: In Azure, create an Azure Migrate project
  • Discover the machines: Download collector VM as an OVA and import to vCenter
  • Collect the information: The collector collects VM metadata using VMware PowerCLI cmdlets. Discovery is agentless and doesn’t install anything on VMware hosts or VMs. The collected metadata includes VM information (cores, memory, disks, disk sizes, and network adapters). It also collects performance data for VMs
  • Assess the project: The metadata is pushed to the Azure Migrate project. You can view it in the Azure portal.

Logon to Azure

Go to All services search for migration projectAZMIG_1

Select Create migration project

AZMIG_2

Give the project a Name, subscription, Resource group & Geography

AZMIG_3

Select Discover & Assess AZMIG_4

Select Discover and Assess. then Discover machines AZMIG_5download OVA. The system requirement for the OVA are:

CPU: 8 vCPU’s; Memory: 16GB; HardDrive: 80GBAZMIG_6

Next step is to import the OVA to VMware

Go to vCenter

AZMIG_7

Browse to the OVA file location and selectAZMIG_8Select the Name and location of the OVAAZMIG_9Select the destination cluster AZMIG_10Click NextAZMIG_11Select destination data store and specify either thick or thin provisioned diskAZMIG_12Select the port group tha the VM will useAZMIG_13Review and confirm settingsAZMIG_14

Once the OVA is imported, power on the VM

Read and accept the license terms and give the collector an admin password.

Log into the VM and run the connector utility on the desktop.

AZMIG_15

Got through the prerequisites checksAZMIG_16

Next step is to connect to the vCenter. Put in the vCenter IP or hostname, Username / Password and once connect select the cluster or host that is currently running the VM’s that need to be assessed for migration.

AZMIG_17

Next step is to connect back to Azure using the migration project credentials that were generated when creating the projectAZMIG_19AZMIG_18

Click continue and the last screen will start the discovery this can take a while to complete (60 minutes or so)AZMIG_20

Once the discovery has completed, we then need to Create assessmentAZMIG_21

Create a new group and select the VM that will be assessedAZMIG_22

Once this has completed go to Overview and click on the assessmentAZMIG_23

Once in the assessment you can see the readiness of your VM and the Monthly estimated cost for running the workloads and AZMIG_24

Click on the VM to view specific details and performance statsAZMIG_25

We can now see what the cost will be for migrating workloads to Azure and this can be presented to give a better understanding of the cost savings that can be achieved with cloud migrations.

 

 

 

 

Configure Branch Cache SCCM 1810

We recently started to roll out Windows 10 and started to see spikes on our WAN links caused by the increased size of updates. We look at installing local DP on each site but this would add a lot of over head for managing these DP’s.

We then looked at using branch cache, I decided to do a post on enabling branch cache in SCCM.

First I need to check on clients if branch cache was enabled to do this run the below command.

netsh branchcache show status all

BC1

Once confirmed we need to enable branch cache in SCCM client settings this can be either enabled on an existing device policy or create a new policy I am going with a new policy.

Logon to SCCM Admin console > Administration > Client settings

Right click on client settings > Create Custom Client Device SettingsBC2

Give the policy a Name and select Client Cache SettingsBC6

set the below settings

  • Change Configure BranchCache to Yes
  • Change Enable BranchCache to Yes
  • Configure the cache size settings (default is 10%)

BC3

As part of Windows 10 OS it does it’s own branch Cache while downloading updates and it will overwrite SCCM client settings. To disable this setting we can create a group policy and apply just to windows 10 OS’s.

Below is the location of the settings that need to be disabled

Computer Configuration \ Policies \ Administrative Templates \ Windows Components \ Delivery Optimization, set (Download Mode) to disabledBC5

If the policy is not showing it is probable because the ADMX template for windows 10 has not been added.

The last part is to enable Branch Cache in SCCM for the distribution points by selecting the properties of the distribution point as given below.BC4

To test that the policy has been applied go to a client device and update the machine policy. Then run netsh command again and we should now see branch cache has been enabled.

netsh branchcache show status allBC7

Install and Configure VMware NSX

Recently we have been looking to implement zero trust networking. One way to achieve this was to use physical firewall and multiple VLAN’s to break out traffic and restrict access to each VLAN this would take a long time to complete and is quite difficult to manage.

It would require adding between 30 to 60 additional VLAN to our physical servers and VMware and re assinging IP to each server which would cause a lot of downtime.

As an alternative to this I have been looking at VMware NSX to try achieve this same segmentation without the need to redesign the entire VMware networks.

NSX consists of multiple components under different planes like management, control, and data plane’s below is an image of the different plane’s. 

In the next set of posts I am going to go thorough install and configuring a basic NSX deployment. I will be setting this up in a Lab environment and will use nested ESXi and appliances.

It is recommended to have NSX installed on its own management cluster along with vCenter.

First step is to download the OVA for NSX current version is 6.4.4

https://my.vmware.com/web/vmware/details?productId=417&downloadGroup=NSXV_644

below are the system requirments to deploy NSX

NSX Component Hard Drive Memory vCpu
NSX Manager 60 16 4
NSX Controller 20 4 4

NSX 6.4.4 is not supported on vSphere 5.5 below are the supported and recommed verison of vSphere to run NSX 6.4.4:

  • For vSphere 6.0:
    Supported: 6.0 Update 2, 6.0 Update 3
    Recommended: 6.0 Update 3. vSphere 6.0 Update 3 resolves the issue of duplicate VTEPs in ESXi hosts after rebooting vCenter server. SeeVMware Knowledge Base article 2144605 for more information.
  • For vSphere 6.5:
    Supported: 6.5a, 6.5 Update 1
    Recommended: 6.5 Update 1. vSphere 6.5 Update 1 resolves the issue of EAM failing with OutOfMemory. See VMware Knowledge Base Article 2135378 for more information.

Once the OVA is downloaded logon to vCenter right-click on datacenter and deploy OVF Template.

NSX6_1

Select the location of OVANSX2

Give the appliance a nameNSX3

Select the Cluster that will run the applianceNSX4

Click next NSX5

Accept the licence agreement and click continueNSX6

Chose Thick ProvisionNSX7

Select the network that will be used for the management networkNSX8

The next screen is where all the customization will be setup

Appliance Password:

HostName:

Network settings: management IP, subnet, gateway, DNS and NTP. Leave blank if  you want to use DHCP but its recommend to use static addressesNSX9NSX10

Once all setting are configured click next and confirm all settings on the last screen. Once finished the OVA should start to deploy. (Note that this failed the first time for me as I selected a host and there seems to be an issue with this in vCenter 6.7, once I selected the cluster the OVA deployed without issue)NSX11

Once the OVA had been deployed I decided to edit the memory size as I was running low on memory so I change it from 16Gb to 8Gb but for production this should be left at 16Gb.

After this you can connect using DNS name configured above or through the management IPNSX12

The last step in this post is to connect NSX to vCenter

Logon using  admin and the password specified in the config of the OVA

Click on Manage vCenter Registration NSX13

both the lookup and vCenter server connection will need to be configuredNSX15

Add vCenter server and user name / passwordNSX16NSX18

There will be a prompt to trust the vCenter certificate click yes to continueNSX17

Once configured both status should show as connectedNSX19

Open the vCenter web client and once logged on there should now be an addtional tab for Networking & Security. (At the time of this post this option is only available in the Flash version of the Web client not the HTML 5 version) 

NSX20NSX21

In the next post we will start to configure the NSX and controllers.

Azure Configure vNet peering

To allow communication between vNet’s in Azure we can set up peering connections. This is useful if there is a need to have different vNet’s for things like web app’s and backend database zones.

To configure peering we will require two different vNets both must be in the same Azure region.

Currently when I try to ping a VM that is running in a different vNet there is no communication.vNet01

Logon to Azure

Go to All services > Virtual networksvNet04

Once in Virtual networks select the network that will be configure for peeringvNet02

Once the network blade is open go to peering > AddvNet03

Enter a Name, select the Subscription that the other vNet is in. Then Select the Virtual Network. Under configuration select Enabled and the last step tick Allow forwarded trafficvNet05

Below are some details on three options:

Allow forwarded traffic: This setting allows the peer’s forwarded traffic (traffic not originating from inside the peer virtual network) into your virtual network.
Allow gateway transit: Allows the peer virtual network to use your virtual network gateway. The peer virtual network cannot already have a gateway configured, and must select ‘use remote gateway’ in its peering settings.
Use remote gateway: You will need to Select this option if you wish to use your peer’s virtual network gateway. The peer virtual network must have a gateway configured, as well as ‘allow gateway transit’ enabled. Only one peering in this virtual network can have this enabled. You cannot use this setting if you already have a gateway configured in your virtual network.

Once all settings are confirmed click ok to create the peeringvNet06vNet07

Two allow communication both ways, there will need to peering setup on the App network aswell.

Once both are enabled we can now see response to ping requestsvNet08

To lock down communication between the networks we can add NSG’s to restricted what inbound and outbound traffic is allowed from the subnet’s.

Configure MFA For Azure Application Proxy

On the last post we setup Azure Application Proxy to allow internal application’s to be made available externally using AAD integration.

To add additional security to the setup we can enable MFA for the group or users that will be allowed access.

To enable MFA we need to create a conditional access policy and enable on the application proxy.

First step Login to Azure

Go to Azure Active Directory (AAD)AZ1

Go to Enterprise applications

AZ3

Select the Application proxy that will require MFA to be enabledMFA6

Once in the Application proxy go to Conditional Access and select New policyMFA1

Give the policy a meaningful name as it will appear in the overall Conditional Access policy’s aswell as on the Application. This will make it easier to manage if there are multiple policy’s.

Then select Users and groups and select the required users or groupMFA2

Next select the cloud apps that will require MFA in this case it is the Exchange ECP application that was configured previouslyMFA3

We will not setup conditions but if this is required it can be set to only allow access from certain devices types, location & sign-in risk level.

Next go to Access controls and then Grant tab. Select Grant access, tick Require multi-factor authentication and Requires one of the selected controls MFA4

Last step is to Enable the policy

MFA7

Click create at the bottom of the policy

The policy should now show and have tick under Enabled MFA5

Now when we try to access the ECP Application proxy URL,

we should be prompted for MFA MFA8

and asked to register and verify a device to be use for MFAMFA9

It is a good idea to enable MFA for application as it gives an additional layer of security.

Configure Azure Application Proxy To Access Internal Application

To access internal applications we can use Azure Application proxy to integrate with Azure AD and allow remote access to internal resources.

To use Azure Application Proxy requires Azure AD basic,  Premium P1 or Premium P2 subscription.

An Account with Global administrator rights

The Azure application proxy connector requires Windows Server 2012 R2 or later

Below are pre-req ports and URL’s

Port number How it’s used
80 Downloading certificate revocation lists (CRLs) while validating the SSL certificate
443 All outbound communication with the Application Proxy service
URL How it’s used
*.msappproxy.net
*.servicebus.windows.net		 Communication between the connector and the Application Proxy cloud service
mscrl.microsoft.com:80
crl.microsoft.com:80
ocsp.msocsp.com:80
http://www.microsoft.com:80		 Azure uses these URLs to verify certificates
login.windows.net
login.microsoftonline.com		 The connector uses these URLs during the registration process.

The following diagram shows how Azure AD and Application Proxy work together to provide single sign-on to on-premises applications.azureappproxxy

To start we need to download and configure the proxy connector

Login to Azure

Go to Azure Active Directory (AAD)AZ1

Once in AAD go to Application proxy

AZ2

Click Download connector serviceAPinstall0

Once downloaded run the MSI on the server that will be used as the application proxy connector (I used a server in a DMZ zone). It will prompt for an Azure account with Global admins rights.

Once configured the server should now show in the application proxy tabAPinstall4

Once connected and active next step is to configure application

Go to AAD and Enterprise applications

AZ3

Once in Enterprise applications click on New application APinstall7

Click on On-premises applicationAPinstall8

Below is a description for each field and option available in the application proxy

Field Description
Name The name of the application that will appear on the access panel and in the Azure portal.
Internal URL The URL for accessing the application from inside your private network. You can provide a specific path on the backend server to publish, while the rest of the server is unpublished. In this way, you can publish different sites on the same server as different apps, and give each one its own name and access rules.

If you publish a path, make sure that it includes all the necessary images, scripts, and style sheets for your application. For example, if your app is at https://yourapp/app and uses images located at https://yourapp/media, then you should publish https://yourapp/ as the path. This internal URL doesn’t have to be the landing page your users see. For more information, see Set a custom home page for published apps.
External URL The address for users to access the app from outside your network. If you don’t want to use the default Application Proxy domain, read about custom domains in Azure AD Application Proxy.
Pre Authentication How Application Proxy verifies users before giving them access to your application.

Azure Active Directory – Application Proxy redirects users to sign in with Azure AD, which authenticates their permissions for the directory and application. We recommend keeping this option as the default, so that you can take advantage of Azure AD security features like conditional access and Multi-Factor Authentication. Azure Active Directory is required for monitoring the application with Microsoft Cloud Application Security.

Passthrough – Users don’t have to authenticate against Azure Active Directory to access the application. You can still set up authentication requirements on the backend.
Connector Group Connectors process the remote access to your application, and connector groups help you organize connectors and apps by region, network, or purpose. If you don’t have any connector groups created yet, your app is assigned to Default.

If your application uses WebSockets to connect, all connectors in the group must be version 1.5.612.0 or later.

Fill out the details required. I am using passthrough for pre authentication for the web site but this can be changed to AAD which then requires authentication before the site can be accessed.

(I created a basic IIS page on an internal web server to test with)APinstall9

Next step copy the external URL and try to access the site. There should be no prompt and the site should load

(Yay my lovely test site is available 🙂 )APinstall13

I decided to also allow access to my internal Exchange server and to also test the AAD pre-authentication.

First create a second application proxy and set the Pre Authentication to Azure Active DirectoryAPinstall14

I wanted to use a custom domain name for the second application proxy so I changed the external URL to the custom domain name in Azure.

Once a custom domain is selected we can add a certificate to match the URL.

There will be a warning that a CNAME entry will be required to point from the custom URL to the msappproxy.net addressAPinstall18

(This will require a CNAME record to be created on public DNS server that will map the application proxy to msappproxy.net)CNAME

Once configured we need to add a user or group to allow access.

Go to the application proxy, select the required application proxy and click on Users and groups, Add user and select either the user or group that will be allowed accessAPinstall16APinstall15

Copy the link for the application proxy.

Unless a valid cert was also uploaded you will receive a cert error click continue to site.

It should now prompt for AAD authentication. Use an account that has access right to the proxyAPinstall11

Once logged in the ECP page should now show. APinstall10