Technitium DNS Server
Technitium DNS Server
This integration guide is community supported. It's not guaranteed to be complete, accurate, or up-to-date. It's likely that if this integration guide does not work for you that changes occurred with a third-party application.
Important Note: This documentation is version specific. Make sure you check the section outlining the tested versions.
Important Note: We always recommend users read the third-party documentation as part of the integration process to ensure configuration elements matches their needs. As such the See Also section is likely to have important links.
Important Note: If you find an error in this documentation please make a Pull Request, start a Discussion, or contact us on a Chat Room.
Tested Versions
- Authelia v4.39.x
- Technitium DNS Server v15.2
Before You Begin
This guide uses the OpenID Connect 1.0 flows. Some common notes apply, in particular regarding generating a client secret.
Assumptions
This example makes the following assumptions:
- Application Root URL:
https://dns.example.com/ - Authelia Root URL:
https://auth.example.com/ - Client ID:
technitium - Client Secret:
insecure_secret
Some of the values presented in this guide can automatically be replaced with documentation variables.
Configuration
Authelia
The following YAML configuration is an example Authelia [client configuration] for use with Technitium which will operate with the application example:
identity_providers:
oidc:
## The other portions of the mandatory OpenID Connect 1.0 configuration go here.
## See: https://www.authelia.com/c/oidc
claims_policies:
technitium:
custom_claims:
roles:
attribute: 'groups'
scopes:
technitium_roles:
claims:
- 'roles'
clients:
- client_id: 'technitium'
client_name: 'Technitium DNS Server'
client_secret: '$pbkdf2-sha512$310000$...' # authelia crypto hash generate pbkdf2 --variant sha512
public: false
authorization_policy: 'technitium'
claims_policy: 'technitium'
require_pkce: false
redirect_uris:
- 'https://dns.example.com/sso/callback'
scopes:
- 'openid'
- 'profile'
- 'email'
- 'groups'
- 'technitium_roles'
grant_types:
- 'authorization_code'
response_types:
- 'code'
access_token_signed_response_alg: 'none'
userinfo_signed_response_alg: 'none'
token_endpoint_auth_method: 'client_secret_post'Configuration Escape Hatch
Potential Escape Hatch Configuration Required
Unfortunately at the time of writing this integration this client does not support OpenID Connect 1.0. Fortunately Authelia has implemented an escape hatch that works for most clients which don't properly support OpenID Connect 1.0. This requires additional configuration to that which is described above. You can read more about this in the OpenID Connect 1.0 Claims Guide.
Clients are required to operate under the assumption that claims requested by scope values are available by using the Access Token (the scope is granted and issued to the Access Token) at the UserInfo Endpoint as described by 5.4. Requesting Claims using Scope Values with the exception of an Implicit Flow that does not return an Access Token, or explicitly request them via the claims parameter as described by 5.5. Requesting Claims using the "claims" Request Parameter .
The requirement to use this option is also often a clear indication the client also ignores the
claims stability requirements
which only allows clients to anchor accounts via the sub and iss claims. This requirement
is strictly required by the specification.
Both of these elements are clear indications the client does not properly support OpenID Connect 1.0 and is not conformant.
The following is an example of adaptation to the above configuration that works around the fact this client does not support OpenID Connect 1.0:
identity_providers:
oidc:
claims_policies:
technitium:
id_token: ['groups']
clients:
- client_id: 'technitium'
claims_policy: 'technitium'Application
To configure Technitium DNS Server to use Authelia as an OpenID Connect 1.0 Provider:
- Sign in to the Technitium web console with a local administrator account (keep one for break-glass).
- Go to Administration → Sessions → Single Sign-On (SSO) and enable it.
- Configure:
- Metadata Address:
https://auth.example.com/.well-known/openid-configuration - Client ID:
technitium - Client Secret: the secret you generated
- Scopes:
openid,profile,email,groups,technitium_roles
- Metadata Address:
- Group Map: add a mapping — Remote Group
dns-admins→ Local GroupAdministrators. - Enable Allow New User Sign Up and Allow Sign Up Only For Mapped Users (so only members of a mapped group are auto-provisioned).
- Save Config (Technitium restarts its web service automatically).
The redirect URI Technitium uses is https://<your-console-host>/sso/callback — it is shown on the SSO settings page; ensure it matches the redirect_uris in the Authelia client.
Back-channel name resolution (common pitfall)
Technitium DNS Server resolves its own outbound requests (the OIDC discovery, token, and JWKS back-channel) using its own DNS engine, not the operating system’s /etc/hosts or stub resolver. If your Authelia URL (auth.example.com) is internal-only (split-horizon / no public record), Technitium will report “Failed to reach SSO provider” even though curl from the same host succeeds.
Fix: make the Authelia hostname resolvable by Technitium itself — e.g. add an internal authoritative record for auth.example.com on the Technitium server (or via its configured forwarder/conditional path), and confirm with dig +short @127.0.0.1 auth.example.com on the Technitium host returning the correct internal IP. Also ensure Technitium can reach the Authelia endpoint on TCP 443.