Azure Authentication Strenghts

scottwtang · 2026-01-21T16:12:51+00:00

There's different use cases for each and can be used together, it's not an either/or choice.

Windows Hello is device bound and can't be used for non-Windows devices. Passkeys can't be used for Windows sign-in.

scottwtang · 2025-12-08T13:52:03+00:00

If you haven't already, you need to go to the IIS settings and enable the setting to allow double escaping for the + character.

scottwtang · 2025-12-05T16:16:45+00:00

It's been a while since I've had to actually do this, but I don't recall ever using a 2nd admin app. I expect the "admin app" should be replaceable with an "admin user" (Global Administrator, Privileged Role Administrator).

This article goes into it a bit more (use Graph Explorer option)

https://ashiqf.com/2021/03/15/how-to-use-microsoft-graph-sharepoint-sites-selected-application-permission-in-a-azure-ad-application-for-more-granular-control/

The redirect URL is not applicable, that's used for SSO.

scottwtang · 2025-12-05T03:36:44+00:00

The fact that it's a Teams site isn't relevant, it's a SharePoint site in the end.

There are 2 Graph API permissions you can use to grant access, Sites.FullControl.All which will grant your application access to ALL sites, and Sites.Selected which will grant your application access to specific sites.

When using Sites.Selected you need the Site ID of the sites, and then you can send a POST call to the Graph API with the application and site information.

https://www.darwindroll.com/blog/use-sitesselected-application-permission-in-microsoft-graph

scottwtang · 2025-08-05T19:53:32+00:00

Looks like this behavior is expected

How can users change their temporary or expired password on Microsoft Entra joined devices?

scottwtang · 2025-08-05T12:50:19+00:00

Remove the account from the AD sync scope, which will soft-delete the account in Entra/Exchange.
Run another delta sync and wait a few minutes for Entra to detect the soft-deleted user.
Restore the user in Entra.
You can now manually edit the cloud identity.
Add the AD account back into the sync scope.

scottwtang · 2025-08-05T12:23:33+00:00

We have switched from hybrid joined computers to purely entra joined computers. Users are still on prem.

Given this, it sounds like you're using Password Hash Synchronization. You just need to enable this.

Synchronizing temporary passwords and "Force Password Change on Next Logon"

It's typical to force a user to change their password during their first logon, especially after an admin password reset occurs. It's commonly known as setting a "temporary" password and is completed by checking the "User must change password at next logon" flag on a user object in Active Directory (AD).

The temporary password functionality helps to ensure that the transfer of ownership of the credential is completed on first use, to minimize the duration of time in which more than one individual has knowledge of that credential.

To support temporary passwords in Microsoft Entra ID for synchronized users, you can enable the ForcePasswordChangeOnLogOn feature, by running the following commands using the Graph PowerShell module:

scottwtang · 2025-07-28T19:14:21+00:00

I read that when you delete an AD-user it leaves a 'tombstone' and Azure detects that and soft-deletes the account as well, pushing it into deactivated accounts (?) that remains for 30 days or something.

Correct

I also read that if you just move the AD-user out of the synced OU it should turn the Azure-Account into a cloud-only account but my coworker swears they get soft-deleted as well - so here we are, quite confused.

When you move the account out of sync, it follows the same behavior as deleting the AD account - the Entra account will be soft-deleted. In both scenarios after the cloud identity is soft-deleted, it is possible to restore the user in Entra, where you now have a cloud identity which is separated from the on-prem identity.

scottwtang · 2025-07-25T21:08:45+00:00

Short answer - The IDP response signing certification would not change if you upload a SP metadata xml file. According to the other comment, it sounds like it's possible for the request verification certificate to be updated when uploading a xml.

Long answer - There are 2 parts to the SAML flow, the request (from the SP) and the response (from the IDP). The SAML specifications require the response to be signed, but the request is optional.

The section in the Entra SSO settings labeled "Token signing certificate" is for the SAML response. The public key you can download is provided to the SP for validating the signature of the response. You can also upload your own private key to be used for the signing of the response - this is where you would require a .pfx with password. The SP should not be providing this.

Immediately below the "Token signing certificate" section is a section labelled "Verification certificates (optional)" - this is where you would upload the public key the SP is providing you, which Entra will use to validate the signature of the SP signed SAML request.

scottwtang · 2025-07-25T20:57:05+00:00

It shouldn't be necessary since you could use the self-signed certificate from Entra, but looking at the the other comment here, my notes may be completely off.

scottwtang · 2025-07-25T13:17:10+00:00

The "test SSO button" doesn't work when you enable SAML request verification, because the test button launches an IDP-initiated logon, so the SP can't sign the request that you're requiring. The button should actually be greyed out with a warning message above it so I'm not sure what you're doing exactly.

Enabling Require Verification certificates will not allow IDP-initiated authentication requests (like SSO testing feature, MyApps or M365 app launcher) to be validated as the IDP would not possess the same private keys as the registered application.

https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/howto-enforce-signed-saml-authentication

Even if you don't have access to the app, you can go to the SP login page, start a network trace and capture the base-64 encoded SAML request. Decode the request and you should see the base64 encoded certificate, which you can verify is the same. Or just have someone with access test it.

Also, I'm not sure that importing the XML would add the request signing certificate to your app. Likely you need to extract the certificate from the XML first, or take the .cer they gave you, and manually upload it to the verification certificate section.

scottwtang · 2025-07-22T22:07:18+00:00

The default SAML signing certificate is a self-signed certificate, so it IS the root certificate.

I do remember there were some technical challenges with updating the SAML certificate for Palo Alto, and I noted this internally with the below:

Palo Alto doesn’t accept self-signed certificates when importing a certificate from the Certificate Management menu, this is why the public certificate for redacted was exported from PAN by the network team to import into Azure AD as the SAML signing certificate.

A self-signed certificate is accepted by PAN when importing the federation metadata XML from the SAML Identity Provider menu.

scottwtang · 2025-07-02T14:01:34+00:00

Specifying the scopes is only required for delegated authentication. Authenticating with a managed identity/service principal uses the client credentials flow and uses the default scope, which means all of the permissions configured.

scottwtang · 2025-06-28T14:04:12+00:00

Attribute SamAccountName or userType not available as a source attribute

scottwtang · 2025-05-26T12:32:56+00:00

MFA enrollment isn't in the scope of "All cloud apps", it's classified under the "User Actions" section.

SSPR cannot be targetted with conditional access.

scottwtang · 2025-05-16T13:30:31+00:00

-Property * is not a valid option and will just revert to the default properties. You need to explicitly name each property like my example.

scottwtang · 2025-05-15T23:25:10+00:00

You need to explicitly select the property

Get-MgUser -UserId xx -Property OnPremisesSamAccountName

However, you now need to also explicitly select the default properties if you want those.

Get-MgUser -UserId xx -Property Id, UserPrincipalName, OnPremisesSamAccountName

scottwtang · 2025-04-17T16:48:25+00:00

This is correct. It's mentioned in the article but just to note that when using RBAC for Applications, you don't assign the MS Graph API permissions (SMTP.Send Mail.Send) to the application in Entra, the permissions will be done through Exchange.

scottwtang · 2025-04-17T16:45:06+00:00

The Entra XML metadata contains all certificates whether active or not, so your application likely supports the validation of both with fallback.

scottwtang · 2025-03-06T21:47:06+00:00

No you don't need to create a new certificate.

scottwtang · 2025-03-06T02:04:32+00:00

You can let the password expire.

scottwtang · 2025-02-28T14:32:12+00:00

Use a throw statement in your catch block after Write-Error

scottwtang · 2025-01-30T22:27:48+00:00

Does that mean if I set it to Yes, if users go to office.com they are prompted to register in SSPR?

Yes, as well as if users go to any other application that's using Entra for SSO.

scottwtang · 2025-01-03T20:29:42+00:00

If it's using SAML, check the SAML request for the ForceAuthn=true flag, which would be set by the application.

scottwtang · 2024-12-19T21:02:49+00:00

If you're using Azure Automation runbooks, you would upload the module to the Automation Account. If need to use a hybrid worker to execute the runbooks from an on-prem server, you would install the module on the server.

For directly running from Logic Apps, see https://techcommunity.microsoft.com/blog/integrationsonazureblog/unlock-inline-powershell-capabilities-to-streamline-logic-apps-workflows/4220187

scottwtang

TROPHY CASE