We explore, once again, the directory extensions project at
Per the instructions, we configure the software to leverage an application, using that from the last post (which explore group claims and graph objects). We use graphexplorer to learn the value of the appobjectid:
and use clientid/clientsecret from the azure portals page about that application:
we build the project, once we have managed the various nuget dependencies (by adding them to the projects)
while the project doesn’t seem to work (on windows 10 beta) first time, we do see that it can get credentials as we debug.
to debug, we first figure that we need to alter the canned user for our tenant (hardcoded to be “admin”).
since we get a runtime error related to extensions binding, we note next that there are no extensions for this user class (which PERHAPS explains the issue).
see https://graph.windows.net/rapmlsqa.com/applications/4079c44a-e4c0-4e45-9ec3-e11d7f259f74/extensionProperties (SEE BELOW FOR NOTES ON THIS TOPIC)
anyways, we fiddle around, and eventually get the form to load for the default user. We then add a form parameters so we can focus on our chosen user:
Some notes (we add application permissions, that may or may NOT be relevant…)
We also learned that the appobjectid is the objectid value from the graphexplorer view. We amend our project.
We can now look at graph extensions in the graphexplorer site and also we can run the tool to create new schema extensions:
having created skypeid as a user class extension property and allowed this application to use it, we can populate a value for rapstaff user using a form that cues off the schema/metadata of the (now extended) user class:
Obviously, each MLS tenant can be its own “application” and receive different user class extensions, with local names, etc.