Forum Discussion
Access Package Assignment Issue
Hello,
We have an access package that was functioning properly in the past, but the assignment process has stopped working.
The issue started on August 22; the last successful assignment was on July 29.
When attempting to manually assign the access package to an external user, we receive the following error:
"You don't meet policy requirements to request this entitlement."
Additional details:
The configuration of the policy has not been changed.
Users who can request access is set to “None (administrator direct assignments only)”.
Changing the “Enable new requests” setting (enabled/disabled) does not resolve the issue.
Expiration is set to 90 days.
This access package is intended for external users, but I tested assigning it to an internal user and it works correctly.
At this point, I do not have additional information about what might be causing the issue. Could you please help us identify the root cause and suggest next steps?
Thank you for your assistance.
Kind regards,
8 Replies
It sounds like this issue is related to external user policies rather than the access package itself. A few things to check:
- External user eligibility: Ensure the external user is properly invited and exists in your Azure AD B2B directory. Expired or unredeemed invitations can trigger the policy error.
- Policy requirements: Even if the policy hasn’t changed, underlying conditions like group membership or directory settings for external users might have. Verify that external users still meet all prerequisites.
- Audit logs: Check the Azure AD entitlement or access package logs around August 22. Any changes in conditional access, B2B settings, or policy enforcement could show why assignments started failing.
- Test with a new external account: This can help isolate if the problem is user-specific or system-wide.
Most often, the “You don’t meet policy requirements” error for external users points to invitation, redemption, or conditional access issues rather than the package itself.
Great analysis from MortenLundPetersen ! The connected organizations approach is definitely the right direction.
Please make checks and leave a feedback.
Hi there!
I know it's frustrating when something that worked perfectly suddenly stops! The good news is that the symptom you're describing ("You don't meet policy requirements") combined with your timeline gives us strong clues.
UNDERSTANDING THE ISSUE
The fact that:
- It works for internal users
- It fails for external users
- Timeline: Last success July 29 → Issue started August 22This pattern strongly suggests a **change in external identity policies or B2B collaboration settings** rather than the Access Package itself.
MOST LIKELY CAUSES (Based on August Timeline)
1. Cross-Tenant Access Settings Changed
Microsoft has been rolling out stricter external collaboration controls. Check if someone modified:
- Azure Portal → **External Identities** → Cross-tenant access settings
- Look for new "Inbound access" restrictions
- Check if "B2B collaboration" is still allowed for your partner organizations2. Conditional Access Policy Blocking External Users
A new CA policy might be interfering:
3. Default External User Access Changed
Check your External Collaboration Settings:
- Azure AD → **External Identities** → External collaboration settings
- Verify "Guest user access restrictions" hasn't changed
- Ensure "Guest invite settings" allows invitations4. Access Package Resource Configuration
One of the resources in your package might now require additional permissions for external users:
- SharePoint sites with new external sharing restrictions
- Teams with changed guest access policies
- Apps requiring internal-only authenticationLet me know what you find in the audit logs and external collaboration settings! Also, please share:
- The exact error correlation ID (helps trace backend logs)
- Whether the workaround test policy works
- What resources are in your access packageI'm happy to dig deeper once we have these details - this type of issue often has a very specific cause that's not immediately obvious!
Good luck, and keep me posted on your findings!
Thank you very much for your information.
I've seen your message about "Microsoft has been rolling out stricter external collaboration controls." However, I couldn't find any Microsoft documentation explaining what was implemented and when, do you that?
Regarding the issues you mentioned, I have checked all of those things in the past. I'm one of the only sysadmins for these services, and I did not change any of the External Identities settings. Unless Microsoft changed something on their end, it's unlikely something changed here.
The access package simply assigns an external contractor to an Entra security group and runs a custom script via a custom extension to send an email to the external user. When I do a manual assignment, I get the error message, "You don't meet policy requirements," and the account is not created.
I did a test to change my policy from "None (administrator direct assignments only)" to "For users not in your directory," and selected "All users (All connected organizations + any new external users)." I am now able to manually assign the user with that configuration.
The problem is that this setup requires at least one step of approval, which I don't want. This process is part of an automation that was working perfectly a month ago, and we don't want to have to approve it as it's an automated process.
I think the only issue is that. Does anyone know why "None (administrator direct assignments only)" was working fine in the past to assign an external user and does not work anymore?
Hi Julien4
It looks like the problem is with how external users are handled in Entitlement Management after some recent backend changes from Microsoft.
The error “You don't meet policy requirements to request this entitlement” usually points to the access package policy scope. Since you have it set to None (administrator direct assignments only), that worked fine for internals but for externals it now requires that the external user’s home tenant is explicitly included in the connected organization for the catalog.
That would explain why it still works for internal users but fails on externals. Before, direct assignment worked for both. After the change in August, externals now need to be onboarded through a connected org to meet the policy requirements.
What I would check:
- Go to the catalog and confirm the external user’s organization is listed under Connected organizations
- Make sure the policy is scoped to allow that connected org
- Double check your cross tenant access settings for B2B inbound to make sure nothing is blocking
If you add the external org to the policy scope it should start working again.
You are right, I think
Thank you very much for your explanation MortenLundPetersen
Unfortunately, this approach will not work for our scenario, as the email addresses involved in this process can be from any domain (e.g., @partnercompany.com, @gmail.com, etc.).
I also haven’t been able to find any Microsoft documentation or communication mentioning such a change in Entitlement Management behavior. Have you come across any official information from Microsoft regarding this?
Thank you again
Hi
i dont expect Microsoft to annonce it, according to this page https://learn.microsoft.com/en-us/entra/id-governance/entitlement-management-access-package-assignments#directly-assign-any-user-preview
the ability to direct assign users outside your organisation is in previewe, and therefore subject to change without prior notice, this is also why i never recommend using a preview feature in a production enviroment.
i know this doesn’t help you but it could explain why it stopped working all of a sudden.
