AAD app provisioning time expectations

  • 52 Views
  • Last Post 31 March 2017
barkills posted this 30 March 2017

We’re trying out AAD app provisioning (salesforce, but it shouldn’t matter). 5 users assigned, via a group.   I’ve read the couple articles Microsoft has published on this topic.   Based on what’s documented, plus what I’ve observed, the approach to AAD app provisioning seems to be that for the initial provisioning sync, some provisioning process must touch every user and group to evaluate if they are both assigned and in scope. Once that initial sync is complete, the documentation suggests that subsequent syncs are “smarter”.   Our AAD tenant has almost 900K users and 30K+ groups.   The guidance says that for “large” tenants, the initial provisioning may take hours.

  We’ve been running the initial provisioning for 43 hours now. Based on the audit logs and other indications in the portal, the provisioning process is definitely still working.   The tools and documented guidance clearly can’t give me good expectations on how long this will take.   I’m wondering if there are any other tenants of approximately our size which have done an AAD app provisioning, and if so, how much time it took for that initial provisioning run.   Thanks,   Brian Arkills

kool posted this 31 March 2017

I work on Brian’s team and have written an AAD tenant monitor application that downloads AAD audit API events. We’ve done this to get an early warning on unexpected changes of which there have been many (mostly

thanks to MS for releasing stuff with insufficient prior notification but also to ensure that our own admins and users don’t make risky changes).

 

I noticed a few days ago that the app was throwing errors. The volume of audit events had gone through the roof. I was completely puzzled until I saw Brian’s email below and the ah-ha light went off. Yes, it

is generating an audit event for every user and group touched by this ridiculous provisioning process!

 

Like Brian says we have a huge AD/AAD. Still, we have been averaging a few hundred audit events an hour over the last several months I’ve had this app running. Starting Tuesday, this surged to 20+ thousand events

an hour. I don’t know the exact amount though because the API calls get throttled. Each call gets a batch of events with a skip-token to get the next batch. A 403 Forbidden is returned after around the 60th skip-token fetch. I could reduce the query

time window down to, say, a half hour instead of one hour which might avoid this but I haven’t done that yet.

 

This process has also yielded a new type of audit activity that I’d not seen before. The activityType is Application with an activity of “Synchronization rule action.” I’ve also noticed that the throttling is

rather unpredictable. It throttles after anywhere from 20k to 32k events. I could write code to restart the query when a 403 is received, but it isn’t clear to me if the events are being returned in a specific time order. I do time-range queries so I’d need

to know what range has been received. As it appears somewhat random, this does not appear feasible. The only other option I see is to reduce the time range when this kind of flood occurs.

 

More details for those who might be interested. The new Service Principal for this SalesForce instance has an object ID of 7ee94405-a86f-4481-a395-530fb18cbee8. It turns out that this object is the target of

each of these events. The actor that is initiating the event is “Azure AD Cloud Sync”. The category is “Account Provisioning” with the aforementioned “Synchronization rule action” activity value. The activity status for one of the events is:

Status : Success

Reason : Group '89c90fda-b66a-47f5-ae5e-56ae10639b28' will be skipped. The Group in Azure Active Directory is not assigned or did not pass the scoping filter

Under Additional Details it lists:

Details : Group details: Skip reason = NotEffectivelyEntitled, Active = True, Assigned = False, Passed scope filter: True;

ErrorCode : None

EventName : EntrySynchronizationSkip

And lastly the Modified Properties:

Name : members

New Value : fba85882-a687-41f2-8090-7b5be52f86cf

This is strange. When I query the Graph API for the SalesForce Service Principal it does not show a “members” property.

 

This is a really messy design. Clearly this activity is internal bookkeeping for AAD back-end processing. It shouldn’t be showing up in the audit API. It just increases the noise to signal ratio. I’d love to

be able to filter it out, but the audit API OData query filter language does not support negation. I can’t say “show me events that do not include this activity.” I complained to MS several months ago about the lack of useful query structures.

 

If anyone has any additional info about the app provisioning process please share it.

 

Thanks,

 

    Eric

 

show

Close