30 day audit limits on M365?

[Ditto]

I'm looking for some advice around audit time limits with M365 products. I have discovered a private folder of mine on SharePoint that is accessible to a number of colleagues that it should not be. I have asked our support team to provide a list of who has access, when the access was provided and who provided it. They have returned of list of those who has access, but have said they can not provide the other details due to being able to only look back 30 days in the audit.

 

Is that likely to be the case or should there be logs that provide the answer? I'm on a E3 license if that's relevant.

 

They are also claiming as the newish IT provider they can't see what the previous provider did - but from my perspective they took over our licenses so I'd hope for a continuum of data.

[psydii]

Yeah there is a 30 day limit on detailed data from MCAS/Defender for Cloud Apps, which is probably where they are pulling the access logs from.

 

You *can* go back up to 6 months, but you can't filter by say SharePoint site folder as you can with the 30-day data, and you can only search in blocks of 1 week.

 

I think from the data you get back you can export it and run it through excel, but not being able to filter first and the "1 week" limit on returned queries almost certainly makes performing the investigation you have requested impractical, unless it is super-sensitive in which case I guess the team will have to suck it up.

 

FWIW as DP Lead and the Global Admin, I have had to do this once.

 

https://learn.microsoft.com/en-us/defender-cloud-apps/activity-filters-queries#query-activities-six-months-back

[Ditto]

Thanks for this @psyii. I have passed this information on to our IT support team. Since discovering the issues, we have found a user who joined as recently as late August with incorrect permissions so we can focus entirely on changes made by this provider and forgot about the previous. They came back to me saying they had a run a search that showed no changes to permissions in the past 6 months, but that seemed odd. I queried how they did 6 months as the link you gave pointed out you could only do a week at a time. They then confirmed what they use is called Microsoft Defender for Cloud Apps Discovery. Then they explained they didn't use Defender for Cloud Apps as the section for audits requires specific licensing 'which there are none on the portal'. Does that make any sense to you?

 

Ultimately, do you think 6 month logs exist, they just very difficult to get to? They've requoted the 30 day limit but then said they'll need to do some 'digging' to say who added the recent joiner.

 

As best I can deduce at the moment, a parent directory (and maybe several grandparent directories) of my file has a permissions group of 17 people (it should be more like 3 or 4 at max). The new individual is thought to have been added by one of those in the group, but we want to know who for some training - and sorting out permissions on our SharePoint will no doubt be a multi-thousand pound project they can run for us, but given the mess they inherited, we have to live with that.

 

I used to do this sort of thing on Google for Workspace - it seemed relatively straightforward, other than a bit of time to get to understand how to use vault.

[psydii]

Hi @Ditto,

 

I think they are saying your tenant isn't licenced for MCAS. Which puts this outside of my experience. I'm not sure how much access to what audit data one has without it.

 

If the event was within the 30 day limit and you have MCAS the "Activity Type:AddedToGroup" filter might return the information you are after.

 

This page suggests the raw audit data is available https://samilamppu.com/2020/08/07/office-365-audit-events-visibility-in-cloud-app-security/ but I've never seen people talk about querying and searching it - and I spend a bit of time on infosec / SharePoint twitter so it probably falls into the realms of specialist forensics (though I could be wrong).

 

Sorry I couldn't be of more help.

[Ditto]

So this has rumbled on and on with our IT support staff and with no clear explanation of what's going on to date. The big issue we have that lead to a data breach is we have a large number of staff as 'Members' at the top level of a site with edit access. Picking the most recently recruited staff, I have asked how they got to be a member of a group. The latest suggestion by our support is that the ' some how added themselves'. They then state that they learnt this after logging into o365 admin and 'ran' audit logs. The image of the output doesn't include headers of truncates columns, but what it has is 'Added user or group to SharePoint gr...' with the users name twice - I can only presume the columns are who was added and by whom. Support then went on to say this access was given by a sharing link, but they can't see who generated the link. Is it possible that someone can add themselves to a " members" group by some obscure means so easily? I have asked for a search on emails with the sharing link to the user.

 

Later, they made reference to a Limited Access Group and stated users were added to the limited access group and from there they can add themselves to the SP site. From my limited understanding of limited access permission, is that they are internally managed - is the scenario painted by the support team realistic?

 

Finally, they attempted to restrict access to to my named folder within SP() but we have very quickly shown another colleague has edit access still - I'm presuming because the are in the long list of SP() members. Would there be a way to set permissions on this subfolder that override the parent directory?

[Boredguy]

Finally, they attempted to restrict access to to my named folder within SP() but we have very quickly shown another colleague has edit access still - I'm presuming because the are in the long list of SP() members. Would there be a way to set permissions on this subfolder that override the parent directory?

 

Yes you can do this within SharePoint, and I do it often on our Class Teams. There is nothing stopping you from removing the group from any folder within the SharePoint Documents or Pages and substituting it with different permissions for other groups. Heck you can remove all the default groups within it and either use Direct User permission or AD Group in the same manner as NTFS.

 

Also this can only be done by people in the "" group, which is normally the account that created the SP Site and anyone they added.

[Ditto]

Thanks - I thought that would be the case, which means the IT provider hasn't done it right - and most likely for another 16 user named folder. The original creator is long gone though, but is still showing as the creator. It remains a mystery as to how the others got in the group though. I'll keep digging, even though they tried to close the case because we said we'd speak to the customer relationship manager about a SharePoint HealthCheck (at more expense), but that is for a company wide issue, not a the specific known problem that I have identified.

[Boredguy]

The GA account in Office 365 can easily add members as Owners of the SharePoint group, but it will still show the original user as the creator if no-one has actually updated the site page, especially if the content is dynamic or just used as a document store.

 

This type is issue is why I generally only put 1 or 2 accounts as Owners on the actual SharePoint sites.. Teams can have more since any "Teacher" is automatically a Owner for them as the students are the members, but for most SharePoint sites, the bulk of the staff can just be visitors unless they have a need to create pages/update documents but even then you can use other permissions on the folders to allow a smaller subset