Solving my az deploy issues with DO-LAB

[dpcybuck]

I ran into issues deploying, i forked this repo, fixed the issues and tested over there.
Not sure if it was just me, but I hit 2 blockers. And I'm thinking if you also make these changes you'll see the same results with the DO DO-LAB deploy, and maybe less blockers for others.
--- I'm not sure if my blockers are unique to me. I generally run my things in Central US, and i have other "detection engineering" labs deployed for tests, and research with other things.
I wanted the DO-LAB and the Labbuilding101 featured int he wwhf videos to increase my "detection engineering" surface.

Please consider these changes - and if others have similar problems deploying to their azure subscriptions this could help them.

Change 1 of 3
Tested in my fork over at: https://github.com/dpcybuck/DO-LAB
First - force azure to assign public IP addresses of standard SKU, i was running into an error where my basic public IP address quota was 0, and could not increase it (documentation was saying basic is deprecated or similar)

Forked this repo, made edits to

• Deploy-AD/azuredeploy-ad.json
• Deploy-Linux/azuredeploy-Linux.json

The edits also include an update to the "apiVersion" in the resource definition.

Change 2 of 3
After forcing standard public ipaddress SKU. I was met with an error when running the ps script for:
"name": "DC01-CreateADForest2-DCPromo" and its call out to Add-DC2-Domain.ps1

Error message: 'DSC Configuration 'Add-DC2-Domain' completed with error(s). Following are the first few: WinRM cannot process the request. The following error with errorcode 0x80090350 occurred while using Negotiate authentication:

My debugging and research seemed to indicate it was something to do with either the timing of when the permissions to do the WinRM call was made, or the permissions themselves.

So I changed

• Deploy-AD/DesiredSateConfig/src/Add-DC2-Domain.ps1

NetBIOSName -DomainFQDN $DomainFQDN)
    [System.Management.Automation.PSCredential]$DomainCreds = New-Object System.Management.Automation.PSCredential ("${DomainNetbiosName}\$($Admincreds.UserName)", $Admincreds.Password)

To

    [System.Management.Automation.PSCredential]$DomainCreds = $AdminCreds

By doing it local, it seemed to avoid the issue that the domain name didn't exist yet, and the script was able to run.

Change 3 of 3
In the process of trouble shooting the issue with add-dc2-domain.ps1, I came across something I thought was the fix. But it seems like a small change for the better any way in:

• Deploy-AD/DesiredSateConfig/src/Deploy-ADCS.ps1

certutil -config "DC01.doazlab.com\doazlab-DC01-CA" -setreg policy\Editflags +EDITF_ATTRIBUTESUBJECTALTNAME2

I thought the issue with the running of add-dc2-domain.ps1 and the error running the remote WinRM call might be the hardcoded domain name here, doazlab.com\doazlab-dc01-ca
So i changed that to be more dynamically set:

$localCA  = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration' -Name 'Active' -ErrorAction Stop).Active
$caConfig = "$env:COMPUTERNAME.$using:DomainFQDN\$localCA"
certutil -config $caConfig -setreg policy\Editflags +EDITF_ATTRIBUTESUBJECTALTNAME2

If you go look at my main branch of the fork, over at: https://github.com/dpcybuck/DO-LAB
Your going to see a lot of search replace changes.

To test this I needed to change all the references to this DefensiveOrigions/DO-LAB /main and /raw/main to point to my repo so that as the arm's and scripts were running they pointed to the modified "azuredeploy-ad.json" and other things.
To test I had to change the encoded URL in readme.md and readme.html to also, point to dpcybuck/DO-LAB fork

Because of permissions I can't create a branch here. But with 3 changes. I was able to execute the DO-LAB deploy from my fork.

[dpcybuck]

In the end my goal here is to just share my adventures in getting the do lab to deploy in azure.

So I created 2 PR to merge the changes from my fork into the do-lab main.
Now I dont expect those to be accepted really, but I wanted you to be able to see the changes easy.

They are small, 4 or less lines in each file, and could be done piece meal ... or not at all. In your own branch with your own testing.

My fork allows me to create the do-lab, not have my azure deploy errors, and progress through the wwhf video, https://www.youtube.com/watch?v=WLuO1Izm9uA to "build a hacking lab on azure" which was my goal. To have a hacking lab on azure that can target the things in the do-lab but with my own detection engineering added in.

Hit me up with questions...or close these issues, or whatever, just wanted to share this with the DO team.