-
Notifications
You must be signed in to change notification settings - Fork 225
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
SqlSetup: Does not allow null or empty password for MSA #378
Comments
@wasabii Would you be so kind to post the configuration you are using? Without any sensitive information. |
I don't think it matters. I solved the problem by creating a |
This was discussed in Gitter, thanks @NReilingh! 🙂 @NReilingh was kind enough to provide the error message from LCM when passing an empty password into the credential object. Using this compiles a configuration correctly. $SqlProxyUserCredential = New-Object System.Management.Automation.PSCredential(
$Node.SqlSetup.ProxyUserMSA,
(New-Object System.Security.SecureString)
) But applying the configuration it gives this error.
And @NReilingh concludes
|
To use a (g)MSA with the credential objects (that support (g)MSA), any password need to passed into credential objects, but the username will only be used. Since we can not change how LCM or MOF works in this repository, the only other way of solving this is to make separate parameters for (g)MSA, like what was done in dsccommunity/xPSDesiredStateConfiguration#441 for the xService resource. I relabel this as a community discussion since this needs more voices if we should do a (breaking) change. |
I think on balance, if we can't get a change out of LCM/MOF, it's preferable to use the "bogus password" workaround than to reimplement as a separate parameter. We would then want to make sure that's consistent across this repository, and documented so people know what they need to do if they want to use MSAs. At the same time, it would be good to reach consensus with other DSC Resources, and is it possible to raise some sort of issue with the team that owns the LCM? One could interpret this as a bug in the encryption/decryption mechanism or MOF format, since it's perfectly valid to create a PSCredential object with no password. Edit: Here's a uservoice issue: https://windowsserver.uservoice.com/forums/301869-powershell/suggestions/13447689-dsc-should-allow-credentials-with-blank-passwords |
I agree we should add this to the documentation. Labeling it as such. |
- SqlServerDsc - Remove the file `.github/CONTRIBUTION.md` as it no longer filled any purpose as GitHub will find the CONTRIBUTION.md in the root folder directly now (issue #1227). - The documentation in CONTRIBUTING.md has been somewhat updated. - Update documentation around design pattern for accounts that does not use passwords (issue #378) and (issue #1230). - Updating the Integration Test README.md to better explain what the integration tests for SqlSetup, SqlRSSetup, and SqlRS does (issue #1315). - SqlAGReplica - Update documentation with a requirement for SqlServer in certain circumstances (issue #1033). - SqlRSSetup - There was a typo in the error message that was thrown when not passing either the `Edition` or `ProductKey` that could be misleading (issue #1386). - Updated the parameter descriptions for the parameters `Edition` and `ProductKey` that they are mutually exclusive (issue #1386).
"The password supplied to the Desired State Configuration resource MSFT_xSQLServerSetup is not valid. The password cannot be null or empty.",
It should, for managed service accounts.
The text was updated successfully, but these errors were encountered: