Dynamic Authorization Failed #CTSREQUEST# (SDA 9800 WLC & ISE)

[mattw]

Hi,

I'm getting my moneys worth from the community this week

I have a 9800-40 WLC running 17.3.4c which is integrated with DNAC for SDA.

Fabric wireless works fine apart from micro-segmentation with SGTs.

If I log into the WLC and run a "show cts environment-data" it does not show the SGTs

ISE RADIUS live logs report "5417 Dynamic Authorization failed" (see attached).

All the AAA/RADIUS/COA/etc config was pushed to the WLC from DNAC so should be correct.

Any ideas how I can resolve this?

[thomas]

Sorry, I'm not opening a *.docx or *.pdf file posted to a community site.

Consider attaching plain text files for long configs or debug output and attaching images inline directly.

You may also use the Insert Code feature of the editor.

If COA failed it's probably a lack of COA configuration on your WLC.

See ▶ Securing Cisco Catalyst Wireless with ISE using mPSK / iPSK / 802.1X

06:50 AAA RADIUS Config

[mattw]

No worries @thomas, 

The config should be correct because it's all been pushed by DNAC and you'd hope DNAC knows what it's doing

Here is the output from debug aaa coa:

AAA request is from proxycoa proxy create aaa protocol :radius coa proxy relay coa resp(iosd)coa proxy create aaa protocol ,size required to flatten attr list : 199coa proxy create aaa protocol :attr list flattened filled buf size : 199coa proxy create aaa protocol :CoA Response Detailscoa proxy create aaa protocol :Attr list : 
<<  username             0   "#CTSREQUEST#">>
<<  nas-ip-address       0   10.201.0.196>>
<<  Event-Timestamp      0   1668187180 (0x636E842C)>>
<<  ssg-command-code     0   38 23 43 54 53 52 45 51 55 45 53 54 23 >>
<<  reply-message        0   "Req init fail">>
<<  error-cause          0   15 [Resource Unavailable]>>coa proxy create aaa protocol :server:160.0.201.10 cfg_saddr:196.0.201.10 udpport:10318 sport:0, tableid:0iden:14 rad_code:43 msg_auth_rcvd:TRUE coa_resp:NACKE40AF95190C1704BB473C1D4DA039C36coa proxy create aaa protocol,msg send to end point 'SMD' succeededAAA request is from proxycoa proxy create aaa protocol :radius coa proxy relay coa resp(iosd)coa proxy create aaa protocol ,size required to flatten attr list : 199coa proxy create aaa protocol :attr list flattened filled buf size : 199coa proxy create aaa protocol :CoA Response Detailscoa proxy create aaa protocol :Attr list : 
<<  username             0   "#CTSREQUEST#">>
<<  nas-ip-address       0   10.201.0.196>>
<<  Event-Timestamp      0   1668187181 (0x636E842D)>>
<<  ssg-command-code     0   38 23 43 54 53 52 45 51 55 45 53 54 23 >>
<<  reply-message        0   "Req init fail">>
<<  error-cause          0   15 [Resource Unavailable]>>coa proxy create aaa protocol :server:160.0.201.10 cfg_saddr:196.0.201.10 udpport:10318 sport:0, tableid:0iden:15 rad_code:43 msg_auth_rcvd:TRUE coa_resp:NACK5FC0D0847F5871B01CBED0948F021F41coa proxy create aaa protocol,msg send to end point 'SMD' succeeded

And screenshots of the RADIUS live logs:

[mattw]

In the CTS debug output, in a couple of places it's writing the NAD and Server IPs with the octets 'backwards'.

I don't know if this is by design or some really weird bug??

E.g. : 

server:160.0.201.10

The IP of the server is actually: 10.201.0.160 (and .161)

And:

cfg_saddr:196.0.201.10

 The IP of the WLC is actually: 10.201.0.196

Weird huh??

[jeaves@cisco.com]

Have a look through this new 9800 guide specifically written for SGT support. Before the env data can be downloaded, the platform needs a PAC. Start at the section entitled 'C9800 CTS Provisioning and Device Enrollment'. The doc doesn't cater for DNAC automation but you should be able to compare: https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/tech-notes/Wireless_9800_Group-Based_Policy_Guide_edited.pdf

[mattw]

Thank you jeaves@cisco.com. Weirdly, the PAC has been downloaded to the WLC but it just won't download the cts environment data. I've cleared and re-added new cts credentials on the WLC and reflected this change in the NAD config on ISE but still no joy. I think I feel a TAC case coming

[hslai]

@mattw

Since you are doing SD-Access, the wireless clients are enforced by the edge switches or others but NOT by WLC or AFAIK. See SD-Access Wireless Design and Deployment Guide - Cisco DNA Center 2.1.1 

Thus far, I've NOT seen DNAC provisioned the complete CTS configurations to a 9800 WLC. Please do follow Joff's guide.

In one of WLC's I checked, DNAC provisioned several AAA radius server groups even though the deployment has only one ISE as the AAA RADIUS server. As a result, I created a new group and use that for the CTS server list and in the AAA method list for CTS. Below are the diff:

!! Define a new radius server group with the existing ISE server dnac-radius_10.1.100.3
aaa group server radius ctsRadGroup
 server name dnac-radius_10.1.100.3
 ip radius source-interface Vlan100
 deadtime 5
!
!! Add a new method list
aaa authorization network ctsAuthZList group ctsRadGroup
!
!! Tell CTS to use the new method list
cts authorization list ctsAuthZList
cts sgt 2
!

After that, I had to refresh the environment data with the command below to get the environment data

cts refresh env

[mattw · Accepted solution]

Thank you @hslai. I had already done what you suggested (added the authz method and list) but I still get the authz failed message which is somewhat frustrating. I think TAC will need to get involved in this one.

[hslai]

@mattw  Yes, definitely good to engage TAC. Do let us know if we may assist.

[hslai]

@mattw FYI

Last week Joff worked with us on a similar issue for Over-the-Top (OOT) wireless. We found the following

• All ISE nodes in the TrustSec AAA server list should be configured in the NADs' allowed-CoA list. Also, each NAD in ISE should be configured to use one of these ISE nodes to perform CoA requests for TrustSec policy updates. By default, ISE uses the primary ISE node for such CoA requests so likely we need to ensure NADs accepting CoA requests from the primary ISE node
• On 9800 WLC, at least one policy profile should be enabled for TrustSec policy enforcement; for example,

  • my9800-WLC#show wireless cts summary
    Local Mode CTS Configuration
     
    Policy Profile Name               SGACL Enforcement     Inline-Tagging   Default-Sgt      
    ----------------------------------------------------------------------------------------
    pp-open                           DISABLED              DISABLED         0                
    pp-dot1x                          ENABLED               ENABLED          777              
    asim43-policy                     DISABLED              DISABLED         0                
    guest-policy-tag                  DISABLED              DISABLED         0                
    default-policy-profile            DISABLED              DISABLED         0                
     
    Flex Mode CTS Configuration
     
    Flex Profile Name                 SGACL Enforcement     Inline-Tagging   
    -----------------------------------------------------------------------
    named-flex-profile                DISABLED              DISABLED         
    default-flex-profile              DISABLED              DISABLED         
    asim43-flex-profile-7             DISABLED              DISABLED   

• My setup did not have any so Joff created one for me as 

  wireless profile policy sampleTestPolicy
   aaa-override
   cts role-based enforcement
   cts sgt 2
   nac
   vlan 100
   no shutdown

These two above were what we missed. Other things to check for are:

• Check if PACs downloaded: 

  show cts pacs​

• Check if bindings 

  show cts role-based sgt-map all​

• Check if the aaa server connectivity is fine 

  test aaa group radius someUser somePass new-code​

• Check if the client is assigned with sgt 

  show wireless client mac-address <> detail​

• Check if the NAD added in ISE with TrustSec configuration
• Check if the NAD's device name and ip are consistent between ISE and NADs.

[Damien Miller]

I will add on to all the good things @hslai posted above. We just had an issue with this in a customers lab that's running cts manual on the uplinks. The configuration was all correct, we scanned the network devices and ISE with a fine tooth comb only to come up with nothing. We reloaded the controllers, still nothing. 

Then my peer tried to ping ISE at the configured MTU, 1500 bytes in this case. The same ping failed to the gateway. 

• From the WLC CLI, ping x.x.x.x size 1500

The pings failed, all the way down to 1492 bytes where it worked. We were missing eight bytes, a crucial eight bytes that was causing packets to get silently discarded by the interfaces. The eventual fix was to completely remove the cts manual and port channel config from both controllers and rebuild the uplinks. It worked after that. This has been a common problem I've seen in the past with cts manual links having some kind of internal MTU mismatch not visible in the startup/running configuration.

[SzantaiNorbert]

Hello All,

I had the exact same issue and i spent hours looking into debugs, but my solution was pretty simple:

My CLI settings were:
wifi-hq#sh run cts
!
cts authorization list ISE-SXP-Nodes
cts sxp enable
cts sxp connection <ip> source <ip> password default mode local listener hold-time 0 0
cts sxp connection  <ip> source <ip> password default mode local listener hold-time 0 0
cts sxp default source-ip <ip>
cts sxp default password <password>
cts sxp retry period 30
cts role-based enforcement

And in the GUI, the cts authorization list was empty:

After debugging I found out that the " ISE-SXP-Nodes" object was not an authorization list, but an AAA server group. But WLC allowed me on the CLI to use it as an authorization list.

I created a cts authorization list where i referenced that AAA server group and it started working immediately.:

aaa authorization network ISE-SXP-Nodes group ISE-SXP-Nodes

If there would be some kind of object type validation in the WLC CLI, that would be great.

Regards,

Norbert