DSC Certificate for encrypting credentials

This topic contains 5 replies, has 3 voices, and was last updated by Profile photo of Bjørn Roalkvam Bjørn Roalkvam 2 weeks, 6 days ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
  • #54683
    Profile photo of Bjørn Roalkvam
    Bjørn Roalkvam

    Using Server 2012R2 with WMF 5.
    I am about to set up a bunch of nodes (SharePoint instal and configure) using a DSC configurations stored on a pull server.

    In test i have been using a wildcard certificate with *.contoso.com and copied and imported the *.contoso.com.pfx to all nodes.
    In my configuration I have specified the *.contoso.com.cer file when compiling configuration to Mofs.

    Any advice on how to handle the certificate(s) for Encrytion/decryption for multiple nodes in production environments? Using a wildcard will not be happening in production :-).

    When you compile a configuration you only specify 1 certificate. Does the certificate require a specific dns name to work on a node?

    Profile photo of Justin King
    Justin King

    The bigger question to me is: are you allowed to use a single certificate and is it only wildcards that are restricted? That can have a big impact on your solution. Keep in mind that when it comes to encrypting passwords the certificate isn't used for identity so the name doesn't actually matter. Instead just make sure you're set to use the appropriate certificate in the node configuration.

    If the problem is more about not using a common exportable certificate (not just that it's a wildcard), you got a slightly more complex issue, as WMF5 configurations don't use node names for anything anymore (something I bemoaned a bit on this forum in the past and still a year later feel is a mistake). You will basically be forced to "emulate" the older WMF4 behavior by giving each node a completely unique configuration to pull to ensure the encrypted passwords lineup with the certificate on said node, or come up with a modification of company policy to allow some kind of certificate overlap.

    I actually wrote about a year ago a series of functions.modules to handle the entire process in WMF4 ... but WMF5 broke it in ugly ways and due to that as well as some class issues I never got around to re-envisioning things for WMF5.

    Still ... if you want to dig through it and see if it helps come up with a plan be my guest:
    Github to module
    old blgo where I walk through the process

    The short of it is I maintained a csv file that relates the node to the certificate so when I create a mof it can look up which cert to use. I then created a simple custom module that's sole purpose was to copy the "best cert choice" to a shared path so the compile could reference it as needed.

    Again ... never finished making a WMF5 version of this flow ... but maybe you'll find the structure useful?

    Profile photo of Bjørn Roalkvam
    Bjørn Roalkvam

    Hi Justin,

    Thank you for the reply.

    We have 3 different network-zones. Each zone will have a SharePoint farm (4-5 SharePoint servers + 1 SQL Server).
    So 1 Certificate per Network zone (SharePoint servers and SQL) would work.

    Keep in mind that when it comes to encrypting passwords the certificate isn't used for identity so the name doesn't actually matter. Instead just make sure you're set to use the appropriate certificate in the node configuration.


    Another unrelated question. Could we use the SQL server as a Web Pull server, giving it two roles (SharePoint SQL + Pull Server)? Can the SQL server pull a configuration from itself:P ?



    Profile photo of Justin King
    Justin King

    So first something I forgot to mention: As you're using WMF5, your generic wildcard cert may not work anyway, as typically web certs don't contain the right purpose/key usage. Make sure the cert is set for 'KeyEncipherment' and 'DataEncipherment'.

    Technically yes: you could put multiple roles on a server as long as the ports don't conflict and DSC is no exception. The web server is really simple, and as you probably already read you could even use an SMB share if you wanted to make it even more so. I personally wouldn't do that, however, as IMO one of the main goals of DSC is making sure all your nodes are setup consistently/reliably and said SharePoint server would then end up being a special snowflake compared to the rest in the farm. The whole "cattle not pets" philosophy.

    Profile photo of JrdnRgrs

    Justin, I did some extensive digging into your blog and repos when I was learning DSC so thanks for all that info, would love an update for WMF 5 and even WMF 5.1 .

    Bjørn, I've experimented with 2 different methods. One method is having a unique cert on each node (generated by a GPO auto-enrollment policy). Another method is having one single DSC cert, which is then distributed to any node needing to use encryption.

    For the most part, I've decided on the latter, because the former (unique certs) requires you to import and keep track of every thumbprint for every node. This is not ideal if you plan on having hundreds of nodes, or even machines that you plan on killing and rebuilding often.

    I currently handle encryption certs in one of 2 ways, depending on the circumstance.

    If the node already exists, I can invoke the 'Import-PfxCertificate' cmdlet on a node or list of nodes, passing the .pfx password in as a SecureString:

    $pwd = Read-Host -AsSecureString -Prompt "Enter cert password to import"
    $nodes = "NODE1","NODE2","NODE3"
    Invoke-Command -ComputerName $nodes -ScriptBlock {Import-PfxCertificate -FilePath "PATHTOPFX.pfx" -CertStoreLocation "Cert:\LocalMachine\My" -Password $pwd}

    But if I am creating a new virtual machine, or a VM template, and I want it to automatically have the cert for encryption without having to touch it outside of creating it, I have set up an unattend.xml answer file. This answer file has 2 RunSynchronous commands which will each run a file (preloaded in a tmp directory) at the time of VM creation. The first RunSynchronous command calls a file called importcert.cmd which contains one line:

    certutil -f -p "PFXPASSWORD" -importpfx "LOCAL\TMP\PATH\TO\PFX"

    The second RunSynchronous command calls a file called metaInject.cmd which deletes both the importcert.cmd and the .pfx file, and then copies a .meta.mof file (also preloaded in the same tmp directory) to C:\Windows\System32\Configuration\MetaConfig.mof, which sets the LCM to pull a config from my pull server. The answer file will restart the node after the second command runs, ensuring the LCM gets enacted and the configuration is pulled. The configuration also includes the File resource to delete the tmp folder it sort of cleans itself up.

    There may be a better way to do this, but this is the method I've come up with as I've been learning DSC...

    Profile photo of Bjørn Roalkvam
    Bjørn Roalkvam

    Hi Justin,

    Thank you for the information!

    For reference in WMF 5, in test my certificate was created like this:

    New-SelfSignedCertificate -Type DocumentEncryptionCertLegacyCsp -DnsName 'MyDscCertificate','*.contoso.com'-HashAlgorithm SHA256

    This worked for encrypting/Decrypting usercredentials.

    Note, I had to run these cmdlets in Windows 10 or Server 2016.

    'KeyEncipherment' and 'DataEncipherment'

    I'll make sure these are in place when i order a certificate from the CA guy.

    Concerning SQL as a PullServer; Since we need a Pull Server in each of our three zones, we will give this a try (SQL server will also be a Pull Server)..

    @jrdnrgrs, I see the logic of using one certificate like you ended up doing. I will probably do the same here. Thank you for sharing your experiences and the two methods you have been using to deploy certificates. I have like you been running the invoke-command to deploy my test certificate for existing nodes. When I order nodes I get them with OS preinstalled, so your second method has not been relevant for me. But I see the advantage if we need to deploy new virtual machines without wanting to hassle with the certificate. Great!



Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.