Hello. We currently have devices bound to Active Directory and are testing (in dev) a migration to Azure. We currently have extension attributes for some items, such as software licensing. When software licenses are purchased, the license holder's AD user object is given group membership in the Active Directory group of license holders for that app. Access to that app in Self Service is made available to those license holders based on an extension attribute that accesses AD, looks for the AD attribute for that software license group membership, and populates a smart group based on the logged-in user's membership in that group. I've been looking online for documentation for a similar way creating an extension attribute for accessing Azure and determining if the logged in user is a member of an Azure group, but I am not finding much info, or I'm not looking in the right places. Thanks for any help you can give me with this.
Extension attributes after Azure migration
+4
+1I am in the same boat for pulling down information from AAD for extension attributes, namely configuring a UPN field for configuration of a security tool. It worked seamlessly with LDAP, but migrating our LDAP connections to AAD doesn't seem to be enough for the previously configured EA to continue working and populate attribute.
Did you ever make any headway on this @xian?
+4I am in the same boat for pulling down information from AAD for extension attributes, namely configuring a UPN field for configuration of a security tool. It worked seamlessly with LDAP, but migrating our LDAP connections to AAD doesn't seem to be enough for the previously configured EA to continue working and populate attribute.
Did you ever make any headway on this @xian?
Hi @SaltyCornelius Jamf suggested that we use the Scope > Limitations tab when using Azure groups for policies and profiles. I attempted that, but the necessary groups were not listed. I checked back with Jamf and was told that the reason is that we migrated to Azure manually prior to the release of Jamf Pro 10.37 instead of using the automated migration that was included with the Jamf Pro 10.37 release. We were told that if we back out of our previous Azure deployment and redeploy under the current version of Jamf Pro, the missing groups will then be accessible. We plan to try this tomorrow in our dev environment and will report back with the results.
+1Hi @SaltyCornelius Jamf suggested that we use the Scope > Limitations tab when using Azure groups for policies and profiles. I attempted that, but the necessary groups were not listed. I checked back with Jamf and was told that the reason is that we migrated to Azure manually prior to the release of Jamf Pro 10.37 instead of using the automated migration that was included with the Jamf Pro 10.37 release. We were told that if we back out of our previous Azure deployment and redeploy under the current version of Jamf Pro, the missing groups will then be accessible. We plan to try this tomorrow in our dev environment and will report back with the results.
Thanks - appreciate the reply. I am pretty sure we used the automated migration tool, but still can't seem to do anything! I wish you luck with backing out and trying again. Yeah, would appreciate an update on how it went, if you have the time! I have worked around my issue for now, by pulling similar information from the Office plist file in the extensionAttbribute, but it is far from ideal.
Thanks - appreciate the reply. I am pretty sure we used the automated migration tool, but still can't seem to do anything! I wish you luck with backing out and trying again. Yeah, would appreciate an update on how it went, if you have the time! I have worked around my issue for now, by pulling similar information from the Office plist file in the extensionAttbribute, but it is far from ideal.
Hey @SaltyCornelius, can you share a little bit of your workaround? I'm trying to gather similar data that we received in the EA for LDAP Attributes but JAMF is not giving the info needed to figure out a workaround other then limitations.
+5@SaltyCornelius I would also be interested in how you got the extensionAttribute to work, as I need to pull one from AAD .
+1Hey @SaltyCornelius, can you share a little bit of your workaround? I'm trying to gather similar data that we received in the EA for LDAP Attributes but JAMF is not giving the info needed to figure out a workaround other then limitations.
Hi @alstalent & @joboo72 !
So I used a defaults read on a plist file for Outlook that contained the primary account email address for the EA. However, I realised later that it was actually much easier to get the information from the $EMAIL variable (which was pulling from AAD lookup when assigning users to devices, even though UPN was not working as it had done with on-prem) from within Jamf - it was the same data as what I was getting from the defaults read EA, of course.
Though Email is not always the same as UPN in our cloud accounts, it got things working for the vast majority of users and left only a couple with a requirement for manual intervention.
Unfortunately I never had the time to revisit and try and find a 'perfect' solution and extend that for looking up any and all fields from AAD.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.