SCIM provisioning - custom app authentication
Hi, in the documentation for handling endpoint authentication, two methods are given: 1) a "long-lived token" (i.e. a secret key that has to be pasted in-clear by the admin) 2) "Microsoft Entra bearer token" - similar to other services (e.g. callbacks for MS Teams bots), Microsoft sign the outgoing calls, and the app being provisioned can validate them against Microsoft's public keys To me, option (2) is by far the best - each message is signed individually, there is no manual handling of secrets etc. As said in the documentation - "Apps that use Microsoft Entra ID as an identity provider can validate this Microsoft Entra ID-issued token." - great! So why on earth does it then say "The token generated by the Microsoft Entra ID should only be used for testing. It shouldn't be used in production environments."? Why not? The whole system of Entra bearer tokens is only for test? And production should go back to secret keys, with all the problems they have? It doesn't seem right.. What am I missing here?
Failed authentication with SAML Certificate
When I create a new Enterprise application, and I set up SAML-based SSO. The token signing certificate (Base64) I get fails to login my user into my application. I have to re-upload the certificate for successful login request. This has started happening often.
Azure AD SCIM Validator is in General Availability (GA) Status
You can now validate the compatibility of your SCIM provisioning endpoint and Azure AD code base using our Azure AD SCIM Validator. This tool can be used by ISVs who want to build SCIM compatible servers either for gallery app or generic app and developers building their line of business SCIM apps.https://learn.microsoft.com/azure/active-directory/app-provisioning/scim-validator-tutorialI would like to understand the ease of integration between Entra ID and Atom C2
We are using Atom C2 as our ticketing platform to submit various types of requests, including access request, and would like to keep using C2 while making our transition to Entra ID, I am trying to understand the ease of integration between C2 and Entra ID. How would I go about doing it, could someone point me in the right direction?Syncing multi-value Extension Attributes with SCIM - attribute is "undefined"
We have a number of extension attributes that we sync from our on-prem AD to Entra ID. One of these attributes is roomNumber, which is a multi-value attribute. We use SCIM to send Entra ID users into various systems, and we wanted to add roomNumber to these feeds. I can query Entra ID by MS Graph and see that these fields are populated (see screenshot): I can also use the Expression Builder in the SCIM apps to query roomNumber against our users (see screenshot): But, when I then try to send this attribute over to any receiving system, the logs show that Entra ID says the attribute is "undefined" and so sends nothing over. I have done a number of things: 1. Modified the app schema to ensure that roomNumber is multi-value 2. Used expressions such as Item(attribute,index) in case there was some issue with retrieving an array. What do I need to do for user provisioning to pickup the roomNumber value?
Issue with API-driven provisioning and Supervisor ID
I am trying to use API-driven provisioning to create new user accounts from my HR system. One of the fields that you should be able to map is the Manager ID to assign the manager. Up until now, we have created Entra users manually so I have added employee IDs to some accounts. When I run the provisioning I use something like "manager": { "value": "12345" } If I use the employee ID of a user that I created manually I receive an entry in the logs like: We were unable to assign 12345 as the manager of 12346. In order to ensure that the references are updated properly, you have two options. First, ensure that 100001 is in scope for provisioning. Provision 12345 on-demand and then provision 12346 on-demand. Alternatively, you can restart provisioning after ensuring that 12345 is in scope for provisioning. If, however, I provision a user with the API and then try to assign that user as a manager - then that userdoes get assigned. Is thereUser provisioning (not SCIM)
Hi I am trying to find a way to provision users to an API enabled SaaSapplication when the accountgets synchronized toAzure. Unfortunately the SaaS app is not really SCIM compliant and runs basic auth. I am looking todo something serverless like Automation Runbooks.I have tried Graph and PowerShell but am not finding a good way to Filter users based on createdDateTime for all users in last x amount of time. In fact, it seems Ican only read createdDateTime for a user if I specify their objectID and not their UPN which seems odd to me. PowerShell seems to have problems with the same type offilteringwith extensionproperty.createddatetime I have lots of examples that don't work such as: https://graph.microsoft.com/beta/users?$filter=createdDateTime gt datetime '2019-01-01' or $When = ((Get-Date).AddDays(-30)).Date Get-AzureADUser -Filter datetime 'extensionproperty.CreatedDateTime -ge $When' But these queries works: ((get-azureaduser -objectID <objectid> ).extensionproperty).createdDateTime and https://graph.microsoft.com/beta/users/(objectid)?select=createdDateTime It's totally likely that I don't understand the odata query syntax or have been looking at this too long LOL Has anyone tried this? Another angle I thoughtofmight be to watch the Azure Audit logs for Add User but that seems pretty far down the rabbit hole and might involve an event hub. Thanks in advance for any help, other ideas, concerns, commiseration, etc. Charlie
SAP application roles in Entra ID and user provisioning
Hello Team, Since SAP IDM is going to retire, can Entra ID be a possible replacement for it ? In some blog post from SAP they recommend themselves to use Entra ID instead of SAP IDM. Entra ID using its identity governance lifecycle workflow can cater to Joiner , Mover , Leaver scenarios and also since it has out of the box integration with SAP HR . But the main question is, since SAP 's applications are mainly Role driven, how can we map SAP application specific roles to users via Azure AD. Eg : User A has joined a company and using SAP HR its record and data is created in Entra ID , but now User A also needs access to SAP app 1, app 2 and app 1 ,app 2 have their own Role sets . How these roles can be made available in Entra ID and even if we some how make it available as a part of Entra ID group , once users becomes part of these group in Entra ID, how will the user provisioning to SAP app 1 and app2 work . Ideally in SAP, provisioning works via SAP IPS service but in Entra ID docs, all we have is just a way to provision the users to SAP IPS using SCIM . There are other SAP components namely SAP IAG and GRC which are the governing authority to provide access to the users to SAP applications to its requested role and provisions the users once the access request is approved in IAG or GRC . How can these systems be integrated with Entra ID. There are no connectors from Entra ID for such event based user provisioning.Can I use Entra API-driven provisioning to synchronize user data but not provision the user?
I'm thinking of scenarios that I've supported using MIM in the past where there is a primary HR system that would feed the user provisioning but there were also one or more secondary systems that would enhance the Identity information with additional attributes. In these scenarios only the HR system would initiate the user provisioning and the secondary systems would only be authoritative for some attributes. If the user were to appear in the secondary system and not the HR system the user would be ignored. Is this type of scenario currently supported by Entra? If not, is it something that is on the horizon?
New Blog | Important update: Deprecation of Azure AD PowerShell and MSOnline PowerShell modules
ByKristopher Bash In 2021, wedescribed our plansto invest in Microsoft Graph PowerShell SDK as the PowerShell provider for Microsoft Entra and transition away from Azure AD and MSOnline PowerShell modules. In 2023, weannouncedthat the deprecation of Azure AD and MSOnline PowerShell modules would occur on March 30, 2024. We’ve since made substantial progress closing remaining parity gaps in Microsoft Graph PowerShell SDK, andas of March 30, 2024, these PowerShell modules are now deprecated: Azure AD PowerShell(AzureAD) Azure AD PowerShell Preview(AzureADPreview) MS Online(MSOnline) You should migrate your scripts to Microsoft Graph PowerShell SDK as soon as possible. Information about the retirement of these modules can be found below. What happens to MSOnline and Azure AD Modules after March 30, 2024? As of March 30, 2024, Azure AD, Azure AD Preview, and MS Online PowerShell modules are deprecated. Support will only be offered for critical security fixes. They will continue to function through March 30, 2025.Note:Only MSOnline versions 1.1.166.0 (2017) and later are assured to function through March 30, 2025. Use of versions earlier than 1.1.166.0 may experience disruptions after June 30, 2024. Read the full blog post here:Important update: Deprecation of Azure AD PowerShell and MSOnline PowerShell modules
