Microsoft Sign-In configuration

A Microsoft button on the sign-in page, tied to your own directory. People use the work account they already have, you stop managing passwords, and access ends when their directory account is disabled rather than when somebody remembers to lock them here. Only accounts in the directory you name can sign in.

Registering the application on Microsoft's side is covered in the Microsoft Entra integration guide.

On RedminePRO Cloud

Availability

Business and above.

Turn it on

Administration → Plugins → RedminePRO Microsoft Sign-In, then paste the Directory (tenant) ID, Application (client) ID and Client secret from your app registration. The button appears on the sign-in page once they are stored.

Permissions

None of its own. This decides how people prove who they are; what they may do afterwards is governed by their roles exactly as before.

Settings

Administration → Plugins → RedminePRO Microsoft Sign-In:

Test configuration confirms connectivity by fetching your directory's configuration and signing keys. Nobody is signed in by it and no secret is logged.

Set Client secret expiry reminder when you create the secret. Directory secrets expire, and an expired one takes sign-in down for everybody at a moment nobody chose. This is the only warning you will get.

Allowed email domains blank is the safe default — existing accounts work, nothing new is created.

Before turning on Force Microsoft sign-in (SSO-only), sign in with Microsoft yourself and confirm it works. Administrators keep a password route as a break-glass path; everyone else loses theirs immediately. When Google Sign-In is also installed, either feature's SSO-only setting disables password sign-in.

Using it

1. A person opens the sign-in page and chooses the Microsoft button.
2. The directory authenticates them, and approval is asked once.
3. They arrive signed in — attached to their existing account if Auto-link by directory email matched one, otherwise newly created if their domain is listed.

Troubleshooting

The directory reports a redirect mismatch. The value in the registration differs from Redirect URI on the settings page, which shows the exact string to add. It must be registered as a web redirect, not another kind.

Sign-in worked yesterday and fails today. The Client secret has expired. Create a new one in the registration, paste it here, and set Client secret expiry reminder this time.

Somebody outside the organisation cannot sign in. By design — only accounts in the directory named by Directory (tenant) ID may.

An account was created without an email address. The directory sent no email claim. Turn on Trust UPN as email so the sign-in name is used when it looks like an address.

Nobody can sign in after enabling SSO-only. Administrators keep a password route as a break-glass path; use it and turn the setting off.

Connecting Microsoft Entra ID

You register one application in your directory and paste three values into the workspace. The workspace shows you the exact redirect address to register. Nothing is asked of the directory beyond identity, and only accounts in the directory you name can sign in.

On RedminePRO Cloud

The feature is preinstalled. Start at the next section.

On your own Redmine

Install the feature first — see the Microsoft Sign-In configuration page — then follow the same steps. Your workspace must be reachable over HTTPS at a hostname the directory can redirect back to.

Before you start

• An administrator account on the workspace.
• Rights to register an application in your directory.
• Your directory identifier to hand.
• Decide which email domains, if any, should get accounts created automatically.

On the external side

1. In the workspace, open Administration → Plugins → RedminePRO Microsoft Sign-In and copy the Redirect URI shown there.
2. In the Microsoft Entra admin centre, register a new application.
3. Choose the supported account types. Accounts in this organizational directory only is the right choice unless you have a reason otherwise — it is what makes the directory the boundary.
4. Add the address from step 1 as a Web redirect address. It must be the web platform specifically, and it must match exactly.
5. Create a client secret. Note its expiry date now — you will need it in a moment, and it is the single most common cause of sign-in breaking months later.
6. Copy the directory identifier and the application identifier from the application's overview.

No API permissions beyond the default sign-in and profile reading are needed.

In RedminePRO

1. Administration → Plugins → RedminePRO Microsoft Sign-In.
2. Paste the Directory (tenant) ID, the Application (client) ID and the Client secret, then save. The secret is stored encrypted and never displayed again.
3. Set Client secret expiry reminder to the date from step 5. The page warns you as it approaches. This is the only warning you will get, and without it an expired secret takes sign-in down for everybody at a moment nobody chose.
4. Press Test configuration. It fetches your directory's configuration and signing keys to prove connectivity. Nobody is signed in by it and no secret is logged.
5. Set Allowed email domains if you want accounts created automatically. Blank is the safe default.
6. Turn on Trust UPN as email only if your directory does not send an email claim.
7. Leave Force Microsoft sign-in (SSO-only) off until you have signed in with Microsoft yourself.

Verify it works

Sign out, open the sign-in page, and use the Microsoft button with your own work account. You should arrive signed in as your existing account rather than a new one — that is Auto-link by directory email doing its job.

Have one other person try before enabling SSO-only. When Google Sign-In is also installed, either feature's SSO-only setting removes the password form, so check both before concluding which one did it.

What is stored

The directory and application identifiers, and the client secret encrypted at rest and never logged. Against each account, the directory identity it is linked to, and the expiry date you entered.

Nothing else. No directory password reaches the workspace, no token is kept after sign-in, and no directory data beyond the person's identity and email is requested or stored.

Troubleshooting