Where ActiveManage runs on a server configured for Windows integrated authentication, domain users can be signed in without typing anything at all — they open the site and they are in.
How it works
A dedicated address on your site is protected by the web server itself, so the browser authenticates against Active Directory before ActiveManage is involved. ActiveManage then looks that user up in the directory and signs them in as an ordinary Active Directory user — the same identity a typed sign-in produces. No password is ever handled by the application.
What the server needs
- On IIS — Windows Authentication on and Anonymous Authentication off, for that folder only. The required configuration file is supplied.
- On Apache — a Kerberos authentication block requiring a valid domain user. An example configuration is supplied alongside it.
This is a server configuration task rather than something done in the Architect Panel, so it needs whoever administers the web server.
The security depends on that configuration staying in place
If the supplied configuration is removed, or the server is later changed to allow anonymous access, ActiveManage simply falls back to the normal login form — an unauthenticated visitor is never treated as signed in. But do not remove it.
When it does not work
Any failure returns the user to the normal login page and stops it retrying in a loop, with the reason written to the Error Log.
- Landing back at the login page usually means integrated authentication is not actually being enforced — check anonymous access is disabled.
- Authentication succeeding but sign-in failing usually means the directory account cannot read the user, or the domain is not configured in ActiveManage.
- Users still prompted for credentials means the site is not in the browser's trusted intranet zone — a browser or group policy setting.
Worked Examples
- Internal intranet: staff on the corporate network never see a login page.
- Hybrid working: integrated authentication in the office, Azure AD when remote.