We created an application with SCIM support over two year ago now and it always worked fine. However recently we have been getting reports from customers that users were no longer deleted/disabled from the target enterprise application.
I already saw there was another question like this one a few years back but that seems resolved and this seems like another issue.
We did a little research on our own and noticed that azure is not sending any requests at all when we remove a user from the assigned user list. We checked the incoming logs from our application and IIS logging and both do not show any requests are sent our way. (we do get logs from POST/GET/PUT of other provisioning related tasks, like creating a user).
In azure audit logs we do see the following:
Remove app role assignment from user
Add a deletion-marked app role assignment grant to user as part of link removal
Which seems to me that azure is doing something, it's just not sending it to the targeted application
Current situation:
We have user A that was created in azure ad and is assigned to our application. Provisioning configuration was done by means of SCIM in azure. And the user is also created in our application, so the connection seems fine.
When I remove the user from the assigned user list in our enterprise application, I expected that counts as a softdelete, causing Azure to sent a PATCH or a PUT to set the active property of the user to false. In case I would delete them entirely from AD I expected them to be removed with the DELETE. I read that it takes up to 30 days which is no problem, but the problem is that user that are no longer assigned are still active in the target application, which is no good.
I have some basic properties mapped on the user and the one thing that might be involved with this issue would be the Not([IsSoftDeleted]) mapping which is mapped to our active property. I don't see how that is wrong, but that's all I can think of at this point.
Anyone that can has any idea what is going here?
Thanks!
I have had contact with Microsoft regarding this issue and it seems to be a bug on their end which they are currently correcting. It is part of a larger set of bugfixes all regarding similar issues so they could not give me a specific time when this specific issue was resolved, but they think around the 10th of July (2020).
In any case, as this was a bug due to changes pushed by MS this is no longer an issue to be solved.
Update:
I have received some replies that a few bugs were fixed connected to this issue but not all. I'm currently on vacation so i'm not sure if the main issue is fixed as well. They did promise a fix fast though.
For now all I can give you is a workaround. The issue happens when the only change that is happening is the unassignment of users, it simple won't execute this until at least 1 property from an assigned user is also changed. When anything is changed, it will fix all unassignments and disable them all, even if the unassignment was in a different sync cycle. So until the actual fix is pushed, that might be helpful to know.
I will keep this thread updated if I get more information.
Ps: The Azure team requested that if anyone else also ran into this issue they report it through Azure. Their dev team will see if your problem matches up with my issue or if it's something new. So please do that as well.
Related
Today, June 23rd, 2022, we are experiencing a mysterious phenomenon that I simply can not see myself out of.
We are a software company where our customers use Azure AD as a login method using SimpleSAML.
This means that these are different websites with different associated Azure ADs.
Today, we have seen that 7 different sites, incl. one of our own, experienced to get the error:
SimpleSAML\Error\Error: UNHANDLEDEXCEPTION
Caused by: Exception: Unable to validate Signature
The above is solved with a refresh of the metadata, and the pages are live again without any problems.
No certificates are due to expire, and the earliest will not expire until 2023.
I can not find any global issue with Microsoft or Azure, and our setup has been working fine for so long, and with the refresh of metadata, it's working again.
Does anyone have any clue on, what could be the issue? It just seems strange that there are 7 different websites, with different Azure setups and different metadata who experience this kind of issue on the same day, within 8 hours of each other.
Beware that we are running a daily cronjob to ensure metadata is refreshed.
Image of the error from 1 of the sites
Microsoft products automatically perform rollover for their certificates. So it can be that the parties you interfaces with automatically rolled over to new certificates. Refreshing the metadata explains why that solved the problem.
ADFS/AD will have the old and new certificate both in metadata for a while before the old one is invalidated, so periodic refresh should work to keep the service working without downtime.
I'm trying to use Azure AD as a standin for production level ADFS systems during development of an application. Up until today, everything worked fine. I don't know what I touched to break everything, but now I'm getting the following error:
AADSTS700016: Application with identifier 'https://foo.bar.localhost:44300/' was not found in the directory '[[GUID]]'. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You may have sent your authentication request to the wrong tenant.
I don't know what's changed, or why this worked last week and not today. I've been trying to change any number of settings - even deleted the app and re-created it, and nothing seems to help. Most of the other articles online keep referring to old versions of the Azure portal, so the clicks/links/menus that they are referring to no longer apply. There's a little popup on my sign in screen that says that I can enable "Advanced Diagnostics", but I don't know where those results show up so that I can see it.
Some things that I've checked:
- Under "App Registrations", the Endpoints for "Federation metadata document" and "WS-Federation sign-on endpoint" match what my application is using (so I'm going to the right place).
- When I click my application, under "Authentication", the Redirect URIs contains "https://foo.bar.localhost:44300/". I've tried with or without the trailing slash (and, sometimes, both).
Those are the biggest two places that other articles imply there may be an issue. Does anyone have any other ideas? Are there specific user-level things that I should be doing? Has something changed (very recently) that would be affecting my ability to use this feature? How are Enterprise Applications related (they're a Premium feature, and my Subscription is not)? I need to get my log-ins working again so that I can get my development process back underway. Thanks!!
Finally found the right setting. Turns out, many of my old applications were created when I was a "personal" user. I've since become a domain/work user, and it puts some things in place differently than before. In this case, I had to change the Application ID URI listed under "Expose an API" for my application. Setting this (where it wasn't set to anything before) allowed my application to be found and my login to succeed.
I finally decided to give Azure a try and the first thing I do - creating a simple web site - fails with: Creation of web site 'null' failed. Details say: Provisioning failed.
I am simply trying to "quick create" a simple website. Researching the Web, I see other people with the same problem, but no real solution.
I do have an active "Visual Studio Ultimate with MSDN" subscription and $150 of unexpired credits.
I must be missing something very fundamental.
Seems to be known issue:
A number of users have experienced “Provisioning Failed” errors when
attempting to deploy Windows Azure Websites. This is a known issue
with the trial version, and there is an active discussion thread on
the MSDN forums here.
It is expected that this is a temporary problem that will be fixed
soon, in the meantime there are a few things you can try: Ensure
database passwords do not contain special characters like ', ", =,
etc. Try creating a website without a database, database creation may
be causing the error. Try deploying the site in a few hours, it may be
a temporary problem in the data center.
So, to put some closure on this, I contacted Microsoft Support and they suggested trying to login to the portal through an anomymous/incognito browser session. Once I did that, I was able to create a website.
Mind you, having cleared all persistent data (cookies, etc.) in the regular browser, I still cannot do anything in Azure, from several different machines. But at least the incognito session is a workable workaround.
This is Dynamics CRM 2011 Rollup 11 On-Premises with SQL 2008 R2
Have the following scenario that we're trying to debug:
In a Synchronous PostCreate plugin we add users to a Team that owns a specific record and has read permission on that record via a security role. That should mean that when the Create process is completed the users added to the Team have access to the record. When such a user then goes to open the record they get a SecurityException ReadAccess error. The record does show in grids, which should not happen if they do not have Read permission on the record.
As a further test we execute the SDK call RetrievePrincipalAccessRequest for the user and record, from a console application, and see that the user does not have Read permission.
We can look a the Team Member list in the UI and user is a member of the Team. If we wait long enough (and create another record the issue will eventually resolve itself - several minutes later.)
We can add a user to the team, using the same code we executed in our Plugin (but running in a console app), and the user has Read permissions and can access the record immediately after the call completes.
There is clearly something going on in our Plugin that is causing an issue but we cannot figure out what or why - since the Create call completes without error and we can see the user listed in the UI. We are not doing anything funky - i.e., direct SQL, external service, etc.
We call a standard CRM 2011 SDK message and it completes without throwing an error. We can validate that the user was added in the user interface. The user have permission to Read the entity but they do not.
Any thoughts/ideas?? We've been tracking like crazy but haven't found our smoking gun!
UPDATE
We can reduce the incidence if you we put a pause in our plug-in code. This error only occurs when the add is done during a plug-in, not when it is done outside the plug-in. I'm starting to wonder if there is a SQL procedure/statement (there are three stored procs that fire when a user is added to a team) that gets cut short or fails to complete, for one reason or another, since the add is successful when not done in plug-in code.
Finally found the answer in the list of items resolved by Rollup 18 (http://support.microsoft.com/kb/2958724)
If You are assigning Team Membership via plugin, the user Cache does
not get invalidated, causing an error when trying to retrieve a
record. The issue occurs if the Team is has a security role and Access
Rights are controlled via Team ownership.
We had opened a ticket about 2 months ago with Microsoft which had involved a lot of back-and-forth but not a definitive fix.
So if you experience the same issue on CRM 2011 you need to update to Rollup 18.
I've been playing around with the new "Websites" feature of Azure (which I believe is still in beta), but I've run into a problem. I've got two subscriptions associated with my account - one for personal use, the other for my company. And of course, I'd like to be able to specify which subscription is used when I create a new website. But when I try to create a website, it always picks my second subscription, and never gives me a chance to specify which one I'd like to use. Nor can I figure out how to move the website to a different subscription after I've created it.
I've walked through this several times now, and I can't spot any place where I can specify which subscription to use. Is this just a beta glitch? Or have I missed something?
I ran into the same thing, called MS support. Switch back to the standard portal to make this change.
To get to the old portal hover over the green "preview" button at the top. This doesn't seem to work in Chrome for me, just IE.
Do take a look at my response on MSDN Forums for a similar question there: http://social.msdn.microsoft.com/Forums/en-US/windowsazurepurchasing/thread/d9624b03-1d6c-484a-9fa8-8548c35a9d4f/. Basically you would need to activate this feature for each subscription separately since it is in preview mode.