Active Directory Connector

The Active Directory connector enables user authentication against a Microsoft Active Directory or Windows Server domain. When configured, employees can log in to the captive portal and WPA2-Enterprise enrolment flows using their existing Windows domain credentials — no separate Kiwire password required. The connector performs an LDAP bind against the domain controller to validate credentials and retrieve user attributes.

'alt' => 'Dashboard overview', 'caption' => 'The default Kiwire dashboard layout', 'screenshot' => true, 'class' => '', ]) Drop images into: public/assets/img/docs/{page}/{filename} --}}

Image not uploaded yet public/assets/img/docs/connector-ad/overview.png

Use Cases

• Corporate WiFi login — employees authenticate to the captive portal or WPA2-Enterprise SSID with their username@domain.com Windows credentials
• Auto-provisioning — new employees are automatically created as Kiwire users on first successful AD authentication, without admin action
• Attribute-driven policy — AD attributes like department or employeeType are mapped to Kiwire fields and can drive zone assignment or profile selection
• Multi-domain support — configure multiple AD connector instances for different Windows domains within the same tenant

Configuration Fields

Field	Description
name	Instance label to distinguish this AD connector from others (e.g., HQ Domain, Branch Office AD)
is_active	Enable or disable this connector instance without losing configuration
domain_controller	IP address or fully-qualified hostname of the domain controller (e.g., 192.168.1.10 or dc01.corp.example.com). For redundancy, you can specify a secondary DC separated by a comma.
account_suffix	Domain suffix appended to the username entered by the user when performing the LDAP bind (e.g., @corp.example.com). Users type only their short username; the suffix is added automatically.
base_dn	The LDAP base distinguished name — the root of the directory tree from which Kiwire searches for user objects (e.g., DC=corp,DC=example,DC=com)
admin_username	UPN of the service account used to bind to the directory for user lookup (e.g., svc-kiwire@corp.example.com). This account needs read-only access to the relevant OU — no elevated privileges are required.
admin_password	Password of the service account. Stored encrypted at rest using AES-256. Never logged or displayed after saving.
port	LDAP port number. Default: 389 for standard LDAP, 636 for LDAPS (encrypted).
use_ssl	Enable LDAPS (LDAP over SSL/TLS). Requires a valid certificate on the domain controller. Strongly recommended for production environments.

Attribute Mapping

The attribute mapping table tells Kiwire which AD attributes to read and store in the Kiwire user record when a user authenticates. Configure the mappings in the Advanced Configuration section of the connector form.

AD Attribute	Kiwire Field	Notes
mail	email_address	Recommended — used for email OTP and notifications
displayName	fullname	User's full display name
telephoneNumber	phone_number	Used for SMS OTP if SMS connector is active
sAMAccountName	username	Short Windows username (without domain suffix)
department	department	Can drive zone or profile auto-assignment rules
employeeID	employee_id	Corporate employee ID for cross-system reference
company	company	Useful for multi-company tenants

Testing the Connection

After saving the connector configuration, click Test Connection to verify that Kiwire can reach the domain controller and bind with the service account. The test performs a real LDAP bind — if the bind succeeds, a success banner is displayed with the number of users found in the base_dn scope.

You can also perform a User Lookup Test by entering a real username and password. This simulates the exact authentication path a user would take through the captive portal or enterprise journey, confirming that end-to-end authentication works before enabling the connector for production.

User Auto-Provisioning

When allow_create_account is enabled on the linked Enterprise Login Method or captive portal login method, Kiwire automatically creates a Kiwire user account the first time an AD user successfully authenticates. The new account is populated using the configured attribute mapping. Subsequent logins update the mapped attributes to reflect any changes in AD (e.g., a name change or new department).

If auto_activate is also enabled, the new account is immediately active and the user can connect without waiting for admin approval. Disable auto_activate in environments where new accounts require review before being granted WiFi access.

Multiple Instances

You can configure multiple Active Directory connector instances to support different Windows domains. Each instance is independent — separate domain controller, service account, base DN, and attribute mappings. Assign each instance to a different login method configuration so the correct domain is used for each SSID or journey.

Required Permissions

view-connector-ad · edit-connector-ad