Hi gimesierra,

Did you ever get this working? I tired to set up the Azure AD User account collector for IG 3.7, with the same results as reported by you. Enabling DEBUG level logging does not reveal any additional information. Couldn't find any documentation about the collector either, so I had to guess things like the permissions required and parameter values. Connection test says "ok".

I've seen the same error message, and I found that granting additional rights to the service account that I'm using fixed it.  I think the error is generated when there are 0 results.  One way to get there is by not having the appropriate rights to see any Users.   I'm sure there are other ways to generate the same error too.

--Jim

Could be. I'm connecting to a test tenant and had Directory.Read.All and User.Read.All grants (Microsoft Graph) for the app. Since I'm trying to collect just the accounts (for now), I figured this should be more than enough. It would be really helpful if there would be additional debug logging but raising the daas log levels to debug doesn't give any more information.

I had added User.Read, User.ReadBasiclAll, and User.Read.All under Microsoft Graph.   And then you have to do the admin consent thing for those.

Also, because I'm a terrible IT guy, I additionally added a bunch of Windows Azure Active Dreictory permissions, but I woudl like to think the collector only uses graph.   So, if you end up thinking you need more permissions, I can list out what I've done with those as well.

--Jim

I thought about the legacy Azure AD Graph API permissions as well, but since it's already deprecated, I figured out this couldn't be the reason. Now that I think about this again, I'm pretty sure this is exactly the reason. The URL that the collector uses by default is https://graph.windows.net/, and this is actually the URL of the legacy Azure AD Graph API...

I think this also reveals why this is poorly documented. Why bother, since the used API is going away.

Granting old AAD Graph API permissions is no longer possible through the admin portal. I think it could still be done through powershell however. Maybe I'll try it, even though this collector clearly needs to be rewritten by NetIQ to use the Graph API.

I thought about the legacy Azure AD Graph API permissions as well, but since it's already deprecated, I figured out this couldn't be the reason. Now that I think about this again, I'm pretty sure this is exactly the reason. The URL that the collector uses by default is https://graph.windows.net/, and this is actually the URL of the legacy Azure AD Graph API...

I think this also reveals why this is poorly documented. Why bother, since the used API is going away.

Granting old AAD Graph API permissions is no longer possible through the admin portal. I think it could still be done through powershell however. Maybe I'll try it, even though this collector clearly needs to be rewritten by NetIQ to use the Graph API.

Greetings,
For Identity Governance versions 3.7.0 and earlier the Azure Collectors are utilizing the Azure Graph API. With the upcoming 3.7.3 on-prem release of Identity Governance, the Azure Collectors will support either the Azure Graph or Microsoft Graph API.  If  you have a set of collectors defined already you will only need to change a couple of values to utilize the Microsoft Graph API.  If you are starting fresh with 3.7.3, where will be a new set of Templates that will be configured for the Microsoft Graph API by default.

The documentation in 3.7.0 does outline the rights necessary for the Azure Graph API. The documentation will be updated for the 3.7.3 for the necessary differences for the Microsoft Graph API connection approach.

Sincerely,
Steven Williams
Principal Enterprise Architect
Micro Focus

Hi Steven,

Thanks a lot for your reply and confirmation about the functionalities. So it seems that we'll have to wait for the 3.7.3 to be released for on-prem.

-Ville