> ## Content Index
> Fetch the complete content index at: https://www.pinglabz.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# ISE MAB Lab: Why a Known Printer Still Gets 15039 DenyAccess
- URL: https://www.pinglabz.com/ise-mab-15039-denyaccess-printer/
- Published: 2026-10-30T03:55:55.000Z
- Updated: 2026-10-30T03:55:55.000Z
- Description: The printer's MAC was in ISE, in the right endpoint identity group, and MAB authentication passed. ISE still sent an Access-Reject. The authorization rule was matching a MAC string that the switch never sends. Here's the lab, the evidence and the fix.
- Author: Jaime
- Tags: 802.1X, Labs, Troubleshooting, Network Security

Printers, badge readers, cameras and the old box in the corner that nobody owns can't run an 802.1X supplicant. For those, the switch falls back to **MAC Authentication Bypass (MAB)**. It sends the device's MAC address to ISE as both the username and the password, and ISE decides what the device gets.

MAB is simple, and that's exactly why it's easy to get subtly wrong. In this lab the printer is known to ISE, sits in the right endpoint identity group, and passes authentication. It still gets refused with **15039 Rejected per authorization profile**. The cause is one authorization rule written against the MAC in the wrong format.

I built this in my home lab with Cisco ISE 3.5 and a Cisco IOSv-L2 15.2 access switch. All the output below is real. Addresses and MACs are documentation values.

If you want the theory first, read [MAC Authentication Bypass (MAB) Configuration on Cisco IOS XE and ISE](https://www.pinglabz.com/mab-configuration-cisco-ios-xe-ise/). If you've done MAB against FreeRADIUS before, [MAB with FreeRADIUS on Cisco](https://www.pinglabz.com/mab-freeradius-cisco-lab/) is the same switch side with a different server.

## The lab

| Device  | Role                              | Addressing                                               |
| ------- | --------------------------------- | -------------------------------------------------------- |
| ise35   | Cisco ISE 3.5, RADIUS server      | 192.0.2.10                                               |
| acc-sw2 | MAB authenticator                 | Gi0/0 10.86.254.10/24 in VRF MGMT; Vlan869 10.86.69.1/24 |
| prn-01  | Headless "printer", no supplicant | 10.86.69.10/24, MAC 00:00:5E:00:53:10, on Gi0/3          |

There are two VLANs on the switch:

- **VLAN 999 PARKING** is the port's configured access VLAN. It has no SVI and goes nowhere. A device that isn't authorized stays here.
- **VLAN 869 PRINTERS** has the gateway, 10.86.69.1\. ISE puts the printer here when it's authorized.

So the printer is configured with a VLAN 869 address but plugged into a port that starts in VLAN 999\. It can only reach its gateway if ISE says yes.

## ISE side

**Network device.** `acc-sw2` is added under **Administration > Network Resources > Network Devices** with its management address, 10.86.254.10/32, because that's where RADIUS comes from. If that's wrong, you get a different failure entirely; see [Fixing 11007 "Could not locate Network Device"](https://www.pinglabz.com/ise-11007-could-not-locate-network-device/).

**Endpoint identity group.** Under **Administration > Identity Management > Groups > Endpoint Identity Groups** I created `Lab-Printers` and added the printer's MAC to it as a static assignment.

[![Endpoint identity group Lab-Printers with 00:00:5E:00:53:10 statically assigned](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ise-mab-05-endpoint-group.png)](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ise-mab-05-endpoint-group.png?ref=pinglabz.com)

**Authorization profile.** `Printer-VLAN869` is an Access-Accept with the common task **VLAN** set to `869`. ISE sends that to the switch as the three tunnel attributes (Tunnel-Type VLAN, Tunnel-Medium-Type 802, Tunnel-Private-Group-ID 869).

**Policy set.** A new set, `Wired-MAB`, sits above Default and matches the built-in `Wired_MAB` condition:

- **Authentication policy:** Default uses `Internal Endpoints`, with **If User not found** set to `CONTINUE`. That's the normal MAB setting. An unknown MAC isn't rejected at authentication, so authorization still gets a chance to handle it.
- **Authorization policy:**
- `Printers` matches `Radius·Calling-Station-ID EQUALS 0000.5e00.5310` and returns `Printer-VLAN869`.
- Default returns `DenyAccess`.

[![Wired-MAB policy set with the Printers rule matching Calling-Station-ID 0000.5e00.5310](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ise-mab-12-policy-set-rules-fault.png)](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ise-mab-12-policy-set-rules-fault.png?ref=pinglabz.com)

That `Printers` rule is the fault. It looks reasonable: I copied the MAC straight out of `show mac address-table`. Keep reading.

## Switch side

This is the relevant configuration on acc-sw2\. The shared secret is a placeholder.

```text
vrf definition MGMT
 address-family ipv4
 exit-address-family
!
interface GigabitEthernet0/0
 description OOB management
 vrf forwarding MGMT
 ip address 10.86.254.10 255.255.255.0
!
ip route vrf MGMT 0.0.0.0 0.0.0.0 10.86.254.1
!
vlan 869
 name PRINTERS
vlan 999
 name PARKING
!
interface Vlan869
 ip address 10.86.69.1 255.255.255.0
!
aaa new-model
radius server ISE-1
 address ipv4 192.0.2.10 auth-port 1812 acct-port 1813
 key <RADIUS_SHARED_SECRET>
!
aaa group server radius ISE
 server name ISE-1
 ip vrf forwarding MGMT
 ip radius source-interface GigabitEthernet0/0
!
aaa authentication dot1x default group ISE
aaa authorization network default group ISE
aaa accounting dot1x default start-stop group ISE
radius-server attribute 6 on-for-login-auth
radius-server attribute 8 include-in-access-req
radius-server vsa send accounting
radius-server vsa send authentication
dot1x system-auth-control
!
interface GigabitEthernet0/3
 description prn-01 printer (MAB)
 switchport access vlan 999
 switchport mode access
 authentication open
 authentication order mab
 authentication priority mab
 authentication port-control auto
 mab
 spanning-tree portfast edge

```

A few notes:

- `authentication order mab` and `priority mab` mean the port doesn't wait for 802.1X timeouts first. A printer will never answer EAPOL, so there's no point spending 30+ seconds on it.
- `aaa authorization network default group ISE` is required for the VLAN in the Access-Accept to be applied. Without it, the switch authenticates the port and ignores the result.
- `authentication open` is there because of my lab switch. The virtual IOSv-L2 only learns the MAC, and so only starts MAB, when the port is in open mode. On Catalyst hardware a closed port kicks off MAB from the first frame, so leave it out there unless you're deliberately running [low-impact mode](https://www.pinglabz.com/802-1x-deployment-modes/). In this lab the printer still goes nowhere while it's unauthorized, because VLAN 999 has no gateway.

## Break it: the known printer is denied

Plug the printer in, let it send traffic, and look at the port:

```text
acc-sw2#show authentication sessions interface GigabitEthernet0/3 details
            Interface:  GigabitEthernet0/3
          MAC Address:  0000.5e00.5310
         IPv4 Address:  10.86.69.10
            User-Name:  00005e005310
               Status:  Unauthorized
               Domain:  UNKNOWN
       Oper host mode:  single-host
      Restart timeout:  60s (local), Remaining: 40s
    Common Session ID:  0A56FE0A0000000E000EB52C
       Current Policy:  POLICY_Gi0/3

Method status list:
      Method            State
      mab               Stopped

```

The User-Name is the MAC with no separators. That's MAB working as designed. The status is `Unauthorized`, though, and the switch will retry every 60 seconds. The port stays in VLAN 999:

```text
acc-sw2#show vlan brief | include 869|999
869  PRINTERS                         active
999  PARKING                          active    Gi0/3

```

The RADIUS counters show the important detail. ISE is answering every request, and the answer is no:

```text
acc-sw2#show aaa servers
RADIUS: id 1, priority 1, host 192.0.2.10, auth-port 1812, acct-port 1813
     State: current UP, duration 791s, previous duration 0s
     Dead: total time 0s, count 0
     Authen: request 7, timeouts 0, failover 0, retransmission 0
             Response: accept 0, reject 7, challenge 0

```

Rejects with zero timeouts mean this isn't a reachability, shared secret or network device problem. Those show up as timeouts, because ISE silently drops requests it can't trust. Here ISE got the request, understood it and decided to refuse it, so the answer is in Live Logs.

### What ISE sees

**Operations > RADIUS > Live Logs** shows a red line for the printer's MAC every time the switch retries:

[![Live Logs: repeated MAB failures for 00:00:5E:00:53:10 in Wired-MAB](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ise-mab-10-livelog-mab-deny.png)](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ise-mab-10-livelog-mab-deny.png?ref=pinglabz.com)

Open the detail report:

[![Live Logs detail: 15039 Rejected per authorization profile, Identity Group Lab-Printers](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ise-mab-11-livelog-mab-deny-detail.png)](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ise-mab-11-livelog-mab-deny-detail.png?ref=pinglabz.com)

Read it top to bottom:

- **Failure Reason:** `15039 Rejected per authorization profile`. Authentication was fine; this is an authorization result.
- **Authentication Policy:** `Wired-MAB >> Default`, with identity store `Internal Endpoints`. The right policy set was hit.
- **Identity Group:** `Lab-Printers`. **ISE already knows exactly what this device is.**
- **Authorization Policy:** `Wired-MAB >> Default`, with Selected Authorization Profile `DenyAccess`. The `Printers` rule did not match.
- **Steps:** `15036 Evaluating Authorization Policy` → `15016 Selected Authorization Profile - DenyAccess` → `15039`.

So the endpoint is in the group, but the rule meant for it never fires. Compare what the rule is looking for with what actually arrived. The successful run below shows the field plainly. ISE sees **Calling-Station-ID as `00-00-5E-00-53-10`**: uppercase hex with hyphens. My rule wanted `0000.5e00.5310`, the dotted Cisco format you see in `show` commands. `EQUALS` is a literal string comparison, so it never matched, and everything fell through to Default.

This is the classic MAB trap. There are at least three MAC formats in play: Cisco dotted on the CLI, colon-separated in the ISE GUI, and hyphenated in the RADIUS attribute ISE evaluates. A rule written against the wrong one fails silently, and nothing in the GUI warns you.

## Fix it: authorize on the identity group, not the MAC string

I could correct the string to `00-00-5E-00-53-10`, and it would work for this printer. That still means one rule, or one ever-growing OR list, per MAC, and it's easy to get wrong again with the next device.

The better fix uses what ISE already worked out: the endpoint's group. I edited the `Printers` rule so its condition is:

```text
IdentityGroup·Name EQUALS Endpoint Identity Groups:Lab-Printers

```

The profile stays `Printer-VLAN869`. Adding the next printer is now one step: put its MAC in `Lab-Printers`. The policy doesn't change.

[![Wired-MAB policy set after the fix: Printers rule matching the Lab-Printers identity group](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ise-mab-22-policy-set-rules-fixed.png)](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ise-mab-22-policy-set-rules-fixed.png?ref=pinglabz.com)

Then I cleared the port so it re-authenticated immediately, instead of waiting for the 60-second restart:

```text
acc-sw2#clear authentication sessions interface GigabitEthernet0/3

```

## Prove it

### Switch

```text
acc-sw2#show authentication sessions interface GigabitEthernet0/3 details
            Interface:  GigabitEthernet0/3
          MAC Address:  0000.5e00.5310
         IPv4 Address:  10.86.69.10
            User-Name:  00-00-5E-00-53-10
               Status:  Authorized
               Domain:  DATA
       Oper host mode:  single-host
    Common Session ID:  0A56FE0A0000000F001667A1
      Acct Session ID:  0x00000001
       Current Policy:  POLICY_Gi0/3

Server Policies:
           Vlan Group:  Vlan: 869

Method status list:
      Method            State
      mab               Authc Success

```

`Authorized`, `Authc Success`, and under **Server Policies** the VLAN that came from ISE: `869`. The port has moved:

```text
acc-sw2#show vlan brief | include 869|999
869  PRINTERS                         active    Gi0/3
999  PARKING                          active

acc-sw2#show mac address-table interface GigabitEthernet0/3
Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
 869    0000.5e00.5310    DYNAMIC     Gi0/3

```

The RADIUS counters show the first accept:

```text
     Authen: request 15, timeouts 0, failover 0, retransmission 0
             Response: accept 1, reject 14, challenge 0

```

And the printer can finally reach its gateway:

```text
acc-sw2#ping 10.86.69.10 repeat 3
Sending 3, 100-byte ICMP Echos to 10.86.69.10, timeout is 2 seconds:
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 2/5/12 ms

```

From the printer side, `ping 10.86.69.1` went from 100% loss to `3 packets transmitted, 3 packets received, 0% packet loss`.

### ISE

Live Logs now shows green lines above the earlier failures:

[![Live Logs: MAB passes for 00:00:5E:00:53:10 above the earlier failures](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ise-mab-20-livelog-mab-pass.png)](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ise-mab-20-livelog-mab-pass.png?ref=pinglabz.com)

[![Live Logs detail: 5200 Authentication succeeded, Wired-MAB >> Printers, Printer-VLAN869](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ise-mab-21-livelog-mab-pass-detail.png)](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ise-mab-21-livelog-mab-pass-detail.png?ref=pinglabz.com)

- **Event:** `5200 Authentication succeeded`
- **Authorization Policy:** `Wired-MAB >> Printers`
- **Authorization Result:** `Printer-VLAN869`
- **Calling Station Id:** `00-00-5E-00-53-10`. This is the format the original rule should have used.
- **Result:** `Tunnel-Private-Group-ID (tag=1) 869`

## Checklist for "MAB passes but the device is denied"

When a known MAB device gets 15039 or lands on the wrong result:

1. On the switch, run `show aaa servers`. Rejects with no timeouts mean ISE is answering, so look at policy, not the network.
2. In the Live Logs detail, check **Identity Group**. If it's the group you expect, the endpoint side is fine.
3. Check **Authorization Policy**. If it says `>> Default`, your rule didn't match. Compare every value in the rule with the attributes in the same report.
4. For MAC-based conditions, compare against **Calling Station Id** in the report, not the CLI or GUI format.
5. Prefer `IdentityGroup·Name` (or profiling) conditions over literal MACs. They survive format changes and scale past one device.
6. Make sure `aaa authorization network` is configured, then confirm the VLAN under **Server Policies** in `show authentication sessions ... details`.

For more on how ISE hands VLANs to the switch, see [Dynamic VLAN Assignment with 802.1X and Cisco ISE](https://www.pinglabz.com/dynamic-vlan-assignment-802-1x-cisco-ise/).