Hey Checkyourlogs Fans,

Introduction:
Intelligent Platform Management Interface (IPMI) controllers (Baseboard Management Controllers or BMCs) provide powerful out-of-band management capabilities for servers. However, if left insecure, IPMI can become a severe liability – attackers who compromise a BMC gain low-level access to the server (power control, BIOS access, etc.). This post details how to harden IPMI interfaces on ~5-year-old Intel-based servers (e.g. DataON appliances) by enforcing best practices and enabling centralized authentication. We’ll configure RADIUS-backed login (using Windows Server 2025 NPS) and add Cisco Duo multi-factor authentication (MFA) to meet security guidelines (e.g. NIST 800-53 IA-2(1) for MFA on privileged access). Real-world considerations like “break glass” accounts, logging/monitoring, and compliance benchmarks (CIS/NIST) are included for administrators preparing for security audits.

1. Hardening IPMI Interfaces

1.1 Secure IPMI Configuration – Best Practices:
Begin by locking down the IPMI itself before adding RADIUS or MFA. Key steps include:

  • Change Default Credentials: Nearly all BMCs ship with a default admin login (e.g. DataON BMC default is admin/admin1). Immediately rename or disable the default “ADMIN” user and set a strong password. Use a complex passphrase and enable any password policy or account lockout features provided by the IPMI (for example, many BMCs let you configure lockout after X failed attempts). This thwarts password-guessing attacks.
  • Least Privilege Accounts: If your IPMI supports multiple user roles (e.g., “User,” “Operator,” “Administrator,” etc.), assign the minimum rights required. Reserve Administrator-level access to as few accounts as possible. Disable or delete any unused accounts.
  • Network Isolation: Never expose IPMI to the public Internet. IPMI should be reachable only on secure management networks (preferably a dedicated VLAN or physical interface). On small networks without a separate management LAN, use IPMI’s built-in IP access control to whitelist only trusted IP ranges or jump hosts. For example, enable “IP Access Control” in the BMC web GUI and add rules permitting only your IT subnet or VPN gateway to reach the interface (all other sources dropped).
  • Use Secure Channels: Ensure the IPMI web interface is set to use HTTPS/TLS (if not by default). Install a trusted certificate or use the latest firmware to get modern ciphers. Disable cipher 0 (an IPMI setting that allows bypassing auth) if your BMC firmware is old enough to have it. Also, disable any legacy protocols you don’t need (e.g. IPMI 1.5, weak cipher suites, older SNMP versions).
  • Update BMC Firmware: Manufacturers like Supermicro regularly patch BMC firmware to fix vulnerabilities. On ~5-year-old hardware, check the vendor’s support site for firmware updates and apply the latest BMC firmware. This can fix known issues (e.g. authentication bypass, default cred backdoors, encryption flaws). Tip: Schedule regular firmware checks, and in the interim, consider disabling features like virtual media (TCP/UDP 623) if an unpatched vulnerability exists.
  • Logging and Alerts: Enable IPMI event logging and integrate it with your SIEM or alerting system. Many BMCs allow configuring a remote syslog target or SNMP traps. Turn this on to receive alerts for IPMI login attempts (both successful and failed) and critical BMC events. Logging is crucial for detecting abuse. Note that IPMI itself may have limited or no onboard authentication logs, so sending events to a central log server is recommended.

1.2 Enabling RADIUS/LDAP on the IPMI Web Interface:
Once basic hardening is in place, you can switch IPMI to use centralized authentication. Most enterprise-grade BMCs (including those in DataON Intel servers) support external directory services under a menu often called “External User Services” or “Directory Service”. Typically, you have options for LDAP/Active Directory or RADIUS authentication. We’ll use RADIUS (backed by AD via NPS) because it integrates easily with Duo MFA. (If your IPMI only supports LDAP and not RADIUS, see the Duo section for LDAP-based options.)

Here’s a step-by-step to enable RADIUS on the IPMI:

  1. Access IPMI Web GUI – Log in with a local admin account. Navigate to the configuration section for user authentication. On Supermicro-based interfaces, this is under Configuration > External User Services (or a similar name). You should see sub-options for “LDAP”, “Active Directory”, and “RADIUS”​.
  2. Configure RADIUS Settings: Check “Enable RADIUS Authentication”. Then enter:
    – Server Address: The IP address (or hostname) of your RADIUS server (we’ll set up NPS on Windows in the next section).
    – Port: UDP port for RADIUS (default 1812​). Change only if your NPS will listen on a non-standard port.
    – Secret: A shared secret string. Choose a complex secret (maximum length depends on BMC, often 16–32 chars, no spaces​). You’ll need to configure the same secret on the NPS side.

(Some BMCs have additional checkboxes; e.g. Lenovo’s ThinkSystem BMC lets you toggle whether RADIUS-authenticated users get KVM or virtual media privileges. Enable those if needed for full remote console functionality.)

  1. Apply and Test: Save the RADIUS config. The IPMI should now attempt to use RADIUS for any new login. Test with a non-critical account first. Until we configure the RADIUS server, logins via RADIUS will fail – so don’t log out of the IPMI yet! First, configure NPS (section 2) and Duo (section 3). Keep a session open or have a backup way in.

1.3 “Break Glass” Local Account:
When using centralized auth, plan for a scenario where the RADIUS/AD system is unavailable (network outage, RADIUS service down, etc.). In such cases, you need a fallback local account to access IPMI. A best practice is maintaining one enabled local admin on the BMC as a break-glass account. For example, a user LOCALADMIN can be created with a strong password known to a few key people or stored in a password vault. This account should only be used in emergencies (e.g. when RADIUS is down or misconfigured). Document the procedure to switch off external authorization if needed. For instance, some IPMIs let you configure an order (try RADIUS first, then fall back to local if RADIUS is unreachable). Others might require accessing the BIOS or using IPMItool to disable RADIUS in an outage. Test your fallback plan.

Additionally, periodically rotate the password of the break-glass account and audit its usage (it should never be used if all is well). This will satisfy cyber insurance auditors that you won’t be locked out of critical systems if SSO/RADIUS fails while keeping that local account’s risk manageable.

2. RADIUS Server Setup (Windows Server 2025 NPS)

We will use Microsoft’s Network Policy Server (NPS) on Windows 2022 as our RADIUS server. NPS will authenticate IPMI login requests against Active Directory. Later, we’ll integrate Duo into this flow. Summary of steps: Install NPS, register it in AD, define the IPMI BMCs as RADIUS clients, and create policies to allow login for the appropriate AD users/groups (with necessary RADIUS attributes).

2.1 Install NPS Role:
On your Windows Server 2025 (which should be domain-joined), install NPS via Server Manager or PowerShell:

  • Server Manager GUI: Add Roles and Features → Network Policy and Access Services → Network Policy Server (and related management tools).
  • PowerShell: Run:
Install-WindowsFeature NPAS -IncludeManagementTools

This installs NPS (the service is called IAS internally). After installation, open the Network Policy Server management console (nps.msc).

2.2 Register NPS in Active Directory:
For NPS to authenticate domain users, it must be authorized in AD. Right-click NPS (Local) in the NPS console and choose “Register server in Active Directory”. Approve the action – this adds the NPS server’s machine account into the domain group “RAS and IAS Servers”. (You can verify in Active Directory Users and Computers -> Builtin container -> RAS and IAS Servers group). This step permits NPS to read user dial-in properties. You should see a confirmation “Network Policy Server is now a domain-authorized RADIUS server”. (PowerShell alternative: use the AD module to add the computer account to the group if GUI is unavailable.)

2.3 Configure RADIUS Clients (BMC IPs):
Next, tell NPS about the devices (RADIUS clients) requesting authentication. In the NPS console, expand RADIUS Clients and Servers > RADIUS Clients. Right-click and select New RADIUS Client. Create an entry for each server’s BMC.

  • Friendly Name: e.g. “DataON-BMC-Server1”
  • Address (IP or DNS): the IP address of the IPMI interface (e.g. 10.0.5.11)
  • Shared Secret: enter the exact secret string configured on the IPMI (RADIUS settings). For security, manually enter and confirm (avoid using the “Generate” for this scenario).
  • Vendor: You can leave this as “RADIUS Standard” (or choose the specific vendor if listed, though we will handle vendor-specific attributes in the policy).

Add each of your BMCs. They will appear in the list of RADIUS clients. Ensure the Enabled box is checked for each. (Below is an example screenshot of a RADIUS client entry in NPS for an appliance – in our case, it will show the IPMI’s IP and “RADIUS Standard” as vendor.):

Example: A BMC IPMI interface is added as a RADIUS Client in NPS (via the NPS console). The shared secret configured here must match the IPMI’s RADIUS secret.

2.4 Create Network Policy for IPMI Logins:
With clients defined, we create a Network Policy to authorize the incoming RADIUS requests from the IPMI. In NPS, under Policies > Network Policies, add a New policy. Configure it as follows:

  • Policy Name: e.g. “IPMI BMC Login Policy”.
  • Type: Grant access. (Select the “Access granted” radio button to ensure NPS will accept if conditions match.)
  • Conditions: Add conditions that identify who and what is allowed. For example:
    • Client IPv4 Address – specify the IP or subnet of your BMCs (so the policy only applies to requests from those IPs). Alternatively, use NAS Identifier or Friendly Name if you prefer to match on the RADIUS client name.
    • Windows Group—(Recommended) Specify an AD security group for IPMI access. For instance, create a group “IPMI-Admins” in AD and add the appropriate user accounts. Then, add a condition “User Group—DomainIPMI-Admins.” This ensures that only members of this group can log in via RADIUS.
  • Constraints: Under the Authentication Methods constraint, enable the protocols your BMC supports. Most IPMI implementations use PAP (unencrypted authentication) or possibly CHAP. Check “Unencrypted authentication (PAP, SPAP)” – otherwise, NPS will reject the request by default (because AD-based PAP is considered less secure). You may uncheck MS-CHAP and others if not needed. (If the BMC does support MS-CHAPv2 or PEAP, you’d configure those accordingly; in practice, PAP is often the only option for BMC RADIUS). Also, consider setting a Session-Timeout (e.g. 60 seconds) under Constraints > Session Timeout, matching any Duo push wait time (more on this in Duo section).

NPS Network Policy – “Authentication Methods” constraints. For IPMI RADIUS, enable PAP (and CHAP if needed) under “Less secure authentication methods.” This allows the BMC’s simple password exchange to be accepted by NPS​

  • Settings: Here, we’ll configure RADIUS attributes in the response. Click the Settings tab of the policy. By default, NPS might include “Framed-Protocol = PPP” and such; you can remove unnecessary items. Add the following:
    • Under Standard attributes, set “Service-Type” = Login. This tells the client this is an interactive login session.
    • Under Vendor-Specific attributes, we need to specify the user privilege for IPMI. Different BMC vendors use different Vendor IDs. For Supermicro-based BMCs (which use ATEN/ASPEED controllers), the Vendor ID is 10876. We will use Attribute Number 1 with a string that encodes the privilege. The format is H=x, I=x, where the values correspond to the privilege level. Use H=4, I=4 (meaning “Administrator” level) for full admin access.
      • In NPS GUI: Click Add > “Vendor-Specific.” Choose Enter Vendor Code = 10876, and check Yes, it conforms to RFC. Then, add an attribute with ID 1 of type String and set the value to H=4, I=4. (See the Supermicro IPMI documentation Appendix for these magic values—essentially 4=Administrator, 3=Operator, etc.).
      • Result: You should see a VSA like “Vendor-Code=10876, Vendor-Assigned-Attr=1, String=H=4, I=4” in the policy settings.

This vendor attribute is critical – without it, the BMC might authenticate the user but immediately deny access because it doesn’t know what role to assign. By sending H=4, I=4, we signal the BMC to log the user in as an Administrator. (If you wanted to assign a lower role via RADIUS, you’d use H=3, I=3 for Operator, etc., likely by configuring a separate policy based on group membership.)

CLI Note: You can automate the creation of this policy with PowerShell. For example, using the NPS module:

# Import NPS module

Import-Module Nps

# Create policy granting access for IPMI-Admins group

Add-NpsNetworkPolicy -Name "IPMI BMC Login Policy" -Condition @{UserGroups="DOMAIN\\IPMI-Admins"; ClientIPv4Address="10.0.5.11"} -GrantAccess $true -AuthenticationMethods @{PAP=$true; MSCHAPv2=$false}

# Then use Set-NpsNetworkPolicy to add attributes (this part is a bit tricky via PS; GUI is more straightforward for VSAs)
  1. Connection Request Policy: You can often use the default connection request policy (which says “Authenticate requests on this server”). If you plan to have NPS forward to another RADIUS (such as a Duo proxy – optional design), you would create a Connection Request Policy to forward matching requests to a remote RADIUS server group. Ensure the default policy is active so NPS will process authentications locally.
  2. Test RADIUS Authentication: With NPS running, you can test using a utility like radtest (on Linux) or NTRadPing (on Windows) to simulate a RADIUS login. However, since we will incorporate Duo, you might skip directly testing plain RADIUS unless you want to verify the AD integration first. If you do test now, use an account in the IPMI-Admins group and ensure NPS logs show an “Access-Accept” for the attempt. Also, watch for the Vendor-Specific Attributes in the output (NPS Event ID 6272 in Event Viewer will show details).

At this stage, your IPMI is configured to talk to NPS, and NPS will verify the AD username/password. If everything is correct, you can log into the IPMI via the web UI via an Active Directory account (in the allowed group). The process: IPMI sends RADIUS Access-Request to NPS; NPS checks AD creds; NPS responds Access-Accept (with the Service-Type and H=4, I=4 attributes); BMC logs you in with that privilege. Next, we’ll enhance this by adding Duo 2FA to the flow.

3. Cisco Duo MFA Integration

Adding multi-factor authentication to IPMI satisfies compliance requirements (e.g. requiring something you have, not just something you know). Cisco Duo can integrate with RADIUS in two ways:

  • Option A: Duo Authentication Proxy as RADIUS Server. In this model, the IPMI sends RADIUS directly to the Duo Proxy. The Duo Proxy, in turn, validates primary credentials (either via AD or by forwarding to another RADIUS like NPS) and then prompts for 2FA. Finally, it returns accept or reject. This is a common and straightforward integration.
  • Option B: Duo for NPS Extension. Duo provides an NPS plug-in that intercepts RADIUS authentications on the NPS server and triggers 2FA. This is simpler (there is no separate proxy service to manage) but may not support all scenarios. We’ll focus on Option A with the Duo Authentication Proxy, as it’s very flexible and can be run on the NPS server or another host.

3.1 Install Duo Authentication Proxy:
Download the latest Duo Authentication Proxy for Windows from Duo’s website. It’s a lightweight service. Installation Best Practice: If your NPS server is dedicated and not heavily loaded, you can install the Duo proxy on the same machine to minimize infrastructure. This is convenient, but NPS and Duo Proxy cannot listen on the same UDP port 1812 on the same IP. To avoid conflicts, you might configure Duo proxy to listen on a different port or use 127.0.0.1 vs the server’s main IP for one of them. Alternatively, install the Duo proxy on a separate small Windows server or even a Linux VM. A separate host can be cleaner, especially if you want high availability (you could run two Duo proxies behind a load balancer if needed). For our example, assume we install Duo proxy on the same Windows server as NPS, but we will configure it to use a different port.

Follow Duo’s instructions to install—essentially, run the installer and let it finish. It will install as a service (DuoAuthProxy) and put a config file at C: Program FilesDuo Security Authentication Proxyconfauthproxy. cf.

3.2 Configure authproxy.cfg for RADIUS-to-Duo:
Open the authproxy.cfg in a text editor (Notepad running as Administrator). We will add two sections:

  • [ad_client] – This section defines how to perform primary authentication against Active Directory. You must provide your domain controller(s) and a service account. For example:
[ad_client]

host=192.168.1.10 ; IP of domain controller

service_account_username=duoproxy_svc

service_account_password=YourSvcAcctPassword

search_dn=DC=example,DC=com

security_group_dn=CN=IPMI-Admins,OU=Groups,DC=example,DC=com

In the above: host can be repeated as host_2, etc., for multiple DCs. The service account should be a domain account with permission to read users (an essential user account works; no special privileges are needed). search_dn limits the scope of search (root of domain in example). security_group_dn is optional – if specified, Duo will only allow authentication for users in that AD group (here we align with the same “IPMI-Admins” group). This adds an extra check so that even if NPS weren’t filtering by group, the Duo proxy would.

  • [radius_server_auto] – This section makes the Duo proxy act as a RADIUS server (with automatic Duo push). We configure it to use the ad_client above for primary auth and our Duo cloud info for 2FA:
[radius_server_auto]

ikey=Integration key from Duo admin;

skey=Secret key from Duo admin;

api_host=your Duo API host, e.g. api-XXXXXXXX.duosecurity.com;

port=18120

radius_ip_1=192.168.1.5 ; IP of IPMI/BMC (RADIUS client)

radius_secret_1=same secret as in IPMI & NPS config;

client=ad_client

failmode=safe

Explanation: We use a non-standard port 18120 here to avoid conflict with NPS on 1812. The IPMI will later be pointed to port 18120 on this host (or you could have IPMI talk to NPS, which forwards to Duo, but here we have IPMI talk to Duo directly). The ikey, skey, api_host come from the Duo Admin Panel when you create a new Application (see next step). radius_ip_1 is the IP that the proxy will accept requests from – set this to your BMC’s address (you can list multiple, e.g. radius_ip_2, etc., or use 0.0.0.0/0 to accept any, but it is better to restrict). radius_secret_1 is the shared secret – use the same value you used in the IPMI and in NPS so that nothing changes on the IPMI side. client=ad_client ties this RADIUS service to the AD authentication section. failmode=safe means if Duo’s cloud cannot be reached, it will allow login after primary auth (you might choose secure to deny instead, depending on your risk appetite).

Save the file and restart the Duo Security Authentication Proxy service from Services.msc (or net stop DuoAuthProxy && net start DuoAuthProxy in a cmd prompt). Check C:\Program Files\Duo Security Authentication Proxy\log\authproxy.log for any startup errors (e.g. typos in config).

If your IPMI only supported LDAP/LDAPS instead of RADIUS, you could configure a [ldap_server_auto] section in the Duo proxy config to make it act like an LDAP directory with 2FA. In that case, IPMI would treat Duo as an LDAP server. The configuration would be similar (specifying client=ad_client and port 389 or 636). However, since our example uses RADIUS, we use the radius_server_auto approach.

3.3 Duo Cloud Setup (Applications & Users):
Log in to your Duo Admin Panel (sign up for Duo and get an account if you haven’t already). Perform these steps:

  • Create Application: In the Duo admin console, navigate to Applications and choose “Protect an Application.” Search for “Radius” or “RADIUS Client”. Duo has a generic RADIUS application type, “Duo Authentication Proxy with RADIUS Auto” (or similar). Select that. It will generate the credentials we just used in authproxy.cfg: an Integration Key (ikey), Secret Key (skey), and API Hostname. Copy those into the authproxy.cfg, as shown above. Adjust the application settings as desired (you can name it “IPMI RADIUS,” etc., in Duo for clarity).
  • Enroll Users: Duo requires that the users exist in its system to perform 2FA. If you set up Directory Sync (recommended for larger orgs), you can automatically sync the AD users (especially the IPMI-Admins group) into Duo. If not, you can manually add the specific users in the Duo Admin Panel (Users section) and send enrollment links. Each user should have at least one 2FA device (smartphone with Duo Mobile app, a phone number for SMS/voice, or hardware token). Duo’s radius_server_auto mode does not support inline self-enrollment, so users must be enrolled beforehand.
  • Configure Global/New User Policy: Adjust the policy for this Duo application, optionally. For instance, you might set “New user policy: Deny access” to be safe (so if an AD user not yet enrolled in Duo tries to log in, it will be rejected rather than auto-enrolled or bypassed). Also, consider setting a requirement for Duo Push or hardware tokens only in the Policy settings. If your organization mandates it, you could require Device Trust or other advanced policies, but that’s beyond the scope.

3.4 Point IPMI to Duo RADIUS & Test the Flow:
We need the IPMI to use the Duo Authentication Proxy for RADIUS to trigger MFA. We have two possible approaches:

  • The simplest is to change the RADIUS Server IP/port on the IPMI to the Duo proxy. For example, if the Duo proxy is on the same server as NPS (192.168.1.5) but is listening on port 18120, edit the IPMI RADIUS settings: set the Server Address = 192.168.1.5 and Port = 18120. The shared secret remains the same. This will send IPMI login requests straight to the Duo service (bypassing NPS’s own auth logic for now). Duo will check AD and then prompt 2FA.
    • (Alternate) If you prefer to keep IPMI pointing at NPS on 1812, you could instead create an NPS Connection Request Policy to forward to Duo. In that case, NPS would act as a proxy: Upon receiving the access request, it forwards to the Duo proxy as a remote RADIUS group. We’ll assume the direct approach (IPMI -> Duo) to reduce one hop for simplicity.
  • Perform a Login Test: With everything in place, try logging into the IPMI web interface using a domain user account enrolled in Duo. Here’s what should happen behind the scenes:
    • Primary Auth: The IPMI sends the username and password to the Duo proxy via RADIUS (PAP). Duo proxy receives this in the [radius_server_auto] service on port 18120. It then uses the [ad_client] to bind to AD and verify the username/password against Active Directory. (If the AD auth fails, Duo proxy sends back Access-Reject, and IPMI login fails immediately.)
    • Duo Push/Challenge: Since the primary authorization has been achieved, the Duo proxy contacts the Duo cloud service to perform the second factor. By default, in radius_server_auto mode, Duo will automatically send a Duo Push notification to the user’s device (or fall back to a phone call if no push device). The IPMI interface will not show any second prompt – the user sees the login page “waiting” as the push is sent. (Duo’s radius_server_auto is meant to be “transparent”; it doesn’t prompt for a code – which is good because the IPMI web GUI wouldn’t know how to ask for it interactively).
      • The user approves the push on their smartphone (or presses the appropriate key if it was a phone call).
    • Access Accept: Once the user approves, Duo proxy sends an Access-Accept back to the IPMI. Necessary: This Access-Accept must include the same vendor attribute for privileges. If we configured Duo to use client=ad_client, Duo proxy by default may not know to include the H=4, I=4 attribute. The duo can be set up to forward specific attributes, or we might need to incorporate that attribute configuration in an upstream RADIUS (if we had used NPS as primary via radius_client). For simplicity, one approach is to configure Duo to forward the RADIUS response from NPS. To do that, we would have set client=radius_client pointing to NPS (instead of ad_client), and NPS would then supply the vendor-specific attribute. This gets complex but is doable (Duo supports MS-CHAPv2 to upstream NPS if needed). If your IPMI fails to assign admin rights after Duo auth, you may need to adjust this. Alternatively, some BMCs (like Lenovo’s) might allow setting a default privilege for RADIUS users. Check your IPMI’s “Advanced RADIUS Settings” – for example, Lenovo enables KVM and Media for RADIUS users but still expects the attribute from the server for authZ. If needed, you can manually extend the Duo proxy to always send H=4, I=4 by editing its source dictionary (this is advanced – for now, assume we got it working by having NPS out of band or by Duo’s radius_client approach). In our scenario, since we directed IPMI to Duo, one quick fix is simply adding the vendor attribute in the authproxy.cfg RADIUS reply settings if Duo allows (Duo’s documentation suggests it will pass through attributes from the primary authenticator if radius_client is used).
    • IPMI Access Granted: The IPMI logs the user in. You should now see the web interface as that AD user. Test that you have appropriate privileges (try mounting virtual media or changing a setting to ensure you have admin rights). Check the Duo Admin Panel logs—they will show the 2FA prompt and outcome for that application. NPS (if it wasn’t used in this direct scenario) may not see anything since we bypassed it. The Duo proxy log will show entries for the transaction as well.

If the login fails, check each component: Does the Duo push reach your device? If not, maybe the radius request didn’t get to Duo – check the IPMI event (if any) or duo log. If push came but after approving, IPMI still said “Login failed”, likely the vendor attribute issue – IPMI may have received Access-Accept but without proper privilege, it might deny access. In that case, consider switching IPMI to point to NPS again and configure NPS to forward to Duo (so NPS can insert the attributes). Duo’s documentation for NPS integration might also help if you use the plug-in route.

3.5 Duo + NPS Alternative (NPS Extension):
For completeness: Duo offers an NPS Extension that you install on the NPS server. It automatically performs a 2FA after NPS validates credentials. If you prefer that route (perhaps to avoid running a separate proxy service or dealing with radius timeouts), you would leave IPMI pointing to NPS on port 1812, install the Duo NPS plugin, and configure it with your Duo application details. The user experience is similar (automatic push). The extension takes care of intercepting the RADIUS response, doing the push, and returning the result. The trade-off is slightly less flexibility (e.g. can’t easily do LDAP-only mode). Many have successfully used it for VPN and other network devices.

3.6 RADIUS Timeouts and Retries:
One crucial configuration: RADIUS client timeout. Duo pushes can take a few seconds for the user to approve. If the IPMI’s RADIUS client is impatient, it might give up. Check if your BMC allows setting a RADIUS timeout or retry count. Some BMC firmware have hidden settings (or IPMI RAW commands) to adjust this, but not constantly in the UI. Ideally, set the timeout to ~30 seconds and at least three retries. If you cannot change it and experience frequent timeouts, you might instruct users to use Duo preemptively. For example, Duo allows appending a factor in the password field (like entering MyPassword, pushing MyPassword, or using the phone as the password, which would auto-approve faster). But this is only if IPMI passes the literal string – many don’t allow a comma. So this may not be an option. In practice, using auto-push and a 10-15 second default timeout is usually fine. Monitor for rejects due to “user did not approve in time.” Users should hit approve quickly after entering their credentials.

4. Security Best Practices & Compliance Considerations

Enabling centralized auth and MFA significantly hardens the IPMI interface. Here, we map these steps to broader security best practices (including NIST SP 800-53 and CIS Benchmarks guidelines) and additional measures to consider:

  • MFA for Privileged Access (NIST IA-2(1)): IPMI accounts are highly privileged. By requiring MFA via Duo, you align with the NIST 800-53 IA-2 control for multifactor authentication on network access to privileged accounts. This is often mandated in cyber insurance questionnaires. Our Duo integration ensures that even if an attacker obtains an admin password, they cannot log in without the second factor.
  • Strong Passwords & Rotation (NIST IA-5): We enforced strong initial passwords on the BMC and used AD’s password policy for user accounts. Ensure your AD accounts (especially those in IPMI-Admins) have robust password policies (length, complexity, and expiry as per compliance). Also, periodically rotate the RADIUS shared secret (document the process since you’d need to update both BMC and NPS/Duo). The “break glass” local account password should be rotated and stored in a secure secrets vault, per CIS recommendations for service accounts.
  • Disable Defaults (CIS Benchmark): We removed default credentials and default settings (cipher 0). This satisfies CIS benchmarks to eliminate vendor default accounts and open services. Check if your BMC has any other default config – e.g. some older IPMI had default SNMP community “PUBLIC” – if so, change it or disable SNMP. Also, consider uploading a proper SSL certificate to the IPMI if required by policy (some security standards flag self-signed certs, though this may be low priority for an internal interface).
  • Network Segmentation (CIS Controls): We placed IPMI on isolated networks or used access control to limit exposure. This adheres to CIS Control guidelines to protect management interfaces. Additionally, ensure firewall rules restrict IPMI access to only what’s needed (UDP 1812/18120 from NPS/Duo, TCP 443 from admin subnets, etc.)—Block IPMI’s ports from any untrusted networks.
  • Firmware and Patching (NIST SI-2): Regularly update the BMC firmware. Treat the BMC like an appliance that needs firmware maintenance. Many BMCs also have OS updates (e.g., if running a Java KVM applet or Redfish service). Subscribe to vendor advisories (e.g., Supermicro security bulletins) so you know new vulnerabilities (e.g., the USB redirection flaw Eclypsium found).
  • Logging & Monitoring: Make sure all authentication attempts are logged. In our setup:
    • NPS logs events in Windows Event Viewer (under Custom Views > Server Roles > Network Policy and Access Services). Successful and failed attempts are logged (with username, client IP, etc.). Action: Forward these events to your SIEM (via Windows Event Forwarding or an agent). Precisely monitor for multiple failed IPMI login attempts, which could indicate password guessing or a misconfigured Duo causing lockouts.
    • Duo provides logs in its admin panel and can send alerts on anomalies (like repeated denied 2FA requests). Consider enabling Duo’s notifications for suspicious logins or user lockouts.
    • The IPMI itself—if it supports Syslog—should be configured to send to your log server. Even if using RADIUS, the BMC might log an “authentication failure” event internally. Having those logs can provide a direct audit trail on the device.
    • Implement alerting for critical events: e.g., alert if the break-glass local account is used (that might indicate RADIUS was down or someone is trying to bypass). Also, alert on any IPMI login from unusual source IPs (if someone somehow accesses it outside the expected range).
  • Periodic Access Reviews: Keep the AD group (IPMI-Admins) membership limited and reviewed. This addresses governance – you should know who can manage servers via IPMI. Any changes (adds/removes) to that group should trigger an email notification to the sysadmin team.
  • Service Account Protection: The Duo service_account_username we used to bind to AD should be a low-privilege domain account. Follow least privilege (it just needs read access to user objects). Deny interactive logon for that account in AD. As mentioned, rotate its password per policy and update the auth proxy.cfg when you do.
  • Test “What-If” Scenarios: Simulate the failure scenarios to ensure your hardening doesn’t lock you out:
    • Temporarily stop the Duo proxy service and attempt an IPMI login. Does the fail mode allow you in (if set to safe) or properly deny you (if secure)? Ensure it aligns with your documented procedure (safe mode might let AD-only auth through if the Duo cloud is down—decide if that’s acceptable or if you prefer it fail closed).
    • Take NPS/Duo offline entirely—verify you can still use the local account to log in to IPMI (this might require booting into BIOS to disable RADIUS if the IPMI firmware doesn’t automatically fallback. That’s why having a dedicated NIC or physical access is essential for break-glass).
  • Compliance Evidence: Finally, document these configurations for your audit binder: Export the NPS configuration (Export-NpsConfiguration PowerShell cmdlet) and save the policy details showing the MFA integration. Screenshot the IPMI config pages (showing RADIUS enabled, IP access control rules, etc.). Auditors often require proof of enforcement, so having those ready helps. For CIS Benchmark alignment, you can note that “IPMI interface is integrated with AD and MFA, default admin disabled, access restricted to management network, logging enabled to SIEM” – which covers multiple CIS controls (Inventory and Control of Enterprise Assets, Secure Configurations, etc.).

Conclusion: We significantly improved the security posture of these critical management components by hardening the IPMI interfaces with strong configuration and layering on RADIUS + Duo MFA. Out-of-band management controllers are often overlooked in security assessments, but incidents have shown that they can be a gateway for attackers if not properly secured. Implement the above measures to ensure your servers’ BMCs are an asset, not a liability. This approach meets the high standards required by cybersecurity frameworks and cyber insurance auditors, giving you peace of mind and a strong story to tell in compliance reviews.

Lastly, remember that security is an ongoing process – review these settings regularly, keep firmware and software (NPS/Duo) updated, and adjust as new best practices emerge. Happy (and secure) managing!

Thanks,

 

Dave Kawula – MVP