I have an Hybrid AD and AAD enviroment. We use AzureAD to provision users and attributes to one of our SaaS solutions. One for those is the "manager" attribute. The problem is that once the manager value has been set once, it does not update. And since the users are synced from onprem, the manager field is in "read only"-mode and there is no way for me to update it.
When i change the value on one of my users and run a sync to AzureAD i can see that there are 1 change to the export attribute flow and Updates to the Delta Import. But in AAD the old value persists.
I ran the Sync troubleshooter and checked for sync issues in AAD, but there are no indicated errors. Everything else seems to work and sync as intended. Anyone know if there is anything special with "manager"? Any help would be appritiated.
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
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 am checking SonarQube 5.4 and the latest LDAP plugin 1.5.1. There are however a couple of issues.
First. My AD account is majcicam. If I log in with it, it is correctly shown in the users list. However if I login with MajcicaM (note capital letters) another additional user is added to the list:
As you can see from the attached image. For every login that I do make, seems it is treated as case sensitive and thinks of it as a different user.
Second thing. Once I assign a group to my user, on the next login those settings are gone. Seems that they are not persisted.
Am I doing something wrong? Is this a bug? Are my settings messed up?
Thanks
Mario
No bugs here, just some subtleties about LDAP Plugin configuration and behaviour. :)
Case-insensitive login
Set sonar.authenticator.downcase to true when delegating authentication to an LDAP/AD server which is case-insensitive.
Group mapping behaviour
When group mapping is configured (i.e. you manually configured ldap.group.* or you use the windows authentication mode with lightweight AD config), membership in LDAP/AD will override any membership locally configured in SonarQube. LDAP/AD becomes the one and only place to manage group membership (and the info is fetched each time the user logs in).
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
I'm trying to restrict TeamCity users to members of a specific AD group (FNC_TEAMCITY_USERS). LDAP user synchronisation was already working. In my ldap-config.properties I changed this:
teamcity.users.filter=(objectClass=user)
to this:
teamcity.users.filter=(&(objectClass=user)(memberOf=CN=FNC_TEAMCITY_USERS,OU=Groups,DC=group,DC=ourdomain,DC=com))
I restarted the TeamCity service and this change had no effect. All AD users can still log in to TeamCity. I tried this on both our 6.5 instance and our 7.0 (EAP) instance.
Is there something I've missed or is this a bug?
The property limiting users who can login into TeamCity is "teamcity.users.login.filter". Try setting it instead of "teamcity.users.filter".
"teamcity.users.filter" is the one affecting users synchronization (particularly creating users in TeamCity for users in LDAP).
Be sure to have "java.naming.security.principal" and "java.naming.security.credentials" correctly specified as they are required for "teamcity.users.login.filter" use.