I need to migrate the contents of an old OpenLDAP user tree to a new instance of OpenLDAP running on a different server. The piece I am having trouble with is how to get the history of passwords which a user has used from their old OpenLDAP into their new OpenLDAP so that the new instance of OpenLDAP won't allow that user to reuse one of their 10 prior passwords from the old OpenLDAP.
I ran this command to get the pwdHistory:
'ldapsearch -b base -H ldaps://machine:636 -D cn=AdminAcct -W pwdHistory'
pwdHistory:20210216200526Z{SSHA}e3kskc8tnsldktekalcilhiritnldingoilixdgf==
pwdHistory:20210216636726Z{SSHA}9hge3hespbup9glxdgpigpih4t9skgnpiaigorpga==
I ran an ldapmodify specifying the pwdHistory parameter I wanted to updated and received a "Constraint violation" error. This is due to pwdHistory being a read only attribute.
Anyone know of a way to get the pwdHistory values into the new OpenLDAP?
Related
Hello
i am working on the IBM webseal authentication. i want to implement the webseal authentication into my application.
while configuring the runtime component i am getting the following error.
Unable to verify the management domain location DN in the
LDAP server: (secAuthority=Default).
If the location does not exist on the server, create it,
otherwise specify a different location that does exist.
Error: DPWAP0003I An error occurred while executing the command: /opt/PolicyDirector/sbin/PDMgr_config -s TRUE -y no -v TRUE -d CN=jony mittal,OU=dev,DC=dgad,DC=com -w XXXX -L 389 -C fips -D Default -m XXXX -l 1460 (0x1)
anyone please help me to resolve this issue.
thanks
When you are configuring ISAM/ISVA PD runtime, PDMgr_config will deploy its registry into your LDAP directory server. This requires modifying the schema of the LDAP server. To do this, it requires administrator rights on the directory. Commonly this will be an account such as cn=root, cn=admin, cn=DM, etc. depending on your directory server.
I believe what may work better for you, if you are configuring ISAM from scratch, is likely deploy using the internal/embedded LDAP. When configuring the runtime choose the local LDAP server option. You can set the credentials on the local/embedded LDAP server on the tab where you configure the runtime. Just set a password on it, then feed that password into the runtime configuration.
Then, if you are needing to tie into another directory, which I expect is the case since you are trying to do this now, then use basic user mode with a "federated registry" so you don't have to deploy the ISAM "registry" and hence do not have to modify the existing directory. This way you can authenticate and authorize users off an existing directory without having to modify that directory specifically to support ISAM.
Additional information here:
Embedded (local) LDAP server instructions
Configuring PD runtime
Basic user mode instructions
Setup federated repository
I am attempting to use ldapsearch to troubleshoot why I am having some odd issues with users.
I can run the following query and find a user that is in AD:
ldapsearch -h <my_host> -p 389 -x -b "cn=users,dc=domain,dc=name" -s sub "name=test 01"
This returns with information for the user as I would expect. If I run the same command but switch test01 to test02, I get "result:32 No such object".
I have gone into AD and I see that the user is in the same structure/folder as the other user. They have the same exact permissions. I opened both users side by side in ADSI Edit and I see the "name" attribute is correct. I disabled and reenabled the user. I even combed line by line in ADSI Edit between a working user and the one that is not working and they appear identical. I have tried to search on other attributes such as sAMAAccountName and it still fails for this individual user. I have ensured I am using the admin account with adsi and there is no difference in the structure of where the user lives
This user was working correctly until fairly recently. The only thing I have been able to find is by using ldapsearch and it failing to find the object (as everything I have searched in AD looked correct). If I run an entire search (without the -s option), I see that it finds:
# test 02, Users, domain.name
dn: CN=test 02, CN=Users,DC=domain,DC=name
but nothing else for the user attributes. The other users I see have objectclasses that return and all of the other attributes that I see in ADSI Edit underneath their entry. I have seen this happen with a couple accounts over the past few months and the only workaround I have is to simply create a new account for the user...Obviously a bad workaround.
Am I missing something obvious or what could be happening?
On the security tab of the accounts that do not return data, see if there are any "DENY" access control entries. Deny takes precedence, so a one-off deny can prevent information from being displayed where there is an allow entry at a higher level.
Check if inheritance is enabled. There are cases where this is programmatically disabled -- domain admins -- and you need to modify the permission set on AdminSDHolder to enact permission changes on the managed objects. If inheritance is disabled but the accounts are not admins where AdminSDHolder applies, add the anonymous read permission to the object (your post indicates that you want anonymous read to user objects). Or risk enabling inheritance.
If all else fails, use "Advanced" on the "Security" tab and select the "Effective Access" tab. Click to select a user and enter "Anonymous". Accept. Then click "View effective access". Compare anonymous' effective access to both a working and non-working account.
Your filter for your search should be:
ldapsearch -h <my_host> -p 389 -x -b "cn=users,dc=domain,dc=name" -s sub "CN=test 01"
or
ldapsearch -h <my_host> -p 389 -x -b "cn=users,dc=domain,dc=name" -s sub "samacountname=test 01"
I recently had an issue like this where a user stopped appearing on a web app. Which syncs users from AD.
After spending couple of days on what is wrong with the user and comparing it to the working ones. My fix was to just .
"Remove this user from the domainusers group disable it then enable it and add it back to domainusers group."
after performing above action user again started syncing like befor.
I created an application on existent OpenShift project by pulling a docker image from remote repo.
The pod is created but fails with STATUS "Crash Loop Back-off".
Invesitgating the reason using
oc log <pod id> -p
it appears a list of unsuccessfull "chown: changing ownership of '...': Operation not permitted
I found this is due to non predictable user id running the container.
According to
https://docs.openshift.com/container-platform/3.6/admin_guide/manage_scc.html and various post here and there,
it seems the solution is to relax security policy:
oc login -u system:admin https://<remote openshift endpoint>
oadm policy add-scc-to-group anyuid system:authenticated
If this is the solution, I don't know, because I cannot get out of 1st problem:
oc login -u system:admin
asks for login/pwd and after print an error
error: username system:admin is invalid for basic auth
I guess there is the need of a certificate, a token, something secure, but I cannot understand how to generate it from Openshift, or
if there was a key pair to generate locally (of which kind) and how to bind the key to the user. Furthermore, checking in the web console
I cannot see that kind of user (system:admin).
Am I missing something?
Thanks a lot,
Lorenzo
We updated our Couchbase from 4.6 Community edition to 5.0.0-2873 Enterprise Edition for testing purposes and our software using the java-client started throwing InvalidPasswordException when trying to open a bucket.
As I've found, every newly created bucket has authType='sasl' and a randomly generated saslPassword.
I've tried creating a bucket using the CLI instead of the GUI:
couchbase-cli bucket-create -c localhost:8091 -u Administrator -p password --bucket=general --bucket-ramsize=1300 --bucket-type=couchbase --bucket-password=
I got the following error:
ERROR: unrecognized arguments: --bucket-password=password
I also tried the bucket-edit function with the same result.
According to the documentation the argument should be valid.
I also tried using the REST API to change bucket authentication (and similarly password), but even though this didn't throw any erros, the authType and the password remained the same.
curl -X POST -u Administrator:password -d 'authType=none' http://<host>:8091/pools/default/buckets/general
Again, according to the documentation this should work.
If I query the bucket information for the sasl password and provide that for the openBucket function then the connection works, however we really don't want to use this feature in our system.
So, any other ideas how it would be possible to remove the bucket authentication in our 5.0EE Couchbase setup?
In Couchbase 5.0 we no longer support bucket passwords and have moved to using role based access control when connecting to buckets. This means that in 5.0 the standard (pre-production) way to connect to a bucket is by using the Administrator user and password that you created when setting up the cluster. In case you're unsure what the Administrator user is, it is the user you create when you first go through the Couchbase setup wizard or the it is the username and password you specify on the command line when running the couchbase-cli cluster-init command.
One thing to note is that using the Administrator user/password is the standard pre-production workflow. I would recommend that when you go into production you create separate users for your application which only have access to cluster resources they need to access in the cluster. You can do this by going to the Users tab in the Administration Console and creating a new user and giving them the Full Bucket Access role which is the standard role that applications should have.
You might now be saying to yourself that this all sounds great, but when I use the Administrator user/password I still am having issues. If this is the case the reason is because you have Couchbase 5.0, but your SDK is not new enough to handle the new RBAC authentication mechanism in 5.0. The workaround for this is to create a user in the Users tab with the same name as the bucket and give that user the Full Bucket Access role. You can then use this user to authenticate.
One last thing to mention is that during an upgrade from a pre-5.0 cluster to a 5.0 cluster Couchbase will automatically create a user for each bucket. The each user will have the same name as one of the buckets and the password for that user will correspond to the bucket password. This is done mainly to ensure that there is no application downtime during an upgrade. After upgrading the cluster the next step should ideally be to upgrade the Couchbase client library to have it start using RBAC authentication.
If you need to stay with old approach and no password you can use cochbase-cli with --rbac-username and --rbac-password "", but you need to specify password as "", e.g.
./couchbase-cli user-manage -c localhost:8091 -u Admin -p password --set --rbac-username <UserForBucket> --roles bucket_full_access[<BucketName>] --rbac-password "" --auth-domain local
I am on a Solaris 10 machine with opendj 2.4.5 installed. I am attempting to set a user's password with the ldappasswordmodify command. In my application I want to be able to set their password without requiring the previous password. I still need the password to obey the history and validation requirements though. I have this working on a similar machine that I set up a while ago and am not sure how I did it.
This is how I am calling the command:
ldappasswordmodify -D cn=mgr -w mgrpw -a uid=user,ou=people,o=systems,dc=program -n newpassword
No matter what password I give it the command works and sets the password.
If I use the command and supply the old password like this:
ldappasswordmodify -D cn=mgr -w mgrpw -a uid=user,ou=people,o=systems,dc=program -c oldpassword -n newpassword
The history and validation requirements are enforced properly.
Does anyone have any idea how to do this or perhaps what to check on the working system to see how I did it before? I'm at a complete loss.
Don't use the manager account. Don't use it for anything actually. Use a user account. The manager account is for slapd itself. It bypasses a lot of security and overlays.
I think this was an issue in OpenDJ 2.4 and it has been resolved in later versions.
You might want to try with OpenDJ 3.0 which is the later release available.