Connecting an authentication, authorization, and accounting (AAA) server to an external identity store uses two main patterns. Lightweight Directory Access Protocol (LDAP) bind-based authentication serves broadband and enterprise identity stores. Home Subscriber Server (HSS) integration over a Diameter interface serves SIM-based subscriber data. Which one applies depends on the access network, and on where the subscriber record is authoritatively managed. This guide covers both at implementation level: how bind authentication is configured and where it breaks under load, which Diameter commands carry subscriber data over SWx, the four synchronization failure modes that cause most of the trouble, and how to choose between the two.
An AAA server is almost never the first place a subscriber identity gets created. By the time the AAA is procured, the operator already has three other systems holding identity. A directory holds enterprise and staff accounts. An HSS holds SIM credentials. A business support system created the billing account before either of them. The AAA’s job is to make an authentication decision against records it does not own.
That makes integration the real implementation work. This article covers the two connection patterns most AAA deployments need LDAP bind against a directory, and Diameter against an HSS at the level of detail needed to configure them. For the full integration surface, including charging, policy, and provisioning as well as identity, see the Alepo AAA Server overview.
Why does an AAA server integrate with external identity stores?
The AAA server is a consumer of identity far more often than it is the source of truth for it. Three situations produce that arrangement, and it pays to know which one you are in before choosing a pattern.
The record predates the AAA. Enterprise and wholesale customers already exist in a corporate directory, and staff accounts exist in Active Directory or another LDAP-accessible store. Re-keying them into an AAA profile database creates a second copy that will drift.
The record is shared with other network functions. SIM credentials in an HSS serve the 4G core and the IP Multimedia Subsystem (IMS) as well as the AAA. Duplicating them means maintaining authentication material in two places – a security problem before it is an operations problem.
The record has a lifecycle the AAA does not control. Joiners, movers, and leavers are handled by identity and access management (IAM) processes wired into the directory. An AAA with its own account list will keep authenticating people who left, and that gap shows up in an audit.
Alepo’s subscriber data management page covers where subscriber records live across 4G and 5G networks. This article picks up where that stops: the wiring.
How does AAA LDAP integration work?
Integration with an LDAP directory works by asking the directory to verify the credential, rather than fetching the credential and checking it locally. The AAA performs an LDAP Bind operation using the subscriber’s identity and password, and treats a successful bind as proof the password is correct. The directory never releases the password hash. That is the security property that makes this pattern acceptable to most identity teams.
There are two shapes of it in practice.
- Direct bind constructs the user’s distinguished name (DN) from a template uid=<username>,ou=subscribers,dc=example,dc=net and binds with it immediately. It is one round trip and it is fast. It only works when every account sits in a predictable place in the tree.
- Search-then-bind authenticates first as a service account, runs a search to find the entry, then binds as the DN that search returned. It costs an extra round trip and needs a service-account credential of its own. In exchange, it survives a directory tree organized by region, business unit, or acquisition history.
A worked example
A subscriber connects to enterprise Wi-Fi and the controller sends a RADIUS Access-Request with User-Name = j.okafor@corp.example.net. The AAA strips the realm and uses j.okafor as the search term. It takes an already-bound connection from its service-account pool and searches ou=people,dc=corp,dc=example,dc=net with a filter on the uid attribute. The search returns exactly one DN.
The AAA then performs the user bind on a separate connection reserved for that purpose. Binding as the subscriber on a pooled connection would change that connection’s authorization state for whatever request uses it next. The bind succeeds. The AAA reads the group memberships on the entry, maps the network-staff group to a virtual LAN (VLAN) and a bandwidth profile from its own policy table, and returns an Access-Accept carrying those attributes. Two LDAP operations, neither of them a fresh connection setup.
Five decisions that determine whether it holds under load
Attribute mapping. Directory attributes are not RADIUS attributes. Decide which directory attribute supplies the identity, which group or role attribute drives authorization, and which attributes are AAA policy rather than directory data. Bandwidth tiers usually belong in the AAA’s policy table keyed by group, not in a custom directory attribute.
Connection handling. Opening a new TCP connection and a new service-account bind for every authentication makes the directory the bottleneck long before the AAA does. Use persistent, pooled connection sets, sized against peak authentication rate rather than average. Peak sizing is the same discipline that governs AAA capacity under traffic spikes.
Timeouts. The LDAP timeout must be shorter than the network access server (NAS) retransmit timer. Otherwise the NAS retransmits while the AAA is still waiting, and one slow directory turns into duplicated authentication load.
Transport security. A name-and-password simple bind sends the password over the connection, so it needs LDAPS or StartTLS. RFC 4513 is explicit that this mechanism is unsuitable for authentication where the connection provides no confidentiality protection, and directories are commonly configured to refuse it outright. Plan certificate trust and renewal at the same time; an expired directory certificate is an authentication outage.
Failure behavior. Decide in advance what happens when the directory is unreachable, and build for it: multiple replicas, a defined fail-open or fail-closed stance per service, and a tested fallback path. The same principle applies to device administration over TACACS+.
How does AAA HSS integration work over Diameter?
HSS integration is a different kind of connection. LDAP is a client querying a directory. Diameter is a peer relationship between two network elements, and it has to be established before any subscriber traffic flows.
Both sides exchange Capabilities-Exchange messages at connection setup, advertise the applications they support, then route by realm rather than by IP address. Transport is TCP or SCTP secured with TLS or IPsec. The peer configuration identities, realms, watchdog intervals, failover peers is deployment work that happens before the first authentication. RFC 6733 defines that base behavior; the subscriber-data interfaces themselves are 3GPP specifications.
The interface that matters most for AAA-to-HSS integration is SWx, defined in 3GPP TS 29.273 for non-3GPP access. Its command flow is small and worth learning by name.
- Multimedia-Auth-Request / Answer (MAR/MAA) retrieves authentication vectors for the subscriber. The AAA then uses them to run the Extensible Authentication Protocol (EAP) exchange — EAP-AKA or EAP-AKA′ — with the device.
- Server-Assignment-Request / Answer (SAR/SAA) registers the AAA as serving that subscriber and retrieves the subscription profile.
- Push-Profile-Request (PPR) lets the HSS push a profile change toward the AAA without being asked.
- Registration-Termination-Request (RTR) lets the HSS deregister the subscriber.
Two related interfaces carry the session side of the same flows: S6b toward the packet data network gateway (PGW) for non-3GPP access sessions, and SWm toward the evolved packet data gateway (ePDG) for untrusted access. Together they are what makes Wi-Fi offload and Wi-Fi calling work against SIM credentials.
One point causes more confusion than any other in design reviews. The AAA does not send the subscriber’s SIM key to the HSS and ask for a verdict. It requests vectors, and the cryptographic challenge-and-response happens between the AAA and the device over EAP. The HSS supplies material; the AAA runs the authentication.
Two implementation details are worth deciding early. First, error handling: Diameter distinguishes protocol-level Result-Code from application-level Experimental-Result, and “user unknown” needs to produce a different operational response than “peer unavailable.” Second, vector caching: retrieving several vectors per request reduces HSS load but means holding authentication material longer, so the cache depth is a security decision, not just a performance one.
What goes wrong when AAA and the identity store fall out of sync?
Whenever the AAA holds a local copy of identity data rather than querying on every request, that copy can be wrong. Four failure modes account for most of the trouble, none of them protocol-level.
Deprovisioning lag is the one with audit consequences. Disabling an account in the directory must reach the AAA on a defined, monitored interval, and that interval is what a review will ask about.
Identifier mismatch is the most common cause of an integration that works except for a subset of subscribers. The directory keys on uid, the HSS keys on IMSI, the business support system keys on an account number, and the NAS sends a User-Name with a realm attached. Normalization rules realm stripping, case folding, prefix handling – belong in one documented place.
Attribute drift happens when someone edits the AAA-side copy directly to fix an urgent problem. Make AAA-side identity fields read-only wherever the platform allows it.
Reconciliation is the safety net: a periodic full comparison reporting accounts present in the AAA but absent from the source. Event-driven sync is the right default; reconciliation catches the events that were dropped.
Live sessions are a separate concern. A profile change reaches a session that is already up only through Change of Authorization (CoA) the same mechanism behind real-time quota management.
Choosing between LDAP and HSS integration for AAA
The choice follows the record. Authenticate against the store that authoritatively owns the credential, and use the interface that store speaks.
| Identity store | Integration pattern | Protocol | Typical use case |
| LDAP directory | Bind-based authentication (direct or search-then-bind) | LDAP / LDAPS | Enterprise Wi-Fi, staff and administrator access, wholesale and B2B broadband accounts |
| HSS | Peer relationship with vector retrieval and profile download | Diameter (SWx, with S6b and SWm for session flows) | SIM-based authentication: Wi-Fi calling, Wi-Fi offload, converged mobile and fixed |
| SQL profile store | Query or synchronized local profile store | SQL / native | Residential broadband where the AAA holds the subscriber profile |
| Business support system (BSS) / customer relationship management (CRM) | Provisioning feed into the AAA profile store | REST API | Account creation, plan changes, suspension and restoration |
One note on 5G. In a 5G standalone core, subscriber data moves to the Unified Data Management (UDM) function, which exposes service-based interfaces over HTTP/2 rather than Diameter. An AAA integrating with a 5G core follows that pattern instead of SWx, and the two coexist for as long as 4G and 5G do. Scope it as a separate interface, not as a variant of the HSS work.
Most converged operators run more than one of these at once, and that is the expected outcome. One AAA platform commonly authenticates residential fiber from a local profile store, enterprise accounts against LDAP, and Wi-Fi calling against the HSS over SWx three patterns, one policy engine, one set of accounting records. Alepo AAA Server terminates RADIUS, Diameter, and TACACS+ on a single stack for exactly that reason.
Plan the effort accordingly. LDAP integration is usually days of configuration and mapping work. HSS integration is closer to a project than a settings change.
Planning your AAA identity store integration
Start by writing down, for each subscriber population you serve, which system owns the credential and which interface that system speaks. Five columns are enough: subscriber population, owning system, interface, identifier normalization rule, and what happens when the store is unreachable. That inventory is usually shorter than teams expect, and it decides the integration work.
What determines whether the result holds up in production is the unglamorous part connection pooling, timeout budgets, identifier normalization, and a written answer for what happens when the store is unreachable. Those four are also the honest answer to the performance question every architect asks: an AAA platform is only as fast as the slowest identity lookup inside its authentication path.
Alepo AAA Server integrates with the HSS over Diameter SWx, with the PGW over S6b and the ePDG over SWm, with LDAP and SQL profile stores, and with BSS and CRM systems over REST APIs. It supports multi-realm and multi-domain operation for operators running several identity domains on one platform. Because these lookups sit inside the authentication path, headroom matters: the platform is built on real-time database replication with stateless session storage backed by database persistence, with N+1 and N+N redundancy, and is engineered for 99.999% availability.
Scoping an LDAP or HSS integration? Book a demo we will map them to an integration pattern.
Frequently asked questions
Q1. How do I connect an AAA server to LDAP?
Through LDAP bind-based authentication. The AAA either constructs the user’s distinguished name from a template and binds directly, or binds as a service account, searches for the entry, and then binds as the DN it found. A successful bind proves the password is correct without the directory ever releasing it.
Q2. How does AAA integrate with an HSS?
Over a Diameter interface, principally SWx as defined in 3GPP TS 29.273. The AAA establishes a Diameter peer relationship with the HSS, then uses Multimedia-Auth-Request to retrieve authentication vectors and Server-Assignment-Request to register and download the subscription profile.
Q3. What is the difference between LDAP and HSS integration for AAA?
LDAP suits broadband, enterprise, and administrator identity stores where credentials are usernames and passwords. HSS integration is specific to SIM-based mobile subscriber data and runs over Diameter. LDAP is a client-server directory query; Diameter is a configured peer relationship between network elements.
Q4. How does LDAP bind authentication work with an AAA server?
The AAA attempts to bind to the directory using the subscriber’s credentials. If the directory accepts the bind, the credentials are valid, and the AAA proceeds to authorization — reading group or role attributes from the entry to select the policy it applies.
Q5. How do I synchronize identity data between AAA and an external store?
Event-driven synchronization from the source store is the usual default, with periodic reconciliation to catch dropped events. The parts that need explicit design are deprovisioning latency, identifier normalization across stores, and preventing direct edits to the AAA-side copy.
Q6. What protocols are involved in AAA-HSS integration?
Diameter, over 3GPP-defined interfaces. SWx carries authentication vectors and subscriber data for non-3GPP access, while S6b and SWm carry the related session flows toward the PGW and ePDG respectively.
Q7. Why would an AAA server need to integrate with an external identity store at all?
Because the subscriber record usually lives somewhere else and has a lifecycle the AAA does not control. Authenticating against the authoritative store avoids a second copy that drifts, keeps authentication material in one place, and means account deactivation takes effect without a separate AAA-side process.
Q8. How complex is integrating AAA with an existing HSS deployment?
More involved than LDAP integration. Diameter requires peer and realm configuration, transport security, and interoperability testing against the specific HSS implementation, plus a test plan covering peer failover and error conditions. Plan it as a project with the HSS vendor involved, not as a configuration change.
