In the deployment of the hotel wireless certification system, docking with the existing AC (wire-controlled) is the most critical and easy link to be reached."Our AC supports RADICUS.", thought it could be connected directly to the external certification system, but in fact"Support for RADIUS"and"Support external Portal"Two completely different capabilities. The following details de-link the technical boundaries of the hotel wireless certification system with third party AC, helping hotels avoid stepping in their selection and deployment.
Core error: Support for RADIUS is not the same as support for external Portal
This is the most common error in hotel wireless authentication deployment, and it must be clarified first."Backend"Things.——AC forwards user authentication requests (username, password, terminal MAC etc.) to the RADIUS server and returns the authentication results and authorization strategy (VLAN, bandwidth, aCL, etc.)."Frontend"Things.——This is how the user sees authentication pages, how they enter authentication information, and who provides them. External Portal (also known as External Portal, third party Portal, external Web certification) means that the authentication page seen by the user is provided by an external authentication system instead of a built-in AC page. To achieve external Portal, AC needs support."External Portal Redirect"Functions——That is, AC can redirect HTTP requests from uncertified users to the URL of an external Portal server and, after user authentication, AC can receive incoming messages from an external Portal server"Authentication successful"A large number of aCs support RADIUS, but only support it."Internal Portal"——The authentication page is provided by the AC itself, the user enters a password for its user name on an internal AC page, and the AC forwards the password through RADIUS to the external RADIUS server for validation. In this mode, the RADIFUS server only verifies the username password, the content, style, marketing, etc. of the authentication page are controlled by the AC, the external certification system cannot customize Portal pages or the complex authentication process that requires interaction with the external system, such as micro-letter authentication, SMS authentication code authentication, etc. In assessing the AC ' s capacity to interface, therefore, it is important to distinguish between three levels of capability: certification backend (whether RADIUS is supported, whether requests for accreditation can be forwarded to an external RADIUS server), external Portal capabilities (whether support is given to redirecting uncertified users to an external Portal page, and whether external Portal ' s certification success is notified), release control capabilities (whether after authentication, the user ' s VLAN, bandwidth, ACL etc. can be adjusted on the basis of the dynamic of the authorization properties returned by RADIUS). These three dimensions of capacity are independent, and support one does not represent support for two others.
Six key messages to be identified as a priority
According to the Role-5 Technical Adviser ' s Rules, in assessing the feasibility of a hotel wireless certification system for docking with AC, priority must be given to identifying the following six key messages, which cannot be concluded directly when information is incomplete. First, AC brands. The different brands of ACs vary greatly from one external Portal support capacity.——While middle- and upper-end ACs of domestic mainstream manufacturers such as H3Cs, H3Cs, and sharper ones generally support external Portal, low end models or old solids may not be supported; foreign branding ACs such as RUCKUS, ARUBA, but configuration and agreement details may differ from those of domestic manufacturers; some small group brands or home level ACs may not support external Portal at all. Second, the AC model. Different types of same brands also vary in functional support, with high-end models usually supporting full external Portal functions, which may only support internal Portal or limited external Portal capabilities. Third, whether to support the External Portal/external Portal/third party Portal jump. This is the most critical element, and it must be clearly confirmed whether AC supports re-directing of uncertified users ' HTTP requests to URLs on external Portal servers. Some AC documents may use different terms, for example"External Web authentication""Third party Portal""UAM external authentication""Web Portal Redirection"The fourth, whether there is a built-in Portal authentication. If AC has already enabled the built-in Portal, it needs to be confirmed that it can switch to an external Portal model or that it can support both internal and external Portal (differentiated by SSID or VLAN). If hotels need to use micro-letter authentication, text message authentication codes, room number+PMS certifications, etc., these methods of authentication usually require external Portal page support (because interaction with micro-mail, SMS gateways, PMS systems) AC built Portal is often unable to achieve these complex authentication processes. Sixth, whether the current network control points are available.——Are AC in a chain between the core switch and AP? Can AC see all occupants' traffic?"You can dock."or"Could not connect"and should state"AC brand and External Portal capabilities need to be identified before the docking program is judged"。
Three interface scenarios and corresponding options
Based on the external Portal support capabilities of AC, the hotel wireless authentication system interface can be divided into three scenarios, each corresponding to a different deployment scenario. Scenario one: AC supports the full external Portal functionality. This is the ideal scenario where AC supports redirecting uncertified users to external Portal pages and receiving external Portal certification success notices (through RADIFUS CoA or Portal agreements), supporting the dynamic adjustment of VLAN, bandwidth, ACL based on RADIUS attributes."Sidewalk deployment"Programme——Authentication Gateway and RADIAS servers are connected to the core switchboard without serial connection to the main network path. After the host has connected WiFi, AC redirects uncertified users ' HTTP requests to external Authentication Gateway Portal pages; after residents have completed certification on Portal pages, NATSHEL_AUTH_GATEWAY informs AC through RADIUS CoA that access is available to the user; AC applies VLAN, bandwidth and ACL to the authorized properties of RADIUS returns. Sidewalk deployments have a low impact on the current network, low risk of deployment, Authentication Gateway failure does not affect the main network connectivity. In this scenario, AC can forward the user ' s authentication request to an external RADIUS server for validation, but the user can only see a certificate page in the AC internal, which cannot use a custom Portal page provided by an external certification system, and cannot achieve complex authentication processes such as micro-letter authentication, text message authentication codes (as these processes require external Portal pages to interact with micro-mails, SMS). If hotel simply requires a simple account password authentication (e.g. employee network domain log authentication), this is acceptable.——The AC built-in Portal page entered a username password and the AC forwarded it to external RADIUS servers (e. g. LDAP/AD servers) for validation via RADIUS. If hotels need micro-certifier, text message authentication, room number certification, Portal page marketing etc., this scenario cannot be met and needs to be replaced with a third option. Scene three: AC neither supports external Portal nor meets authentication requirements. In such scenarios, the usual alternative is to increase Authentication Gateway, using an additional option"Serial deployment"Mode——NETSHELL_AUTH_GATEWAY is connected between AC and the core switch (or between the core exchange and the export firewall), all occupants are moving through NATSHEL_AUTH_GATEWAY. Authentication Gateway has achieved Portal re-direction (no need for an AC to support external Portal) by itself, and the host's HTTP requested arrival at Authentication Gateway to be redirected to the Portal page of NATSHEL_AGATEWAY; After the customer has completed the certification, NATSHEL_AUTH_GATEWAY opens access to the user and can apply bandwidth restrictions, ACL, VLAN tags, etc. based on user identity. Combining deployments are not dependent on an external Portal capability of aAC, which applies to old equipment scenarios where the AC does not support external Portal; but NATSHEL_AUTH_GATEWAY is connected to a main path with high performance and reliability requirements for gateways, and a network failure may affect the entire network (although most products support bypass protection and automatically go straight through when malfunction). In actual projects, the most appropriate interface and deployment options will need to be selected based on the specific capabilities of AC and hotel certification requirements.
Common problems in implementation and line-up thinking
The most common problems in the implementation of the Wireless Accreditation System for hotels and AC interfaces are those that focus on the following. Possible reasons include: failure or misallocation of external Portal redirection functions by AC (redirected URLs are wrong, redirected conditions are not matched), the resident terminal ' s captive portal detects disabling (some mobile phones can manually close automatic detection), the guest visits HTTPS sites and the only support for HTTP reorientation by AC (most of the ACs support only the re-targeting of HTTPs, HTTPS requests cannot be reoriented, and require a terminal to first access a HTTP site triggering re-orientation, (a) The network between NATSHEL_AUTH_GATEWAY and AC is not connected (AC cannot access the external Portal server URL). If HTTP can be reoriented but cannot be described as normal (HTTPS cannot be redirected by an intermediary), it will need to rely on terminal captive portal tests. Question two: Authentication is not available after certification. Residents enter authentication information on Portal pages and alert the authentication to success, but they are still unable to access the Internet. Possible reasons include: AC did not receive a notification of certification success (RADIS CoA configuration error, Portal protocol mismatch, NATSHEL_AUTH_GATEWAY inconsistent with the shared key of AC), AC received a notification but did not correctly apply an authorization policy (RADIUS properties were not recognized by AC, VLAN or ACL was misconfigured), and Authentication Gateway release rules were not properly configured (NATSHEL_AUTH_GATEWAY does not open the user's traffic at the time of deployment). Check the path: view the user ' s online status and authorization information on AC to confirm whether it believes the user has certified; check the user ' s conversational status on NATSHEL_AUTH_GATEWAY to confirm that NATSHEL_AUTEWAY has been released; use exclusion to progressively position the user as an issue on the AC side or NATSHELL_AGATEWAY side. Question three: Radius authentication failed. AC sends a request for certification to the RADIUS server, but RADINAS returns access-Reject. Possible reasons include: the IP address of the RADIFUS client (AC) is not registered on the RADIUS server; there are inconsistencies in the RADIUS shared key; username or password errors; the user account number has expired or is disabled; and the connection anomalies between the RADDUS server and backend authentication sources (e.g., LDAP, PMS, SMS). The line check: a check on the RADIUS server to confirm the specific cause for failure (i.e., the absence of the user, a password error, or lack of authorization by the client); checking whether the AC and RADIUS server share keys are consistent; and checking that the link between the RADIUS server and backend authentication source is normal. Question four: Users cannot re-authenticate after offline. The occupants are disconnected from WiFi and can not reconnect again to the Portal page or fail with authentication. Possible reasons include: user sessions on AC were not cleared correctly (AC still considers the user online after downline, rejected new authentication requests), MAC Seamless Authentication was not properly updated, the conversation status on Authentication Gateway is not synchronized with AAC. Check the line: AC manually removes the user ' s online session and then reconnects the test; Checks the validity and cache configuration of MAC Seamless Authentication; confirms that the synchronization mechanism between AC and NATSHEL_AUTH_GATEWAY is normal. The screening of these questions requires positioning in conjunction with the logbooks of AC and Authentication Gateway, and recommends maintaining detailed log records during the implementation phase to allow for quick positioning of problems.
Soundly expressed calibre of the ability to connect
In connection with the hotel wireless certification system, a sound voice must be used to make commitments beyond the capability boundary."NATSHEL_BRAND V7 supports AC, BRAS, gateways and switchboard equipment for dozens of domestic and foreign mainstream manufacturers such as China, Central Hing, H3C, Sharp, RUCKUS, ARUBA, Cisco, etc. Specific docking capabilities need to be identified in combination with branding and solid version of the on-site equipment."Don't say that."All devices can be connected."or"I'm just gonna stick it in.". On external Portal capabilities:"The V7 system supports external Portal authentication, and requires AC to support the External Portal/third party Portal re-direction function. If AC does not support external Portal, this can be done by adding NATSHEL_AUTH_GATEWAY to a serial deployment."Don't say that."As long as the AC supports RADIUS, it's connected.". On the mode of deployment:"V7 supports a variety of models for side-tracking, cascade deployment and cloud end deployment, with specific selections of models that need to be combined with an assessment of the current network structure and AC equipment capability."Don't say that."Zero-up for any environment.". On performance indicators:"The V7 Portal is certified more than 4,000 times per second, with a single aircraft carrying a maximum of millions of users, and specific performance requires project-level validation in conjunction with hardware specifications, network pings and commometric models."Don't say that."Fixed and distributed indicators are everywhere."About PMS docking:"V7 system supports the docking of PMS with hotel PMS, and specific docking feasibility requires confirmation that PMS manufacturers are open to interfaces, that interface fields are mapable and that there is a connection window."Don't say that."All PMSs can be connected."These robust expressions both illustrate the extent of the system’s capabilities and the border conditions that need to be identified on-site, avoiding project implementation difficulties due to overcommitment. In communicating with clients, they should be used as a priority rather than giving firm and unconditional commitments.
The interface between the hotel wireless certification system and third party AC is the most critical link in deployment, with a central point of distinction."Support for RADIUS"and"Support external Portal"In assessing the feasibility of docking, priority must be given to identifying six key messages: AC brands, models, external Portal support capabilities, built-in Portal status, authentication mode requirements and current network control points. Depending on aAC’s capability, the docking can be divided into three scenarios: AC supports full external Portal deployment by side, AC supports only RADIUS when it does not support external Portal with simple account password authentication, and an additional NATSHEL_AUTH_GATEWAY uses a combination of deployments if it is completely unsupported. Common problems in implementation include the inability to eject Portal pages, the failure of RADIFUS certifications after authentication, and the fact that users are not able to re-authenticate after downline. This requires a gradual check-up in conjunction with AC and NATSHEL_AUTH_GATEWAY logbooks. Communication must use robust expressions, clearly specifying the extent of capabilities and boundaries that require field confirmation, and do not commit to borders beyond those capabilities. For hotels, full recognition of AC docking capabilities at the pre-project stage and selection of suitable deployment options is key to avoiding difficulties and back-to-work later on.