Chapter Contents
Authentication domains determine how Elektron will authenticate users. You can create entries for multiple domains, and assign a different authentication method (such as LDAP or ODBC) to each domain. For instance, if you create a authentication domain for “example.com”, all users attempting to login with an account ending in “@example.com” will be authenticated through the method configured for the example.com domain. You may configure an unlimited number of authentication domains.
There is always at least one domain configured, the “Default Authentication Domain”. This defines the catch-all authentication method that is triggered when a user attempts to log in with a domain that does not have a corresponding entry in your authentication domains table, and when a user attempts to log in with a username that has no domain.
Authentication domains can be useful even if you have only one domain. For instance, if your default authentication domain is configured to use Windows Accounts and want to add a temporary guest account for wireless authentication only, adding a new authentication domain will allow you to do this without touching your active directory. To do this, add a new authentication domain for guests only (e.g., “guest.example.com” if your domain is “example.com”). Set the guest authentication domain to use Elektron accounts, and create an Elektron account for each of your guest users. You guests will be able to log in to your network as “user@guest.example.com”, while your regular network users will be able to continue to log in with their usual “user@example.com”, “EXAMPLE\user”, or simply as “user”.
Authentication Domain Settings
Every authentication domain has three settings in common:
Domain This is the domain or domains that are to be authenticated. This can be a single domain (“example.com”), or a comma-separated list of multiple domains (“foo.com,bar.com”). Elektron supports both internet style domains (“user@example.com”) and Windows style domains (“EXAMPLE\user”).
Authenticate Using This selects the method used to authenticate users.
Strip Domain Before Authenticating With this option selected, Elektron will strip the domain from the username before forwarding the authentication request. For instance, “user@example.com” would be authenticated as “user”. This is useful for authentication methods that are not expecting the domain to be included.
Authentication Methods
The following authentication methods are available:
Elektron Accounts You may configure Elektron to maintain its own internal database of usernames and passwords. This allows you to keep your wireless network logins separate from you other network credentials.
LDAP This method allows you to verify user identities using an LDAP directory. This is helpful when your network authentication infrastructure is based on an existing directory. However, it may limit the authentication options available to users. For instance, MS-CHAPv2 authentication is unavailable when authenticating against an LDAP directory. Consult the chart below for detailed information on which authentication methods are supported by each provider. If you are hosting your authentication information in Active Directory or Open Directory, selecting Windows or Mac OS X accounts for authentication will give you more authentication options than LDAP.
RADIUS With this option selected, Elektron will pass all authentication requests on to another RADIUS server. With this option you can create an authentication hierarchy consisting of multiple Elektron servers, or use Elektron to authenticate Wi-Fi users against a legacy RADIUS server. If your organization has an existing RADIUS server that supports basic authentication methods like PAP but not tunnelled Wi-Fi methods like PEAP and TTLS, this option allows you to use Elektron as a front end to your older RADIUS server.
ODBC The ODBC authentication method stores user credentials in an ODBC-compliant SQL database. This allows you to store your credentials in a scalable database that can integrate with other services on your network and to manage user accounts using your own tools.
Windows Accounts This option is available for Elektron servers installed on Windows systems. With this option selected, Elektron will verify usernames and passwords using the system accounts from the server on which it is installed. If Elektron is installed on an Active Directory controller, this includes the Active Directory accounts.
Mac OS X Directory Services This option is available for Elektron servers installed on Mac OS X systems. This authentication method will verify usernames and passwords against the system accounts on the machine on which Elektron is installed. If Elektron is installed on an Open Directory server, this includes the accounts in the Open Directory.
Script With script authentication, Elektron will execute an external script or application to authenticate a user. Based on the result of the script, the use will be granted or denied access.
Supported Authentication Protocols
This table describes which authentication protocols are supported by each authentication method.
| PAP | CHAP | MS-CHAP | MS-CHAPv2 | |
|---|---|---|---|---|
| Elektron Accounts | • | • | • | • |
| LDAP | • | |||
| ODBC | • | • | • | • |
| RADIUS | • | • | • | • |
| Script | • | |||
| Mac OS X Accounts | • | • | ||
| Windows Accounts | • | • |
For tunnelling protocols like PEAP and TTLS, this table refers to the inner authentication method supported by Elektron. The majority of Wi-Fi user logins are made using PAP or MS-CHAP-V2 authentication, which are the default inner authentication methods for most client implementations of TTLS and PEAP, respectively.
EAP-TLS authentication is not handled by the method selected in the authentication pane. Instead, it is handled using the certificate services provided by the operating system.