Start a new topic

Extensive logging

I have a feature request regarding the logging.


It would be nice if further logging was available with the Royal TS server, so that you for example can use it as a logging aggregator for all clients.


This logging would help greatly with GDPR requirements as we need central logging which cannot be tampered with (unless access to the Royal TS server).


The logging should then include which user accessed which connection at what time so that tracabillity is good, for example "user dialect\tejo connected to server BananaServer via RDP at 14:00:00 16-03-2018"


Moreover if someone edits/unlocks the document this should also be logged into the Royal TS server.


Best regards

Ted


3 people like this idea

Hi,


we definitively have something like this on the list - at least for our own log messages (e.g. from all Royal TS/X clients).


When logging into a file or in the Windows Eventlog - is the information that shows there currently enough?


cheers,

Michi


We would also like to have this feature implemented in Royal Server for the same reasons. +1 vote!


1 person likes this

Hi Michael,

the information shown and logged from Royal TS to Event Log is enough for our needs.

heya,

thx for your answer. what exactly would you need additionally?

cheers,

Michi


Hey!

What i am looking for exactly is a way to send all the loggs from the clients to the royal TS server for easy aggregation off all logs so that you can see who has done what.

For example who edited a connection at what time, and which person connected to a server at a specific time. This should work when working towards a document centrally stored on the Royal TS server.


Example of proposed output from connection to server:

"user dialect\tejo connected to server BananaServer via RDP at 14:00:00 16-03-2018"

Example of proposed output from editing a connection:

"user dialect\tejo edited the password of Bri_adsrv01 at 14:00:00 16-03-2018"

The above mentioned should also logg when changing the password on a folder


The information that is logged to file is enough :)


4 people like this

Hey Michael


Is something like this already implemented? Especially the part "user dialect\tejo connected to server BananaServer via RDP at 14:00:00 16-03-2018" stated from Dialect_Skove.


I thought this was logged out of the box, but I could not find it at all. Not in logs, request/reponse logs and event viewer.


Kind regards

Jeffrey


1 person likes this

Hi everyone and Michael !


I know that this topic is 5 years old but I also would like to see such auditing features !


At least some basics as it can be requested by cyber insurances nowadays to be covered in case of an attack.


From the server/gateway POV, what would be interesting:

  • Beeing able to get records of the which user logged in (with at leaste timestamp, source IP)
  • Details of failed authentications attempts (known/unknown user, reason of failure like wrong password or MFA/timeout, ...)
  • Which document(s) has been opened by whom and which rights were applyed and when
  • Which tunnels were opened for an user and to which internal server, ...

From the admin console POV:
  • Users and groups modifications (added, deleted, modified, changed MFA on/off, ...)
  • Documents modifications (add/delete)
  • Documents access rules modifications


From the RoyalTS/X clients POV, when interacting with RoyalServer's document from the store:

  • Is the document was unlocked for modification
  • What have been modified or revealed, ...
  • If those records can be sent back to the server for central logging it would be nice too !


We already have a SOC that is monitoring accesses to our infrastructure to identify potential intrusions or account misuse (e.g. logged in from an unusual country) from the WAN side.

If all those informations can be send to a log file or event the Windows Eventlog of the RoyalServer, it can be grabbed by some agents (Winlogbeat, Wazuh, Splunk, ...) and alerting rule in near-realtime can be raised !


I also noticed that RoyalTS for Windows use Serilog and is already bundled with Splunk/ElasticSearch/ Syslog sinks, so adding the ability to directly send logs to such logging plateforms could be achieved without too much headache ;-)


Hope this will help !

As always, feel free to ask if you want more inputs on the topic :)


Best Regads,

Nicolas.

Hi Nicolas,


thanks for your inputs. I will try to describe what's existing already:


server/gateway POV: Being able to get records of the which user logged in (with at leaste timestamp, source IP):

When it comes to accessing a management connection, this is what is logged in Information level:


Request "2bab099f-a9a3-4a2a-b17b-ed9eefad1693", Payload: RequestID: 2bab099f-a9a3-4a2a-b17b-ed9eefad1693 | ManagementModuleID: RoyalServer.ManagementEndpoint.Module.WindowsServices | RequestCommand: ListServices | RequestUsername: MSADMINDAD8\msadmin | ClientIP: 10.1.0.135 | DestinationHostnames: localhost | DestinationUsername: demoadmin | GatewayUsername: demoadmin | Arguments { WQLWhereClause: , CommandProvider: WMI }


So any given module/command you see for which user towards which IP it was executed.


server/gateway POV: Details of failed authentications attempts (known/unknown user, reason of failure like wrong password or MFA/timeout, ...)

We log this as a  Warning including what Windows is returning as error code, e.g. this is a log entry when you have configured a wrong password for a Royal Server user:


Failed to logon {"Domain":"MSADMINDAD8","Username":"demoadmin","LogonUserType":"WindowsAccountName","OriginalUsername":"demoadmin","NormalizedUsername":"MSADMINDAD8\\demoadmin","IsLocalUser":true,"$type":"LogonUser"} with error code 1326



server/gateway POV: Which document(s) has been opened by whom and which rights were applyed and when

This is what we log when someone opened a document via Royal TS:


Request "11cbfb57-b77a-4a97-a3ea-8e95ce6b77de", Payload: RequestID: 11cbfb57-b77a-4a97-a3ea-8e95ce6b77de | ManagementModuleID: RoyalServer.ManagementEndpoint.Module.RoyalDocumentStore | RequestCommand: GetDocumentList | RequestUsername: [not provided] | ClientIP: 10.1.0.135 | DestinationHostnames: localhost | DestinationUsername: | GatewayUsername: MSADMINDAD8\demoadmin | Arguments { }


for opening the document and 


Request "ad966513-3984-4e9e-a360-3bf95c0fd675", Payload: RequestID: ad966513-3984-4e9e-a360-3bf95c0fd675 | ManagementModuleID: RoyalServer.ManagementEndpoint.Module.RoyalDocumentStore | RequestCommand: LoadDocument | RequestUsername: MSADMINDAD8\msadmin | ClientIP: 10.1.0.135 | DestinationHostnames: | DestinationUsername: demoadmin1 | GatewayUsername: demoadmin1 | Arguments { DocumentId: 1304f687-054e-4a56-a9e0-18702e839003, DocumentName: doc1, RoyalServerId: 1f4563d5-3b95-4a19-843b-6b8451ad7f03, MfaCode: }


for actually opening a document. MfaCode would be filled out if a 2nd factor was requested (e.g. the TOTP value from the Authenticator App). In the case of a wrong MFA code, this is what is logged:


User demoadmin1 provided invalid MFA code


server/gateway POV: : Which tunnels were opened for an user and to which internal server, ...

Technically, we can only log which user requested to which server on which port using which Royal Server username (not the one to the destination server) - Royal Server cannot inspect what's happening inside the tunnel (e.g. which username is used for the destination server)


2023-09-05 12:57:30.399 [INF] [SECG] Local forwarding connection requested - Session: {"SessionId":1,"SessionUsername":"demoadmin","RemoteHostName":"10.1.0.50","RemotePort":22} 



admin console POV: Users and groups modifications (added, deleted, modified, changed MFA on/off, ...)
Windows Group Memberships are done by Windows and is entirely out of Royal Servers domain. So this is not easily logged by Royal Server. 


MFA settings for the MFA feature itself are not logged at the moment directly but when Royal Server starts, it logs the complete configuration (if MFA configuration is on, if Reject Unknown Users is on and for each MFA Provider if its on). Any change of these settings requires a restart of Royal Server. So indirectly, you can see changes from start to start. Though I can see why its interesting to log these changes explicitly and will include this in one of the next versions.


Any configuration changes for a specific MFA user are logged like this:


Request "4ac5595c-d9d7-447d-9c4f-a5a453836c88", Payload: RequestID: 4ac5595c-d9d7-447d-9c4f-a5a453836c88 | ManagementModuleID: RoyalServer.ManagementEndpoint.Module.RoyalServerManagement | RequestCommand: EditUserMfaConfig | RequestUsername: [not provided] | ClientIP: 10.1.0.135 | DestinationHostnames: localhost | DestinationUsername: | GatewayUsername: MSADMINDAD8\demoadmin | Arguments { MfaID: be2352b0-bc4e-485d-bee7-fc47300e3310, PrincipalSID: S-1-5-21-3408523168-2584769710-3117695478-3642, Username: MSADMINDAD8\demoadmin1, Comment: , CacheSuccessFor: 00:00:00, RequireDocStore: True, RequireSecureGateway: False, ModifiedBy: MSADMINDAD8\msadmin, Provider: Generic_TOTP, Issuer: Royal Server on MSADMINDAD8, Label: MSADMINDAD8\demoadmin1, SelfServiceAllowed: False, SelfServiceVerified: False }


admin console POV: Documents modifications (add/delete)
As with any modules, these operations are logged like this:


2023-09-05 14:51:39.993 [INF] [NORM] Request "87928739-8499-4656-9298-5063125986fe", Payload: RequestID: 87928739-8499-4656-9298-5063125986fe | ManagementModuleID: RoyalServer.ManagementEndpoint.Module.RoyalDocumentStore | RequestCommand: CreateDocument | RequestUsername: [not provided] | ClientIP: 10.1.0.135 | DestinationHostnames: localhost | DestinationUsername:  | GatewayUsername: MSADMINDAD8\demoadmin | Arguments { ServerDocumentName: hugo1, ServerDocumentComment: , AdditionalEncryption: false, ServerDocumentPassword: [hidden], ServerDocumentLockdownPassword: [hidden], UserName: MSADMINDAD8\msadmin


for creation and for deletion:


2023-09-05 14:53:22.777 [INF] [NORM] Request "d6dfeeed-683e-4639-8619-8b052939b748", Payload: RequestID: d6dfeeed-683e-4639-8619-8b052939b748 | ManagementModuleID: RoyalServer.ManagementEndpoint.Module.RoyalDocumentStore | RequestCommand: DeleteDocument | RequestUsername: [not provided] | ClientIP: 10.1.0.135 | DestinationHostnames: localhost | DestinationUsername:  | GatewayUsername: MSADMINDAD8\demoadmin | Arguments { DocumentId: 8c881b87-e72f-4eaf-9bac-b3566cb30670


admin console POV: Documents access rules modifications
same as above:
2023-09-05 14:55:19.018 [INF] [NORM] Request "ae959e35-3b12-4d21-bd41-084214f3adfe", Payload: RequestID: ae959e35-3b12-4d21-bd41-084214f3adfe | ManagementModuleID: RoyalServer.ManagementEndpoint.Module.RoyalServerManagement | RequestCommand: SetDocumentACL | RequestUsername: [not provided] | ClientIP: 10.1.0.135 | DestinationHostnames: localhost | DestinationUsername:  | GatewayUsername: MSADMINDAD8\demoadmin | Arguments { Operation: read, Mode: add, Permission: grant, DocumentID: 1304f687-054e-4a56-a9e0-18702e839003, DocumentName: doc1, ModifiedBy: MSADMINDAD8\msadmin, PrincipalSid: S-1-5-21-3408523168-2584769710-3117695478-1001, PrincipalName: msadmindad8\demoadmin, PrincipalType: user, PrincipalPath: WinNT://WORKGROUP/MSADMINDAD8/demoadmin } 
2023-09-05 14:55:19.083 [DBG] [DOCS] SetDocumentACL with mode add for document (uninitialized)_1304f687-054e-4a56-a9e0-18702e839003_read_S-1-5-21-3408523168-2584769710-3117695478-1001_user_grant_DocumentStore 

2023-09-05 14:55:22.177 [INF] [NORM] Request "570c4637-23a3-4206-ba5f-988a81c1d562", Payload: RequestID: 570c4637-23a3-4206-ba5f-988a81c1d562 | ManagementModuleID: RoyalServer.ManagementEndpoint.Module.RoyalServerManagement | RequestCommand: SetDocumentACL | RequestUsername: [not provided] | ClientIP: 10.1.0.135 | DestinationHostnames: localhost | DestinationUsername:  | GatewayUsername: MSADMINDAD8\demoadmin | Arguments { Operation: read, Mode: remove, Permission: grant, DocumentID: 1304f687-054e-4a56-a9e0-18702e839003, DocumentName: doc1, PrincipalSid: S-1-5-21-3408523168-2584769710-3117695478-1001, PrincipalName: msadmindad8\demoadmin, PrincipalType: user } 


RoyalTS/X clients POV: Is the document was unlocked for modification
True, Document lock or unlock operation are currently not logged in Royal TS/X.

RoyalTS/X clients POV: What have been modified or revealed, ...
What do you mean by this? The Document Policies?


If those records can be sent back to the server for central logging it would be nice too!

Ha, for this (centralised logging for Royal TS/X clients via Royal Server) seems to be a good Feature Request . Would you mind creating one so others can discuss/vote for it too? https://www.royalapps.com/go/feature-request-server-main


One more thing: Royal Server also is using Serilog from Version 4 onwards though we do not ship other sinks than the File, the EventLog and the Syslog sinks with Royal Server. Would that be enough for your scenarios?


Let me know if this helps,


cheers,

Michael


Hi Mickael !


Thank you for the detailed explanation ! It will be very useful :)

Maybe a KB article or tutorial would help other with similar needs as a starting point !


After posting my message I realized that Serilog was also used like RoyalTS. Also I didn't spotted those messages the first time as RoyalServer log a lot of performance metrics by default and what I looking for was lost in all of these ;-)


Regarding what is revealed or unlocked, 

  • For document without lockdown-mode enabled, users can freely reveal password, sometime you need to let this ability to users (eg auto-fill does not work on some pages) and using security policy or lockdown-mode is not a choice : logging when a user reveal the password on an object (credential, connection, ...) can be useful.
  • When lockdown-mode is enabled on the document, no reveal is possible unless you know the lockdown-password to unlock the document: being able to know who unlocked the document may help spot unauthorized access, added to password reveal logs you can know in such cases if there is a compromize


Personnaly I use Winlogbeat to send logs to an Elastic Stack through Logstash. Winlogbeat can easily read a flat log file with single or multilines log entries or directly from Windows Eventlogs, and Logstash can act as a syslog receiver, so I think that would be enough for a start!


You seems to use a lot of custom EventIDs (435 for service start, 5096 for perf, 26865 for starting config tool, etc ...), I'll try to filter the list and identify the more interesting ones but if you have a list of IDs used and their meaning, that can definitely help filter the output and collect only what matter for auditing :p

 


I'll try to setup a PoC with all those details and see how it goes ;-)


I'm going to fill a new feature request for RoyalTS/X logging to RoyalServer and let see what other users have in mind too !


Best Regards,

Nicolas.

Login or Signup to post a comment