Collecting logs from Read only Domain Controller

mishymishy Member Posts: 209 ■■■□□□□□□□
Hi Guys,

I have been trying to do some research on whether if I collect logs (from Application, System and Security), especially Security logs from a Read only Domain Controller (RODC), is there any possibility that I will be collecting logs duplicate logs since I have already collected the logs from the main Domain Controller (DC)?

I am not really sure how the read only domain controllers work but I am assuming they will read and store Active Directory data from the main Domain Controller and then a client will send its request to the RODC. On the other hand I suspect that the data that will be exchanged between the 2 DC will not show in the logs but the actual request by the client to the RODC will be logged as an event on the RODC which will also pass this data to the main DC.

Any advice on the best approach for an environment that has for example 4 main DCs and 4 RODC, if you were to collect security logs from all the DC and RODC is there a possibility of duplicates? I am eventually going to have to collect the security logs from the RODC because there is also other applications that will log their activity there but my main concern is I will also need to find a way of dealing with duplicates if there is any.

Comments

  • ChitownjediChitownjedi Chasing down my dreams. Member Posts: 578 ■■■■■□□□□□
    What about local logs of Admins that might log on to the box and make changes that are not directly tied to SYSVOL and the replication mechanics of RODC? Capturing those would be needed to show system security -- No doubt you will be ingesting logs that are passed down from the writable DC's which may be duplicates --
  • poolmanjimpoolmanjim MCSE, MCSA: 2016, MCSA: 2012 KC, KS, USAMember Posts: 285 ■■■□□□□□□□
    If you turned on advanced DC logging then you absolutely would see multiple entries. Otherwise, DCs process the requests they get. A password is validated by a single DC, it is only passed to another DC if that DC fails to authenticate the user and then it sends it to the PDC to be sure the password didn't change. This is basically the behavior of RODCs, since they can't do writes any of that is passed to a RW-DC and if they encounter passwords they do not have stored or cannot have stored, the send it up the chain to another DC to handle. I'm not sure if that process is reflected in event logs.

    In short: grab logs from all your DCs.
    2019 Goals: Security+
    2020 Goals: 70-744, Azure
    Completed: MCSA 2012 (01/2016), MCSE: Cloud Platform and Infrastructure (07/2017), MCSA 2017 (09/2017)
    Future Goals: CISSP, CCENT
  • mishymishy Member Posts: 209 ■■■□□□□□□□
    Many thanks Chitownjedi and poolmanjim, I think i will collect all the logs from the RODC because I will also need the security logs generated by other applications on the server.
  • backtrackerbacktracker MCSE CP&I, MCSA Server 2016, MCSA Windows 10, MCSA Server 2003, Security +, Network + Member Posts: 91 ■■■□□□□□□□
    In addition, accounts can be specifically replicated and allowed on the RODC so that they do not have to authenticate over the wire; that would be another reason to grab the RODC local logs.
    MSM-ISS (Information System Security)-'07 Colorado Tech.
    MCSE | MCSA X3 | Security + | Network +
  • beadsbeads Senior Member Member Posts: 1,467 ■■■■■■■■□□
    Depending on the complexity of your compliance needs, particularly HIPAA you will need the usual suspects: System, Hardware, Security and Application for access purposes. Depending on how that logging is setup and scheduled RDOC as well if you need to follow the entire path of an intruder. If nothing else it gives more credibility to the investigator's report.

    Want more fun than you can handle? IIS logs are notoriously difficult to capture and parse in human readable format. I am looking you AWS. IIS is a flat file not a full expression file like you'd expect. This is another possible instance where you may have to look at the RODC.

    - b/eads
Sign In or Register to comment.