Multi-branch workBusiness Wireless Network CertificationThe problem is quite different from the one-point project. One-point projects run a system in one place, multiple branches running simultaneously at N locations, with the same account strategy effective, failure affecting only locally and without global implications, so that headquarters can check it together.
The typical structure for multiple branches is: Authentication & Billing platform deployed at headquarters or on cloud ends, and local NATSHEL_AUTH_GATEWAY (NAS equipment) deployed in each branch. Staff or visitors go to WiFi on the branch link, certification requests are sent to local gateways, local gateways are directed to the status of the authentication platform at Headquarters, which accesss the site after certification has been approved. The benefit of this architecture is that accounts are managed centrally at headquarters without separate account numbers in each branch; If the network connection between headquarters and a branch is broken, access to this branch depends on the design of local cache mechanisms.
NatShell V7 Authentication & Billing supports distributional deployments, with each branch access gateway of the multi-branch to match a single authentication platform. The head office manager can see online status, certification records, and strategy configuration of all branches at the backstage without having to log separately into the management backstage of each branch. This is the most direct managerial value of this architecture.
But here's a question that needs to be thought out in advance:Can you verify the Internet locally when branch networks are out?
If the request for certification depends entirely on a headquarters response, if the branch is disconnected from its own line or VPN, it will not be possible to access the network even if the local network is good. This issue is particularly sensitive in a scenario where the availability of the network is high, such as bank points, chains and so forth. NATSHEL_BRAD program supports local authentication caches for this scene.——The account information can be stored locally, and in the event of a headquarters loss, local authentication can still be done with the cached account data, maintaining basic Internet access services, and synchronizing when the dedicated line is restored.
The second problem to be addressed is:How do you align the account system?
In multi-branch settings, there are usually two types of accounts. One is a group with a unified AD domain or HR system where all branch staff account numbers are maintained, V7 matches are certified directly by the group account system and branches do not need to maintain their own accounts. This is the ideal state, which is least costly to maintain.
The other is that the group has no uniform account system, with each branch having its own local IT and its various accounts. In this case, the multiproject management functionality of V7 can be set up in the same system (one item per branch), with headquarters managers having global authority and branches only looking at their own items. Accounts are maintained separately, but the management interface is harmonized, so the strategy template can be reused between projects without having to configure each branch from zero.
The third problem to be addressed is:How can the Internet strategy be harmonized, but allowing for branch differences?
Group level basic strategies (e.g. visitors can only go to the public network, bandwidth ceilings, log retention requirements) need to be pushed down uniformly and not be changed by branches themselves.——A branch has a VIP visitor area, which requires higher bandwidth ceilings; a branch has a special operations system and staff require additional inside-network access."Base strategy succession + branch-level differential configuration"and the tier mechanism.
NATSHEL_BRANDV7 multi-level competency management and regional and project management cross-functionality can support this differentiated strategy. Headquarters sets the basic strategy as a template, which allows branches to adjust some of their parameters within their purview and for those that are beyond their authority to be approved by headquarters.
There is also an implementation difficulty that has often been underestimated in multi-branch settings: the network equipment models and versions of each branch are inconsistent. Some have been split into ACs, others H3Cs, or older ones. The certification system will be used to match the equipment of different manufacturers, and will confirm the compatibility of the Portal version of each device and the consistency of RADIFUS interface configurations. However, it would be preferable to have the equipment lists of each branch prepared prior to implementation and to make an earlier compatibility confirmation, so that a model could not be detected until it was online.
On cloud-side deployment or local deployment: if there are multiple and wide branches, the authentication platform is usually easier to manage on cloud-side, without requiring separate resources for each branch in the headquarters office and facilitating horizontal expansion. NATSHEL_BRAND V7 supports cloud-side deployment and local deployment, which depends on the group ' s IT security strategy——Some groups explicitly require that core systems be deployed locally without clouding.
Last practical point of judgement: Multi-partitionBusiness Wireless Network CertificationThe project, which is a much more complex implementation phase than the single-point project, is primarily a high cost of coordination. It requires coordination between headquarters IT, branches IT, network operators (special line configuration), certification system programmers and multiple combinations to move forward.——Not because of conservativeness, because when you push multiple branches together, and if there's a problem at one point, you don't know which branch is wrong or the whole picture, the time for screening is multiplied. The pilot phase has been validated, and the subsequent branch copying configuration is faster.