One of the IT executives told me that they didn't work very well after they got into the certification system.——The employee was too busy to use it, and then he simply bypassed the authentication direct router AP. What's the problem? He used a way of certifying his own account number. I said your company had an AD domain. Why not use an AD area account?
Enterprise deploymentNetwork access certification systemThe LDAP and AD domain interface is difficult, simple or not. The key is that you do not have a stand-alone certification system; rather, you make the certification system part of the enterprise’s current identity management system. This positioning is clear, and the configuration behind it is in the direction of direction.
Why do you have to connect with AD or LDAP?
Businesses do it in the AD domain or LDAP.Network access certification systemThe user management is essentially a unified identity management system.——If the network access certification system is able to interface with this identity system, it means that when an employee enters a job, IT creates an account number in AD and WiFi automatically synchronizes the entry number; when an employee leaves, it disables the account number in AD and the WiFi authentication system without repeating it in two systems.
This value is not very significant, but it is the basis for network security control. If WiFi certification system does not interface with AD domain, there is a time difference: on the day of the employee ' s departure, the AD account number is disabled, but if WiFi certification system has his account number, this person would theoretically be connected to WiFi into the enterprise intranet.
The other real value is password harmonization. A worker does not need to write two sets of passwords, logs WiFi using the AD password, drops it directly from IT to replace the AD password, and does not need to contact the administrator of the WiFi authentication system for processing it alone. The easier the user is, the less resistance the policy will impose, which is a safety bottom logic.
Rationale for LDAP docking
LDAP (LightWeight Access Protocol) is a directory service protocol, and the AD domain is based on LDAP. The authentication system interfaces with LDAP, which means that the certification system is an LDAP client, initiating queries to the domain controller and asking questions"This account number and password are in A.D."Domain controller answer."Yes."or"Yes", the certification system determines whether to release it on the basis of the answer.
The process is simple, but there are several parameters that cannot be used: address and port of the LDAP server, Base DN (directorial path), manager binds DN and password, user search filter conditions. These parameters are filled wrongly, authentication will not work.
The LDAP server is usually an IP or domain name for the domain controller, port defaults 389 and SSL is used 636. Base DN is a root node path for the AD directory tree, for example"DC=company,DC=com". The administrator binds the DN to an AD account with directory query privileges, usually a dedicated service account built by the IT administrator and does not recommend using the domain administrator account. Search filter conditions determine which user objects are searched, usually in AD object classes"person", the filtering condition is not correctly written, and the computer accounts, the group accounts, are all identified and authentication is disrupted.
Two modes of NATSHEL_BRAND platform docking AD domain
The NATSHEL_BRAND unified authentication platform supports two AD domain docking models: real-time query and synchronization.
In real-time query mode, after user authentication requests arrive in the authentication system, the system initiates a LDAP query in real time to the AD domain controller to verify that the account number password is correct. The benefit of this approach is that the account changes (new, disabled, password modifications) in AD are effective immediately and do not need to wait for synchronisation. The bad news is that each authentication requires an AD, which will slow down if it has insufficient or high network delay control performance.
In synchronization mode, the authentication system regularly pulls user lists and account status from the AD domain to local databases. The benefits of this approach are: certification is fast and does not rely on real-time performance from AD domain controls; the bad news is that there are delays in changing accounts, and if the AD account is disabled immediately after an employee leaves but the sync is not complete, the employee can also authenticate with old accounts within this time window.
In actual projects, most businesses use synchronization.——The risk of delayed separation is largely manageable by setting a synchronization interval of one to five minutes, but the real-time model is more insuranceable if enterprises have special security compliance requirements, such as financial or government industry.
The logic of matching company micro-letters, nails, flybooks.
In addition to the AD domain, modern enterprises are increasingly using business micro-letters, nails and flybooks as office entry points.Network access certification systemThe links are different from the AD domain, but the core line is consistent: staff have to log WiFi with their existing office account numbers without additional numbering.
The process for business micro-credit authentication is: users select on the authentication page"Enterprise Micro-Linking", the system guides users to the enterprise micromail authorization page, the user completes the authorization in the micromail, and the authentication system gets a certificate of authority and goes to the company's micro-letter backoffice for validation and confirmation that it is a real employee. The process user only needs to check in the micromail and not enter any account password.
The same logic for authentication of nails and flybooks is the OAuth 2.0 authorization process. There is a common premise for both docking: an enterprise has already started to run an enterprise version of its micro-letter, nail or flybook, and managers have opened API privileges to certification systems at backstage. If the business uses personal or free versions, there are restrictions on the interface, which must be confirmed in advance at the programme stage.
The NATSHEL_BRAND platform also supports the interface between business micro-letters, nails, flybooks, and enterprises can choose the corresponding authentication method based on the office packages actually used. If an enterprise uses a variety of office tools (e.g. flybooks, market nails), it can be equipped with multiple docking schemes in its certification system, with employees from different sectors using their own office tool account numbers to access WiFi, which is managed centrally at backstage.
Third-party data source interface: the most flexible but complex to implement
Some enterprises do not have identity data in the AD domain, nor in their micro-letters, but rather in operational systems such as hospital HIS, school teaching systems, factory MES. The user data for these systems are not."Staff account"However, these identities also require access to WiFi networks.
The third-party data source authentication for NATSHEL_BRAND is intended to address this issue.——The certification system can check with employee IDs to determine whether the identity exists or is valid, provided that the other party provides a query interface and then decides whether to release it.
This interface is most difficult to implement, because it involves interface development and data mapping between two systems. A certification system is usually required to provide standard interface specifications, and third-party system development teams are routinely engaged in docking development.
Common reasons for the failure of the match
So many positive remarks, and finally a few common pits where the docking failed.
The first is a firewall. A AD domain controller usually operates on the Intranet, and external LDAP ports 389 and 636 are not necessarily accessible. If an authentication system is deployed at cloud ends to interface with an inner network AD, it must have a LDAP port or VPN/specific line on the firewall. Some enterprise network administrators are reluctant to access this portal because of their security strategy, resulting in a failure to dock.
The second pit is the account name specification. The account name format in AD varies from one account to another, some using sAMAcaccountName to others using a userPrincial Name. The PN format of the authentication system configuration must correspond to the actual user properties in AD, otherwise querying will always be empty.
The third pit is a cryptographic strategy. ADD usually has password complexity requirements, password expiry strategies. If an employee uses the OS code for WiFi, which expires in AD, certification will fail. This is particularly easy when employees stay away from business for long periods and remain on the company web site.——Since WiFi was not used on the Intranet and did not trigger authentication, no one noticed that the password had expired until WiFi was found to be unavailable.
The LDAP and AD domain are not technically complicated, but it must be implemented in full communication with the company’s IT and network security teams, with details of network strategy, account code, password strategy identified well in advance. Otherwise, when the system is online, problems will arise one after another, and then turn back and at a much greater cost than planned earlier.