I'm trying to configure the dedicated XML agent on IOS XR 4.2.3 (ASR9K) . The API guide says to do the

xml agent
aaa authorization exec default local

which I did, and I can connect to the router on port 38751, but then I get

telnet 38751

Escape character is '^]'.

User Access Verification

Username: aaronw
Password: blah

User Access Verification

Username: aaronw
Password: realpassword
Session start failed :'AAA API' detected the 'fatal' condition
'No method could process the authorisation request'Connection closed by foreign host.

So if I put in a fake password, it knows that it's the wrong one, and doesn't go any further, but when I put in my real password it looks like I'm missing some kind of link-up between the authorization engine and the XML engine. If I take out the aaa authorizaion exec default local, I get a slightly different error:

Session start failed :'AAA API' detected the 'fatal' condition 
'Requested function is     not configured'

I know the API guide linked is the 4.1 version, but I can't find the 4.2 version of the same document. Also, the XML tty agent (i.e., typing 'XML' at the # prompt) does work as expected.

RP/0/RSP0/CPU0:ios#xml echo format 
Tue May 21 20:32:01.802 UTC
XML> exit

In IOS-XR, there are different concepts of authorization than in classic IOS. In classic IOS, there's only command authorization, which allows or denies specific commands, typically sent to a tacacs+ or radius server. In IOS-XR, there is command authorization (aaa authorization commands) (but you're better off doing this via task-groups) and exec authorization(aaa authorization exec) , which controls who can actually start an exec session.

It appears that using the normal access method (ssh/telnet to the vtys) that if you're authenticated, no other authorization is necessary, but if you start the XML agent on its own dedicated port, then that use must be authorized. In my particular case, we are using a TACACS server for authentication, and I was specifying to use local authorization. The username does not exist on the router, so using the local method 'aaa authorization exec default local' caused authorization to fail. Changing it to 'aaa authorization exec group tacacs+ local' caused it to get the 'authorization OK' from the TACACS servers, and all is well.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.