DSC, Azure templates, and key vaults

DSC
1

I am running into an issue using the xComputer module in a DSC extension to an ARM template, trying to join it to a domain that is created earlier as part of that same template. What I am doing is passing the same admin credentials to the DSC template, but I get a failure saying it’s the wrong username/pass. I think maybe what’s happening is that, since the admin password in the parameter template file is a reference to a keyvault, maybe the account running DSC doesn’t have access to it. Does anyone happen to know what account that would be running as? The keyvault does allow my @outlook account access to the secret that contains the password, so the template deployment does work, but if the DSC extension is running as something else it almost certainly doesn’t have access.

I know I can use a domain join extension in the template itself, which if this is the issue, will probably work. I will try that tomorrow if I don’t figure this out before then.

Edit: If it helps, this is the branch of the project I am working on - https://github.com/oradcliffe/AzureRm-Windows-Domain/tree/domainjoin

2

The LCM runs as SYSTEM, unless you’ve passed a PSCredential to a given setting to make that setting run as something different. But I’m not quite certain that’s the credential you’re asking about - I’m not quite following the thread of what I think you’re after.

3

Hey Don,

I wound up just using a join-domain extension within my ARM template, so I guess that was a workaround. However, the question I was trying to ask was whether or not we are able to pass a secure password from an Azure Key Vault to a DSC extension. Do you happen to know if that’s doable?

It seems like every time I try to use a DSC extension within an ARM template I run into credential issues - for instance, now I have a primary DC and a server that joins the domain, and another server coming up in the template, but trying to make that third server a backup DC seems to be having similar issues, but this time using the xADDomainController resource. I guess I am wondering if the issue may be that I am just giving it bad credentials somehow due to the password being stored in a keyvault.

Thanks!

4

Here’s an update - I don’t think the fist DSC config I have is actually using any credentials at all when standing up that first domain controller; I think it’s using the first user’s (local admin) account.

The reason I think this is because now that I am working on adding a second domain controller (which checks for a domain and so would need domain credentials), I can’t get the DSC config to work, except in the case that I use this in my DSC config:

"configurationArguments": {
                "DomainName": "[parameters('domainName')]",
                "Admincreds": {
                  "Username": "radcliffe",
                  "Password": "Pa$$w0rd"

Notice here I am not using any protected settings, and indeed if I replace that Pa$$w0rd with:

"settings": {
              "wmfVersion": "latest",
              "configuration": {
                "url": "[variables('DSCURL')]",
                "script": "[variables('DC02DSCscript')]",
                "function": "[variables('DC02DSCfunction')]"
              },
              "configurationArguments": {
                "DomainName": "[parameters('domainName')]",
                "Admincreds": {
                  "Username": "radcliffe",
                  "Password": "PrivateSettingsRef:AdminPasswordDC02"
                }
              }
            },
            "protectedSettings": {
              "Items": {
                "AdminPasswordDC02": "Pa$$w0rd"
              }
            }

This fails every time, saying that the domain cannot be found. It does a domain check when you’re adding a second domain controller to a domain, and for that it needs domain credentials. The first DC doesn’t need domain credentials, since the domain doesn’t exist yet.

So I guess I am not sure how to check for what is actually being passed into this DSC config and what credentials it is actually using to check for the domain, but maybe protected settings in the JSON file don’t work with the DSC extension.

5

(do please avoid cross-posting; it’s not helpful)

whether or not we are able to pass a secure password from an Azure Key Vault to a DSC extension. Do you happen to know if that's doable?

Do you mean Secure credentials in the Azure PowerShell Desired State Configuration (DSC) extension - PowerShell Team, or am I still misunderstanding the goal?

It seems like every time I try to use a DSC extension within an ARM template I run into credential issues – for instance, now I have a primary DC and a server that joins the domain, and another server coming up in the template, but trying to make that third server a backup DC seems to be having similar issues, but this time using the xADDomainController resource. I guess I am wondering if the issue may be that I am just giving it bad credentials somehow due to the password being stored in a keyvault.

I’m not sure I’m parsing all that - you might break that up into a numbered list or something ;). Also, I think you’re having a “problem,” not an “issue” {grin}. You’re also kind of early-days with ARM and the DSC extension; I wouldn’t expect it to all work smoothly, especially at the edges. Have you opened a support incident with Azure about this? Serious question - it’s possible you’re banging your head against an actual bug, and you’ll never find out any other way.

Moving on to your second post (and apologies for not being more responsive here; I plead “Thanksgiving” and “45th Birthday” as distractions).

So I guess I am not sure how to check for what is actually being passed into this DSC config and what credentials it is actually using to check for the domain,

And that’s exactly what we need to troubleshoot. So, the gist is that you’re sucking in PrivateSettingsRef:AdminPasswordDC02 but we don’t know if that actually is anything, or what it is. One option would be to make a simple Script resource that, in its Test, accesses the same variable and dumps it to - I dunno, a log, an event entry, a text file, something. So that you can go back afterwards and see what the variable contains. Or maybe use the Log resource to do something similar. I lean toward a Script resource only because you can write code. Like, write out the variable’s length, contents, whatever - just to get some visibility into what’s happening.

In in fact the variable is empty, then either (a) you’re doing it wrong or (b) Azure’s doing it wrong. All you can do then is validate your syntax against the sparse docs that exist, and then open an incident with them.

6

And I should also point out that Key Vault passes credentials not passwords; it’s a PSCredential object, not a password per se. You probably know that; just clarifying terminology.

7

Thanks Don, and happy birthday! I’ll go back to troubleshooting tomorrow and if I can’t get it working, and actually do see something via the script resource, I’ll look into filing a bug. It’s not even just the key vault though, I’m finding. Even referencing the password from a parameter that explicitly contains the password isn’t working for me, so I will start there. I was thinking I was doing something wrong because

https://github.com/Azure/azure-quickstart-templates/tree/master/active-directory-new-domain-ha-2-dc

does kind of what I need, in that it has a second domain controller and presumably is passing domain credentials to get the second one up.

For now, I do have everything working when I explicitly define username/pass in the actual template, but that’s obviously not ideal.

Thanks again!

8

Is it possible to use the File resource to just create a text file with Contents = $Domaincreds.username or something similar?

Otherwise, I am thinking something like:

Script ParametersFile 
        {
            GetScript = {
                @{ Result = (Get-Content 'C:\creds.txt') }
            }
            TestScript = {
                Test-Path 'C:\creds.txt'
            }
            SetScript = {
                $using:DomainName | Out-File 'C:\creds.txt'
                $using:Admincreds.UserName | Out-File 'C:\creds.txt' -Append
                $using:Admincreds.Password | Out-File 'C:\creds.txt' -Append
                $using:DomainCreds.UserName | Out-File 'C:\creds.txt' -Append
                $using:DomainCreds.Password | Out-File 'C:\creds.txt' -Append
            }
        }
9

OK, so I wound up using this in the DSC file that configures my second domain controller:

Script ParametersFile 
        {
            GetScript = {
                @{ Result = (Get-Content 'C:\creds.txt') }
            }
            TestScript = {
                Test-Path 'C:\creds.txt'
            }
            SetScript = {
                "Domain: $using:DomainName" | Out-File 'C:\creds.txt'
                "Admincreds.username: $($using:Admincreds.UserName)" | Out-File 'C:\creds.txt' -Append
                "Admincreds.password.length: $($using:Admincreds.Password.Length)" | Out-File 'C:\creds.txt' -Append
                "Domaincreds.username: $($using:DomainCreds.UserName)" | Out-File 'C:\creds.txt' -Append
                "Domaincreds.password.length: $($using:DomainCreds.Password.Length)" | Out-File 'C:\creds.txt' -Append
            }
        }

That worked to grab the username, and the length of the password. When I set my DSC resource without using protected settings, everything built out fine, and the file on C was what I expected.

"resources": [
        {
          "name": "CreateSecondDC",
          "type": "extensions",
          "location": "[resourceGroup().location]",
          "apiVersion": "2016-03-30",
          "dependsOn": [
            "[resourceId('Microsoft.Compute/virtualMachines', parameters('GTM-DC02Name'))]",
            "[concat('Microsoft.Compute/virtualMachines/', parameters('GTM-Server01Name'),'/extensions/Server1JoinDomain')]"
          ],
          "tags": {
            "displayName": "DC02DSC"
          },
          "properties": {
            "publisher": "Microsoft.Powershell",
            "type": "DSC",
            "typeHandlerVersion": "2.20",
            "autoUpgradeMinorVersion": true,
            "settings": {
              "wmfVersion": "latest",
              "configuration": {
                "url": "[variables('DSCURL')]",
                "script": "[variables('DC02DSCscript')]",
                "function": "[variables('DC02DSCfunction')]"
              },
              "configurationdata": {
                "url": "[concat(parameters('assetLocation'), variables('adPopulationData'))]"
              },
              "configurationArguments": {
                "DomainName": "[parameters('domainName')]",
                "adminCreds": {
                  "userName": "[parameters('GTM-DC01AdminUserName')]",
                  "password": "[parameters('GTM-DC01AdminPassword')]"
                }
              }
            },
            "protectedSettings": {
            }
          }
        }
]

With that, I see this in the file I am creating with the script resource:
Domain: gametimeor.priv
Admincreds.username: radcliffe
Admincreds.password.length: 16
Domaincreds.username: gametimeor.priv\radcliffe
Domaincreds.password.length: 16

When I set the DSC resource to use protected settings -

[
        {
          "name": "CreateSecondDC",
          "type": "extensions",
          "location": "[resourceGroup().location]",
          "apiVersion": "2016-03-30",
          "dependsOn": [
            "[resourceId('Microsoft.Compute/virtualMachines', parameters('GTM-DC02Name'))]",
            "[concat('Microsoft.Compute/virtualMachines/', parameters('GTM-Server01Name'),'/extensions/Server1JoinDomain')]"
          ],
          "tags": {
            "displayName": "DC02DSC"
          },
          "properties": {
            "publisher": "Microsoft.Powershell",
            "type": "DSC",
            "typeHandlerVersion": "2.20",
            "autoUpgradeMinorVersion": true,
            "settings": {
              "wmfVersion": "latest",
              "configuration": {
                "url": "[variables('DSCURL')]",
                "script": "[variables('DC02DSCscript')]",
                "function": "[variables('DC02DSCfunction')]"
              },
              "configurationdata": {
                "url": "[concat(parameters('assetLocation'), variables('adPopulationData'))]"
              },
              "configurationArguments": {
                "DomainName": "[parameters('domainName')]",
                "adminCreds": {
                  "userName": "[parameters('GTM-DC01AdminUserName')]",
                  "password": "PrivateSettingsRef:AdminPassword"
                }
              }
            },
            "protectedSettings": {
              "Items": {
                "AdminPassword": "[parameters('GTM-DC01AdminPassword')"
              }
            }
          }
        }
      ]

I get the following in the text file output:
Domain: gametimeor.priv
Admincreds.username: radcliffe
Admincreds.password.length: 32
Domaincreds.username: gametimeor.priv\radcliffe
Domaincreds.password.length: 32

It seems odd that the password length doubles. Does that mean anything to you, or do you think I should file a bug report?

Also, [parameters(‘GTM-DC01AdminPassword’) actually does reference a value in a keyvault, so that seems to be working, just the PrivateSettingsRef piece isn’t.

10

Regrettably, you’ve moved beyond my ability to help with ARM. Honestly, if it were me, I think I’d open a support ticket with them. This isn’t so much a PowerShell thing as an Azure thing, and I just haven’t used ARM to this depth, yet.

(I don’t think the password length is a problem; it’s being stored as a secure string, not a clear string, so I’d expect the length to seem off).

11

I submitted some feedback using the feedback link in the portal; do you know if that would get to the right people? If I try to file a support request I need a support plan, which I do not have. Thanks for looking through all of this with me! If nothing else it really helps as a sanity check since I am just learning this.

12

If you want an answer, you’ll have to probably pay for it. If it ends up being a bug, they typically refund you. The Feedback link isn’t like to get your squat, unfortunately.

13

Bummer, that’s probably the end of the line for me in terms of this issue then - I am using a Visual Studio account and this has been basically for learning. I’ll keep playing around with it and if I find a solution I will update here.