resources / faq
Questions teams ask
Deployment, PAM, MFA and policy, compliance, and pricing, in one place.
18 questions shown
MFA and policy
Yes. AuthNull triggers the push in the app your users already have: AuthNull Authenticator, Duo, or Okta.
- Open the factor matrix →
The factor-by-protocol matrix on the MFA page shows every combination.
Service accounts can’t approve a push, so exempt them with a policy instead of requiring MFA:
- Windows / AD: create an Allow policy for the group that holds your service accounts. When AuthNull scans your directory, it suggests Allow for groups named like svc-, svc_, sa- or service-.
- SSH (PAM): give automation accounts a policy with Allow without approval.
- RADIUS: use an Allow policy for those users or devices.
- Applications: an app that only needs a second factor for its own users calls the MFA API with its own client ID and secret, and nobody approves anything for the app itself.
- See access policy →
Yes. Rules can use user, group, OU, source, time, and machine.
PAM
It covers the session gateway, recording, just-in-time access, the vault and rotation, SSH keys, and sudo step-up. It doesn’t cover Windows PEDM, application secrets, or CIEM.
No, once enforced. Direct connections are refused and the gateway is the only path.
SSH sessions are recorded as text (everything typed and shown, playable in the console). By default they’re stored on the AuthNull server. If you configure Recording Storage, they’re moved to your own Amazon S3, S3-compatible (MinIO, Wasabi, Ceph) or Google Cloud Storage bucket, with optional KMS encryption.
Each recording is integrity-checked with SHA-256. Recordings are kept until you delete them; to expire them automatically, set a lifecycle rule on your bucket.
Not today. Approvals go to the user’s phone through one push provider per organisation: Duo, Okta Verify or the AuthNull Authenticator. A code from an authenticator app (TOTP) or a backup code works when the phone is offline.
The vault holds it and rotates it. People never see it.
Deployment
No for AD and Windows: the DC Sensor runs on domain controllers only. Yes on database hosts. SSH and RDP go through one gateway host.
Both. Use our hosted service, or install AuthNull on your own Linux server with Docker Compose and one install script, over HTTPS on your own domain or by IP address.
Self-hosted needs no inbound access from the internet. It needs outbound access to our image registry, your MFA provider (Duo or Okta), and your mail server. Licences work offline.
It depends on the product, and in most cases access is refused rather than let through without MFA:
- Windows / Active Directory: you choose per directory. With Deny, logins are refused; with Allow, they go through without MFA. Each domain controller sensor applies the choice after repeated failed calls to AuthNull.
- RADIUS (VPN): logins are refused by default. You can switch the bridge to let them through instead (FAIL_OPEN=true).
- SSH (PAM): connections are refused, because every session needs a fresh approval. Keep a key-only break-glass account for emergencies.
- Applications (SSO): sign-in isn’t possible while AuthNull is down, since AuthNull is the sign-in service.
- Databases: connections are refused.
Yes:
- Active Directory: install a sensor on every domain controller that handles logons. They work side by side, so losing one doesn’t affect the others.
- RADIUS: register several RADIUS servers and set them as primary and secondary on your VPN. Either one can complete a login.
- SSH (PAM): you can run as many gateways as you like, but each server is reached through one gateway at a time. If a gateway fails, you move its servers to another with “Change gateway”.
No. AuthNull works with on-prem AD only.
Compliance and pricing
PCI DSS 4.0 requirement 8.4, CMMC IA.L2-3.5.3, and SOC 2 CC6, plus session recordings for any audit.
A human or service account that authenticates through AuthNull in the billing month.
- See pricing →
Yes. One month, on any plan.
Yes, for PAM today. Under Settings → Logs Configuration you can send events to Splunk (HEC), Elasticsearch, any HTTP endpoint (JSON) or Syslog (TCP, UDP or TLS, RFC 5424 or 3164).
The events cover SSH access decisions, session start and end, recordings, password reveals and rotations, sudo elevation and endpoint changes. Each event carries a unique ID so your SIEM can drop duplicates, and secrets are stripped before sending.
Still have a question?
Walk through your environment with our team in 20 minutes.