Nile Access Service - Start Here
If your organization is about to deploy the Nile Access Service, or you are looking for a detailed technical overview, this section of the knowledge base is for you.
- What is the Nile Access Service?
- What is the Nile Architecture?
- Nile's layer 3 only network: Transcending VLANS
- Building a Zero Trust Campus: Zero Trust Access
- Zero Trust Access 802.1x
- Zero Trust Access: Single Sign-On (SSO)
- Zero Trust Access: MAC Authentication Bypass (MAB)
- Nile Service Block Hardware
What is the Nile Access Service?
Legacy network management is complex, reactive, and inhibits security and scalability. Nile Access Service is a cloud-native platform that simplifies connectivity, enforces zero-trust principles, and ensures optimal user experience.
Nile delivers wired and wireless connectivity as a service within a cloud-native platform. In this document, we'll explore the architecture and features of the Nile Access Service, along with its deployment model within modern enterprise networks.
A typical network consists of user and devices connecting via wired or wireless at the access layer. Upstream to the access is the core router and/or firewall which connects to the Internet. Nile focuses on providing Network as a Service for all wired and wireless users and devices.
Nile is not an MSP. We provide connectivity infrastructure in the same way Amazon, Google and Microsoft provide cloud compute. You configure the system to deliver services required, and Nile ensures the underlying infrastructure provides the necessary capacity and reliability.
The Nile Access Service is delivered by combining modern cloud architecture with fully integrated hardware. The Nile Service Block (NSB) includes switching, APs and sensors. Which have all been developed in-house, to achieve our goal of bringing an Apple-like experience to the enterprise.
There are a number of notable innovations that support the Nile Access Service;
- 'Outside-In' Approach: Nile utilizes physical and virtual sensors for proactive monitoring, ensuring consistent end-user experience and rapid issue resolution.
- Redundancy by Default: Nile's architecture prioritizes redundancy at all layers, minimizing downtime and maintaining service availability even during hardware failures.
- Layer 3, Host-based Segmentation: Nile replaces traditional VLANs with Layer 3 segmentation, enhancing security and simplifying policy management.
- Campus Zero Trust: Nile enforces granular access controls and micro-segmentation based on device identity, minimizing attack surface and lateral movement.
- Shared Responsibility: Nile's cloud-delivered model provides a clear delineation of responsibilities, simplifying operations for IT teams.
Let's explore each of these in more detail.
The 'Outside-In' Approach
Nile simplifies network management and ensures optimal user experience through proactive monitoring. We've deployed an "Outside-In" approach, utilizing wall-mounted physical WiFi sensors, Nile AP dedicated monitoring radio, and a range of virtual sensors throughout the NSB further enhancing our comprehensive data collection.
Using these sensors to construct a real-time, outside in view in three key areas; Core, Environment & Context.
Core
The sensors monitoring the Core are continuously monitoring critical services;
- Network Availability: Validates NSB availability to end users and devices
- Coverage: Validating if the sensor can hear at least on AP with -67dm or better signal (Video conferencing quality signal)
- Capacity: Validates if the committed number of AP's on a floor are functioning or not
Designing our own hardware means we can embed physical and virtual sensors through out the NSB in order to gather the deep intelligence required to deliver fully automated infrastructure.
Environment
Ensuring continuous service doesn't end at the NSB, we actively monitor power delivery, data cabling infrastructure, and the RF space for any service affecting issues in the physical Environment where Nile Access Service is deployed.
Context
The main page of the Nile Portal always displays the health of your Top 10 most used applications, DNS, DHCP and authentication services. The usage patterns for both network devices and users are also monitored for anomalous activity. Monitoring the Context of the Nile Access Service using the outside in approach delivers a detailed view of user experience.
This data-driven approach to monitoring Core, Environment, and Context underpins our industry-leading verifiable SLAs. Unlike traditional network monitoring that often relies on user-reported issues, Nile's "Outside-In" method proactively identifies and resolves potential problems before they significantly impact the end-user experience.
Additionally, Nile's reporting tools are a fundamental tool in planning future capacity and coverage with your team.
The Nile network is guaranteed to be always-on and backed financially if SLAs are not met.
Nile SLAs
Nile stands apart from traditional connectivity providers with financially backed SLAs that guarantee network reliability and a 99.5% uptime commitment. This is enabled through the Availability, Coverage, and Capacity monitoring provided by our Outside In approach.
Our proactive monitoring allows us to alert you of potential issues before they significantly impact your users. If a violation of our 99.5% SLA occurs, Nile provides financial credits, demonstrating our commitment to exceptional service. We calculate SLA compliance monthly, per building, based on the percentage of time Nile meets the above thresholds.
[INSERT IMAGE OF SLA REPORT]
[JR: I need to understand core/context in greater detail, and where it should fit in this doc?] Core: Core is basically what Nile offers, Secure Wireless and Wired connectivity as a service. Context: Context is the infrastructure that supports the Nile Access Service, these include the Internet, DHCP, DNS , Radius, device and applications
Nile's High-Availability Architecture
Nile's architecture is designed to ensure maximum uptime and minimize service disruptions. We achieve this through built-in redundancy at every layer of the Nile Service Block:
-
NSB Gateway NSB gateway is a role that is assumed by the switch that connects to the customers upstream router/firewall using OSPF to dynamically manage path failover, ensuring continuous connectivity even if a hardware component fails. Whether a large campus with Distribution switches or a remote site with only Access switching, NSB Gateway guarantees service resiliency.
-
Access: Two or more Nile Access switches are deployed per wiring closet, coupled with a "Salt & Pepper" WiFi configuration where neighboring APs are connected to different switches in the wiring closet. Should a switch fail, WiFi coverage remains unaffected, and only a subset of your wired ports on the floor are impacted. Given that the Nile Access Service does not have port level config, affected devices can be easily moved from the impacted Access Switch to a functioning AS. OSPF ensures upstream path redundancy.
This proactive focus on high availability underpins our SLAs and allows IT teams to focus on delivering an exceptional user experience instead of troubleshooting outages.
Learn more about the Nile Service Block.
Host-Based Segmentation
Nile simplifies network management and enhances security by replacing traditional VLANs with Layer 3 host-based segmentation. This approach enables granular access control, micro-segmentation, and a streamlined operational model.
-
Flexible Assignment: Nile dynamically assigns segments to devices based on MAC address and device fingerprinting. Unidentified devices can be automatically isolated or placed into a restricted "guest" segment for further review, enhancing security posture.
-
Centralized Policy Enforcement: Nile integrates with security appliances like Fortinet, Palo Alto, and cloud-based services like ZScaler, enabling centralized policy definition and enforcement based on segment membership.
-
Operational Simplicity: With Nile, there's no need to configure VLANs on individual switch ports. Segments are defined and managed globally through Nile's cloud-based platform, significantly reducing configuration complexity.
-
Dynamic Routing: Nile Access Services utilizes OSPF for efficient routing and failover, ensuring network resilience and policy consistency.
Segments within the Nile Access Service are globally defined, allowing consistent policy enforcement across multiple sites (SFO, BLR, FRA, etc.). This eliminates the need to replicate VLAN configurations on every switch, significantly streamlining network management. The segment-based model aligns with Zero Trust principles, enabling granular access control that follows users and devices regardless of their physical location.
The diagram below illustrates how this works for two devices in the same Layer 3 segment.
RL - > Now we have micro-segmentation available so there is no need to send anything to the upstream device. Should we talk about our micro-segmentation?
If we are going to show the below diagram, we should show a Firewall and not a router as the firewall has policies for allowing/denying the traffic.
Learn more about Nile's host based segmentation.
Campus Zero Trust
Nile's architecture incorporates Zero Trust principles to enhance security and simplify network management. This "never trust, always verify" approach minimizes the attack surface and reduces the risk of unauthorized access or lateral movement within your network.
-
Flexible Authentication: Nile integrates seamlessly with existing NAC solutions and can leverage device fingerprinting and MAC authentication bypass for granular access control. Policies are dynamically assigned based on authentication methods, ensuring the principle of least privilege.
-
Layer 3 Micro-Segmentation: Nile's Layer 3 segmentation isolates users, devices, and applications. This approach goes beyond traditional VLANs to provide enhanced security and flexibility, limiting the potential for lateral movement by attackers.
-
Distributed Policy Enforcement: Access control policies are enforced consistently throughout the Nile Service Block. Nile can integrate with upstream firewalls and security services to dynamically apply policies based on evolving needs and threat conditions.
-
AI-Powered Visibility: Nile's cloud-based reporting and AI-powered analytics provide deep visibility into network traffic and potential threats. This enables proactive threat detection and mitigation, minimizing risk within your environment.
Key Benefits
-
Enhanced Security Posture: Nile's Zero Trust model significantly reduces the likelihood and impact of successful cyberattacks.
-
Streamlined Operations: Granular segmentation simplifies policy management, improving operational efficiency.
-
Adaptable to New Threats: AI-driven analytics and dynamic policy integration provide agility in responding to emerging threats.
Learn more about Campus Zero Trust.
Shared Responsibility
Nile simplifies network operations by providing a cloud-delivered connectivity solution. This model ensures optimal network performance and security through a clear division of responsibilities.
Nile's Responsibilities:
- Connectivity Infrastructure: Design, deployment, and continuous operation of the Nile Service Block (switches, APs, sensors).
- Platform Management: All software updates, feature releases, and configuration of the Nile cloud-based management platform.
- Reliable Connectivity: Ensuring Nile components adhere to the strict SLAs, guaranteeing network availability, coverage, and capacity.
- Proactive Monitoring: 24/7 visibility into Nile service health, with proactive issue resolution ensuring an exceptional user experience.
Customer Responsibilities
- Network Strategy: Customers provision their intent on top of our standard system design across campus and branch locations. This includes management of upstream security appliances (firewalls), WAN connectivity, NAC/SASE solutions, and DHCP infrastructure.
- Endpoint Security: Security solutions and policies on end-user devices remain within the customer's domain.
Collaborative Support
Nile provides comprehensive support for the Nile Access Service. In scenarios where issues might require coordination between Nile infrastructure and customer-managed components, clear communication channels and escalation processes enable rapid troubleshooting and problem resolution.
RL -->Should we make a 3-tier RACI showing partner responsibility like showing site survey, Cabling, Rack, and Stack, RMA.
Also, DHCP is mentioned in two orange blocks. Why is Guest Access and Guest Service different? Guest Service is Nile-specific only.
In the graphic above an orange box (DHCP, DNS etc.) with blue text is an optional service, customers can use their own solutions.
Items in blue boxes with an orange border (Site Survey, Cabling plan, etc.) can be conducted by the customer or partner, adhering to Nile's established standards.
Our commitment to shared responsibility starts with planning your Nile Access Service deployment together using this framework.
Read Next
What is the Nile Architecture?
What is the Nile Architecture?
Overview
The Nile Architecture is based on the core principles of Core, Environment, and Context. These three pillars form the foundation of the Nile network design and management approach.
Core, Environment, Context
Core
When we talk about 'Core' in this context we are referring to the Nile Service Block which provides wired and wireless access infrastructure as a service. Designing our own hardware means we can embed physical and virtual sensors through out the NSB in order to gather the deep intelligence required to deliver fully automated infrastructure.
Environment
An autonomous vehicle uses an array of sensors to monitor it's surrounding environment, using this data to inform decisions and, if necessary raise alerts. Nile monitors the environment where NSB is deployed using a similar model.
Physical Wi-Fi sensors and dedicated monitoring radios in our APs provide real-time data on the wireless environment, while switches in the NSB monitor for cabling health and power fluctuations.
Context
In the Nile Architecture, Context refers to the users and devices connected to the NSB, as well as the services and applications being consumed/delivered. Nile's context monitoring doesn't end with device status, monitoring user/device experience at the point of consumption is vital to our 360 degree view.
For example; when a wireless user establishes a connection they will be authenticated using RADIUS or other NaaC services. Once authenticated they receive an IP address via DHCP from internal systems or Nile DHCP. The user accesses enterprise cloud applications, requiring DNS.
Nile monitors the availability and response time of these services, building an ongoing 'pattern-of-life' dataset which our AI tools can use to take action if there are deviations in normal operations.
The same methodology is used to monitor the user experience across 3,800 automatically identifiable applications.
This 'Outside-in' approach is both unique and fundamental to the Nile Access Service.
Read next
Nile's Layer 3 Only Network: Transcending VLANS
Nile's layer 3 only network: Transcending VLANS
Introduction
Since the introduction of VLANs (802.1q), networks have become increasingly complex. Cloud adoption, IoT proliferation, and heightened security threats have exposed the limitations of the traditional Layer 2 approach, driving the need for more robust access controls and secure network architectures.
VLANs were primarily invented to mitigate broadcast storms, but their use for security-driven network segmentation was a later development. However, broadcast domain limitations, complex management overhead, and insufficient security boundaries hindered scalability, agility, and the ability to enforce granular access controls. Using VLANs for segmentation also left networks vulnerable to attacks within shared broadcast domains and introduced complexity in managing segmentation across multiple devices and vendors.
This document explores how dynamic, policy-driven Layer 3 segments, a foundational innovation of the Nile Access Service (NaaS), addresses these challenges. Nile's approach, grounded in zero-trust principles and microsegmentation, enables organizations to build secure, dynamic, and future-proof networks aligned with modern security best practices and scalability requirements.
Why a Layer 3 only network?
Nile's Layer 3 Network Architecture represents a significant advancement in network design, addressing the limitations of traditional VLAN-based segmentation. By operating entirely at the network layer (Layer 3) of the OSI model, Nile's architecture leverages technologies like network virtualization, overlay networks, and routing protocols to create secure, isolated network segments that span multiple physical locations.
Nile's Layer 3 segments are logical constructs that define network access and security policies based on user identities, device attributes, and application requirements, rather than relying on IP addresses or physical network boundaries. Hybrid cloud technologies, dedicated Nile Access Service hardware, and OSPF routing create logical segments that can span across multiple physical networks and locations. Layer 3 segmentation also solves the inherent complexity of managing and securing traditional VLANs, as segments are created in the Nile Customer Portal and applied to devices and users wherever they connect.
At the core of Nile's approach is the principle of zero trust, which assumes that no user, device, or application should be implicitly trusted. Instead, granular access controls and continuous authentication and authorization are enforced through a combination of network segmentation, security policies, and identity-based access management.
Key features and benefits of Nile's Layer 3 Network Architecture include:
-
Granular Segmentation: Nile's architecture allows for the creation of fine-grained segments based on various criteria, such as user roles, device types, or application requirements. This level of granularity enables precise access controls and reduces the attack surface.
- Centralized Policy Management: Network access policies and security controls are managed centrally through Nile's intuitive management interface. This simplifies the configuration and enforcement of consistent policies across multiple locations and eliminates the complexity associated with traditional VLAN configurations.
- Scalability and Flexibility: Nile's architecture can easily scale to accommodate a large number of segments and can adapt to changing business requirements. New segments can be created, modified, or removed without the need for extensive network reconfiguration or hardware changes.
- Enhanced Security: By enforcing zero trust principles and micro segmentation, Nile's architecture significantly enhances network security. By default, each segment, device and user is isolated from all others, mitigating the spread of threats and reducing the attack surface.
- Campus Zero Trust by default: Unknown devices accessing the network are isolated by default, mitigating any threat of malware entering the domain.
- Seamless Integration: Nile's Layer 3 Network Architecture seamlessly integrates with existing network infrastructure and security solutions. It leverages standard routing protocols like OSPF to enable efficient communication between segments and can integrate with leading security appliances and cloud platforms.
Jas >> regarding the Centralized Policy Management, with Nile's Access Engine, we are just controlling access policies, when I as a user is reading security controls, the first thing that comes to my mind is IDS/IPS, DDoS and other security related things that a firewall typically controls. Nile's Access Engine is not a security center but instead it is just a policy center. Before we had Access Engine, our story to the customers has always been about Centralized Policy Management through the firewall: By default Nile will forward all the traffic to the firewall upstream, where the customer will be able to take care of adding all the security and access policies and they would have a single management plane where they can troubleshoot and add/delete any new policy. We want to promote the use of Nile's Access Engine but at the same time also show a note to the customers that if they want security policies to be applied, they still need to use the firewall to control those aspects.
Layer 3 segmentation in the Nile Service Block operates at the network layer by leveraging OSPF to facilitate communication between segments. Each segment functions as a separate logical network, with upstream security appliances or routers handling inter-segment traffic. The Nile Access Service integrates closely with security vendors like Palo Alto, Fortinet and zScaler, ensuring policies are consistently applied to all traffic.
Nile's Layer 3 Network Architecture represents a significant step forward in network design, providing organizations with a scalable, flexible, and secure foundation for building modern, zero-trust networks. By eliminating the complexities associated with traditional VLAN-based segmentation and enabling granular access controls, Nile empowers organizations to protect their critical assets, streamline network management, and adapt to the ever-evolving demands of the digital landscape as we enter this period of AI powered innovation.
Layer 2 vs Layer 3
Characteristic | VLAN (Layer 2) | Nile's Layer 3 Architecture |
---|---|---|
Scope of Segmentation | Confined to the broadcast domain | Creates logical segments isolated at the network layer |
Role of Routing | Requires external routers for inter-VLAN communication | Inherently leverages routing for inter-segment traffic |
Configuration Complexity | Configuration maintenance and control across multiple devices and vendors is highly complex and prone to human error. |
Centralized management and simplified configuration through the Nile Customer Portal |
Security Approach | Limited isolation within shared broadcast domains and susceptible to physical port vulnerabilities |
Zero trust principles with granular access controls and default isolation between segments, users, and devices |
Redundant Connectivity | Implementing redundant links is cumbersome | OSPF routing enables optimized path selection and redundancy |
Broadcast Domain Issues | Prone to broadcast storms and performance degradation in large networks | Significantly reduces broadcast traffic, enhancing performance |
Connectivity Approach | Often tied to physical location or switch port | Policy-based connectivity based on user identity, device attributes, and application requirements |
The comparison between traditional VLANs and Nile's Layer 3 Network Architecture highlights the significant advancements and benefits of Nile's approach in terms of segmentation, management simplicity, security, performance, and connectivity. These advantages position Nile's Layer 3 Network Architecture as a powerful enabler of zero-trust security models and a foundation for building modern, agile, and secure networks.
Nile Layer 3 Architecture: Customer Use Cases
Now that we've covered the theory, how are Nile Access Service customers benefiting from our Layer 3 only approach today?
Healthcare
One of our customers in the healthcare industry faced a critical security challenge when the manufacturer of their 50 x-ray imaging machines suddenly announced the discontinuation of security and OS updates. The customer was advised to replace all the machines, many of which were not fully depreciated, leading to a financial impact of several million dollars.
With Nile's Layer 3 segmentation, the customer was able to swiftly create firewall rules to isolate the vulnerable x-ray machines from the rest of their network. Through the Nile Customer Portal, they centrally configured and deployed the segmentation policies across all affected sites, without the need for physical reconfiguration or on-site visits.
By leveraging Nile's architecture, the customer avoided the premature replacement of the x-ray machines, saving them millions in replacement costs and lost productivity. Moreover, the segmentation approach ensured the customer maintained compliance with HIPAA regulations and protected sensitive patient data, despite the vulnerabilities in the x-ray machines.
Read Next
Building a Zero Trust Campus: Zero Trust Access, Nile Service Block Hardware
Building a Zero Trust Campus: Zero Trust Access
Authentication Methods in the Nile Access Service: Building a Zero Trust Campus
The Nile Access Service is built on the principles of the "Zero Trust Campus," ensuring that no user or device is implicitly trusted. By implementing strong authentication methods and granular access controls, the Nile Access Service helps organizations secure their network resources and protect against unauthorized access.
The following authentication methods are supported within the Nile Access Service, each playing a crucial role in establishing a Zero Trust Campus:
- Wired and Wireless 802.1X
- Single Sign-On (SSO)
- MAC Authentication Bypass (MAB)
Let's review each of these in more detail.
Wired and Wireless 802.1X: Strong Authentication for Zero Trust
802.1X is an IEEE standard for port-based network access control, providing strong authentication and encryption for both wired and wireless connections. By implementing 802.1X, organizations can ensure that only authenticated users and devices can access network resources, aligning with the principles of the Zero Trust Campus.
Nile's implementation of 802.1X offers:
- Integration with existing RADIUS infrastructure for centralized authentication and authorization
- Granular access control based on user identity and device
posturefingerprint.Shiv> We dont do device posture. However we plan to integrate with Crowdstrike in the futre to offer device posture based access.
JR> I recall mention of device fingerprinting somehow being used? - Centralized policy management through the Nile Customer Portal
Learn more about configuring 802.1X in the Nile Access Service to strengthen your Zero Trust Campus.
Single Sign-On (SSO): Streamlining Zero Trust Access
Single Sign-On allows users to access multiple applications with a single set of credentials, streamlining the user experience while maintaining the principles of the Zero Trust Campus. By integrating SSO with the Nile Access Service, organizations can enforce consistent authentication and authorization policies across their network resources.
Nile's SSO integration provides:
- Support for popular SSO protocols, including SAML, to ensure compatibility with leading identity providers.
- Centralized SSO configuration through the Nile Customer Portal
Discover how SSO can be seamlessly integrated into the Nile Access Service to enhance your Zero Trust Campus.
MAC Authentication Bypass (MAB): Securing Devices in a Zero Trust Campus
MAC Authentication Bypass is an authentication method that grants network access based on a device's MAC address. While MAB is useful for devices that don't support 802.1X, it's essential to implement additional security measures to maintain the integrity of the Zero Trust Campus.
Nile's MAB implementation includes:
- Quarantine all new devices by default
- Centralized MAB configuration through the Nile Customer Portal
- Create custom rules based on match criteria;
- Exact MAC address
- Fingerprint
- MAC OUI
- Optionally Integration with external MAC address databases (e.g Aruba ClearPass and Cisco ISE) for granular access control
Explore the configuration and best practices for MAB in the Nile Access Service to secure devices within your Zero Trust Campus.
By leveraging these authentication methods and following best practices, organizations can build a robust Zero Trust Campus with the Nile Access Service, ensuring secure access to network resources and protecting against unauthorized access.
RL -> We are also releasing wired SSO soon. In the below table, we can write wired and wireless SSO just like you have it on for 802.1x.
In the benefits of SSO, should we write about the SCIM protocol and its benefits of real time user information?
Authentication Comparison
Authentication Method | Description | Zero Trust Campus Benefits |
---|---|---|
![]() Wired and Wireless 802.1X |
- IEEE standard for port-based network access control - Supports various EAP methods (PEAP, EAP-TLS, EAP-TTLS) - Provides strong authentication and encryption |
![]() ![]() ![]() |
![]() Single Sign-On (SSO) |
- Allows users to access multiple applications with a single set of credentials - Supports popular SSO protocols (SAML, OAuth, OpenID Connect) - Reduces password fatigue and improves user experience |
![]() ![]() ![]() |
![]() MAC Authentication Bypass (MAB) |
- Authenticates devices based on their MAC address - Useful for devices that don't support 802.1X (printers, IoT devices) |
![]() ![]() ![]() |
Read Next
802.1x Authentication, Single Sign-On (SSO), MAC Authentication Bypass (MAB)
Zero Trust Access 802.1x
Overview
Nile's Campus Zero Trust approach to network security is essential in today's high risk environment. Nile's support for industry-standard 802.1X authentication enables you to enforce consistent access controls and policies across your wired and wireless campus networks, ensuring only authorized devices and users can connect.
By integrating with your existing RADIUS infrastructure, such as Active Directory, to authenticate clients The Nile Access Service ensures only authorized devices and users can access network resources. In the Campus Zero Trust architecture, devices are denied access by default, and can only access resources through one of the supporteed authentication methods, including 802.1x. This streamlines the onboarding process and ensures a seamless user experience, all while maintaining a strong security posture.
Configuring 802.1X Authentication on Nile
To set up 802.1X authentication on your campus zero trust network with Nile, follow these steps:
-
Configure RADIUS Servers
- In the Nile Portal, navigate to "Settings>Authentication" tab and click "Add".
- Enter the details for your RADIUS server, including the Name, port, shared secret, the Geo Scope which it supports, nad the IP address or FQDN. I
- Click the "VERIFY HOSTS" button to confirm your settings. If everything passes, you can then save this server configuration.
-
Enable 802.1X on a Nile Segment
- Go to Settings>Segements tab. section, click the pencil icon to edit your chosen segment.
- In the segment details, navigate to the Service Area tab.
- Select the RADIUS server you just configured in the Authentication dropdown.
- Click SAVE to immediately enable 802.1x on that segment.
Supporting Non-802.1X Devices in a Campus Zero Trust Network
Nile understands that not every device on your network will support 802.1X. For these non-802.1X-capable clients, Nile offers MAC Authentication Bypass; learn more.
Shiv> I forgot about this. We need to upload the NIle dictionary file here. This file is uploaded in the RADIUS server and is used to send us back the segment name as a Vendor specific attribute.
Dynamic Segment Assignment with Nile Dictionary
The Nile Access Service supports dynamic segment assignment based on user and device attributes received from external RADIUS servers, such as Cisco Identity Services Engine (ISE) and Aruba ClearPass. To facilitate this, Nile provides a custom dictionary file that can be uploaded to the RADIUS servers.
When a user or device authenticates to the Nile Access Service using 802.1X, the RADIUS server can send the "netseg" attribute during the authentication process. This attribute informs the Nile Access Service which network segment the user or device should be assigned to.
Example Use Case: Single SSID for Teachers and Students
Shiv provided the following example use case:
- The SSID "Univ of Den" is used by both teachers and students.
- Teachers belong to the "teacher" segment, while students belong to the "student" segment.
- The RADIUS server is configured to send the "netseg" attribute during the 802.1X authentication process.
- The RADIUS server sends "netseg=teacher" when a teacher authenticates, and "netseg=student" when a student authenticates.
- The segment names sent by the RADIUS server must exactly match (case-sensitive) the segment names configured in the Nile Access Service.
Configuring Dynamic Segment Assignment
To configure dynamic segment assignment using the Nile dictionary file, follow these steps:
-
Obtain the Nile Dictionary File: Contact Nile support or your account representative to obtain the Nile dictionary file. This file contains the necessary vendor-specific attributes (VSAs) used for dynamic segment assignment.
-
Upload the Nile Dictionary to the RADIUS Server: Depending on the RADIUS server you're using (Cisco ISE or Aruba ClearPass), follow the instructions in the respective guides:
-
Configure the RADIUS Server to Send the "netseg" Attribute: Ensure that your RADIUS server is set up to send the "netseg" attribute during the 802.1X authentication process. The attribute value should match the segment names configured in the Nile Access Service.
-
Configure Segments in the Nile Customer Portal: In the "Settings" > "Segments" section of the Nile Customer Portal, create the necessary network segments that correspond to the "netseg" attribute values received from the RADIUS server (e.g., "teacher" and "student" segments).
-
Associate Segments with 802.1X Authentication: When configuring 802.1X authentication in the "Settings" > "Segments" section, select the RADIUS server you've set up and enable dynamic segment assignment. The Nile Access Service will then automatically place users and devices in the appropriate network segments based on the "netseg" attribute received from the RADIUS server.
By leveraging dynamic segment assignment with the Nile-provided dictionary file, organizations can achieve a higher level of granular access control, ensuring that users and devices are consistently placed in the correct network segments based on their identity, device type, and location. This enhances the overall security of the campus zero trust network by reducing the risk of unauthorized access and lateral movement.
Unique Passphrase (UPSK) with SSO External RADIUS
The Nile Access Service supports the integration of Unique Passphrase (UPSK) with external RADIUS servers, such as Cisco ISE and Aruba ClearPass. UPSK enhances the security of traditional pre-shared key (PSK) wireless networks by assigning a unique passphrase to each authenticated user, rather than a single shared key.
To configure UPSK with an external RADIUS server in the Nile Access Service, follow these steps:
-
Configure the SSO Provider
- ??
-
Create a UPSK-enabled SSID in the Nile Customer Portal:
- Navigate to the "Settings" > "Wireless" page in the Nile Customer Portal.
- Select the "Personal" SSID type and enable the "Enable SSO" option.
- Enter a pre-shared key and select the network segments accessible via this SSID.
-
Configure the RADIUS Integration in the Nile Customer Portal:
- Go to the "Settings" > "Authentication" page and add the external RADIUS server details, including the name, IP address or FQDN, port, and shared secret.
- Verify the RADIUS server connection by clicking the "Verify Hosts" button.
- In the "Segments" section, edit the segment associated with the UPSK-enabled SSID and select the RADIUS server you just configured.
-
Provide Users with the UPSK Registration Link:
- Instruct users to visit the my.nilesecure.com website or use the unique registration link provided in the Nile Customer Portal.
- Users will be prompted to authenticate using your organization's identity provider (IdP), which should be integrated with the external RADIUS server.
- After successful authentication, users can generate a unique passphrase for their device to connect to the UPSK-enabled SSID.
By integrating UPSK with an external RADIUS server, you can leverage your existing identity management infrastructure to provide secure wireless access, while still benefiting from the enhanced security and user-specific credentials offered by the Nile Access Service's UPSK feature.
Centralized Management and Visibility
Nile's cloud-managed architecture provides a simple path for 802.1X deployment. This includes the ability to:
- Easily onboard and manage primary, secondary and tertiary RADIUS servers for redundancy and segmentation
- Shiv> We should point out how redundancy works
- Its a primary, secondary, tertiary model. So only if primary faiils we send it to secondary and if secondary fails we send it to tertiary. I will find out what happens if primary comes online.
- Shiv> We should point out how redundancy works
- Track authentication events and client activity across your wired and wireless networks
- Quickly troubleshoot connectivity issues with detailed logs and reporting
(Screenshot of the Nile Portal's 802.1X monitoring and reporting dashboard)
By leveraging Nile's 802.1X capabilities, you can establish a robust, campus zero trust network that securely connects all devices and users, regardless of their location or device type.
Contact us today to learn more about how Nile can help secure your campus environment.
Read Next
Zero Trust Access: Single Sign-On (SSO)
Integrating SSO for a Zero Trust Campus
The Nile Access Service is built on the principles of a "Zero Trust Campus," ensuring that no user or device is implicitly trusted. As part of this security model, the Nile Access Service supports the integration of Single Sign-On (SSO) to streamline user authentication and authorization across multiple applications and resources.
[diagram required]
By implementing SSO, organizations can leverage their existing identity providers (IdPs) to centrally manage user credentials and enforce consistent access policies. This approach aligns with the Zero Trust principle of verifying user identity or device before granting access, reducing the risk of unauthorized access and enhancing overall security.
Why Use SSO with the Nile Access Service?
The Nile Access Service's support for SSO integration offers several key benefits:
- Improved User Experience: SSO allows users to access multiple applications and resources with a single set of credentials, reducing password fatigue and improving productivity.
- Centralized User Management: By integrating with existing IdPs, the Nile Access Service enables organizations to manage user identities and access privileges from a central location, simplifying user provisioning and deprovisioning.
- Consistent Policy Enforcement: SSO integration ensures that access policies defined within the IdP are consistently applied across the Nile Access Service, ensuring a unified security posture.
- Enhanced Security: The Nile Access Service's SSO integration, combined with its Zero Trust principles, helps mitigate the risks of password-based authentication by verifying user identity and device posture before granting access.
Integrating Identity Providers with Nile Access Service
The Nile Access Service supports integration with various identity providers (IdPs) using the SAML protocol. This allows users to authenticate to the Nile platform using their existing corporate credentials, providing a seamless single sign-on experience.
The general steps to integrate an IdP with the Nile Access Service are as follows:
-
Configure the IdP Application:
- Log in to the administration portal of your IdP (e.g., Azure AD, Google Workspace, Okta, OneLogin).
- Create a new SAML application or custom integration for the Nile Access Service.
- Provide the necessary configuration details, such as the Assertion Consumer Service (ACS) URL and Entity ID.
- Download the IdP's SAML signing certificate.
-
Configure the Nile Identity Provider:
- Log in to the Nile Customer Portal as an administrator.
- Navigate to the "Settings" > "Global Settings" > "Identity" page.
- Click "Add a New Provider" and fill out the form with the details from the IdP configuration:
- IdP Issuer URI
- IdP SSO URL
- Destination URL
- Upload the IdP's SAML signing certificate.
- Configure any necessary group mapping rules to assign users to segments based on IdP group membership.
- Click "Add a New Provider" and fill out the form with the details from the IdP configuration:
-
Test the SSO Integration:
- Verify that users can successfully log in to the Nile Access Service using their IdP credentials.
- Ensure that the user is being placed in the correct segment based on your configured policies.
Refer to the provider-specific integration guides for detailed steps on configuring Azure AD, Google Workspace, Okta, and OneLogin as identity providers for the Nile Access Service.
Links to individual config guides will be added
Unique Passphrase (UPSK) + SSO
Unique Passphrase (UPSK) is a feature of the Nile Access Service that enhances the security of traditional pre-shared key (PSK) wireless networks. Unlike a typical PSK network, where a single key is shared among all devices, UPSK assigns a unique key to every authenticated user.
To use UPSK, follow these steps:
-
Create a UPSK-enabled SSID:
- In the Nile Customer Portal, navigate to "Settings" > "Wireless".
- Select the "Personal" SSID type and enable the "Enable SSO" option.
- Enter a pre-shared key and select the appropriate network segment.
-
Register Devices:
- Provide users with a unique registration link, which can be obtained from the Nile Customer Portal or the my.nilesecure.com website.
- Users will be redirected to an SSO login page to authenticate.
- After successful login, users can generate a unique passphrase for their device.
-
Connect Devices to the UPSK SSID:
- Users can connect their devices to the UPSK-enabled SSID using the generated passphrase.
- Alternatively, users can scan a QR code from the self-registration page to automatically connect their device.
The UPSK feature ensures that each user and device has a unique set of credentials, enhancing the overall security of the wireless network and aligning with the Nile Access Service's zero-trust principles.
For more information on configuring identity provider integration or the Unique Passphrase feature, refer to the provider-specific guides and the Nile Access Service documentation.
Read Next
Zero Trust Access: MAC Authentication Bypass (MAB)
MAB and the Zero Trust Campus
The Nile Access Service is built on the principles of a "Zero Trust Campus," ensuring that no user or device is implicitly trusted. As part of this security model, the Nile Access Service supports MAC Authentication Bypass (MAB) as an authentication method for devices that cannot accommodate the 802.1X standard.
While MAB provides network access for non-802.1X capable devices, such as printers and IoT equipment, it is essential to maintain the principles of Zero Trust. Nile's implementation of MAB includes additional security measures to isolate these devices and limit their potential impact on the network.
Why Use MAB?
Nile requires all wired access to be authenticated before granting network connectivity. The Nile Access Service supports three different wired authentication methods:
- Wired 802.1X authentication (requires a RADIUS server)
- Wired RADIUS MAB authentication (requires a RADIUS server)
- Nile Portal Wired MAB authentication
MAB is a crucial authentication method for devices that cannot support the 802.1X standard, ensuring comprehensive coverage and secure access to Nile Access Service Segments.
Configuring MAB
Nile provides flexible options for configuring MAB within the Nile Access Service:
Uploading a MAC Address List
You can upload a list of MAC addresses for wired MAB authentication by navigating to the Nile Portal (Settings > Access Management > Wired) and providing the following information:
- MAC address: The device's MAC address (mandatory)
- Segment: The network segment to which the device should be assigned (required for "Allow" status, optional for "Deny")
- Lock to Port: Lock the device to a specific switch port (optional)
- Site, Building, Floor: Restrict the device to a specific geographical location (optional)
- Allow or Deny: Specify whether to allow or deny access for the device (mandatory)
[screenshot required]
Enabling Auto-MAB for Specific Device Types
You can also configure Nile to automatically authenticate devices based on their Organizational Unique Identifier (OUI), the first 24 bits of a MAC address that identify the device manufacturer. This can be done in the Nile Portal (Settings > Access Management > Wired > Add Device > OUI/MAC), where you can select the segment, status (Approved/Denied), and geographical scope for the OUI-based policy.
[screenshot required]
MAB Port Locking and Geographical Scope
Nile offers additional security features for MAB, including the ability to "Lock to Port" and restrict devices to specific geographical locations ("Geo Scope"). These options help mitigate the risks associated with MAB by ensuring that devices can only connect to authorized switch ports and locations.
[screenshot required]
Disabling Nile Wired Authentication
Nile's network is designed with security best practices in mind, and you cannot disable MAB authentication entirely. However, you can create a catch-all "allow all" policy to grant network access to all devices, assigning them to a specific segment. While this approach is not recommended, it can be enabled in the Nile Portal (Settings > Access Management > Wired > Add Device > Allow all MACs).
Remember that the "allow all" policy will automatically create a unique MAC-allowed entry for each device when it first connects to the Nile switch. Deleting the "allow all" policy will not impact connected devices or delete the specific policies that were auto-created.
By understanding the role of MAB within the Nile Access Service and the available configuration options, you can ensure that non-802.1X capable devices are granted secure network access while maintaining the principles of the Zero Trust Campus.
Summary
In summary, the Nile Access Service's implementation of MAC Authentication Bypass (MAB) is a vital component of our comprehensive authentication framework. Nile's flexible MAB configuration options, including MAC address lists, auto-MAB for specific device types, and advanced security controls like port locking and geographical restrictions, empower organizations to extend secure network access to a wide range of devices, including those that cannot support 802.1X.
Furthermore, Nile's innovative approach to network segmentation, which transcends traditional VLAN-based models, enhances the benefits of MAB. The Nile Access Service's Layer 3 segmentation, driven by user identity, device attributes, and application requirements, enables granular access controls and micro-segmentation. This powerful combination of MAB and Nile's advanced segmentation strategy helps enterprises maintain a robust security posture while accommodating diverse connectivity needs, in alignment with Zero Trust principles.
By leveraging the flexibility and security of MAB within Nile's innovative network architecture, organizations can confidently provide secure access to a wide range of devices, minimizing the attack surface and reducing the risk of lateral movement. As a key part of the Nile Access Service's authentication framework, MAB contributes to the overall effectiveness of this cloud-native network solution in helping enterprises build resilient, agile, and highly secure network environments.
Nile Wired Access Management FAQ
Why do we need Wired Access Management?
Nile requires all wired devices to be authenticated before accessing the network. The Nile Access Service supports three different wired authentication methods:
- Wired 802.1X authentication (requires a RADIUS server)
- Wired RADIUS MAB authentication (requires a RADIUS server)
- Nile Portal Wired Access management authentication
Can I upload a list of Wired pre-approved devices to Access Management?
Yes, you can upload a list of pre-approved devices to the Nile Access Management by uploading a CSV file via the Nile Customer Portal (Settings > Access Management > Wired). The CSV file should include the following information:
- MAC address: The device's MAC address (mandatory)
- Segment: The network segment the device will be assigned to (required for "Allow" status, optional for "Deny")
- Lock to Port: Lock the device to a specific switch port (optional)
- Site, Building, Floor: Restrict the device to a specific geographical location (optional)
- Allow or Deny: Specify whether to allow or deny access for the device (mandatory)
Can I Disable Nile Wired Device Authentication?
No, the Nile network is designed with security best practices, and you cannot disable wired device authentication entirely. However, you can add a catch-all "allow all" policy (not recommended) to grant network access to all devices, assigning them to a specific segment. This policy can be enabled in the Nile Customer Portal (Settings > Access Management > Wired > Add Device > Allow all MACs).
Can I Enable Nile Auto Wired Device Authentication for a Specific Vendor or Device Type?
Yes, you can create a wired device authentication policy for a specific device vendor or type using the Organizational Unique Identifier (OUI). The OUI is the first 24 bits of a MAC address that is used as a globally unique identifier assigned by the IEEE to identify network devices.
You can enable the OUI-based policy in the Nile Customer Portal (Settings > Access Management > Wired > Add Device > OUI/MAC), where you can select the segment, status (Approved/Denied), and geographical scope for the OUI-based policy.
What is Nile Wired Access Management Lock to Port?
The "Lock to Port" feature will lock a device's approval to a specific Nile switch port when the device connects for the first time. If the wired device is moved to a different port or a different switch, the Wired Access Management policy will be changed from "allow" to "deny", and the Nile portal administrator will need to allow the device again.
You can enable the "Lock to Port" feature in the Nile Customer Portal (Settings > Access Management > Wired > Add Device) by entering the OUI (for multiple devices) or MAC (for a single device), selecting a specific segment, and optionally choosing the geographical scope.
What is Wired Access Management Geo Scope?
The Wired Access Management Geo Scope is a feature that limits wired device authentication pre-approval to a specific location (site, building, or floor). If a wired device is moved to a different location, the Wired Access Management policy will be changed from "allow" to "deny", and the Nile portal administrator will need to allow the device again.
You can enable the Geo Scope in the Nile Customer Portal (Settings > Access Management > Wired > Add Device) by entering the OUI (for multiple devices) or MAC (for a single device), selecting a specific segment, and choosing the geographical scope (site, building, or floor).
Can Administrators Pre-Approve Devices Based on Device Make, Model, or Software?
Yes, the Nile Access Service can fingerprint devices and allows administrators to create fingerprint-based rules to pre-approve devices. You can navigate to "Settings > Access Management > Wired > Add Devices" in the Nile Customer Portal. Nile has an extensive database of device models, makes, and operating systems that can be used to create these rules. When you start typing the name of your device, the system will auto-populate and display the matching entries in our database.
What If My Device is Not in Nile's Database?
If your device is not in the Nile database, the administrator will need to use the MAC address or Organizational Unique Identifier (OUI) for pre-approval. You can reach out to Nile support and provide the details of your device, so it can be reviewed and added to the database at a later date.
How Does Fingerprint-Based Approval Work?
Nile's device fingerprinting works as follows:
- The exact MAC address rule match always takes precedence.
- If there is no exact MAC address match, the device will be matched against a fingerprint rule.
- If there is no fingerprint rule match, the device will be matched against an OUI rule.
- If there are no other matching rules, the device will be assigned to the "All" rule.
When a new device connects to the network and does not have an IP address, Nile will use limited information like the MAC address to attempt a fingerprint match. To get the device a temporary IP address, you need to create an "All" rule with a quarantine or Internet-only segment. Nile's fingerprinting uses parameters like MAC address, DHCP, DNS transactions, and User-Agent data to accurately match the device.
If the device does not match the fingerprint rule, it will be placed in the segment defined by the "All" rule. Once the device gets a temporary IP and starts communicating, Nile will fingerprint it and automatically move it to the correct fingerprint-based segment, updating the device's IP address accordingly. Nile will learn the device's fingerprint and create a specific entry for it going forward.
What Happens If I Create an Exact MAC Address Entry for a Device?
If you create an exact MAC address entry for a device with a specific segment assignment, Nile will not automatically move that device to a different segment based on fingerprinting. Devices matching an exact address or OUI rule will not be moved automatically. It is recommended not to create exact MAC address or OUI entries for devices you want to onboard using fingerprinting.
What If Nile Fingerprints a Device Incorrectly?
If a device is fingerprinted incorrectly, Nile recommends removing the device from the cache and adding the exact MAC address. You can then contact Nile support to provide the device details, so we can evaluate and add it to our database.
What Happens If a Device Matches Multiple Fingerprint Rules?
When a device matches multiple fingerprint rules, the most specific rule will take precedence. For example, a rule for "Avaya IP Phone 250" will win over a more general "Avaya" rule.
What If I Create New Rules After Devices Are Already Connected?
Rules need to be created before connecting the devices. When a device connects, Wired Access Management will match it against the existing rules. If there are no matching rules, a device entry will be created with a "waiting for approval" status. To have a new rule applied to an existing device, you will need to delete the device entry and disconnect/reconnect the device to apply the new rule.
Nile is adding an enhancement to automatically verify all existing entries with a "waiting for approval" status after a new rule is created. If the device matches the new rule, its status will automatically change to "allow" or "deny" based on the new rule.
What Happens If We Delete an Existing Rule?
Deleting an existing rule will not impact any existing device Wired Access Management entries. It will only affect the addition of new devices. When a new device is added, if it matches a rule, a specific entry will be created for that device. The only impact would be if both the rule and the device entry were deleted - in this case, the device status will change to "waiting for approval" and require manual approval.
Read Next
Nile Service Block Hardware
Nile Service Block Hardware
NSB hardware, deployed throughout your sites, serves as the common access layer for both wired and wireless users, along with devices such as surveillance cameras and printers. The physical components of NSB include WiFi 6E APs, Distribution and Access Switches, and Sensors.
-
Switches
-
Distribution Switches
-
24x10/25 Gbps ports for servers and access switches
- 1/10/40 Gbps ports for upstream routers/firewalls.
-
-
Access switches
- 48 multi-gig (100M to 5Gbps) ports for APs, desktops, printers
- 4x10/25Gbps, and unlimited number of switches in a ring
- All ports are PoE / PoE+ capable
-
-
Wi-Fi Access Points
-
Indoor and Industrial Wi-Fi 6e APs
- 4 Radios + 1 BT
- 3 Radios serving clients: 2.4Ghz: 4x4:4; 5Ghz:4x4:4; 6Ghz:4x4:4
- 1 Tri band radio for WIPS/WIDS, RF Monitoring & virtual sensor
- 5Gbps Uplink
-
-
Sensors to actively monitor user experience SLAs.
There are no local interfaces to NSB hardware. The Nile Cloud Platform manages all aspects - from ordering and provisioning to operation and monitoring.
NILE DASHBOARD IMAGE