Missing information about the Risport API concerning selectcmdevice field statusreason

groupes-sopa1 · ‎11-27-2020

Hi,

Me and a collegue are programming an internal website to give Management/Techsupport the ability to view who is registered with each of their Devices (CSF/SEP/TCT/BOT...) and see, for each device, if they are logged into their corresponding linegroups.

The website itself is functional at the moment (with a mix of AXLquery/risdb and a read-only application user). But when we received the results, their are some things unknown to us that I can't find in the RisPort70 API Reference Guide.

1. StatusReason Code 6 has been found with some CSF devices. This code is unknown to the API reference guide.

2. It seems that the field RegistrationAttempts is way less interesting as I thought. Whenever I try to connect with a bad Username/PWD for a CSF device (we user LDAP Authentication), this counter doesn't change... Is their an EASY way (without filtering eventlogs on Windows DC to find the last status of an authentication request for an end-user.

Friendly greetings,

Mario

groupes-sopa1 · ‎11-27-2020

I found another reasoncode that is not known to the RISPort API Reference Guide

Statusreason CODE 28 also a CSF Device.

dstaudt · ‎11-30-2020

I've got an inquiry in on these two (and any other missing) codes...hopefully we can get the docs updated with anything missing.

As far as login failures, I understand there are some Tomcat logs you can analyze for that, but might be iffy/difficult (this API might help). Might also investigate CUCM alarms (and I guess audit logging)and syslog/remote syslog, which might be a bit more programmatic...

groupes-sopa1 · ‎12-01-2020

Thx for the research about the missing codes.

Concerning the login failures. I effectively found something (using RTMT) in the Audit Log Viewer for the concerning CUCM nodes.

It seems that the interesting info is in the field resourceaccessed (when an end-user authenticates it seems to be cucm-uds).

I then tried using SOAPUI to create a working request (soapaction:selectLogFiles) but that always seems to fail with error 500. Do you have a working example where the Jobtype is DownloadtoClient.

Also the soapaction:listnodeservicelogs request works without issue. So my credentials should be fine.

dstaudt · ‎12-01-2020

Here a working example of listing the available files (note 'DownloadtoClient' mode only provides a listing - it doesn't actually download:)

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soap="http://schemas.cisco.com/ast/soap">
   <soapenv:Header/>
   <soapenv:Body>
      <soap:selectLogFiles>
         <soap:FileSelectionCriteria>
            <soap:ServiceLogs>
               <soap:item>Security Logs</soap:item>
            </soap:ServiceLogs>
            <soap:SystemLogs>
            	<soap:item></soap:item>
            </soap:SystemLogs>
            <soap:SearchStr/>
            <soap:Frequency>OnDemand</soap:Frequency>
            <soap:JobType>DownloadtoClient</soap:JobType>
            <soap:ToDate></soap:ToDate>
            <soap:FromDate></soap:FromDate>
            <soap:TimeZone/>
            <soap:RelText>Minutes</soap:RelText>
            <soap:RelTime>5</soap:RelTime>
            <soap:Port/>
            <soap:IPAddress/>
            <soap:UserName/>
            <soap:Password/>
            <soap:ZipInfo/>
            <soap:RemoteFolder/>
         </soap:FileSelectionCriteria>
      </soap:selectLogFiles>
   </soapenv:Body>
</soapenv:Envelope>

To retrieve a specific file (via DIME) you can use <GetOneFile> or retrieve bulk files via SSH-FTP push by using <selectLogFiles> with JobType = 'PushtoSFTPServer', e.g.:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soap="http://schemas.cisco.com/ast/soap">
   <soapenv:Header/>
   <soapenv:Body>
      <soap:selectLogFiles>
         <soap:FileSelectionCriteria>
            <soap:ServiceLogs>
			<soap:item>Cisco Audit Logs</soap:item>
            </soap:ServiceLogs>
            <soap:SystemLogs/>
            <soap:SearchStr/>
            <soap:Frequency>OnDemand</soap:Frequency>
            <soap:JobType>PushtoSFTPServer</soap:JobType>
            <soap:ToDate/>
            <soap:FromDate/>
            <soap:TimeZone>Client:(GMT-6:0) Central Standard Time</soap:TimeZone>
            <soap:RelText>Minutes</soap:RelText>
            <soap:RelTime>60</soap:RelTime>
            <soap:Port>22</soap:Port>
            <soap:IPAddress>sshftpserver</soap:IPAddress>
            <soap:UserName>sshftpuser</soap:UserName>
            <soap:Password>password.</soap:Password>
            <soap:ZipInfo>false</soap:ZipInfo>
            <soap:RemoteFolder>deliveryfolder</soap:RemoteFolder>
         </soap:FileSelectionCriteria>
      </soap:selectLogFiles>
   </soapenv:Body>
</soapenv:Envelope>

If you're using Python, I added a sample 'logcollection_GetOneFile.py' to this repo which shows listing/retrieving one file via DIME: CiscoDevNet/serviceability-python-zeep-samples

dstaudt · ‎12-04-2020

This updated enum list was provided by engineering:

enum Reason
{
    Unknown = 1, 
    ConnectivityError = 6, 
    DeviceInitiatedReset = 8, 
    CallManagerReset = 9, 
    DeviceUnregistered = 10,  
    MalformedRegisterMsg = 11, 
    SCCPDeviceThrottling = 12,  
    KeepAliveTimeout = 13, 
    ConfigurationMismatch = 14, 
    CallManagerRestart = 15, 
    DuplicateRegistration = 16, 
    CallManagerApplyConfig = 17, 
    DeviceNoResponse = 18, 
    EMLoginLogout = 19,  
    EMCCLoginLogout = 20,  
    EnergywisePowerSavePlus = 21,  
    CallManagerForcedRestart = 22, 
    SourceIPAddrChanged = 23, 
    SourcePortChanged = 24, 
    RegistrationSequenceError = 25, 
    InvalidCapabilities = 26, 
    FallbackInitiated = 28, 
    DeviceSwitch = 29, 
    DeviceWipe = 30,  
    DeviceForcedShutdown = 31,  
    LowBattery = 33, 
    ManualPowerOff = 34  
}

Note that #2->#6 and #19->#21 with regards to the original DevNet docs - not sure why, but I'm assuming this enum list is probably more canonically correct. Once we get that straightened out (possibly a change in some past CUCM version..?) and some explanatory text for the added enums we'll update the docs...

groupes-sopa1 · ‎02-03-2021

Thanks kinda forgot about this post. But indeed the documentation has been adapted. Thanks a lot!