Forum Discussion
Documenting Office365 Configuration set for Tenant
- The reports at https://support.office.com/en-us/article/Reports-in-the-Office-365-Security-Compliance-Center-7acd33ce-1ec8-49fb-b625-43bac7b58c5a and at https://support.office.com/en-us/article/View-and-download-reports-about-service-usage-in-Office-365-30E5558F-D3C0-4A3B-A0D5-58FC7750C0AD?ui=en-US&rs=en-US&ad=US should help you get started.
Screen shots are also very helpful, but have limited lifetime because the screens are changed by MS.
Given that MS changes the APIs without notice you will never be able to fully define a comprehensive detailed baseline. You need to determine which settings truly matter to your org and then you can use the reports above to audit any changes.
Hi folks - this is something I've been looking at too.
Scenario: an administrator makes a change to the Sharing outside your organisation setting, within the Sharing settings screen in the SharePoint admin center. I need to be able to determine the change that was made; if possible the previously configured state or value, and of course when.
Ideally, I'd like to document a baseline configuration and then gather activities from the audit log (either from Office 365 Security and Compliance, or though PowerShell remote session to Office 365 Admin API). Of course, what's not ideal, is that somebody has to manually click through the admin center once a month to determine if the current state matches the baseline.
How does one query the audit log for the setting mentioned in the above scenario?
Is there a better approach altogether that I'm missing?
Would love to know if you have solved this. I have been struggling with this for several weeks myself.
- I'm afraid I never did really crack this one.
There was a certain degree that just had to be accepted, without being documents - and the risks mitigated accordingly.
Keen to see what options you may find :-)
What do you mean by 'baseline configuration'?
You can easily set an alert for a particular activity in the https://protection.office.com/#/alertpolicies.
What I mean is that for purpose of regulatory compliance, an organisation may need to record configuration of a platform and be able to approve that it's been tested against in order to mitigate risk.
Now suppose we've recorded that configuration and somebody then changes it outside of a formal CR process, we need to find a way of being informed of that.
Initially the folks I'm working with suggested a full export of any admin config options available - whether through PowerShell or other means. Then periodical re-exports to compare. I don't think this is efficient and went down the path of audit querying/reporting and alerts - most definitely the right way to go.
Anyhow, I've since gone into a test tenant of mine and made a change in SharePoint Online Admin Center > Settings > Custom Script > Prevent users from running custom script on personal sites. I've set it from enabled to disabled.
When looking at the Audit Log activities for that operation, I see that a user (the admin, me in this case) has visited the page, but I have no information at all about what was configured differently; that being my problem here :-)
Hello Jason Dunbar,
Thanks for your detailed explanation. What you have depicted is really a good option to have a control on the Office 365 environment which is handled by multiple admins.
Most of the configuration tracking can't be achieved by activity alerting. We need to collect all of the configuration periodically and verify the changes with the existing configuration stored locally. It becomes complex as we need to invoke too many PowerShell cmdlets as the configuration management is scattered among various cmdlets.
We will try to include this use case in our http://demo.admindroid.com. :)
Not a very solid example, but bear with me...
Suppose I'm working in a regulated industry and for whatever reason, it's important for me to prohibit scripting in personal sites. It might be the case that the configuration options of the platform are set, recorded and tested against so that we're able to demonstrate to a regulatory body that we've mitigated the risks involved.
Now, suppose somebody changes that setting and puts the org in a position where they're not regulatory compliant. What now? How are we to be aware of it?
The initial idea was to have something extract Audit Actions to determine what's changed, but that's inefficient. I'm aware of the Alerts and agree that's the way to go... But I fear the scripting option above is not an option for which a change is recorded in the audit log. So far I don't find anything that tells me otherwise.
I've changed the setting in a test tenant I have and I'll wait for the log import to refresh to see what it comes through as (if at all).
The point here is that I don't have a definitive list of the configuration changes that will appear in the audit log to determine whether or not it meets the needs from a complance standpoint, rather than something being changed ad-hoc, without testing, and potentially putting important information at risk.
You are using the only approach, the Audit Log Search reports any "Changed A Sharing Policy" activity. Run a search with that value and you will get the info you need.
