-
Notifications
You must be signed in to change notification settings - Fork 141
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ADReadOnlyDomainControllerAccount: New resource #713
Conversation
Just doing an initial pull to see if this works before I update the tests - leave this with me for now :) |
For the build to run, update azure-pipelines.yml according to this: gaelcolas/Sampler#477 (comment) |
@johlju Love it when you pop out for lunch & the solution's waiting when you return! Ta! :) |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #713 +/- ##
====================================
Coverage 98% 98%
====================================
Files 25 26 +1
Lines 3475 3720 +245
====================================
+ Hits 3406 3651 +245
Misses 69 69
|
…ontroller if this computer is the target
@johlju This PR is ready for review whenever you are :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome work, just one comment to discuss.
Reviewed 4 of 7 files at r1, 1 of 2 files at r3, 8 of 9 files at r4, 1 of 1 files at r5, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @Borgquite)
source/Modules/ActiveDirectoryDsc.Common/ActiveDirectoryDsc.Common.psm1
line 1354 at r5 (raw file):
$domainControllerObject = Get-ADDomainController @getADDomainControllerParameters if (-not $domainControllerObject -and $env:COMPUTERNAME -eq $ComputerName -and (Test-IsDomainController) -eq $true)
Not sure about this change, this prevents the command to be called from another computer - feels like a breaking change. Why is it needed? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @johlju)
source/Modules/ActiveDirectoryDsc.Common/ActiveDirectoryDsc.Common.psm1
line 1354 at r5 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
Not sure about this change, this prevents the command to be called from another computer - feels like a breaking change. Why is it needed? 🤔
Sure.
TL;DR Get-DomainControllerObject is currently broken when $ComputerName is not $env:COMPUTERNAME, and this fixes it.
--
Get-DomainControllerObject is used by ADDomainController and now ADReadOnlyDomainControllerAccount to find the domain controller object for $ComputerName. Until this change, it's never been used for anything other than $env:COMPUTERNAME (local node) inside ADDomainController - but I'm reusing it in ADReadOnlyDomainControllerAccount.
However, at present, if $ComputerName is set to another name, to check if a computer other than the local computer has a domain controller account, it always fails. This line basically says 'if there is no domain controller account object named $ComputerName, and the local computer is a domain controller, throw an error' (Test-IsDomainController returns true if the local computer is a domain controller). This doesn't make any sense at all if $ComputerName is not the local computer - so Get-DomainControllerObject always fails if $env:COMPUTERNAME != $ComputerName. The fix here is to bypass running Test-IsDomainController unless we’re checking the local computer’s name - which allows the function to be used in ADReadOnlyDomainController as intended.
@johlju Let me know if I haven't explained the above very well! |
@johlju Ping - when you are able! |
I've updated Get-DomainControllerObject to make the intended fix clearer |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @Borgquite - great job! I've finished review and just a few minor things.
One thing I always ask: Is it possible to create integration tests for this resource as well? Even if they can't be executed in the Azure DevOps pipeline, being able to run them locally on a node in a test AD would be useful. I haven't kept up with this module, so it's possible that the module doesn't generally keep up this practice - so defer to the usual maintainers 😀
Reviewed 4 of 7 files at r1, 1 of 2 files at r3, 6 of 9 files at r4, 1 of 1 files at r5, 1 of 1 files at r6, all commit messages.
Reviewable status: all files reviewed, 21 unresolved discussions (waiting on @Borgquite and @johlju)
CHANGELOG.md
line 23 at r6 (raw file):
- Update build process to pin GitVersion to 5.* to resolve errors (https://github.com/gaelcolas/Sampler/issues/477).
Can you also mention the fix to Get-DomainControllerObject
?
source/DSCResources/MSFT_ADDomainController/MSFT_ADDomainController.schema.mof
line 20 at r6 (raw file):
[Write, Description("Specifies one or more Flexible Single Master Operation (FSMO) roles to move to this domain controller. The current owner must be online and responding for the move to be allowed."), ValueMap{"DomainNamingMaster", "SchemaMaster", "InfrastructureMaster", "PDCEmulator", "RIDMaster"}, Values{"DomainNamingMaster", "SchemaMaster", "InfrastructureMaster", "PDCEmulator", "RIDMaster"}] String FlexibleSingleMasterOperationRole[]; [Write, Description("Specifies if the DNS Server service should be installed and configured on the Domain Controller. If this is not set the default value of the parameter `InstallDns` of the cmdlet Install-ADDSDomainController is used. This parameter is only used during the provisioning of a domain controller. The parameter cannot be used to install or uninstall the DNS server on an already provisioned domain controller.")] Boolean InstallDns; [Write, Description("Indicates that the cmdlet attaches a server to an existing Read-Only Domain Controller (RODC) account. If specified, a member of the Domain Admins group or a delegated user can run this cmdlet.")] Boolean UseExistingAccount;
This seems to refer to a cmdlet. Presumably this should refer to "apply the DSC resource"?
Code quote:
If specified, a member of the Domain Admins group or a delegated user can run this cmdlet.
source/DSCResources/MSFT_ADDomainController/en-US/about_ADDomainController.help.txt
line 106 at r6 (raw file):
.PARAMETER UseExistingAccount Write - Boolean Indicates that the cmdlet attaches a server to an existing Read-Only Domain Controller (RODC) account. If specified, a member of the Domain Admins group or a delegated user can run this cmdlet.
See previous comment about: "This seems to refer to a cmdlet. Presumably this should refer to "apply the DSC resource"?"
source/DSCResources/MSFT_ADReadOnlyDomainControllerAccount/MSFT_ADReadOnlyDomainControllerAccount.psm1
line 99 at r6 (raw file):
# Retrieve any user or group that is a delegated administrator via the ManagedBy attribute $delegateAdministratorAccountName = $null $domainControllerComputerObject = $domainControllerObject.ComputerObjectDN | Get-ADComputer -Properties ManagedBy -Credential $Credential
nit: Long line - can this be split at the pipe (I know other resources in this module don't adhere to this - so only a nit)
source/DSCResources/MSFT_ADReadOnlyDomainControllerAccount/MSFT_ADReadOnlyDomainControllerAccount.psm1
line 102 at r6 (raw file):
if ($domainControllerComputerObject.ManagedBy) { $domainControllerManagedByObject = $domainControllerComputerObject.ManagedBy | Get-ADObject -Properties objectSid -Credential $Credential
nit: Long line - can this be split at the pipe (I know other resources in this module don't adhere to this - so only a nit)
source/DSCResources/MSFT_ADReadOnlyDomainControllerAccount/MSFT_ADReadOnlyDomainControllerAccount.psm1
line 107 at r6 (raw file):
} $allowedPasswordReplicationAccountName = (
nit: Are ( ) needed here?
source/DSCResources/MSFT_ADReadOnlyDomainControllerAccount/MSFT_ADReadOnlyDomainControllerAccount.psm1
line 110 at r6 (raw file):
Get-ADDomainControllerPasswordReplicationPolicy -Allowed -Identity $domainControllerObject | ForEach-Object -MemberName sAMAccountName) $deniedPasswordReplicationAccountName = (
nit: Are ( ) needed here?
source/DSCResources/MSFT_ADReadOnlyDomainControllerAccount/MSFT_ADReadOnlyDomainControllerAccount.psm1
line 122 at r6 (raw file):
DomainName = $domainControllerObject.Domain Ensure = $true InstallDns = $InstallDns
Is this value stored with the RODC account? If not, how does it get used when prestaging an RODC account?
I can see that Add-ADDSReadOnlyDomainControllerAccount
does support the -InstallDns
parameter, but I can't actually figure out how it would actually work - unless the flag was stored with the AD object.
The reason I'm asking is if the state is not stored and able to be retrieved, could we eliminate it entirely - as we're not installing an RODC (and the DNS service), we're just creating the RODC account object.
Sorry if this doesn't make sense (it's been a while since I've dealt with RODC's 😁)
source/DSCResources/MSFT_ADReadOnlyDomainControllerAccount/MSFT_ADReadOnlyDomainControllerAccount.psm1
line 151 at r6 (raw file):
<# .SYNOPSIS Installs, or change properties on, a read only domain controller account.
nit: Installs -> Creates?
source/DSCResources/MSFT_ADReadOnlyDomainControllerAccount/MSFT_ADReadOnlyDomainControllerAccount.psm1
line 288 at r6 (raw file):
} if ($PSBoundParameters.ContainsKey('InstallDns'))
See previous query regarding InstallDns parameter.
source/DSCResources/MSFT_ADReadOnlyDomainControllerAccount/MSFT_ADReadOnlyDomainControllerAccount.psm1
line 347 at r6 (raw file):
$delegateAdministratorAccountSecurityIdentifier = Resolve-SecurityIdentifier -SamAccountName $DelegatedAdministratorAccountName Set-ADComputer -Identity $domainControllerObject.ComputerObjectDN -ManagedBy $delegateAdministratorAccountSecurityIdentifier -Credential $Credential
nit: long line - can split or use splat?
source/DSCResources/MSFT_ADReadOnlyDomainControllerAccount/MSFT_ADReadOnlyDomainControllerAccount.psm1
line 398 at r6 (raw file):
} if ($PSBoundParameters.ContainsKey('DenyPasswordReplicationAccountName'))
This block seems to have a lot of similar code to the previous block. Any chance we could split it out into a function and reduce the duplication?
source/DSCResources/MSFT_ADReadOnlyDomainControllerAccount/MSFT_ADReadOnlyDomainControllerAccount.psm1
line 477 at r6 (raw file):
Provides a list of the users, computers, and groups to add to the password replication denied list. .PARAMETER InstallDns
See previous query regarding InstallDns
source/DSCResources/MSFT_ADReadOnlyDomainControllerAccount/MSFT_ADReadOnlyDomainControllerAccount.psm1
line 609 at r6 (raw file):
} if ($PSBoundParameters.ContainsKey('DenyPasswordReplicationAccountName') -and
nit: some code duplication in this block, but probably not enough to warrant splitting into a function. Will leave decision to you.
source/DSCResources/MSFT_ADReadOnlyDomainControllerAccount/README.md
line 8 at r6 (raw file):
DelegatedAdministratorAccountName rather than requiring Domain Admins permissions. >The resource does not support removing pre-created Read Only Domain Controller accounts.
nit: Add space after >
source/DSCResources/MSFT_ADReadOnlyDomainControllerAccount/en-US/MSFT_ADReadOnlyDomainControllerAccount.strings.psd1
line 3 at r6 (raw file):
ConvertFrom-StringData @' ResolveDomainName = Resolving the domain name '{0}'. (ADRODCA0001) DomainPresent = The domain '{0}' is present. Looking for read only domain controller accounts. (ADRODCA0002)
nit: domain controller account.
E.g., it only looks for one right? 😀
source/Modules/ActiveDirectoryDsc.Common/ActiveDirectoryDsc.Common.psm1
line 1354 at r5 (raw file):
Previously, Borgquite (Chris Hill) wrote…
Sure.
TL;DR Get-DomainControllerObject is currently broken when ComputerName is not $env:COMPUTERNAME, and this fixes it.
--
Get-DomainControllerObject is used by ADDomainController and now ADReadOnlyDomainControllerAccount to find the domain controller object for a computer. Until this change, it's never been used for anything other than $env:COMPUTERNAME (local node) inside ADDomainController - but I'm reusing it in ADReadOnlyDomainControllerAccount.
However, at present, if ComputerName is set to another name, to check a domain controller other then the local computer, it always fails. This line basically says 'if there is no domain controller account object named COMPUTERNAME, and the local computer is a domain controller, throw an error' (Test-IsDomainController returns true if the local computer is a domain controller). This doesn't make any sense at all if COMPUTERNAME is a remote computer - so Get-DomainControllerObject always fails if $env:COMPUTERNAME != $ComputerName. The fix here is not to run Test-IsDomainController if we're running against another computer - which allows the function to be used in ADReadOnlyDomainController as intended.
That makes sense. Can a new unit test be added for this function so that we can test the behavior is now correct?
tests/Unit/MSFT_ADReadOnlyDomainControllerAccount.Tests.ps1
line 40 at r6 (raw file):
# Load stub cmdlets and classes. Import-Module (Join-Path -Path $PSScriptRoot -ChildPath 'Stubs\ActiveDirectory_2019.psm1') -Force
nit: not something to fix here, but I feel at some point this will need to be determined dynamically (e.g., different stubs needed for 2022 or newer).
tests/Unit/MSFT_ADReadOnlyDomainControllerAccount.Tests.ps1
line 68 at r6 (raw file):
} Context 'When the domain name is not available' {
nit: When the domain could not be found?
tests/Unit/MSFT_ADReadOnlyDomainControllerAccount.Tests.ps1
line 88 at r6 (raw file):
} Context 'When the system is in the desired state' {
nit: Is this level of Context needed? It doesn't really make sense when combined with the subcontexts. Could just remove to reduce the block depth.
source/DSCResources/MSFT_ADReadOnlyDomainControllerAccount/en-US/about_ADReadOnlyDomainControllerAccount.help.txt
line 34 at r6 (raw file):
Specifies if the read only domain controller will be a Global Catalog (GC). .PARAMETER Ensure
I don't think this should be here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 1 of 9 files at r4.
Reviewable status: all files reviewed, 21 unresolved discussions (waiting on @Borgquite and @johlju)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, the resource is based on ADDomainController - so a lot of my fixes below I've also fixed there, for consistency. For that reason I also haven't done any integration tests - there aren't any for ADDomainController, and I guess that may be due to complexity (you'd have to spin up an existing domain first to be able to do it, a job beyond me!) However because the resource is a copy/paste of a resource that is working well, I hope we can live without it for now.
Reviewable status: 6 of 17 files reviewed, 15 unresolved discussions (waiting on @johlju and @PlagueHO)
CHANGELOG.md
line 23 at r6 (raw file):
Previously, PlagueHO (Daniel Scott-Raynsford) wrote…
Can you also mention the fix to
Get-DomainControllerObject
?
Done.
source/DSCResources/MSFT_ADDomainController/MSFT_ADDomainController.schema.mof
line 20 at r6 (raw file):
Previously, PlagueHO (Daniel Scott-Raynsford) wrote…
This seems to refer to a cmdlet. Presumably this should refer to "apply the DSC resource"?
Yeah - this was a copy/paste from the Install-ADDSDomainController documentation, but I've updated it here, as well as in the help for ReadOnlyReplica above. :)
source/DSCResources/MSFT_ADDomainController/en-US/about_ADDomainController.help.txt
line 106 at r6 (raw file):
Previously, PlagueHO (Daniel Scott-Raynsford) wrote…
See previous comment about: "This seems to refer to a cmdlet. Presumably this should refer to "apply the DSC resource"?"
Done.
source/DSCResources/MSFT_ADReadOnlyDomainControllerAccount/MSFT_ADReadOnlyDomainControllerAccount.psm1
line 107 at r6 (raw file):
Previously, PlagueHO (Daniel Scott-Raynsford) wrote…
nit: Are ( ) needed here?
Not sure - but this isn't my code (copied from ADDomainController) so reluctant to fiddle as it currently works.
source/DSCResources/MSFT_ADReadOnlyDomainControllerAccount/MSFT_ADReadOnlyDomainControllerAccount.psm1
line 110 at r6 (raw file):
Previously, PlagueHO (Daniel Scott-Raynsford) wrote…
nit: Are ( ) needed here?
Ditto
source/DSCResources/MSFT_ADReadOnlyDomainControllerAccount/MSFT_ADReadOnlyDomainControllerAccount.psm1
line 122 at r6 (raw file):
Previously, PlagueHO (Daniel Scott-Raynsford) wrote…
Is this value stored with the RODC account? If not, how does it get used when prestaging an RODC account?
I can see that
Add-ADDSReadOnlyDomainControllerAccount
does support the-InstallDns
parameter, but I can't actually figure out how it would actually work - unless the flag was stored with the AD object.The reason I'm asking is if the state is not stored and able to be retrieved, could we eliminate it entirely - as we're not installing an RODC (and the DNS service), we're just creating the RODC account object.
Sorry if this doesn't make sense (it's been a while since I've dealt with RODC's 😁)
Ah, this was something that was bugging me too. In my investigations:
- I couldn't see how the switch made any difference to the created AD object (perhaps it does something elsewhere though?)
- HOWEVER when performing the 'other half' of the process (Install-ADDSDomainController -UseExistingAccount), the -InstallDNS parameter is not available within the cmdlet parameter set. I therefore think it's important to leave it in, in case it happens to be doing something under the hood somewhere I didn't think to check.
source/DSCResources/MSFT_ADReadOnlyDomainControllerAccount/MSFT_ADReadOnlyDomainControllerAccount.psm1
line 288 at r6 (raw file):
Previously, PlagueHO (Daniel Scott-Raynsford) wrote…
See previous query regarding InstallDns parameter.
See above
source/DSCResources/MSFT_ADReadOnlyDomainControllerAccount/MSFT_ADReadOnlyDomainControllerAccount.psm1
line 398 at r6 (raw file):
Previously, PlagueHO (Daniel Scott-Raynsford) wrote…
This block seems to have a lot of similar code to the previous block. Any chance we could split it out into a function and reduce the duplication?
Again, not my code, copied from ADDomainController, so would prefer not to get into this for this patch.
source/DSCResources/MSFT_ADReadOnlyDomainControllerAccount/MSFT_ADReadOnlyDomainControllerAccount.psm1
line 477 at r6 (raw file):
Previously, PlagueHO (Daniel Scott-Raynsford) wrote…
See previous query regarding InstallDns
See above
source/DSCResources/MSFT_ADReadOnlyDomainControllerAccount/MSFT_ADReadOnlyDomainControllerAccount.psm1
line 609 at r6 (raw file):
Previously, PlagueHO (Daniel Scott-Raynsford) wrote…
nit: some code duplication in this block, but probably not enough to warrant splitting into a function. Will leave decision to you.
Not my code, as above
source/DSCResources/MSFT_ADReadOnlyDomainControllerAccount/en-US/MSFT_ADReadOnlyDomainControllerAccount.strings.psd1
line 3 at r6 (raw file):
Previously, PlagueHO (Daniel Scott-Raynsford) wrote…
nit: domain controller account.
E.g., it only looks for one right? 😀
Fixed (also in MSFT_ADDomainController)
source/Modules/ActiveDirectoryDsc.Common/ActiveDirectoryDsc.Common.psm1
line 1354 at r5 (raw file):
Previously, PlagueHO (Daniel Scott-Raynsford) wrote…
That makes sense. Can a new unit test be added for this function so that we can test the behavior is now correct?
Done my best here (see elsewhere!).
tests/Unit/MSFT_ADReadOnlyDomainControllerAccount.Tests.ps1
line 68 at r6 (raw file):
Previously, PlagueHO (Daniel Scott-Raynsford) wrote…
nit: When the domain could not be found?
Not my code, but happy to update
tests/Unit/MSFT_ADReadOnlyDomainControllerAccount.Tests.ps1
line 88 at r6 (raw file):
Previously, PlagueHO (Daniel Scott-Raynsford) wrote…
nit: Is this level of Context needed? It doesn't really make sense when combined with the subcontexts. Could just remove to reduce the block depth.
Not my code - and my Pester knowledge is quite limited - but I think it just reflects the other Contexts in Set and Test so maybe keep for symmetry if nothing else?
source/DSCResources/MSFT_ADReadOnlyDomainControllerAccount/en-US/about_ADReadOnlyDomainControllerAccount.help.txt
line 34 at r6 (raw file):
Previously, PlagueHO (Daniel Scott-Raynsford) wrote…
I don't think this should be here.
Sorry - don't follow? Ensure is a supported read only attribute?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Heh - yeah, I built Labbuilder way back to deal with the problem of integration testing the AD/ADCS DSC resources (got tired of rebuilding DCs).
I was certain I built integration tests for ADDomainController ... but turns out I raised it as an issue to create them in 2016 :D but never got round to it: Create Integration Tests for Resources · Issue #121 · dsccommunity/ActiveDirectoryDsc (github.com) - oops my bad 😀
So, yes, can live without for now.
Thanks again for submitting this! And if you do feel like building integration tests for these (or other resources... there's an open issue 😆 )
Reviewed 12 of 12 files at r7, all commit messages.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @Borgquite and @johlju)
source/DSCResources/MSFT_ADReadOnlyDomainControllerAccount/MSFT_ADReadOnlyDomainControllerAccount.psm1
line 107 at r6 (raw file):
Previously, Borgquite (Chris Hill) wrote…
Not sure - but this isn't my code (copied from ADDomainController) so reluctant to fiddle as it currently works.
Sure - leave it as is.
source/DSCResources/MSFT_ADReadOnlyDomainControllerAccount/MSFT_ADReadOnlyDomainControllerAccount.psm1
line 122 at r6 (raw file):
Previously, Borgquite (Chris Hill) wrote…
Ah, this was something that was bugging me too. In my investigations:
- I couldn't see how the switch made any difference to the created AD object (perhaps it does something elsewhere though?)
- HOWEVER when performing the 'other half' of the process (Install-ADDSDomainController -UseExistingAccount), the -InstallDNS parameter is not available within the cmdlet parameter set. I therefore think it's important to leave it in, in case it happens to be doing something under the hood somewhere I didn't think to check.
Ok- happy to leave it in - as I expect it's not going to hurt anything. Just wanted to make sure it wasn't some oversight.
source/DSCResources/MSFT_ADReadOnlyDomainControllerAccount/MSFT_ADReadOnlyDomainControllerAccount.psm1
line 398 at r6 (raw file):
Previously, Borgquite (Chris Hill) wrote…
Again, not my code, copied from ADDomainController, so would prefer not to get into this for this patch.
Is it identical code to the code in ADDomainController I feel like it should be refactored at some point. I gettit though: keeping ahead of all the refactoring we should do on these is a losing battle 😀 But it still ok to refactor existing/other code if it makes maintaining easier and reduces the size of the code base.
Could an issue be added to remediate this at some point - e.g. DRY?
tests/Unit/MSFT_ADReadOnlyDomainControllerAccount.Tests.ps1
line 68 at r6 (raw file):
Previously, Borgquite (Chris Hill) wrote…
Not my code, but happy to update
Thank you - reviewable just showed it as new code. But as maintainer, love to have improved code, even if it's cloned from something else (or even if the original code is refactored as well 😁) - all just considered code janitorial work (which we need a lot of in these repos).
tests/Unit/MSFT_ADReadOnlyDomainControllerAccount.Tests.ps1
line 88 at r6 (raw file):
Previously, Borgquite (Chris Hill) wrote…
Not my code - and my Pester knowledge is quite limited - but I think it just reflects the other Contexts in Set and Test so maybe keep for symmetry if nothing else?
Would have most likely been for symmetry - which I can understand. But it makes the length of the test messages longer and may also lead to confusion (e.g., where are the get tests when the system is not in the desired state).
Happy to leave as is.
source/DSCResources/MSFT_ADReadOnlyDomainControllerAccount/en-US/about_ADReadOnlyDomainControllerAccount.help.txt
line 34 at r6 (raw file):
Previously, Borgquite (Chris Hill) wrote…
Sorry - don't follow? Ensure is a supported read only attribute?
Sorry, I didn't notice the read
and because the README.txt mentioned that the resource can't be used to remove the account, I thought it was a mistake - but understand it is retained to return current state.
Sidenote: I think the name ensure
for this type of parameter (where it is only used to return the state... not ensure
it is actually in a given state) doesn't really make sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@johlju -
If you're happy to merge, can you approve the changes?
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @Borgquite and @johlju)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I you all are happy, I'm happy. 🙂 Thank for helping review @PlagueHO!
Reviewed 1 of 1 files at r6, 12 of 12 files at r7, 2 of 2 files at r8, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @Borgquite)
Pull Request (PR) description
As discussed in #711 - a new resource to allow pre-staging of read-only domain controller accounts
This Pull Request (PR) fixes the following issues
Task list
Entry should say what was changed and how that affects users (if applicable), and
reference the issue being resolved (if applicable).
help.
This change is