RadiusAccountingStart/Stop always reports same username

Hi,

I have been testing with the pxGrid SDK and the default samples.

I've followed the technical document with regards to testing each item and as I was testing a subscriber model to the RadiusAccountingStart/Stop, I noticed that when using the RadiusSimulator.jar from the pxGrid website - that the username is always logged as "user1".

The guide indicates that user1 is the default if left blank but i'm specifying a username in the call to the jar.

For example, if you run "session_subscribe.sh" in one window. Then execute the radiussimulator.jar with the following:

java -cp RadiusSimulator.jar -DUSERNAME=user5 -DPASSWORD=Aa123456 _DCALLING_STATION_ID=11:11:11:11:11:11 -DAUDIT_SESSION_ID=1024 _DFRAMED_IP_ADDRESS=172.18.1.26 _DFRAMED_IP_MASK=255.255.255.0 RadiusAccountingStart 172.18.1.35

I see the session notification but it's always for user1. Is this a known issue?

Also, is it possible to subscribe the the RadiusAuthentication calls? I'm still trying to find a way to determine how to make that work.

Thanks!

Hi David

Here is feedback from Cisco Dev Engineering on your query:

Subject: Re: pxGrid query on DevNet forum

Very likely, the audit session id had remained as 1024. The first call made was using the default user1 and audit session id 1024. Since the user is already set in session directory for this session.

Hi Brian and R&D - first thank you for the response.

I have done some further testing and have a couple follow on questions to better understand what I am seeing.

I understand that changing the session should be done for each new user, that's not a problem. However, I still do not see any published session data when running the RadiusAuthentication option of RadiusSimulator.

Here is what I've been running it with:

java -cp RadiusSimulator.jar -DUSERNAME=user4 -DPASSWORD=Aa123456 _DCALLING_STATION_ID=11:11:11:11:11:11:11 -DAUDIT_SESSION_ID=1004 -DFRAMED_IP_ADDRESS=172.18.1.4 -DFRAMED_IP_MASK=255.255.255.0 RadiusAuthentication 172.18.1.35

It appears that I only see a session published over XMPP when doing a RadiusAccountingStart or RadiusAccountingStop. Not sure if that is normal or if I'm doing something wrong (this is when using the sdk samples from version 1.3.0.876. Is that the current version?). I do see the authenticated sessions in the admin UI however.

One other thing that I've noticed is that when running the RadiusAuthentication command with the simulator, the simulator will print out the session information for the authenticated user although it does not appear to come directly from the session_subscribe example script. Not sure if i'm just missing something there or not.

Thank you!

David

Hi David,

If their using a session_subscribe that is correct, they  will see the 802.1X notifications when using RadiusAccountingStop/RadiusAccountingStart with RadiusSimulator.

So when RadiusSimulatorAccountStop, AccountingStart, Authentication with session_subscribe, are you saying that the username differs from the one called in the RadiusSimulator?

Also as a reference for script testing, please see:

http://www.cisco.com/c/dam/en/us/td/docs/security/ise/how_to/HowTo-84-Configure_and_Test_Integration_with_Cisco_pxGrid.pdf

This may help with some expectant results and illustrated examples.

Hi John,

Thanks for the documentation. That is similar to the doc I found on the developer site as well which I have been using as a guide.

When I use the RadiusSimulator and do a RadiusAccountingStart and RadiusAccountingStop I will see the session being published back to my client.

However the username doesn't appear to change even though i'm using unique fields for the following for each call:

-DCALLING_STATION_ID

-DAUDIT_SESSION_ID

-DFRAMED_IP_ADDRESS

So for example, if I have two users created in ISE, "user2" and "user4". Both with passwords of "Aa123456".

If I launch the simulator with the following command:

java -cp RadiusSimulator.jar -DUSERNAME=user2 -DPASSWORD=Aa123456 -DCALLING_STATION_ID=11:11:11:11:11:11:12 -DNAS_IP_ADDRESS=172.18.1.150 -DAUDIT_SESSION=1032 -DFRAMED_IP_ADDRESS=172.18.1.2 -DFRAMED_IP_MASK=255.255.255.0 RadiusAuthentication 172.18.1.35

Followed by an accounting start:

java -cp RadiusSimulator.jar -DUSERNAME=user2 -DPASSWORD=Aa123456 -DCALLING_STATION_ID=11:11:11:11:11:11:12 -DNAS_IP_ADDRESS=172.18.1.150 -DAUDIT_SESSION=1032 -DFRAMED_IP_ADDRESS=172.18.1.2 -DFRAMED_IP_MASK=255.255.255.0 RadiusAccountingStart 172.18.1.35

I see the correct session data - i.e. the username and attributes defined - being published back (except no session publish for the RadiusAuthentication call).

If I then change the call to user "user4" (for example) - notice the calling station, audit session, and framed ip change:

java -cp RadiusSimulator.jar -DUSERNAME=user4 -DPASSWORD=Aa123456 -DCALLING_STATION_ID=11:11:11:11:11:11:14 -DNAS_IP_ADDRESS=172.18.1.150 -DAUDIT_SESSION=1034 -DFRAMED_IP_ADDRESS=172.18.1.4 -DFRAMED_IP_MASK=255.255.255.0 RadiusAuthentication 172.18.1.35

Followed by an accounting start for this same user, the published information returned shows the right attributes for -DCALLING_STATION_ID, -DAUDIT_SESSION and -DFRAMED_IP_ADDRESS but the username published back is "user2" rather than "user4".

What has me scratching my head is why i'm seeing back the wrong username.

If I look in ISE under Authentications->Show Live Sessions, I can see both users accounted for in the audits with accounting start/stop events so it seems that the data is being properly pushed up to ISE from the simulator.

It's strange, almost like the username is being cached or maybe a variable not cleared - or maybe a misconfiguration on my part.

Note that this behavior happens with the native sample libraries and scripts and also with a custom client connector I wrote that uses the libraries from the /lib directory (not using the .jar from the samples/lib dir).

Does that help?

Thanks!

David

Hi David,

Working with the development team on this one, they asked if you're running different Audit Session ID's for different users.

Also with regards to session_subscribe using RadiusAuthentication, this is not possible because the RadiusAuthentication simulates user authentication, RadiusAccountingStop and RadiusAccountingStart are used to terminate or initiate user authentication.

Hi John,

Yep, each username has a unique AUDIT_SESSION_ID, CALLING_STATION_ID, and FRAMED_IP_ADDRESS.

What's interesting is that the ISE UI displays the data properly under Operations->Authentications.

It's just the published information sent back seems to have the same username returned.

What also seems a bit peculiar is that when this happens, I can go under Operations->Authentications and display both user entries seperately but the field "CoA Action" has a little blue arrow icon next to both user2 and user4 and if I hover over it says: "There are multiple endpoints at this NAS port. Click to perform CoA".

Not sure if that has something to do with it or not. I can take a screen shot and run the simulator a couple times with output if that helps?

David

Hi David,

Nope, that's fine. It looks like there's a bug with RadiusSimulator, I have verified this as well. Let me check with development and get back with you.

Fantastic! Thanks for checking into this!

David

Hi David,

It turns out there is additional argument -DACCT_SESSION_ID that needs to be inserted into RadiusAccountingStart and RadiusAccountingStop and different for each user as well.

java -cp RadiusSimulator.jar -DUSERNAME=user1 -DPASSWORD=cisco -DCALLING_STATION_ID=1001 -DAUDIT_SESSION_ID=1001 -DFRAMED_IP_ADDRESS=10.0.0.5 -DFRAMED_IP_MASK 255.255.255.0 RadiusAuthentication 10.0.0.21

java -cp RadiusSimulator.jar -DUSERNAME=user1 -DPASSWORD=cisco -DCALLING_STATION_ID=1001 -DAUDIT_SESSION_ID=1001 -DACCT_SESSION_ID=1001 -DFRAMED_IP_ADDRESS=10.0.0.5 -DFRAMED_IP_MASK 255.255.255.0 RadiusAccountingStart 10.0.0.21

java -cp RadiusSimulator.jar -DUSERNAME=user1 -DPASSWORD=cisco -DCALLING_STATION_ID=1001 -DAUDIT_SESSION_ID=1001 -DACCT_SESSION_ID=1001 -DFRAMED_IP_ADDRESS=10.0.0.5 -DFRAMED_IP_MASK 255.255.255.0 RadiusAccountingStop 10.0.0.21

You will see session_subscribe trigger on RadiusAccountingStart and RadiusAccounting notifications.

There is a certain logic for the Session Directory lookup for an existing session.

It searches session in this order for RadiusAuthentication:

1. audit_session_id

2. calling_station_id

For RadiusAccountingStart:

1. acct_session_id

2. audit_session_id

3. calling_station_id

Basically to simulate properly, acct_session_id and audit_session_id remains the same for the same session.

calling_station_id is different for different user (at least this is what ISE assumes)

Hi John,

Sorry for the delay and for beating a dead horse on this one.

I've gotten back from PTO and had a chance to test based on your last suggestion and it appears I'm still seeing the same behavior.

Here is an example:

I authenticate with one user, 'mlcuser' defined in the internal ISE database.

First user (mlcuser):

java -cp RadiusSimulator.jar -DUSERNAME=mlcuser -DPASSWORD=mypassword -DCALLING_STATION_ID=

00005e04bb02 -DAUDIT_SESSION_ID=1011 -DFRAMED_IP_ADDRESS=172.18.1.13 -DFRAMED_IP_MASK=255.255.255.0 RadiusAuthentication 172.18.1.35

code=2 id=1 length=106

authenticator=6780ca4c4bf8f645fd85272617f08cd8

Attributes={

  UserName=mlcuser

  State=ReauthSession:1011

  class="CACS":1011:ise/221698093/167

  vendorId=9 vsa=[profile-name=Unknown,]

}

java -cp RadiusSimulator.jar -DUSERNAME=mlcuser -DPASSWORD=mypassword -DCALLING_STATION_ID=

00005e04bb02 -DAUDIT_SESSION_ID=1011 -DACCT_SESSION_ID=1011 -DFRAMED_IP_ADDRESS=172.18.1.13 -DFRAMED_IP_MASK=255.255.255.0 RadiusAccountingS

tart 172.18.1.35

code=5 id=1 length=20

authenticator=17f2e3f5399c494f1b296db43ab4a45

Attributes={

}

** ==> Returned from ISE session (using Utilities.print in samples dir):

Session (ip=172.18.1.13, Audit Session Id=1011, User Name=mlcuser, AD User DNS Domain=null, AD Host DNS Domain=null, AD User NetBIOS Name=null, AD Host NETBIOS Name=null, Calling station id (mac addr)=00:00:5E:04:BB:02, Session state=STARTED, NAS IP=172.18.1.150, Session Last Update Time=Mon Jun 15 11:21:23 CDT 2015 )

Then run accounting stop:

java -cp RadiusSimulator.jar -DUSERNAME=mlcuser -DPASSWORD=mypassword -DCALLING_STATION_ID=

00005e04bb02 -DAUDIT_SESSION_ID=1011 -DACCT_SESSION_ID=1011 -DFRAMED_IP_ADDRESS=172.18.1.13 -DFRAMED_IP_MASK=255.255.255.0 RadiusAccountingS

top 172.18.1.35

code=5 id=1 length=20

authenticator=47b5ddd78d9afefa2381af90e43299

Attributes={

}

** ==> Returned from ISE

(Acct Stop):

Session (ip=172.18.1.13, Audit Session Id=1011, User Name=mlcuser, AD User DNS Domain=null, AD Host DNS Domain=null, AD User NetBIOS Name=null, AD Host NETBIOS Name=null, Calling station id (mac addr)=00:00:5E:04:BB:02, Session state=DISCONNECTED, NAS IP=172.18.1.150, Session Last Update Time=Mon Jun 15 11:21:33 CDT 2015 )

ALL is OK.

-----------------------------------------------------------------------------------------------------------------

Problem is then I attempt with a different using following the first authentication.

Note different AUDIT_SESSION_ID, ACCT_SESSION_ID, FRAMED_IP_ADDRESS and CALLING_STATION_ID:

Next user (epoadmin):

java -cp RadiusSimulator.jar -DUSERNAME=epoadmin -DPASSWORD=mypassword -DCALLING_STATION_ID

=00005e04bb01 -DAUDIT_SESSION_ID=1010 -DFRAMED_IP_ADDRESS=172.18.1.12 -DFRAMED_IP_MASK=255.255.255.0 RadiusAuthentication 172.18.1.35

code=2 id=1 length=107

authenticator=695e656e39683dea439bd8c15bf3dc9e

Attributes={

  UserName=epoadmin

  State=ReauthSession:1010

  class="CACS":1010:ise/221698093/170

  vendorId=9 vsa=[profile-name=Unknown,]

}

java -cp RadiusSimulator.jar -DUSERNAME=epoadmin -DPASSWORD=mypassword -DCALLING_STATION_ID

=00005e04bb01 -DAUDIT_SESSION_ID=1010 -DACCT_SESSION_ID=1010 -DFRAMED_IP_ADDRESS=172.18.1.12 -DFRAMED_IP_MASK=255.255.255.0 RadiusAccounting

Start 172.18.1.35

code=5 id=1 length=20

authenticator=2631457d57729d7c4b1795a02cb56c5c

Attributes={

}

** ==> Returned from ISE (notice the session ip and audit session id are correct fo this attempt but the username is "mlcuser" rather than "epoadmin":

Session (ip=172.18.1.12, Audit Session Id=1010, User Name=mlcuser, AD User DNS Domain=null, AD Host DNS Domain=null, AD User NetBIOS Name=null, AD Host NETBIOS Name=null, Calling station id (mac addr)=00:00:5E:04:BB:01, Session state=STARTED, NAS IP=172.18.1.150, Session Last Update Time=Mon Jun 15 11:25:47 CDT 2015 )

Then run accounting stop:

java -cp RadiusSimulator.jar -DUSERNAME=epoadmin -DPASSWORD=mypassword -DCALLING_STATION_ID

=00005e04bb01 -DAUDIT_SESSION_ID=1010 -DACCT_SESSION_ID=1010 -DFRAMED_IP_ADDRESS=172.18.1.12 -DFRAMED_IP_MASK=255.255.255.0 RadiusAccounting

Stop 172.18.1.35

code=5 id=1 length=20

authenticator=6de43238755445ba6bd318855f3f1127

Attributes={

}

** ==> Returned from ISE

Session (ip=172.18.1.13, Audit Session Id=1011, User Name=mlcuser, AD User DNS Domain=null, AD Host DNS Domain=null, AD User NetBIOS Name=null, AD Host NETBIOS Name=null, Calling station id (mac addr)=00:00:5E:04:BB:01, Session state=DISCONNECTED, NAS IP=172.18.1.150, Session Last Update Time=Mon Jun 15 11:25:55 CDT 2015 )

The session notification is coming back for the audit session id "1011" and user "mlcuser" and not audit session id 1010 and user epoadmin.

What is interesting is that when I look at the ISE logs under "active authentications", I see that the proper account is flagged when the accounting start/stop occurs.

It looks like the ISE server is returning the wrong session info?

Is it possible for you to try with two seperate back to back users?

I've tried synchronizing the methods getting the session information using the example code but am still able to replicate the issue.

If it helps, the ISE version is version 1.3.0.876.

Thank you!

David

Hi David,

Can you try the following below and ensure that you have -DACCT_SESSION_ID in RadiusAuthentication as well:

java -cp RadiusSimulator.jar -DUSERNAME=user1 -DPASSWORD=cisco123 -DCALLING_STATION_ID=11.11.11.11.11.11 -DAUDIT_SESSION_ID=2007 –DACCT_SESSION_ID=2007 -DFRAMED_IP_ADDRESS=10.1.100.105 -DFRAMED_IP_MASK=255.255.255.0 RadiusAccountingStop 10.1.100.31

java -cp RadiusSimulator.jar -DUSERNAME=user1 -DPASSWORD=cisco123 -DCALLING_STATION_ID=11.11.11.11.11.11 -DAUDIT_SESSION_ID=2007 –DACCT_SESSION_ID=2007 -DFRAMED_IP_ADDRESS=10.1.100.105 -DFRAMED_IP_MASK=255.255.255.0 RadiusAccountingStart 10.1.100.31

java -cp RadiusSimulator.jar -DUSERNAME=user1 -DPASSWORD=cisco123 -DCALLING_STATION_ID=11.11.11.11.11.11 -DAUDIT_SESSION_ID=2007 –DACCT_SESSION_ID=2007 -DFRAMED_IP_ADDRESS=10.1.100.105 -DFRAMED_IP_MASK=255.255.255.0 RadiusAuthentication 10.1.100.31

java -cp RadiusSimulator.jar -DUSERNAME=user2 -DPASSWORD=cisco123 -DCALLING_STATION_ID=22:22:22:22:22:22 -DAUDIT_SESSION_ID=2008 –DACCT_SESSION_ID=2008 -DFRAMED_IP_ADDRESS=10.1.100.101 -DFRAMED_IP_MASK=255.255.255.0 RadiusAccountingStop 10.1.100.31

java -cp RadiusSimulator.jar -DUSERNAME=user2 -DPASSWORD=cisco123 -DCALLING_STATION_ID=22:22:22:22:22:22 -DAUDIT_SESSION_ID=2008 –DACCT_SESSION_ID=2008 -DFRAMED_IP_ADDRESS=10.1.100.101 -DFRAMED_IP_MASK=255.255.255.0 RadiusAccountingStart 10.1.100.31

java -cp RadiusSimulator.jar -DUSERNAME=user2 -DPASSWORD=cisco123 -DCALLING_STATION_ID=22:22:22:22:22:22 -DAUDIT_SESSION_ID=2008 –DACCT_SESSION_ID=2008 -DFRAMED_IP_ADDRESS=10.1.100.101 -DFRAMED_IP_MASK=255.255.255.0 RadiusAuthentication 10.1.100.31

java -cp RadiusSimulator.jar -DUSERNAME=user3 -DPASSWORD=cisco123 -DCALLING_STATION_ID=33:33:33:33:33:33 -DAUDIT_SESSION_ID=2009 –DACCT_SESSION_ID=2009 -DFRAMED_IP_ADDRESS=10.1.100.102 -DFRAMED_IP_MASK=255.255.255.0 RadiusAccountingStop 10.1.100.31

java -cp RadiusSimulator.jar -DUSERNAME=user3 -DPASSWORD=cisco123 -DCALLING_STATION_ID=33:33:33:33:33:33 -DAUDIT_SESSION_ID=2009 –DACCT_SESSION_ID=2009 -DFRAMED_IP_ADDRESS=10.1.100.102 -DFRAMED_IP_MASK=255.255.255.0 RadiusAccountingStart 10.1.100.31

java -cp RadiusSimulator.jar -DUSERNAME=user3 -DPASSWORD=cisco123 -DCALLING_STATION_ID=33:33:33:33:33:33-DAUDIT_SESSION_ID=2009 –DACCT_SESSION_ID=2009 -DFRAMED_IP_ADDRESS=10.1.100.102 -DFRAMED_IP_MASK=255.255.255.0 RadiusAuthentication 10.1.100.31

Thanks,

John

Hi John,

Gave that a try, same behavior. The username returned via SessionSubscribe for second and subsequent authentication->accounting start->accounting stop requests will be the username of the first authentication that was made. The correct user is still started/terminated within the ISE server authentication logs. Interestingly all of the session information returned is also correct, i.e. the Audit Session ID, Calling Station ID, IP/mask.

One thing I did notice was that looking at the ISE Operations->Authentications, the "Account Session ID" field for every user is always "123" despite using the switch -DACCT_SESSION_ID field in the radius simulator.

When I look at what is returned when the SampleNotificationHandler.onChange is called, the RADIUSAVPairs from the ISE server always returns the value:

[ Acct-Session-Id=123]

Could this be part of the problem? Especially if the lookup order is:

1. acct_session_id

2. audit_session_id

3. calling_station_id

In addition, the Audit Session ID is being logged properly based on the -DAUDIT_SESSION_ID field in the radius request from the simulator.

Hi David,

Can you provide me with your email address and will be in touch.

Thanks,

John

Hi John,

Thank you - my email address is david_lepage@mcafee.com

I have the same issue. If you have found the reason, can you publish the answer, please?

I tried to reproduce the same Radius commands with radclient and it works as expected.

Analyzing the packets with tshark, when using RadiusSimulator.jar, I found that Acct-Session-Id is incorrectly set to "123" on all packets, independently of the value of ACCT_SESSION_ID.