You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Previous to 4.4.0, one could create and apply user rights assignment rules to non-domain joined systems (see issue #362) . Several rules depended on users that would only exist for domain joined systems (see rules V-63871, V-63877, V-63879, V-63873 and V-63875). For these rules it was previously easy to overcome the problem by creating an exception that omitted the domain and forest users. With PR #643, all user rights assignment rules are skipped if the Domain or Forest names are not specified (both must be supplied contrary to the comment in the code) this despite that only 5 out of the 26 user rights assignment rules could not be fully applied for Win10Client (I have not done the analysis for the server rulesets).
Describe the solution you'd like
The windows.UserRightsAssignment resource should be more granular in excluding rules based on whether the value contains a username that requires a domain or forest name. Ideally the rules that included domain and forest level users would still be applied with those users omitted and a warning generated.
Describe alternatives you've considered
The workaround is to continue to use exceptions and a bogus DomainName and ForestName.
Additional context
Our company creates kiosks that are often deployed to DoD sites that are either not part of the domain or are completely disconnected from the network. Despite being disconnected, the Authorization To Operate still requires applying all of the user rights assignment rules including those that are directly related to network access. These machines are provisioned and configured in the factory prior to shipment and necessarily prior to joining a domain. It is our view that the current implementation of the Windows10Client rule in regards to user rights assignment makes this more complicated than it needs to be.
The text was updated successfully, but these errors were encountered:
Good Catch, thanks for the issue. I have updated the composite to handle lack of Domain/Forest and still compile the rules that call for guests and other non-domain/forest identities. Let me know what you think.
I believe #719 will prevent the issue. One change that I might suggest is that the test for $DomainName be done separately from $domainTranslation.Contains, and similarly for the ForestName, so that you can generate a warning. I found the old warning useful for discovering the problem in my configuration.
Is your feature request related to a problem? Please describe.
Previous to 4.4.0, one could create and apply user rights assignment rules to non-domain joined systems (see issue #362) . Several rules depended on users that would only exist for domain joined systems (see rules V-63871, V-63877, V-63879, V-63873 and V-63875). For these rules it was previously easy to overcome the problem by creating an exception that omitted the domain and forest users. With PR #643, all user rights assignment rules are skipped if the Domain or Forest names are not specified (both must be supplied contrary to the comment in the code) this despite that only 5 out of the 26 user rights assignment rules could not be fully applied for Win10Client (I have not done the analysis for the server rulesets).
Describe the solution you'd like
The windows.UserRightsAssignment resource should be more granular in excluding rules based on whether the value contains a username that requires a domain or forest name. Ideally the rules that included domain and forest level users would still be applied with those users omitted and a warning generated.
Describe alternatives you've considered
The workaround is to continue to use exceptions and a bogus DomainName and ForestName.
Additional context
Our company creates kiosks that are often deployed to DoD sites that are either not part of the domain or are completely disconnected from the network. Despite being disconnected, the Authorization To Operate still requires applying all of the user rights assignment rules including those that are directly related to network access. These machines are provisioned and configured in the factory prior to shipment and necessarily prior to joining a domain. It is our view that the current implementation of the Windows10Client rule in regards to user rights assignment makes this more complicated than it needs to be.
The text was updated successfully, but these errors were encountered: