There is a section in “The DSC Book” with this title that discusses this.
If you were to use “Basic Authentication”, what form does the “Credential” LCM Meta configuration setting look like, and what prevents users from seeing it if they were to run “Get-DscLocalConfigurationManager”?
Is there a way to instead use “Windows Authentication” so you don’t need to pass a username and password in clear text, assuming you are using HTTP and not HTTPS? Could you instead configure the DSC NT Task Scheduler job to run as some sort of domain service account instead of “System”?
If the goal is to restrict who can request configuration, regardless of how the caller authenticates (Basic or Windows), how do you then “Authorize” only certain user? Would you simply use some form of IIS Url authorization based on AD group membership?
You need to first evaluate whether you really want to use HTTP. You don’t. That’s walking into a massive security exploit one day. You’re MEANT to use HTTPS.
The LCM keeps it as a secure string, so users won’t see a password. But keep in mind that DSC is largely designed to avoid dependencies on Active Directory, which is what Windows authentication (Kerberos/NTLM) would require.
In terms of wrangling IIS to avoid an unauthorized computer from requesting a configuration… I suppose you could do whatever authentication rules you wanted, but I think I’d need a deeper discussion of why that’s a goal to give a good answer.
I completely understand your point regarding using HTTPS and not HTTP.
Regarding your comment about IIS configuration to avoid an unauthorized computer… My thinking is that solely restricting access to configuration information to authenticated users (and not to anonymous users) isn’t secure enough. You’d want to further restrict access to specific authenticated users. This is where Authorization comes in, once a user has been authenticated.
I don’t think DSC was specifically designed with all that in mind. On a pull server, at least, a target node will only pull the GUID you’ve given it. I don’t think MS regards DSC as “content,” per se. I’m not saying that what you want is wrong, just that it wasn’t part of the design for this release of DSC. So, getting what you want is going to be hacky.
I’m not sure I, personally, would worry about authorization on this in most of the environments I’ve worked in. We haven’t identified any risks from a computer for some reason trying to pull a config other than its own. I’m not saying there is zero risk, but it’d entail having a well-informed imposter on the network, and if you have that, I’m not sure DSC is going to be the thing they go after.
But, in any event, this’d be a “figure it out on your own” kind of thing. Might be easier to go with an SMB pull server, where NTFS permissions are a little more straightforward. If you know all your computers are going to be domain-joined, that’d be easy enough to set up, although a bitch to manage ongoing, if you’re permissioning .MOF files per-machine.
Ok,so if I use basic auth I have to provide a username and password which will get encrypted in the meta.mof file used by the LCM when authenticating with the Pull server. So if I need to update the LCM configuration on a bunch of servers with the credential to use, I think it would be easier if all LCM client servers used the same cert so when updating their configuration I can use the same public key and thumbprint for all. Do you agree?