A park has to go on the WiFi network real name certification system, and discussions tend to focus on project development."Which one?""Could you confirm it with text or scan?"These are obvious questions. It is only at the implementation stage that it is not the platform itself that takes time to find out, but rather a bunch of pre-issues that nobody ever talks about in the programme review process. That's what this article says.——Those are..."The system hasn't started yet."I should have thought about something before.
Where's the account number? Who's gonna keep it?
The core of the authenticated title is"Authentication Subject"The problem is that these account numbers are in different systems, some of which are old LDAPs deployed 10 years ago, some of which are sub-watches from the ERP module or simply Excel.
The WiFi network real name authentication system is to be connected, which means that the account list will be retrieved from these data sources and it will be synchronized in real time.——The entry-level certification and the separation from service is automatically disabled. It sounds simple, with many problems when landing: LDAP versions are too old to support TLS; ERP interfaces charge fees; Excel forms are not maintained and there is a lot of data on separating staff. If these issues are not clearly identified at the time of setting up, then the implementation phase will be followed by a coordinated data source, which will result in a direct one month extension of the project cycle.
There's a kind of scene that gets much more complicated.——Outsourcing staff, visitors, casual workers. These people are not in the official account system, but do need to be online.
Did Tatsuo comb it?
The way WiFi network real name certification systems are deployed depends directly on network traffic. Mainly, there are bypass modes (a certified server attached to the core switch with flow through authentication judgement) and serial models (NATSHEL_AUTH_GATEWAY direct ahead of export route). Both types of engineering vary widely, and compatibility requirements for existing networks differ.
A common problem is that many small and medium parks have supplied suppliers with web-based pamphlet maps when they are set up several years ago, which is not the same as the current situation. One building has added APs, some links have been changed, but the pamphage has not been updated. The supplier has followed the old scheme and only discovered at the site that there are no spare ports for the core switchboard or that the bandwidth of the export has been fully absorbed by other operations, and the authentication traffic is simply uninhibited.
Another problem is the multi-AP mix of manufacturers. Many parks now run two or three branded wireless equipment, some of which were bought a few years ago, and others of thin AP+AC controls for nearly two years. To be able to take over these devices in uniform, WiFi's network real name certification system must confirm the compatibility of authentication protocols on a case-by-case basis. The 802.1X protocol is theoretically common, but there are differences in the details of the implementation between different manufacturers, especially with regard to the parameters of certification time-consuming, heavy-certification strategies, and without alignment, Wi-Fi will have an incredible loss or duplicated certificate page.
Have you ever touched the log retention requirements?
Another core value of the real name certification system is the retention of logs——Who's using the account number and the AP at what time, and who's visiting which IPs. This is a compliance requirement for cyber-security and telecommunications regulations, and it's a basis for retroactive ex post facto activity. But many projects have not been carefully counted in their project development phase.
A park with 500 co-users, the daily amount of log data generated is probably at several GB levels. If you want to save six months, the storage space is around 1 TB. Where do these data exist? Local servers? Clouds? Do not need encryption? Is there an external audit requirement? These questions are not confirmed in advance, and when you go online, it will be found that storage resources are not available or that the data format does not match the compliance auditing system.
And one more detail: the logbook."Real identity."Where do you come from? If the authentication is a mobile number, there's only a cell phone number in the log, no ID number, and it's not possible to get back to the authorities. This requires clear communication with local supervision in advance, and no default."Just have the certification."。
How do you handle the user who failed authentication?
The question sounds very marginal, but it's actually one of the highest numbers on the manifest. Cell phones changed, accounts locked, systems not synchronised to new employees' data.……Various reasons lead to user certification failure and then to IT.
Before WiFi's online real name authentication system, the IT team needs to think about a few things: which channel does the failed certification user go to file? Mailing, working or going straight to the front desk? What is the number of SLA processing mechanisms (e.g. no physical authentication for a screen-laying device in a conference room)? If these processes are not designed, they will be flooded on the first day of the access and eventually become"The certification system is annoying."The end.
How much did the terminal compatibility test do?
Different operating systems, different versions of equipment, and different ways to respond to authentication behaviour. iOSs will eject a small built-in window for the user to complete certification when connected to WiFi that requires authentication; some versions of Andre will detect automatic post Portal browsers, some of which are not; old Windows will fail silently if the certificate chain is incomplete when using 802.1X authentications, as the user sees."I'm connected to WiFi, but I can't get on the net."。
The terminal compatibility test should be initiated at the system selection stage, rather than waiting for the contract to be signed and the equipment arrived. It is recommended that a list of terminals be collected at the time of the project, covering the distribution of the operating systems version, and then that suppliers be asked to provide certified success data for these terminals or run it through the pilot environment. Non-temporal devices such as old industrial terminals, special hardware, are better marked, with many real name certification platforms implicitly not supporting the capture of this type of device by the browser Captive Portal.
Did the transport team get into the selection process?
The last question may be the most easily overlooked: is the team responsible for follow-up on the feeder a system? Many times in the decision chain are procurement departments or management panels, and technical operators only come into contact with the system for the first time during implementation. When they find out that the operating logic of managing backstage is completely different from their own habits, or that a key function requires additional authority to use it, there is no way back.
The WiFi network real-name certification system is an infrastructure that requires long-term security, not to buy it and put it on the table. The familiarity with the system and its adaptability to day-to-day operating interfaces directly influences whether the system can really run. Their inclusion in selection reviews and their prior testing of Demo is a useful way to reduce late friction, but few projects do.
Thinking about these issues before going online is not to make the project more complex, but to avoid remedying them after they have already started. The cost of remediation is always higher than that planned in advance.