A couple notes on this one:
The following statement isn't quite true:
For expired client secrets, first you must delete all of the expired secrets for a given clientId. You then create a new one with MSO PowerShell, wait at least 24 hours, and test the app with the new clientId and ClientSecret key.
From my testing, you do not need to delete expired secrets. You can simply create a new client secret and it will work, even if there's an expired secret still tied to the SP. Granted, this still makes sense to do, as an expired secret really doesn't do you any good.
Additionally, this doc might benefit from an update to not use the MSOL PS module. I think it's possible to do this via graph using
Add-MgServicePrincipalPassword but I haven't confirmed that yet. I certainly have done it with the Azure AD module using New-AzureADServicePrincipalPasswordCredential which appears to map to the previously mentioned graph command in https://learn.microsoft.com/en-us/powershell/microsoftgraph/azuread-msoline-cmdlet-map?view=graph-powershell-1.0
Lastly, I made a note on a related doc, but I think you can actually manage the keys from an app registeration if you do not register the app via the appregnew.aspx link, and instead, create the app initially in the azure portal (which creates the SP/Enterprise App). This has a couple of benefits, the big one being that tenant admins aren't needed to maintain the secret for the app, the person who created the app reg can actually manage it entirely. Given the appregnew.aspx does allow a non tenant admin to create the app in the first place, it makes sense I think to have a method for the person who originated the request to maintain the secret.
Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.
A couple notes on this one:
The following statement isn't quite true:
From my testing, you do not need to delete expired secrets. You can simply create a new client secret and it will work, even if there's an expired secret still tied to the SP. Granted, this still makes sense to do, as an expired secret really doesn't do you any good.
Additionally, this doc might benefit from an update to not use the MSOL PS module. I think it's possible to do this via graph using
Add-MgServicePrincipalPasswordbut I haven't confirmed that yet. I certainly have done it with the Azure AD module usingNew-AzureADServicePrincipalPasswordCredentialwhich appears to map to the previously mentioned graph command in https://learn.microsoft.com/en-us/powershell/microsoftgraph/azuread-msoline-cmdlet-map?view=graph-powershell-1.0Lastly, I made a note on a related doc, but I think you can actually manage the keys from an app registeration if you do not register the app via the appregnew.aspx link, and instead, create the app initially in the azure portal (which creates the SP/Enterprise App). This has a couple of benefits, the big one being that tenant admins aren't needed to maintain the secret for the app, the person who created the app reg can actually manage it entirely. Given the appregnew.aspx does allow a non tenant admin to create the app in the first place, it makes sense I think to have a method for the person who originated the request to maintain the secret.
Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.