One of the problems with WiFi’s project is almost impossible to get around: how does WiFi certification system interface with existing identity systems? An enterprise may use AD domain for employee identification management, nails or micro-letters for corporate organization, and an independent visitors’ management system. If authentication systems fail to link these identities, the operator has to synchronize the accounts manually between multiple systems, far beyond expectations.
LDAP/AD docking practices
The WiFi authentication system and AD domain interface are the most common scenes. Staff use a local account company WiFi without having to maintain a separate password, nor do IT need to maintain two sets of accounts.
The advantage of the equipment is that it's a simple structure, with less maintenance costs for an intermediate server. But the bad side is also obvious: most network equipment supports LDAP."It works."Level, relative functional limitations——For example, search filters cannot write complex nesting conditions, user group mapping is more difficult to do and log information is often not detailed enough when checking the reasons for certification failure.
The program that is transmitted through RADIUS is much more flexible.——Checks whether the user belongs to a specific security group, checks if the account is disabled, or even sends out different network privileges strategies based on the user UU. The cost is that more servers will need to be maintained and RADIUS servers will have their own high availability.——More than a few hundred.——The RADIUS relay programme is largely followed, as the benefits of flexibility in transport cover much more than the cost of that server.
The difference between direct and synchronised docking
This is a problem that many programme documents do not specify but have a significant impact. Direct docking is the real-time search of the identification source by WiFi certification system for each authentication, without local user data being stored.
Direct dockings seem simple and elegant, but there is a fatal problem: WiFi cannot be certified in its entirety if the identity source is dead or the network is broken. If the AD server that the certification system relies on is deployed in the headquarters room, and the branch office's dedicated line is cut off, the branch staff will not even go to WiFi. This is an unacceptable risk in actual operations.
Synchronization of the docking solved this problem.——The local library contains copies of user data, even if the source system is temporarily inaccessible, and authentication is not affected. The cost is to maintain a synchronized task and consider consistency: how long can synchronous tasks be passed on to the local repository of the certification system when staff members leave and account numbers are disabled in AD? If the synchronization cycle is four hours, then separated staff members can go to WiFi before synchronizing is completed, which is a risk window that needs assessment for security management.
In actual projects, most scenarios suggest a synchronous docking mode, with the synchronization cycle controlled within 30 minutes to one hour and a buffer of some time retained locally in the certification system——For example, the account in AD is disabled and is immediately marked as uncertified locally in the authentication system.
Account conflicts requiring attention when multiple identity sources merge
Some businesses have a more complex scenario: the headquarters uses AD, but the production base uses another system; or the domestic site uses AD and overseas sites uses Azure AD. WiFi certification systems need to be linked to multiple identity sources simultaneously, and the most easy problem is account conflict.
Like what?"zhangsan"This account is available in the AD, and overseas in Azure AD, but it's actually two different people. If the authentication system does not separate the namespace, one of these two individuals may log into the WiFi section that another person should use. The process is usually done by prefixing each identity source to the certification system, for example."ad-zhangsan"and"azure-zhangsan"and decide which network privileges to send in the authentication strategy based on prefixes.
There is also a common pit: the only identification for some identity systems is not user names, but other fields——For example, AD’s sAMAcaccount Name and userPrincial Name may not be consistent or the company’s microcredit is uniquely marked by CorpID plus UserId. The field must be identified as the main key before docking, and all systems across the chain have a consistent understanding of this field. Otherwise, it will appear"The authentication server says this account does not exist, but the AD administrator says it's in the library."The bullshit.
Reciprocal feasibility assessment of cloud identity sources
An increasing number of businesses have moved their identity systems to cloudy ends, such as Azure AD, Okta, or flying book/clining structures. To interface with cloud identification sources, WiFi certification systems need to assess several technical conditions: first, is the authentication system itself publicly accessible? Many enterprise networks’ security strategies do not allow direct access to network equipment, and WiFi certification systems cannot directly communicate with API if deployed on the intranet.
A compromise solution is to deploy a local proxy server that will communicate with the cloud identity system, and WiFi certification system will interact only with the local agent. This option accommodates security strategy and functionality requirements, but an additional layer of agents has one more failure point, and the architecture needs to be designed in such a way as to identify where this proxy node should be deployed, network paths and high-availability options.
The WiFi identification system is not a big technical dilemma, but its complexity is that it is not a technical standard; it is the actual information-based status of each enterprise. It is more important to get a picture of the situation than to choose a theoretically superior interface.