I have an Azure Active Directory (AAD) set up in my Azure subscription associated with an email address of mine, which we'll call A.
Some time later, I updated my Microsoft Account to use a new email address B as the primary email address, with A being associated with it still so it can still be used and the two email addresses treated as being one.
In AAD there is one user, whose user Id is A which appears not to be able to be changed as it is greyed-out. Attempting to add B fails with the error: You cannot add yourself.
Is there a way I can force the user name of the AAD user to be B instead of A?
The reason I ask is because I am trying to setup an Azure Key Vault in my subscription as it appears to be failing because whether or not I sign in as A or B in Azure Powershell, I am always signed in as B. This then causes this error message, which I appear to be unable to work around:
New-AzureKeyVault : Cannot find the Active Directory object 'B' in tenant
'{Tenant Id}'. Please make sure that the user or application service principal you are
authorizing is registered in the current subscription's Azure Active directory. The TenantID displayed by the cmdlet
'get-AzureSubscription -current' is the current subscription's Azure Active directory.
Can you check that you are using the latest bits for Key Vault PowerShell?
I talked with some folks internally and we believe that an experience like this may be expected if you are using an older version of the PowerShell CMDLETs, but the lastest version should be update to date and not run into the issue you are having.
If you find that you still hit this issue after upgrading, we may have a bug on our side that we should fix.
In that case, my suggestion is for you to create a new Admin User. Then delete the old Admin Account (you may need to Transfer Onwership of your AAD Subscription to the new Admin), and then recreate your account, which will pull the lastest information from that user.
However, I only reccommend trying this after having updated the PowerShell bits.
Please let us know if either of these methods resolves your issues.
Thanks,
Shawn Tabrizi
Related
I have Scim provisioning setup and connected to azure ad using a custom application which isn't in the marketplace. Provisioning new users and changing data on existing appears to work fine. But when I delete data from a previously synched field, I'm not seeing any change to remove this data in the scim application.
I've tried all number of combinations and checking out documentation for this as a known issue, but have come up short. Does anyone know why this doesn't work?
Mapping
Data deleted from provisioned user
Provisioning User on demand doesn't show any changes
Thank You user3269662 for sharing the right document it will help other member who is looking for the same, currently AAD Provisioning doesn't send null/empty values in almost all cases that is the reason empty/null value of phone number is not reflecting in SCIM application.You can update the value of phone number but can not pass null value, as Microsoft found this is special type of consideration and they are working on that. For knowing about progress on this you can comment on Same MS Q&A post.
WorkAround : You need to manually delete the attribute value from SCIM application if you set null value for any attribute of AAD
For a client, we have to connect a WSO2IS 5.10.0 to an Active Directory.
For that we have created a secondary user Store with this configuration:
User store main configuration
User store optional configuration
User store advanced configuration
WSO2IS can connect to Active Directory as we can retrieve users and roles.
Before doing any claim mapping we have tried to edit and create user without any problems.
And then we have mapped some claims to retrieve more information from Active Directory.
And here come our problems:
We can't create a user in Active Directory
We can't update a user in Active Directory
This two problem gives us this error :
Caused by: javax.naming.directory.NoSuchAttributeException: [LDAP: error code 16 - 00000057: LdapErr: DSID-0C090C45,
comment: Error in attribute conversion operation, data 0, v1db1
Things that we have tried:
Check (and check a second and third time) that all our claims are mapped correctly (and they are)
Reset all claims to default mapping (on the state where we where able to create/update user)
Set User DN Pattern (as explained here)
Restart on a fresh instance of WSO2IS 5.10.0
But all things that we have tried are not helping and we are stuck.
Any help would be hugely appreciated. Thank you for any suggestions.
As asked, this is the AD attribut we have mapped :
sn
givenName
cn
displayName
name
description
mail
sAMAccountName
userPrincipalName
accountExpires
pwdLastSet
userAccountControl
scriptPath
homePhone
mobile
facsimileTelephoneNumber
title
department
company
Here the issue is LDAP_NO_SUCH_ATTRIBUTE returned from the AD.
We don't know which attribute is missing on AD side.
From the existing DEBUG logs of the server, probably you wouldn't be able to log all the attributes that WSO2 is going to update. Therefore, you have to choose an alternative option.
Manual check - Even though there are only few attributes configured (and verified) by you, there are other claims with default attribute mappings. Please check all the mapped attributes that are there in the http://wso2.org/claim dialect.
Remote debug - Remote DEBUG the server to check what are the attributes WSO2 is trying to write in to. (Smaller subset than previous approach) Then verify if those exist.
To do this remote debugging you can check out the Kernel source code from here.
To find out the correct tag to checkout, you can find the kernel version of your identity server version from this release matrix.
Once you clone and checkout the correct tag, you can use IntelliJ Idea or a capable IDE to remote debug the server as explained in the this blog.
Though it's hard to point an exact line of code, you can put DEBUG points to ActiveDirectoryUserStoreManager.doAddUser() and ActiveDirectoryUserStoreManager.doSetUserClaimValue() methods and start from there.
P.S. You can also check if the carbon log's stack trace contains any clue of the failing attribute or the respective claim, so that you can check validate it.
I'm trying to use WSO2IS with an Active Directory LDS.
Using the store to display and read users is no problem.
However when editing a user, there's a hiccup.
The users are situated in OUs in the AD and in the synced AD LDS.
(We use the AD LDS to add user attributes without changing the original AD.)
When I edit a user it will be moved by the IS to the UserSearchBase.
IS is still able to show the user - for now.
When the AD LDS is synced with the AD, the user will be moved back to its original OU.
The IS will not be able to find the user, because it is still looking for the user in the "new" location in the UserSearchBase root.
Only if I restart the IS, the user will be found again.
I tried to recreate the behaviour by hand:
Create user in an OU situated in the UserSearchBase
Edit the user with IS
Move the user back to its original location in the OU in the AD
IS throws error
Is there a way to tell the IS to leave the user DN/location as is?
Is there a way to disable caching? (Without impact on performance?)
Regards,
Mat
This looks like a known issue with Cache Expiry Bug 6471. Please see if the description matches your exception trace.
There is a fix going on for the above. That will be available on future release.
You can also build from the public repository once the fix is done, if this is the case.
Workaround
You can edit and save the user store, if his user store is configured with the UI. You do not need to change any value. This will cause a new instance to be created, thus re-creating the cache.
I'm currently trying to integrate with Azure AD using the admin consent flow.
I've set up an app in our domain, set a few permissions on it and am then navigating to the following link:
https://login.microsoftonline.com/mytestdomain.onmicrosoft.com/oauth2/authorize?client_id=12345678-1234-1234-1234-123456789012&response_type=code&redirect_uri=http://example.com/responsehandler&resource=12345678-1234-1234-1234-123456789012&prompt=admin_consent&state=12345
(Some of the values here have been swapped out for "example" values)
When I navigate there I get asked to sign in, which I do using a different test domain into which I want to import the app.
After signing in I'm shown a list of all the permissions that the app needs (which appear to be correct), I click accept but then I get the following error:
AADSTS90002: Requested tenant identifier '00000000-0000-0000-0000-000000000000' is not valid. Tenant identifiers may not be an empty GUID.
I'm not sure where this empty GUID is coming from and after some searching I can't find any reference to what might be causing it.
Daniel Camargo's comment above seems to have done the trick.
When I navigated to the login.microsoftonline.com link I was logging in with the user that created the domain.
If I log in with a test admin user that I created it works as I'd want.
I am not convinced that we had exactly the same problem, given that my case was involving a Cordova application, but I will share my scenario anyway:
I created a trial account for my proof of concept and for that I used my personal Microsoft account that I will call mypersonalaccount#outlook.com.
Thus, mypersonalaccount#outlook.com is now part of 2 directories: the outlook.com and my recently created mypersonalaccount.onmicrosoft.com.
When I was trying to authenticate in my Oauth2 application using mypersonalaccount#outlook.com I got that error. My humble guess is that the error is related to some sort of collision between the 2 accounts.
I later created a user1#mypersonalaccount.onmicrosoft.com and a guest account using my gmail account. Everything worked fine with these ones.
Was having the same problem, and the same after 1 week of work by the azure team, was solved.
My problem was being trying to log in to VSTS with AAD accounts.
I have some users that have had no problems at all in the past. All of a sudden they can't log in anymore. Nothing has changed in the OUs in Active Directory. All other users can log in, no problem. It's just these two. The only thing I can see is in the 'field_data_ldap_user_current_dn' table their 'ldap_user_current_dn_value' got set to null. I manually set this in the db back to the correct dn, but this didn't help. How can I get these users their access back?
Edit:
Whenever cron gets run these two users get their DNs nullified.
I don't know if there is another solution, but I had to delete the users account and assign their content to anonymous. Then they logged in using LDAP credentials and the account was created successfully. Then I just had to assign their content back to them.