Loading

The Available Sign-In Sources

As well as its own accounts, the platform can sign users in against a range of external sources. Each appears on the sign-in page once configured and enabled.

Where to find it

Architect Panel → Security:

  • Authentication Methods — which sign-in routes are enabled

Architect Panel → Integration & Connections:

  • Azure AD Tenants — Microsoft directory connections
  • SAML Identity Providers — enterprise single sign-on

What is available

  • ActiveManage — the platform's own accounts. Enabled by default.
  • External ActiveManage Instance — signing in against another installation. Also enabled by default.
  • Active Directory — on-premises corporate sign-in.
  • Azure AD — Microsoft 365 and Entra organisations.
  • SAML — enterprise single sign-on with the usual identity providers.
  • Login Links — sign-in by a link rather than a credential.
  • Xero.
  • Social — Google, Microsoft, Apple, Facebook, Twitter, Amazon, GitHub, Instagram and LinkedIn.

Everything except the two defaults ships disabled

Nothing appears on your sign-in page until you enable it and enter its credentials. That is the right posture — an unexpected sign-in route is an unexpected way in.

It also means enabling one is a deliberate act, so the list of what is on should be short and explicable.

Choosing for a population

  • Staff in a Microsoft organisation — Azure AD.
  • Staff with another enterprise provider — SAML.
  • Staff on an on-premises domain — Active Directory.
  • Consumers — social logins reduce registration friction considerably.
  • Partners at another ActiveManage installation — the external instance route.

Social logins are a trade

They remove the password problem and they hand part of your sign-in journey to a company with its own priorities. An account tied to a social provider can be lost if that account is closed or suspended, and you cannot do anything about it.

Offer them where registration friction is the constraint. Avoid depending on them exclusively for anything people must be able to reach.

Enable few

Every enabled route is a tile on the sign-in page and a path to maintain. Nine social providers on one page is a paralysing choice, and users who cannot remember which one they used create a second account.

Two or three, chosen for your actual population, works better than everything available.

The same person, two routes, two identities

Worth understanding before enabling several. Identity is recorded as a method plus an identifier, so somebody arriving by Google and by password is two identities unless you have deliberately linked them.

That is usually the commonest support question after enabling a second route — "it says I have no account" from somebody who definitely does.

Keep one route you control

If every administrator signs in through an external provider and that provider is unavailable, nobody can get in to fix anything. One local administrative account, strongly protected, is worth keeping.

Worked example

An organisation enables Azure AD for staff and Google for its public users, leaving the other seven social providers off. Two local administrator accounts with passkeys are retained. Support calls about "no account found" fall away once the sign-in page makes clear which route each population should use.

Recommendations

  • Enable only what your populations use.
  • Two or three social providers at most.
  • Keep a local administrative route.
  • Expect identity confusion when somebody has two routes.