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.

Parents
  • 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.

Reply
  • 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.

Children