Share all details about your problem, including any error messages you may have received.
Hi Sailors,
I am working on onboarding the Azure DevOps connector application for the first time. I completed the aggregation part without any issue; now I am working on the provisioning part. Here I tested adding and removing entitlements of existing Azure DevOps application users; it’s working fine. But while I am trying to add a new user to that Azure DevOps application, I am facing the above issue, which I posted in the image. I checked a PAT scope; it’s having a graph read & managed. So I need help here. Thanks in advance.
Hi @neel193
Thanks for your reply.
Yes currently I enabled both member entitlement and identity manage scope also. Still I am ending up with same error.
The issue is Azure DevOps has an org-level policy called “Restrict administrators from inviting new users.” By default, Team and Project Administrators are blocked from inviting brand-new users into the organization — only a Project Collection Administrator (PCA) can add a new user. Project Collection Administrators can still add new users to the organization regardless of the policy status. This exactly matches your error text: “you do not have permissions to add new users to the organization… contact a Project Collection Administrator.”
Solution:
can you add the service account to PCA group — recommended for provisioning to keep working long-term):
Go to your azure portal → Organization settings
Permissions → Project Collection Administrators
Add the identity/service account whose PAT is being used by the IIQ Azure DevOps connector to this group.
@naveenkumar3 Thanks for your reply. You are correct and your solution is perfect match for my issue.
– > May I now how you are handling PAT token via cyberark?
→ PAT token having valid of 30 days only in my org how to overcome this issue any idea ?
@Richie1997 Would recommend reading the article shared here to understand how you can disable the restricting policy to allow your PCA account to create new users.
You can save PAT tokens in CyberArk by creating a privileged account object followed by updating Credential Configuration update in IIQ .. but the problem which you’ll face is on the expiration. AFAIK there is no module available within CyberArk that natively support PAT rotation for Azure DevOps.
Glad it resolved your issue. mark the post as solution. Regarding your below asks, please find my response
two separate things here — CyberArk isn’t actually integrated with the Azure DevOps connector by default, and the 30-day expiry needs a rotation strategy since Azure DevOps doesn’t offer non-expiring PATs.
On CyberArk:
CyberArk CCP (Central Credential Provider) REST API called from a BeforeProvisioningRule / build.xml pre-hook or a custom scheduled task that fetches the current PAT from the CyberArk Safe at runtime and updates the application config attribute (accessToken/PAT field) via Application.setAttribute() before the connector runs.
A scheduled Rule or external script (cron/task scheduler) that rotates the PAT in Azure DevOps via its REST API, pushes the new value into CyberArk, and IIQ pulls it from CyberArk at each aggregation/provisioning cycle.
On the 30-day PAT expiry — two option i think,
Automate rotation with a scheduled task/rule combo (most common fix):
Write a BeanShell rule or external script that calls the Azure DevOps REST API to generate a new PAT before the old one expires.
Have that rule update the IIQ Application’s PAT attribute (or push it to CyberArk if that’s your source of truth) automatically.
Schedule this to run every ~25 days (before the 30-day expiry) so there’s never an outage.
Ask your Azure DevOps org admin if the max PAT lifetime policy can be extended — Microsoft allows PATs up to 1 year by default; a 30-day cap is usually a custom org policy (Organization settings → Policies → “Third-party application access via OAuth” / PAT lifetime policy), so it may be adjustable if there’s no compliance mandate forcing 30 days.
@neel193 - Thanks for highlightling this global PAT retirement. Service principal alternative solution also good alternative auth method. But the ADO connector which we are having in my org only support PAT not Entra/ service principal. So that I planned to go with organization specific PAT instead of generating global PAT. Since global PAT only getting retire by DEC 2K26 this ORG specific PAT method will be fine I think. Any thoughts on this ?
AFAIK, current versions doesn’t support service principal. You might want to reach out to your CSM well ahead to understand the impact and see if Sailpoint has any plan to provide a patch or something.
