I am trying to move contents of a Resource Group A in MSFT Public tenant to Tenant B.
I get a AjaxError: ajaxExtended call failed
Is it possible to move across Tenants ?
Related
We use Azure AD user provisioning, to create and manage users in Salesforce. In itself this is working correctly. But... we have created a new (custom) profile in Salesforce (which Azure AD refers to as role) and this new profile is not being loaded into Azure AD. When creating a new user, we see our old custom profiles, but not the new one.
We started looking in the provisioning logs and saw a lot of "failed" entries. The first part of these logs reads like this:
The name, id, and claim properties of an app role in Azure AD must be
unique. We are unable to update an app role as one or more properties
are not unique. This is most commonly caused by having non-unique role
names in the directory from which roles are being imported.
And then a bunch of non-unique profiles/roles are listed. These are all standard profiles, such as Standard User and System Administrator. They appear twice in the list.
Going back to the screen where we add users, sure enough, these double entries are there as well. Each duplicate being an inactive choice. And: some old custom profiles are shown, also inactive. But not the new one.
This has worked before, as we see the old custom profiles listed. But somewhere/somehow double entries have been added and now we are stuck.
What is the solution? I have no idea on how to remove those duplicate entries from Azure AD. In Salesforce, there are no duplicate profiles. And even if I could remove the duplicate entries from Azure AD, maybe they would be added again on the first provisioning run.
You've got this great new feature in Azure AD under Entitlement management: Access Packages.
Packages including groups and what more for specific users and roles.
https://learn.microsoft.com/en-us/azure/active-directory/governance/entitlement-management-access-package-create
The issue I'm struggling with, is how can I add users by dynamic group without them having to request access first?
I feel like I'm overseeing something, but as it looks now you can only add a Dynamic Group & the users in the group can request access to the AccessPackages.
Has anyone else dealt with this already?
Please check the references and if below can be worked around in your case.
According to Create a new access package in entitlement management - Azure AD | Microsoft Docs.
If you want to bypass access requests and allow administrators to directly assign specific users to this access package. click None (administrator direct assignments only) in request section to create a policy where users need not request for access. For this group selection is not there.Users won't have to request the access package.
But if you need to select specific dynamic group for policy .
You can create a access package with dynamic groups selected .
You can create a policy separately for the users for dynamic group with require approval disabled and requests disabled.
Then while assignment requests are bypassed and approved even if the policy has request approval.
Even if require approval and requests are enabled in first step, you can set a separate policy by setting the by pass approval to yes.
Note :Dynamic group is to be given the owner role for access packages.
Reference: active-directory-entitlement-management-request-policy | (github)
I am trying to retrieve the Azure AD user given a subject id (sub) in an Azure AD registered application. I know the application and the sub, but I cannot find a way to retrieve the oid or upn for the actual user using this information.
Digging around I cannot find anything on retrieving User based on sub and application id in the docs:
https://learn.microsoft.com/en-us/graph/api/resources/user?view=graph-rest-1.0
When reading about the id token it is suggested that sub + tid + oid should be used for synchronizing across services. And looking at sub more specifically says:
The principal about which the token asserts information, such as the user of an app. This value is immutable and cannot be reassigned or reused. It can be used to perform authorization checks safely, such as when the token is used to access a resource, and can be used as a key in database tables. Because the subject is always present in the tokens that Azure AD issues, we recommend using this value in a general-purpose authorization system. The subject is, however, a pairwise identifier - it is unique to a particular application ID. Therefore, if a single user signs into two different apps using two different client IDs, those apps will receive two different values for the subject claim.
https://learn.microsoft.com/sv-se/azure/active-directory/develop/id-tokens
https://learn.microsoft.com/sv-se/azure/active-directory/develop/access-tokens
I also had a look around SO and only found this related answer but it seems to go from OID to SUB:
Getting User's Token Subject Identifier (sub) From Within Azure AD
Can I query the Graph API using application identifier and subject identifier to find the object identifier or upn?
If it is not possible using the Graph API. Is there any way at all to backtrack which Azure AD user has a given subject id for an application?
By design sub is unique for each user per application. So the same user visiting two applications will have a different sub. This is to ensure that applications that don't have the profile scope are not able to map the users profile outside its own data.
There isn't a way to obtain the oid from the sub for this very reason.
We have an application where we store users login name in the format domain\username. We authenticate via windows and then get additional info from our database by matching the domain\username we get from the user to our database.
Now they want to move to the cloud. We authenticate users via apps in Azure AD. However, the user identifier we get back is first.last#domain.com.
I have fiddled around with https://graph.microsoft.com/v1.0/users/email and the select command to try and get the 'old' name. Howev,er I have not yet found out how to get it.
The reason they move to the cloud is that they are merging two ADs. So some users will be DomainA and some DomainB, but in the same tenant. So my first thought was to try and convert the mail to the other format. However, the two different ADs have different naming standards. One has DOMAINA\fila (two first letters from the first name and two first letters from the last name) and the other one has DOMAINB\firlas. Also it feels really ugly to try and solve it that way.
Is it possible to fetch the users loginname formatted as domain\username via Microsoft Graph?
Using the beta edition of Graph, you can obtain the user's domain and username from the onPremisesDomainName and onPremisesSamAccountName properties:
/beta/users?$select=userPrincipalName,onPremisesDomainName,onPremisesSamAccountName
The domain is stored as a FQDN so you'll need to do some translation. For example, domainName.ad.contoso.com might translate to domainName\).
This will give you a workaround so you can match up users with your internal databases. It is however only a temporary solution. Long-term, you really want to migrate to using the userPrincipalName. This is the primary user identifier and guaranteed to be unique within a given tenant.
Azure AD is a little different than the legacy Active Directory. Certain concepts from legacy AD such as Organizational Units (OUs), Group Policy Objects (GPOs), Kerberos Authentication, Lightweight Directory Access Protocol (LDAP), Domain trusts between multiple domains, and several others simply do not exist in the cloud.
How do you get the System Permissions to be pulled?
I am working on building a Metadata deployment for our company, and part of the deployment includes creating several new profiles. We are trying to capture all of the permissions for these profiles, but can't seem to get the system permissions to match in our test runs.
I know that when you retrieve the profile object, what you get is dynamic, based on what other object you are retrieving. (see Chap 4 bullet 2)
The Following System Permissions are different between our source and destination environment
Customize Application
Manage Connections
Manage Custom Report Types
Manage Dashboards
Manage Public Documents
Manage Public List Views
Manage Public Reports
Manage Public Templates
Manage Translation
Manage Users
Modify All Data
Reset User Passwords and Unlock Users
+ Send Email
Transfer Record
View All Data
note: + indicates added in the destination. All others are lost.
In order to use the Metadata API - the user must have the "API Enabled" and the "Modify All Data" permissions.