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.
Related
In my site the guest users have access to the flow and they able to run the flow and even create records. When the flow try to find the created record the next error accrue:
Because Get_Record is passed to an action, subflow, or Lightning component, store the values of all Request_for_ChemTox__c fields that the running user has access to.
I gave access to every field for that user and still keep getting this error.
Any ideas?
It's probably not field level security (~table columns) but whole record's security (~table rows).
Check your site/community/experience settings as described in this article: https://help.salesforce.com/s/articleView?id=000352970&type=1. If there's something set - the ownership of created record is immediately transferred over to that internal user and guest loses visibility. It sucks but it's there to protect you, makes sure that if you have for example Leads or Cases submitted by guest users - they immediately "disappear", guest/hacker can't report on them, experiment with IDs in the url to learn other people's data...
You can Check Setup -> Sharing Settings for this object and create new sharing rule. (I can't upload image right now but start making new sharing rule with step 2 "rule type = Guest user access, based on criteria")
https://help.salesforce.com/s/articleView?id=sf.networks_guest_record_default_owner_best_practices.htm&type=5 has some good tips too:
If you’d like to create a different experience for guest users, use
flows in System Mode to redirect guest users to a different custom
screen after they create a record
I have tried multiple times to get this to work, but I haven't figured it out yet, so I'm asking in here, hoping that someone will be able to help me out.
I am using Atlassian's Bitbucket, Jira and Bamboo and they're all synced with an AD. At the moment I am using my AD user to retrieve all the other users. It works, but it's not optimal, as the password expires every three months, and I have to change the LDAP user login info on all three applications. We have ordered a Service User, where the password doesn't expire, but the problem is that the Service User is in another group.
The picture below shows how the AD is set up. My Service User is in a group called Special Users. I would like to use this user as the login user in the settings. This way I would never have to think about changing password, when my AD password expires.
I would then like to retrieve all the users from the "Normal Users" group.
Let me know if more information is needed.
Thanks.
You could also add multiple user directories pointing to different parts of your Active Directory.
Jira has an internal Crowd out of the box.
You may let Jira connect to User directory and let all other application use Jira for authintication.
This would save time by only updating your LDAP password every 3 months on 1 application and reflected on all 3 applications
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 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 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.