cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Provide a way of finding out when a user last accessed the Integrity server.

Provide a way of finding out when a user last accessed the Integrity server.

 

In general, most of the companies that I have worked for, it is required (by audit) that we have a way to tell if users have not logged on to the system (or application) beyond a certain period of time.  If they have not for a certain period of time, you might need to follow up to see if they still require access and suspend it, and if perhaps it's a longer predefined time, their access and id's might be revoked.  The rules might vary slightly, but in general that's the idea.  In order to implement this type of automated system, you would need to be able to extract that information from the applicable application/s.  There currently is no way to get this information from Integrity.  We looked into a number of options i.e.

 

  • getting the information from the audit log – the information required was not available there
  • the license manager – again the information was not available
  • PTC System Monitor – this is a third party tool for monitoring performance (using dynatrace) , and it did contain information that was useful, but we cannot extract it via CLI or other connectors that we are aware of.

  

In order to get the data needed, we have to extract a user list from Integrity, and then extract the users that logged on in the last x number of days from PSM.  From the delta you can identify who has not logged on in that period.  We do this manually on a monthly basis, but require that this be done in an automated fashion daily, which cannot currently be done as far as we are aware.

 

An article in the PTC community:  CS91906 confirms that we cannot extract this information from Integrity.

 

There is also an existing community discussion on this: Re: Audit inactive users

 

It appears that there was also an RFC # 634693

7 Comments
Newbie

Related:

In a global environment, where change is the only constant, in addition to knowing the user and when they last connected, we also need to know which client they connected with (Web, GUI, CLI, web service), and in cases where there is an installed client, the version of the client. Further, since the information is available, the IP address or machine name of the client would be nice as well.

From an internal support perspective, this additional information can inform us of people that have old/incorrect client versions, which in turn allows us to ensure that we get them updated correctly. It also gives us metrics on who uses what access method, and allows us to be pre-emptive with our users in terms of internal support. We have our own internal Integrity support team to help users, and can direct their issues to the correct people easier if we can see how they connected and the version of the client. We do have quite a number of non-technical users that access the product, and trying to talk them through how to get the version number and how they connected can be frustrating and error prone.

Aquamarine

Hello Jim,

using ILM 10.4 not all (=> CLI  and/or  Web Service) but at least some infos are available.

In our company we can see:

- User ID

- User's Hostname

- last login (date + time)

- info  "active"  or   "idle <since>"

- info column:  direct // via Proxy  //  web  //  api

Does this cover your suggestion  (except from CLI and Web Services ...)

Following two examples:

example1.jpg

---

example2.jpg

Newbie

Yes, Klaus...the "Client Connections" Server Diagnostic will show those results...but it is only valid at the moment that diagnostic is executed.  Once a user logs off, they disappear from the list the next time the command is executed.  And if a user logs in after the first execution of the "Client Connections" diagnostic command, but then logs out before the second execution of the "Client Connections" command, they will not appear in either list.

What Kevin is requesting (and which is also a requirement at our organization) is a user property that is automatically tracked by the system which shows the last login date/time for every user.  Or, conversely, an automatic running log of every user login/logout action.  I would suggest that Integrity consider a couple of solutions:

Option 1: Have the system create a new running text log on the application server which only captures the following on each line:

  • username
  • login or logout
  • date/timestamp
  • client type (web, GUI, API, etc.)
  • IP Address
  • Machine name
  • License type
  • EXAMPLE:
  • john.doe  LOGIN  2016-09-28 13:59:08  web  128.4.5.6  WORKBOOK9876  Seat
  • jane.smith  LOGOUT  2016-09-28 14:01:10  CLI  128.7.8.9  DESKTOP3456  Float
  • RemedyAdmin LOGIN  2016-09-28 14:01:22  API  192.168.5.1  BMCSERVER-PROD  Seat
  • john.doe  LOGOUT  2016-09-28 14:03:22  web  128.4.5.6  WORKBOOK9876  Seat

Option 2: Modify the UserBean objects within Integrity to support more than just 3 properties (currently just "Username", "DisplayName", and "EmailAddress"), with the new properties including things such as:

  • LastLogin (java.util.Date)
  • LastClientType (java.lang.String)
  • LastIPAddress (java.lang.String)
  • LastMachineName (java.lang.String)
  • HasSeatLicense (boolean)

Et cetera.

Aquamarine

Thanks for clarification.

But it would be good that such an extended Logging should be made configurable,

cause in some countries such a logging isn't allowed to be used only after confirmation of the company's workers committee.

Newbie

Good point.

If the logging option is chosen (instead of the UserBean properties option), it should be fairly easy to enable/disable this "last login" log similar to how audit logging is controlled in the is.properties file (mksis.auditor.logins=true|false) or as a standard log level per the logger.properties file:

  • mksis.logger.message.includeCategory.LOGINS=10 for full capture of LOGINS
  • mksis.logger.message.includeCategory.LOGINS=0 to disable capture of LOGINS
Community Manager
Status changed to: Acknowledged
 
Participant

Audit logging must include login/logout for all users in Integrity, by default, with the option to opt out, to accommodate local laws.

 

As of now, login/logout info is only recorded in the server.log and it is painful to retain log files for extended periods, and parse them for user login/logout info for auditors.