This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(118.4, 96%, 21%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESG%3C/text%3E%3C/svg%3E)
I am deploying an M365DSC infra for my org. I've followed the pre-requisites and installed and updated DSC on a stand-alone Azure VM. I intend to use certificate authentication and created the EntraID application using the Update-M365DSCAzureAdApplication cmdlet. I am a Global Admin and ran this command using my creds and permissions.
PS C:\Windows\System32> Update-M365DSCAzureAdApplication
>> -ApplicationName 'Microsoft365DSC'
>> -AdminConsent
>> -Type Certificate
>> -CreateSelfSignedCertificate
>> -CertificatePath C:\temp\M365DSC.cer
>> -Permissions @(
>> @{Api='Graph';PermissionName='User.Read.All'},
>> @{Api='Graph';PermissionName='UserAuthenticationMethod.Read.All'},
>> ......lots of permissions.....
>> )
The cert gets created and I install the cert to the User Personal store. (I know the instructions on the official documentation say to install the cert to the LocalMachine Personal store, but I was having connection problems and found that the Connect-MgGraph cmdlet only looks for certs in the User Personal store, so I installed the cert in both locations).
I connect using the following values:
$TenantId='mycompany.onmicrosoft.com'
$AppId='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx'
$CertThumbprint='xxx....' #cert thumprint copied from certificate entry in EntraID Application.
I am trying to connect with connect-mggraph -ApplicationId $AppId -CertificateThumbprint $CertThumbprint -TenantId $TenantId
Each time I try to connect, I get the following error; Connect-MgGraph: ClientCertificateCredential authentication failed: The certificate certificate does not have a private key.
By default, the cert created by the Update-M365DSCAzureAdApplication cmdlet does not have a private key. What am I doing wrong?
edit: clarity
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(256, 74%, 34%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ERM%3C/text%3E%3C/svg%3E)
I think this addresses your problem: https://github.com/microsoft/Microsoft365DSC/issues/2910
Thank you, but it does not. I've went through that thread many times prior to submitting this question. There is conflicting information and different results in that thread. Notice the cert screen shot in that thread has the line "You have a private key that corresponds to this certificate"; that statement does not exist on any certs I've created using the cmdlet. You'll see further down that someone echoed that same thing, and there is a post that says the certs are created without private keys, which is what I've found. I'm guessing that somewhere along the line something was changed with regard to cert creation and/or use, but that information has not yet made its way to the documentation.
I know very little about Azure. You might say it's pretty close to nothing.
Admittedly I didn't read all the way through the problem report or look at the problem report it was linked to.
It looks like the Update-M365DSCAzureAdApplication has a XML help file. Have you tried updating the PowerShell help?
Which version of the Microsoft365DSC module are you using? The "current version" is 1.22.615.1, but that module looks to be updated almost weekly! The last version is 1.24.1106.3 (about 3 days ago).
If there's still a problem using the "latest" version you're better off reporting the issue on the modules Github page. The module's written by a product group and isn't part of PowerShell. Using the Q&A forum might bet an answer form someone, but it's unlikely to noticed by the product folks responsible for its maintenance.
I posted to the Github page yesterday morning and have not gotten any replies (or even any views for that matter). Thought I would cross-post here hoping someone had ideas.
I am using version 1.24.1016.1. I haven't updated since early last week. This problem existed far longer than just last week.
The help file is small and simply points you to the online documentation. Update-help for the module fails because "the specified module does not support updatable help". lol
Have you tried creating the self-signed certificate yourself? Using the New-SelfSignedCertificate cmdlet to generate the cert and than export the cert (using Export-PfxCertificate) with its private key to a file might work.
ignore this comment
I have not tried creating my own cert yet. I did find conflicting instructions in their man page for the Update-M365DSCAzureAdApplication cmdlet. The instructions say the -CreateSelfSigedCert and -CertificatePath switches cannot be used together, but the examples show them being used together. I submitted a documentation issue on GitHub. Hopefully it will get corrected and clarified.
"Code never lies. Documentation does."
PowerShell has a mechanism for dealing with parameters that shouldn't be used together: Property Sets. If you're able to use two parameters together that should never be mingled, it's clearly the programmers' fault. If the documentation is incorrect the code should be disallowing the use of conflicting parameters.
This is a good case for unit or integration testing. If they tested for ineligible parameter combinations the code should never reach production.
Maybe testing is why this module receives so many updates. Whatever it is, it's not something I'm willing to get involved in since I have no access to anything Azure. The source code for the module is available if you're up for it. ;-)
SOLVED!! Turns out PowerShell 7 is the culprit here. I was executing all previous commands using PowerShell 7.4 (because that's my preferred version). I took all the steps required to use PS7+, per https://microsoft365dsc.com/user-guide/get-started/powershell7-support/.
On the EntraID App, I deleted all permissions and the previous certificate. I executed the same Update-M365DSCAzureAdApplication command using PowerShell 5.1. The cert was created and the same permissions assigned. I installed the cert to the user store and executed the Export-M365DSCConfiguration command. It authenticated successfully and exported the requested items.
I then opened another PS7 session and executed the same Export command, and it successfully authenticated with the same cert thumbprint; no other changes were made!
It would seem that the self-signed cert created under the PS7 session somehow differs than the one created under the PS5 session. I reported this to the devs on GitHub. Hopefully, this little knowledge-nugget makes its way into the documentation.
SOLVED!! Turns out PowerShell 7 is the culprit here. I was executing all previous commands using PowerShell 7.4 (because that's my preferred version). I took all the steps required to use PS7+, per https://microsoft365dsc.com/user-guide/get-started/powershell7-support/.
On the EntraID App, I deleted all permissions and the previous certificate. I executed the same Update-M365DSCAzureAdApplication command using PowerShell 5.1. The cert was created and the same permissions assigned. I installed the cert to the user store and executed the Export-M365DSCConfiguration command. It authenticated successfully and exported the requested items.
I then opened another PS7 session and executed the same Export command, and it successfully authenticated with the same cert thumbprint; no other changes were made!
It would seem that the self-signed cert created under the PS7 session somehow differs than the one created under the PS5 session. I reported this to the devs on GitHub. Hopefully, this little knowledge-nugget makes its way into the documentation.
@Shawn Goodwin Nice! I hope it makes it into the code for the module!