Using the Microsoft Graph API I need to be able to update the attribute proxyAddresses as part of our provisioning process to enable self-service password management for our end users.
I see that this attribute is read-only from the Graph API but as of 8 months ago MS was entertaining the possibility of making it RW. Does anyone have any color on this, has anyone found a workaround to this issue via API?
This isn't supported in either v1.0 or Beta at the moment but this is an open OverVoice request for this feature: Ability to update the user's email aliases (proxyAddresses attribute).
Also if you are working with bigger customers - usually you want to sync their identities from local Active Directory using AD Connect tool. In that case you should implement things and change proxyaddresses attribute in local AD, because it is the "identity authority" (means that you can't change it on cloud side and it must be done in on-prem AD).
So it could be workaround for problem you are trying to solve.
Also if it is cloud only (not synced) identity - you can use PowerShell to modify proxyaddresses attribute on users.
Here is documentation on how to do that - https://technet.microsoft.com/en-us/library/bb123794(v=exchg.160).aspx
Related
I have not started any script yet but wanted to check first If this can be achieved to configure Azure AD Non gallery enterprise app using PowerShell that let me enter metadata such as entity id, reply URL, sign-on URL and attributes information.
I need a suggestion to start on this If you could shed some lights?
For powershell, this is not currently possible.
In May, Microsoft added the ServicePrincipals endpoint to 1.0 graph api for (enterprise applications). So using graph api, you may be able to accomplish it. I know until very recently this was still not possible, however checking today the updateserviceprincipal endpoint seem to have the replyurls attributes and loginurl and the serviceprincipalnames (entityid?)
So there is a good chance you could get it to work using graph api. but you may have to use the beta graph endpoint.
I would use this endpoint to create the application: https://learn.microsoft.com/en-us/graph/api/applicationtemplate-instantiate?view=graph-rest-beta&tabs=http I believe the custom basic saml app template id is : 8adf8e6e-67b2-4cf2-a259-e3dc5476c621
after creating it. you would need to find the service principal objectid and set the signinmode to saml:
Here are all the necessary calls and example. https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/application-saml-sso-configure-api#step-2-configure-single-sign-on
is it possible tracking all authentication requests on AD Server? no matter the requests go through LDAP, Kerberos or NTLM, and getting know the source IP address and account name?
That information is already in the Event Viewer on each of your domain controllers.
If you search online, you may be able to find some software that can be installed on each DC that will consolidate all that information for you to make it easier to look at and search. But I've never done that, so I can't recommend anything.
I have a (not so small) project started with ReactJS and Firebase web SDK - and I would like to somehow manage (at least add & delete) users in my system.
I am totally aware, that there is an Admin SDK, but I wouldn't like to transition to that in the current phase of the development. I would like to go on with the web SDK.
I have seen this nice workaround regarding the user-addition - and I managed to create & insert users with that.
Now, I need a way to delete or suspend users (at least), if possible. (I don't need strictly to have the update option, I can live without that.)
Do you now any way / workaround to that - similar to the point 2. ? Any idea how to achieve that?
The mobile and web clients for Firebase Authentication are not capable of changing the status of an arbitrary user account. A user account only has permission to delete itself, not other accounts.
You will need to use the Admin SDK for that, from a backend or desktop system you control. Initialized with a service account, it will have privileged access to manage user accounts.
I have a standalone web application (not an add-in) and I would like to access Project Server PWA oData from this web application without using the PWA username/password combination.
I can do this for SharePoint oData by registering my web app in Azure AD and configuring the application to require "Read" permissions from "Office 365 SharePoint Online"
If you are interested to do this for SharePoint data, see this article for details: https://www.itunity.com/article/integrating-angularjs-aad-office-365sharepoint-part-1-622
My problem is that I want to do the same for a Project Server, but can't see any relevant Project Online permission in Azure AD.
Has any one ever accessed Project Online using Azure AD tokens?
My 10 Minutes of Internet Research™ leads me to believe this isn't available but that it was a planned feature at one point. [see here]
Without knowing much (anything) about Project Server, this seems like a situation I've dealt with on AWS at work. We have a bunch of endpoints that are secured using IAM (AWS) credentials and we can't leave those creds lying around in our app (because that would be silly). Our solution is to generate access URLs server-side and hand them out, these typically will have a time limit and be restricted to a very specific action.
A quick search for Azure's equivalent to IAM tells me that you might be able to do something similar though I'm unsure it exists for Project Server.
That failing, you could always set up an intermediary micro-service that acts as proxy and has the username/password combo. We do stuff like this all the time with Lambda (AWS's serverless functions).
We’ve got a CRM 2011 implementation using IFD which in turn means is uses claims based identity and ADFS.
I’m struggling to determine how I can keep my user logged in across multiple browser sessions.
I’m not an ADFS expert; I know enough to watch the How-2 video for CRM IFD and click through the wizards. Usually I'd back myself to Google something like this in no time but I've had no luck to date.
Can anyone provide some guidance as to how I might configure some sort of persistence of login in this setup? i.e. for the user to remain logged in and able to return directly to CRM even when they close their browser.
You need to increase the TokenLifetime. Refer:
CRM 2011 ADFS and TokenLifetime
It is hardcoded to be a session cookie in Microsoft.Crm.Authentication.CrmSessionAuthenticationManager, Microsoft.Crm.Authentication
You would need to decompile the class, change the code and configure CRM to use your new module in the web.config