Partial configurations and credentials?

This topic contains 8 replies, has 3 voices, and was last updated by  Don Jones 10 months, 3 weeks ago.

  • Author
  • #56629

    Joey Piccola

    I was thinking of using DSC to manage DFS. I already have per node configurations setup on a pull server. These configurations were generated with configData so that I have a MOF per DFS server. In that configData is the PKI info for encrypting credentials per node (although really it's the same AD DFS admin creds). I was thinking of using partial configurations to simply the DFS DSC management (one mof etc etc), but since I need credentials I'd have to distribute a cert to all my DFS servers. That seems clunky. Thoughts?

    On another note, I also find it a little weird with my code below to have configData that only works / makes sense with a single node named localhost.

    $configName = 'DFSConfig'
    $configPath = "c:\dsc\configs\$configName"
    $certPath =  "c:\dsc\certs\$configName.cer"
    # make a dir for our config path
    if (!(Test-Path -Path $path)) { New-Item -ItemType Directory -Path $path }
    Configuration $configName
            [pscredential] $Credential
        Import-DscResource –ModuleName 'PSDesiredStateConfiguration'
        Node $allnodes.nodename
            file MakeMeSomeDFS
                Destinationpath      = 'c:\DFS.txt'
                Ensure               = 'Present'
                Type                 = 'File'
                Contents             = 'wow'
                PsDscRunAsCredential = $Credential
    $ConfigData = @{
        AllNodes = @(
                Nodename        = 'localhost'
                CertificateFile = $certPath
                Thumbprint      = (Get-PfxCertificate -FilePath $certPath).Thumbprint
    # credential used for the configuration
    $cred = Get-Credential -UserName 'ad\AccountWithRightsToManageDFS' -Message 'pw plz'
    # run the configuration with our configData and credential
    & $configname -OutputPath $path -ConfigurationData $ConfigData -credential $cred
    # change the name of our mof from localhost to our configuratoin name
    Move-Item "$path\`localhost.mof" "$path\$configName.mof" -Force
  • #56630

    Don Jones

    Distributing certs to all of your nodes would be a requirement – but if it's clunky, then you should step back and look at your total PKI picture. It _shouldn't_ be clunky; the ability to distribute certificates should be a core competency, at this stage in the game. So I'd look at ways to make that non-clunky. Having this as a core competency – like patch management or user management – will benefit your infrastructure in a lot of ways.

    • #56633

      Joey Piccola

      Don, Thanks for the speedy reply. PKI is definitely a core competency of mine (specifically windows certificate services). I guess what I was asking was is it legit to have all my DFS servers use the same cert? I guess it really doesn't matter. Perhaps I'm stuck thinking with a basic "secure the MOF" mentality of each node has their own cert etc etc. Thanks!

      edit: typos

  • #56639


    I struggle with this too.
    I originally set up my nodes to each have a unique cert via a cert auto-enrollment GPO, which I would each export to the config authoring node and then list in my config data.
    But I found that this was a little too clunky just like you said, mainly because this method requires keeping track of all the node names and thumbprints in your ConfigData.

    For now I've settled on pretty much exactly what you're doing here with the single DSC cert.
    I like this method better because it doesn't require your node to be within the scope of your PKI.
    This also saves you from having one huge directory with all the required certs, which to be honest is a nightmare.

    Finally, I also think (just my opinion) that this method better exemplifies the DSC "cattle vs pets" mantra, as you don't need to worry about the specific nodename and thumbprint in your ConfigData...But I'd really like to hear more thoughts on all of this

    • #56642

      Joey Piccola

      single DSC cert

      Can you expand on that? Do you use: (this question doesn't matter, just curious)...

      1) a single cert on the target node with its public key on the authoring node
      2) a single cert on the authoring node with its key pair on the target node

      No doubt you've read this, but more on that here: Certificate creation.

      In either case, are you doing this across all your nodes in that all your nodes could potentially decrypt the credentials from MOFs that might not necessarily be applicable to them?

  • #56696

    Don Jones

    So, let me offer an observation.

    Encryption works by one machine – in this case, the authoring node – using a public key, from a certificate, to encrypt data. The corresponding private key, on the node, is then the only thing which can decrypt that data. By using a single certificate, you're essentially making the private key broadly available, and much more easily compromised. A _single node_ running a piece of malware could be used to decrypt ALL DSC credentials in your environment. This is, to put it mildly, a Bad Idea. This is a cyber punch in the face waiting to happen; you might as well just call it quits and use clear-text credentials in your MOFs. This is literally like having a single Domain Admin account, with a bunch of people who know its password.

    I realize that deploying certificates, tracking their thumbprints, and using them in configuration data blocks on a per-node basis is hard. Security is almost always hard. That's what I mean when I say, "you need to make this kind of certificate management a core competency." You can't – pardon the language, here – half-ass this. If you're going to, at least know in your soul that you're _not_ creating a secure, safe environment. Tell your boss that you're not. Make sure everyone in the company has bought off on a poor, single-certificate-based approach – don't let this be a secret that only you know, because it's going to bit you in the butt one day.

    And my concerns here aren't theoretical – I've seen it happen. There's malware out there specifically designed to do exactly this – grab a certificate, knowing it's used far too broadly. Once your certificate is compromised, your entire environment becomes easy pickings.

    • #56720

      Joey Piccola

      Don, while I'll always have an opinion, I don't think I'd ever challenge your observation let alone your advice. Both are always welcome :). // steps back slowly and bows down //

      Since it is my intent to use partial configs shared amongst servers of similar roles (as to me that's a benefit of partials) I don't see an option that would allow me to use a single certificate. This is not to say that I am going to use the same cert that I would use for DFS credentials also with something else. Again, not arguing here... But now I'm curious if my use of partials is correct or if when partials are used with credentials I'd be better off using a MOF/configuration per node. I totally understand the security risk, one server get's popped turns into a set of credentials that work on a group of severs (in addition to some nasty rights in AD 'Dfs-Configuration').

      This is a great discussion, interested in your additional thoughts.


  • #56723

    Don Jones

    Well, the idea is, if you're using certificates to encrypt credentials, you want a unique MOF per node. If you're using partials, then each node gets a unique set of partials just for itself. I get why you'd want to avoid that, because *messy*, but that's the intent, more or less.

    However, I'm opposed to partials for a number of reasons ("The DSC Book" dives into why), and this'd be one of them. I'd rather modularize my config scripts and produce one MOF per node, period.

    However, some of what you're running into is the whole "dumb pull server" problem, which is why is trying to be a thing. With that, you could very conceivably generate MOFs on the fly. E.g., node asks for MOF, you look up the thumbprint that the node was assigned (in a database), you dynamically generate the MOF using that certificate's public key. So you don't have MOFs lying around – you're making them intelligently as you go. I just need some time (and help) getting Tug finished for that kind of thing to be straightforward.

    And following that same thought, the pull server could then easily combine multiple "partial configurations" on-demand – essentially giving you the upside of partials, but ultimately producing one MOF server-side and delivering that to the node. The world is your oyster, etc.

  • #56725

    Don Jones

    And BTW, this whole thing is another reason I think partials, as a feature, weren't well thought-out :(. There wasn't a lot of architecture-level thinking about how this'd be used in conjunction with stuff like certificates. I get the upside of modularizing complex configs, but delivering multiple MOFs to the nodes winds up not working out in all but the simplest scenarios.

You must be logged in to reply to this topic.