edsaAzureUserPrincipalName attribute blank / not working

Please bare with me, I am trying to breakdown other people's work. What I am looking through now is a 'deprovisioning' workflow. That workflow does a few things, but it is pulling the edsaAzureUserPrincipalName and the edsvaAzureObjectID. the object ID is present. If fact I can search in Active Roles MMC and yes, that is there. I can even filter on that property.

Ok, the script stops running if the edsaAzureUserPrincipalName returns blank. When I search in the MMC, the property is null. In fact I can't event filter on that property. When search for properties to filter on, it doesn't return available.

I am looking to try and rewrite the existing code, as I am good with powershell, no so much with quest scripts / workflows yet. The object ID in azure really should be good enough. The issue is there are a lot of scripts that are using this attribute. (edsaAzureUserPrincipalName). I did see that there is an article that you have to do a get-qaduser and get both properties (edsaAzureUserPrincipalName and edsvaAzureObjectID) otherwise it will return blank. So the scripts do that, but when I am connected to quest via the shell, it will not let me filter / include other properties not found in the default. I assume there is an acess template controlling that.

Finally I read up and found that the edsa attributes are calculated vs the edsva being a virtual attribute we get to populate. Anyway any help on figuring out this mess would be helpful.

  • I'm not quite clear on what your question really is but I will offer this:

    Many of the "...Azure..." virtual attributes are not writeable as they are pulled on the fly from your tenant.

    One which you can write to is edsaAzureUserAccountEnabled.  If you set that to FALSE, and the edsvaAzureObjectId is also populated on that AD object, AR will disable the equivalent Cloud object for you.

  • Well I think we are starting to sync. I understand now that they are populating on the Fly. That is good to know. Would there be a reason it would be blank? Is it possible that the connect to 365 is not working correctly? For the edsavAzureObjectID is present on ALL objects. again not sure HOW it is populating, but the AzureUserPrincipalName is coming up blank. I assume there is a connection error somewhere in quest to 365 / Azure? Oh, and something else to know we are running 7.4. I know that is unsupported. Not sure if there are new issues with that.

  • To your point about the edsaAzureUserPrincipalName - if I want to see if an object is Azure-enabled, I will look for:

    edsvaAzureObjectID
    edsvaAzureOffice365Enabled

    ...these are the two attributes that determine if AR knows about an equivalent Cloud object for the on-premises AD user.

    As you may have found, you need to explicitly request these when doing a Get-QADUser - i.e. -IncludedProperties edsvaAzureObjectID,edsvaAzureOffice365Enabled

    You must also include the '-proxy' switch so that your query is directed to/via the Active Roles server.

    'Hope that helps.

  • So do i need IncludedProperties edsvaAzureObjectID,edsvaAzureOffice365Enabled, edsaAzureUserPrincipalName to get a value for edsaAzureUserPrincipalName? I guess this all broke sometime end of year last year. My original thoughts were around basic auth being turned off my Microsoft.

    When I look at the attributes of a user that we are trying to deprovision or rather in this step backup all the attributes in EXOnline and Azure the edsvaAzureObjectID is present the edsavaAzureOffice365Enabled is true, but the value of the edsavaAzureUserPrincipalName is blank.

  • 7.4....mmm

    You can check your connectivity in the ARWebAdmin site of the Web UI.

    This documentation from 7.5 should help.

  • but the value of the edsavaAzureUserPrincipalName is blank.

    That would suggest that connectivity with your tenant is not working.

  • So it looks like our Tenant was not in the Azure configuration. I helped them get a tenant created in there with a service account. It is setup now as an Exchange Admin, User Admin, and Application Admin. When I do a check health I get Graph and Tenant connectivity as successful, but fail or a red X on Application Connectivity. Is that something that is needed to get the user? Also does it take time to get those edsaAzure* attributes to populate?

    I am getting mixed info on whether or not this SA needs Global Admin.

    Finally I am looking at 'Add Azure Application in Azure Configuration', the documentation is not very clear on what that is/