MAC Authentication

mac auth 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 auth as an authentication method for devices that cannot accommodate the 802 1x standard when a device connects to a nile switch, its mac address is learned and sent to the nile cloud or external radius server for authentication if the device is successfully authenticated a segment name is returned to the nsb the device is then assigned the segment and traffic is allowed nile cloud mac authentication by default when a device connects to the nile switch it will show up in the nile portal as "waiting for approval" this device can then be manually approved or denied if approved a segment will be assigned to it approving or denying each individual device can be cumbersome so nile provides the ability for an admin to create pre define rules the following are the rules that can be created exact match address the admin can create an entry with an mac address fingerprint rule nile has an exhaustive list of fingerprints in its database so a rule based on fingerprint can be created e g devices matching "hp printer" should be assigned the printer segment oui create a rule based on the first 3 octets of a mac address catch all rule if none of the rules are not matched a device can be mapped to a segment using this rule all these rules are optional but its recommended to create rules mac auth address matching process when a client connects to the nile service block (nsb) and mac authentication is enabled, the following matching rules are applied to determine the client's authorization and network segment assignment exact mac address match if the client's mac address exactly matches an entry in the mac auth table, the client is authorized and placed in the configured network segment if no exact mac address match is found, the process moves to the next rule device fingerprint match if the client does not match any of the previous rules, the system attempts to match the client's device fingerprint against the configured fingerprint based rules the device fingerprint is determined based on factors like mac address, dhcp, dns transactions, and user agent data if no fingerprint match is found, the process moves to the next rule oui match if the client's organizational unique identifier (oui) the first 24 bits of the mac address matches a configured oui based rule, the client is authorized and placed in the corresponding network segment if no oui match is found, the process moves to the next rule catch all match if the client does not match the exact mac address, fingerprint or oui based rules, the system checks the "catch all" rule the catch all rule can be configured to either allow the client and place it in a specific network segment, or self serve with wired sso if fingerprint based rules are being used, its strongly recommended to have the catch all rule once the device gets an ip address and passes some traffic like dns or user agent, it can get accurately fingerprinted and then moved to the appropriate segment for example define a rule defined as "allow hp printer on the printer segment" when the printer connects to the network, it may not get fingerprinted right away but once it falls in the all rule, gets an ip and passes some traffic, it will get fingerprinted and moved to the printer segment setup mac auth nile provides flexible options for configuring mac auth within the nile access service uploading a mac address list you can upload a list of mac addresses for wired mac authentication by navigating to the nile portal (network setup > access management > wired) and providing the following information oui/mac/name (mandatory) either enter a mac address or oui or a fingerprint value description (optional) an admin can provide a description for this device segment the network segment to which the device should be assigned (required for "allow" status, optional for "deny") geoscope (optional) site, building, floor restrict the device to a specific geographical location the default is all geoscopes which means a device can be plugged into any switch at any site assuming "lock to port" is not set status (mandatory) specify whether to allow or deny access for the device lock to port (optional) the "lock to port" feature automatically locks the device to the switch port where it first achieved successful authentication for example; when a voip phone is connected to the network, the admin may choose to lock it to a port to ensure its location is not changed if this phone is moved to a different port on the same switch or different switch, it will be denied access allow all macs (optional) catch all rule for devices that don't match and criteria's wired sso (optional) if a device falls in the all category, enable sso and move the device to an employee segment m ac auth with external radius server mac authentication is a mandatory for all devices that don't support 802 1x but admins have the choice to use mac auth with their own radius server as opposed to nile cloud when a radius server is created and the "wired auth" checkbox is checked; nile will do a mac auth with the external radius server note external radius servers must be configured to return a segment name with authentication to ensure the device is placed in the correct segment refer to the expandable header below for details segment assignment with radius in some use cases, a single ssid can be mapped to multiple segments in the nile access service in such scenarios, it is mandatory for the radius server to send back the exact segment name that the user or device should be assigned to for example; the denver university ssid could have both faculty and student segments mapped, allowing each to access their specific resources without needing multiple ssids as well as being very convenient for users, it reduces the issues that can occur when vlan locked ssids proliferate the segment assignment can be achieved in two ways vendor specific attribute (nile dictionary file) the nile dictionary file needs to be uploaded into the radius server, and the "netseg" attribute should be leveraged for example, the radius server should send "netseg=teacher" or "netseg=student" when authenticating users the "netseg" value is case sensitive and must match the segment names configured in the nile customer portal nile custom dictionary file vendor nile 58313 begin vendor nile attribute redirect url 1 string attribute netseg 2 string attribute nile avpair 3 string end vendor nile standard radius attribute if the radius server does not support uploading a custom dictionary file, the segment name can be sent using the standard radius attribute "tunnel private group id" if the segment name sent by the radius server is null or does not match the configured segments in nile, the device will fail authentication with the appropriate error message note that if the ssid is mapped to only one segment in the nile access service, the use of the nile dictionary file or the standard radius attribute is not required by understanding the role of mac auth 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 auth is a vital component of our comprehensive authentication framework nile's flexible mac auth configuration options, including mac address lists, auto mac auth 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 mac auth https //docs nilesecure com/niles layer 3 only network transcending vlans , driven by user identity, device attributes, and application requirements, enables granular access controls and micro segmentation this powerful combination of mac auth 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 mac auth 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, mac auth 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 mac 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 portal (network setup > 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 (network setup> 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 (network setup> 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 (network setup> 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 (network setup> 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) the admin can view this information in the mab table 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 "network setup> 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; https //app archbee com/docs/jugamsswawauxxjhmyr53/nqrx00kdrs4w4lgx fqn4