Windows Server 2008 R2 Enterprise X64 Serial Number
Bok Mull
Cisco Meraki MR access points (APs) offer a number of authentication methods for wireless association, including the use of external authentication servers to support WiFi Protected Access 2 - Enterprise (WPA2-Enterprise). This article outlines dashboard configuration to use a RADIUS server for WPA2-Enterprise authentication, RADIUS server requirements, and an example server configuration using Windows Network Policy Server (NPS).
WPA2-Enterprise with 802.1X authentication can be used to authenticate users or computers in a domain. The supplicant (wireless client) authenticates against the RADIUS server (authentication server) using an Extensible Authentication Protocol (EAP) method configured on the RADIUS server. The gateway access point (authenticator) sends authentication messages between the supplicant and authentication server. This means the RADIUS server is responsible for authenticating users.
Access points perform Extensible Authentication Protocol Over LAN (EAPOL) exchanges between the supplicant and convert these to RADIUS Access-Requests messages, which are sent to the RADIUS server's IP address and UDP port specified in dashboard. Gateway access points need to receive a RADIUS Access-Accept message from the RADIUS server in order to grant the supplicant access to the network.
To achieve the best performance, we recommend placing the RADIUS server and gateway access points within the same layer-2 broadcast domain to avoid firewall, routing, or authentication delays. Keep in mind the access point is not responsible for authenticating wireless clients and acts as an intermediary between clients and the RADIUS server.
The following image provides a detailed breakdown of the Protected Extensible Authentication Protocol (PEAP) with the Microsoft Challenge Handshake Authentication Protocol version 2 (MSCHAPv2) association process:
When WPA2-Enterprise with 802.1X authentication is configured, the following attributes are present in the Access-Request messages sent from the Cisco Meraki access point to the customer's RADIUS server.
Note: SSIDs broadcasted by repeater access points in a mesh deployment can't use NAS-IP-Address attribute because repeater access points do not have IP addresses assigned. You can use NAS-ID attribute instead, which by default carries NODE_MAC:VAP_NUM.
Note: Certificate-based authentication using EAP-TLS is also supported by the Meraki platform, but is outside the scope of this document. For more information, refer to the documentation on RADIUS: WPA2-Enterprise With EAP-TLS.
There are many server options available for RADIUS, which should work with MR access points if configured correctly. Please refer to your RADIUS server documentation for specifics, but the key requirements for WPA2-Enterprise with Meraki are as follows:
The most common method of authentication with PEAP-MSCHAPv2 is user authentication, in which clients are prompted to enter their domain credentials. It is also possible to configure RADIUS for machine authentication, in which the computers themselves are authenticated against RADIUS, so the user doesn't need to provide any credentials to gain access. Typically, you can use EAP-TLS to configure machine authentication. However, some RADIUS server options make it simple to use PEAP-MSCHAPv2 to configure machine authentication (including Windows NPS, outlined in the example configuration below).
Note: "Machine Authentication" is not the same as MAC-based authentication, which is another configuration option in dashboard under Wireless > Configure > Access Control. Machine authentication, specifically, refers to devices authenticating against RADIUS.
Microsoft's RADIUS server offering for Windows Server 2008 and later is their NPS. Please refer to the following two Microsoft documents for instructions on adding the NPS role to Windows Server, and registering the new NPS server in Active Directory (allowing it to use AD as its userbase):
In this scenario, access points communicate with clients and receive their domain credentials, which the access point then forwards to NPS. In order for the NPS to process an access point's RADIUS access-request message, you must first add the access point as a RADIUS client/authenticator by its IP address. Since only gateway access points have an IP address on the LAN, all gateway access points in the network must be added to NPS as RADIUS clients.
To quickly gather all gateway access point's LAN IP addresses, navigate to Wireless > Monitor > Access points in dashboard, ensure that the "LAN IP" column has been added to the table, and take note of all LAN IPs listed. Access points with a LAN IP of "N/A" are repeaters and they do not need to be added as RADIUS clients:
Once a list of gateway access point's LAN IPs has been gathered, please refer to Microsoft's documentation for instructions on adding each access point as a client in NPS. Take note of the shared secret configured in NPS, which is referenced in the dashboard.
Note: To save time, entire subnets can also be added to NPS as RADIUS clients, and any requests coming from that subnet will be processed by NPS. This is only recommended if all access points are on their own management VLAN and subnet, to reduce security risks.
In many cases each RADIUS authenticator must be added to the RADIUS authentication server such as Microsoft NPS or Cisco ISE. For VPN concentration and concentrated Layer 3 roaming SSIDs, only concentrators would need to be added to the RADIUS authentication server.
For a seamless user experience, it may be ideal to deploy a PEAP wireless profile to domain computers so users can easily associate with the SSID. Though optional for user auth, this is strongly recommended for machine authentication.
Once a RADIUS server has been set up with the appropriate requirements to support authentication, the following instructions explain how to configure an SSID to support WPA2-Enterprise, and authenticate against the RADIUS server:
Aside from the RADIUS server requirements outlined above, all authenticating access points will need to be able to contact the IP address and port specified in dashboard. Make sure that your access points all have network connectivity to the RADIUS server and no firewalls are preventing access.
Dashboard offers a number of options to tag client traffic from a particular SSID with a specific VLAN tag. Most commonly, the SSID will be associated with a VLAN ID (see VLAN Tagging on MR Access Points), so all client traffic from that SSID will be sent on that VLAN.
With RADIUS integration, a VLAN ID can be embedded within the RADIUS server's response. This allows for dynamic VLAN assignment based on the RADIUS server's configuration. Please refer to our documentation regarding Per-User VLAN tagging for configuration specifics.
Optionally, RADIUS accounting can be configured on an SSID that's using WPA2-Enterprise with RADIUS authentication. When RADIUS accounting is configured, "start" and "stop" accounting messages are sent from the access point to the specified RADIUS accounting server.
Cisco Meraki access points can be configured to provide enterprise WPA2 authentication for wireless networks using Cisco Identity Services Engine (ISE) as a RADIUS server. This article will cover instructions for basic integration with this platform. For more detailed information on how to configure Cisco ISE, please refer to the Cisco Identity Services Engine User Guide.
After installation, Cisco ISE generates, by default, a self-signed local certificate and private key, and stores them on the server. This certificate will be used by default for WPA2-Enterprise. In a self-signed certificate, the hostname of Cisco ISE is used as the common name (CN) because it is required for HTTPS communication.
Note: Using a self-signed certificate is not recommended for RADIUS. In order to use the default self-signed cert, clients will need to have RADIUS server's identity validation disabled in order to connect. For certificate options on the RADIUS server you may refer to the RADIUS configuration section in this document.
Cisco ISE supports policy sets (see Cisco ISE: Introduction to Policy Sets), which allows grouping sets of authentication and authorization policies, as opposed to the basic authentication and authorization policy model, which is a flat list of authentication and authorization rules. Policy sets allow for logically defining an organization's IT business use cases into policy groups or services, such as VPN and 802.1X. This makes configuration, deployment, and troubleshooting much easier.
***Some general info***
- Each host needs to be licensed.
- A minimum of 8 core licenses is required for each physical processor and a minimum of 16 core licenses is required for each server.
- Core licenses are sold in packs of two.
- Standard Edition provides rights for up to 2 Operating System Environments or Windows Servers containers with Hyper-V isolation when all physical cores in the server are licensed. For each additional 1 or 2 VMs, all the physical cores in the server must be licensed again.
- DataCenter Edition provides rights for unlimited Operating System Environments or Windows Servers containers with Hyper-V isolation when all physical cores in the server are licensed.
So, if I want to have Windows Server 2022 Standard on my Dell PowerEdge R540 with Twelve Core 3Ghz processors, I need to purchase the package of 16 core licenses for Windows Server Standard, not the one with 2 core licenses. Correct?
Necro this article because of past and upcoming changes.
@VINEIT if the DELL Server has 2 physical CPUs and 12 physical cores in total, then yes. 16-core pack for this device, for a regular Standard or Datacenter licensing.
Standard or Datacenter Edition is based on the amount of VMs
Azure Stack HCI requires Datacenter Edition
If it is one physical CPU with 12 physical Core you can mix and match to license 12 cores, like 6x 2 Core Packs of the same edition or other packs and filling up the rest with 2-core packs.
Mind that packs are available in different sizes with different rebates. So 1x 16-core pack might be even cheaper than 6x 2-core packs.
At times I've even seen 4-core packs in volume licensing price lists.
CSP (CSP Subscription mostly recommended due to the release of WS 2025 and more reasons), offer 8-core packs, only.
Understanding Licensing packs
License packs are literally packs. They can be seperated to be assigned to physical cores and even different servers. Like you can take one bottle of beer from a pack of 6.
The only thing is you have to take care about your paperwork in your SAM / Excel in case of an audit, that it remains clear what you did and most importantly when.
The reason for 8-core packs in CSP Subscription is that everything is licensed as in Azure.
Also CSP Subscription would allow a per VM licensing.
"Per VM" licensing
In opposite / or even in addition to "per core licensing", you can add more licenses
This makes especially sense in very special cases when having larger clusters with VMware or Proxmox or Azure Stack HCI, but only VERY few Windows Server VMs running on these and you want them to move within the cluster, without licensing every CPU core in this cluster.
The rule here is 8-core pack "per VM", license still assigned to the HW but it can move. The number of virtual CPUs of the VM is near irrelevant. It is 8 or a multiple of 8 like 8, 16, 24 etc.
so 2 vCPUs still require a minimum 8-core pack for this VM.
Thank you for the excellent summary @Robin Clive-Matthews
Windows Server licensing has a quite an amount of caveats but also chances to save :)
It depends on the licensing model (Volume Licensing like Open, Enterprise Agreement), CSP, SPLA (for hosting) etc. pp. Variety of Azure Benefits, BYOL benefits etc pp.
Even the perfect stated rule of @Dave Patrick becomes obsolete as soon choose for "per VM" licensing.
OEM licensing even allows to "break" the 8 Core per CPU / 16 Core per Server rule and allow you to pay only active CPU cores (de/activated to and present to the OS via UEFI setup), but this comes not handy if you want to add Volume Licensing Software Assurance. And then again the paperwork. Cannot really recommend unless you bought an OEM box with no intentions for Software Assurance and oversized the CPUs for whatever reasons.
Windows Server 2025 will offer on-demand licensing, but we consider it before not written in Product Terms.
Microsoft Licensing is often like white magic, and there is one source of trust to study:
Everything about it can be found here (and trusted for audit only here):
All other sources are complementary and not binding for audits (including my posting) ;)
Before checking details
- choose your licensing program you are into on the top bar
- if any, mind your licensing commitments to Microsoft (like MPSA, Enterprise Agreement), that you might not license certain products via other programs
- if you need to know the terms back in time of purchase use the date picker (if you know what you are doing).
I could recommend a good tutor on YT, but still Product terms beat any other information.