Group: Allow compounding of 'MembersToInclude' about psdscresources

[johlju]

The Group schema have the GroupName as the unique Key. Only one instance of the same resource and "set of unique keys" is allowed, that is why you get the error when trying to add the resource twice using the same local "Administrators" group.

I think newer DSC modules have a 'Name' attribute, so it allows multiple Group declarations on the same Group.

Not sure what you mean by this. Do you mean resource that uses Name as the key, for example specify the username as the unique key?

You built a Script resource to solve this, but another option would be to add a resource with all three accounts when the target node name is one of these specific computers. But maybe that is not possible in your scenario?

[ewhitesides]

Johlju - I'm referring to DSC modules such as SecurityPolicyDSC https://github.com/PowerShell/SecurityPolicyDsc/blob/dev/Examples/SecurityOption_Example.ps1

You can compound the SecurityOption by specifying a different Name parameter.

The issue with the current Group resource and targeting by nodename, is that you also have to define an accompanying 'node -ne x' resource for the other servers.

This is fine for one unique server, but the logic starts getting a little out of control when you have for example, 5 servers that need unique accounts of different types.

To simplify the logic I found that I eventually had to start defining the local Administrators group for each server, which adds a lot of extra lines to the DSC configuration, even though 75% of the servers had the same accounts.

So if there is a Name parameter, you could have a setting for All computers that defines 'Domain Admins' in MembersToInclude, and on specific computers, you could define additional accounts in MembersToInclude without conflict.

[aydeisen]

Is there a way that Non-Node Data could be used combined with a different way of grouping the server exceptions? If so, something like this might work:

$ConfigData = @{
    NonNodeData = @{
        AllAccessUsers = 'CONTOSO\Domain Admins', 'Administrator'
    }
    AllNodes    = @(
        @{
            NodeName = 'ServerC'
            Role     = 'Web'
        }
        @{
            NodeName = 'ServerB'
            Role     = 'FileServer'
        }
        @{
            NodeName = 'ServerA'
            Role     = 'FileServer'
        }
    )
}

Configuration GroupMembershipExample {
    Node $AllNodes.Where( {$PSItem.Role -contains 'Web'} )
    {
        Group 'AdministratorsGroupMembers'
        {
            GroupName        = 'Administrators'
            Ensure           = 'Present'
            MembersToInclude = ($NonNodeData.AllAccessUsers + 'CONTOSO\AddlMbr01')
        }
    }
    Node $AllNodes.Where( {$PSItem.Role -contains 'FileServer'} )
    {
        Group 'AdministratorsGroupMembers'
        {
            GroupName        = 'Administrators'
            Ensure           = 'Present'
            MembersToInclude = ($NonNodeData.AllAccessUsers)
        }
    }
}

[ewhitesides]

that could work but in my environment i have to add various developer users to different servers. there are only about 20 servers, so it seems a little excessive to create a lot of 1:1 server:group relationships.

so my by making a Script resource for this issue, my config code looks a lot more simple/streamlined.

i think DSC is a wonderful tool, but if you're not careful it can start looking excessively long and complicated. I spend a lot of time trying to make my code easy to read in case someone besides me has to look at it later.

[johlju]

@ewhitesides

So if there is a Name parameter, you could have a setting for All computers that defines 'Domain Admins' in MembersToInclude, and on specific computers, you could define additional accounts in MembersToInclude without conflict.

The equivalent to Name is GroupName. You specify 'Domain Admins' in GroupName so that you can make sure that the group Domain Admins are always in desired state, that it will only contain account X and Y.

If we would add Name in addition to GroupName then you will get a ping-pong behavior in certain scenarios. This configuration would never become in desired state.

Group 'All computers'
{
    Name             = 'All computers'
    GroupName        = 'Administrators'
    Ensure           = 'Present'
    Members          = @('Administrator', 'User1')
}

Group 'Only computer Y'
{
    Name             = 'Only computer Y'
    GroupName        = 'Administrators'
    Ensure           = 'Present'
    Members          = @('Administrator', 'User2')
}

[aydeisen]

@johlju: I hope I'm assuming @ewhitesides scenario correctly, but is there a way to do something like this:

Group 'All computers'
{
    Name             = 'All computers'
    GroupName        = 'Administrators'
    Ensure           = 'Present'
    Members          = @('Administrator', 'User1')
}

Group 'Only computer Y'
{
    Name                      = 'Only computer Y'
    GroupName                 = 'Administrators'
    Ensure                    = 'Present'
    MembersToInclude          = @('User2')
    DependsOn                 = '[Group]Only computer Y'
}

The biggest problem I can see is that every time Group 'All computers' runs, it would erase the members defined in Group 'Only computer Y' until it reruns it again. The only other thing I can think of would be a way for DSC to process all Group resources for the same Group Name before creating the MOF file, but I feel that would just go back to separating configuration and envirionment data in DSC

$ConfigData = @{
    NonNodeData = @{
        AllAccessUsers = 'CONTOSO\Domain Admins', 'Administrator'
    }
    AllNodes    = @(
        @{
            NodeName = '*'
            Admins   = @('CONTOSO\Domain Admins')
        }
        @{
            NodeName = 'ServerC'
            Role     = 'Web'
            Admins   = @('CONTOSO\Domain Admins', 'CONTOSO\AddlMbr01')
        }
        @{
            NodeName = 'ServerB'
            Role     = 'FileServer'
        }
        @{
            NodeName = 'ServerA'
            Role     = 'FileServer'
        }
    )
}

Configuration GroupMembershipExample {
    Node $AllNodes.NodeName
    {
        Group 'AdministratorsGroupMembers'
        {
            GroupName        = 'Administrators'
            Ensure           = 'Present'
            MembersToInclude = $Node.Admins
        }
    }
}

If there's another way of doing it, I'm not sure what it would be.

[ewhitesides]

I think what's great about powershell (most of the time) is that the syntax resembles how a human thinks.

without getting super-technical when I think of 'membersToInclude' I think the following regardless if you have one or multiple scriptblocks applied to the same computer:

'check if user A is in this group X. if not there, add them'

so ideally, it would be nice to have it work like this:

Node $AllNodes.Nodename {
Group 'LocalAdmins' {
GroupName = 'Administrators'
Ensure = 'Present'
MembersToInclude = @('Administrator', 'User1')
}
}

Node $AllNodes.Where{$_.NodeName -eq 'WebSrv1'}.NodeName {
Group 'AdditionalAdmins' {
GroupName = 'Administrators'
Ensure = 'Present'
MembersToInclude = @('User2')
}
}

i realize that there may be a bunch of 'under the hood' changes to make this happen. I think MembersToInclude should probably function differently than the 'Members' property in perhaps a more simplistic way.

[aydeisen]

@ewhitesides I believe Members and MembersToInclude are supposed to be similar in name and function to their Restricted Groups counterparts in Group Policy, where 'Members' ensures that only the listed members are part of the group, and 'Member Of' (MembersToInclude) ensure that the listed members are included, but does not remove other accounts listed as members.

It would very likely be possible to do this with Group Policy's Restricted Groups feature, using 'Members Of' in a parent and child OU. The only way I can think of doing something similar using DSC is by using Partial Configurations with a parameterized nested configuration or composite resource

I defer to @johlju as to whether it would be possible to change the Group Resource without changing the core functionality of DSC. There may be other options that I'm not considering.

[johlju]

The limitation is that there can only be one Group resource with the same Key's in the final compiled configuration. If there are two resources with the same Key the compilation fails.
Another limitation is that an array can't be used as Key.

Snippet of the schema. GroupName is the only type qulifier Key.

[ClassVersion("1.0.0"),FriendlyName("Group")]
class MSFT_GroupResource : OMI_BaseResource
{
  [Key, Description("The name of the group to create, modify, or remove.")] String GroupName;
  ...
  [Write, Description("The members the group should have.")] String Members[];
  [Write, Description("The members the group should include.")] String MembersToInclude[];
  [Write, Description("The members the group should exclude.")] String MembersToExclude[];
  ...
};

@ewhitesides Your suggestion will not work unless LCM is fundamentally changed.

@aydeisen your first scenario would technically work if adding another Key (property Name). But that will result in a user can make a mistake and get a ping-pong behavior (see my example), especially if using partial configurations. The second scenario will work, as longs as $Node.Admins will contain an array with all the names, those names will be compiled into the final configuration using only one Group resource.

Most of the time we would like LCM (DSC) to behave like a program flow, but for it to make sure a specific configuration is in desired state (and not getting a ping-pong behavior) there are some rules (limitations) to follow. 🙂

That said, there is nothing that say that this can't change in the future. Please submit any proposal as a uservoice and the community can vote on them.

I don't think adding a property Name as Key is the right way to go.

[aydeisen]

@johlju: thanks for the clarification. The latter makes sense to me since, based on the document discussing separating configuration data from environment data, having the full list under inside a Node hashtable allows for it to be used a documentation for the group.

I know that Microsoft has mentioned overhauling the LCM so it can be used with PowerShell 6 and .NET Core, with the advantage of the LCM being platform agnostic. Is the new LCM also a GitHub project that can be commented on, or is uservoice the only way to do it?

For better or worse, my observation is that uservoice is completely dependent on the community seeing and upvoting suggestions, and stuff tends to gets lost in uservoice. (Unrelated but, as an example: I have a request in uservoice for WSUS to allow Azure AD Authentication to SUSDB so the damn thing can be offloaded to an Azure Cloud Database offering. No comments, no responses, no upvotes. Even more disappointing, it's the top result in Bing and Google if you look for 'WSUS' and 'Azure Active Directory Authentication')

[johlju]

@aydeisen I know PowerShell Team is using their user voice. For the other, when last Wednesdays community call recording is online, listen to it as it is some news there; https://www.youtube.com/channel/UCMhQH-yJlr4_XHkwNunfMog. I can take a while until the recording is up there.

[johlju]

I'm closing this issue at this time as 'not fixed'. Please comment and reopen if there is still unanswered questions.

[aydeisen]

@johlju: Thanks. I attended the call. Sounds like the DSC Resource team has some interesting things in the works Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

…

________________________________ From: Johan Ljunggren <[email protected]> Sent: Tuesday, May 1, 2018 11:59:02 AM To: PowerShell/PSDscResources Cc: aydeisen; Mention Subject: Re: [PowerShell/PSDscResources] Group: Allow compounding of 'MembersToInclude' (#98) @aydeisen<https://github.com/aydeisen> I know PowerShell Team is using their user voice. For the other, when last Wednesdays community call recording is online, listen to it as it is some news there; https://www.youtube.com/channel/UCMhQH-yJlr4_XHkwNunfMog. I can take a while until the recording is up there. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#98 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ANZGFTWhd8HplINJHGp58U818qbhL4SJks5tuIZGgaJpZM4SoyyB>.