openLDAP cn=config doesn't seem to be configured correctly - openldap

I'm new to LDAP's, but have an openLDAP config which I have moved to using olc instead of the slapd.conf.
When I run the command
ldapsearch -H ldap:// -x -s base -b "" -LLL "configContexts"
I get the empty result dn:
Does this suggest the config isn't working? I was unable to use the -H to authenticate until I imported an ldif setting {1}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break into olcDatabase={0}config under olcAccess, so I think that was done correctly. But now that I add other ACL's, none of them seem to take.
Is the empty result from the configContexts command a concern?
This is all to get something like the following to work so I can set admins over the LDAP.
{3}to * by dn.exact=uid=myadminaccount,dc=domain,dc=com manage by * break

You probably want to query attribute configContext (without trailing 's').
Provided you access control rules allow the bound entity to read it the result looks like this:
$ ldapsearch -H ldap://-s base -b "" -LLL "configContext"
dn:
configContext: cn=config

Related

Enabling dynlist on OpenLdap server : ldapmodify: modify operation type is missing

I'm trying to enable server side sorting on an OpenLdap instance I'm running.
I know it's not enabled because I get a critical exception when trying to query using a Novell AD client.
From my research online, I need to enable dynlist to be able to perform a server sorted search.
I'm using the following command to try and enable dynlist:
ldapmodify -Y EXTERNAL -H ldapi:/// -f ${CONFIG_DIR}/dynlist.ldif -Q
and my ldif is as follows:
# Load dyngroup module
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: dynlist
# Set up dynlist overlay
dn: olcOverlay={0}dynlist,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcDynamicList
olcOverlay: {0}dynlist
olcDlAttrSet: msDS-AzureADObjectId memberURL member
I took the example code from here and modified it as I want to sort by the msDS-AzureADOObjectId which I have configured already in my server
# Add the msDS-AzureADObjectId Attribute
dn: cn={0}core,cn=schema,cn=config
changetype: modify
add: olcAttributetypes
olcAttributetypes: ( 1.2.840.113556.1.6.54.2.1 NAME 'msDS-AzureADObjectId' SYNTAX '1.3.6.1.4.1.1466.115.121.1.40' SINGLE-VALUE )
When I run my code to add the dynlist I get the following errir:
+ ldapmodify -Y EXTERNAL -H ldapi:/// -f /opt/openldap/bootstrap/config/dynlist.ldif -Q
modifying entry "cn=module{0},cn=config"
ldapmodify: modify operation type is missing at line 8, entry "olcOverlay={0}dynlist,olcDatabase={1}mdb,cn=config"
But I'm unsure what I've got wrong, thanks for any help clearing this error

Unable to use openldap olcTLS attributes

I've been working on trying to migrate an openldap instance from CentOS7 to CentOS8. RHEL deprecated the openldap packages in RHEL8, so I've been trying to migrate to the Symas packages.
https://symas.com/openldap-for-linux-now-available-for-rhel-8/
https://repo.symas.com/sofl/rhel8/
With the Symas packages installed, I've actually been able to get everything migrated over and working with the exception of TLS for STARTTLS. It seems that it doesn't recognize any of the olcTLS* attributes. I'm assuming that's schema related somehow but if someone could point me in the right direction I'd appreciate it.
tls.ldif:
dn: cn=config
changetype: modify
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/openldap/certs/ca.crt
Results:
# ldapmodify -Y EXTERNAL -H ldapi:/// -f tls.ldif
modifying entry "cn=config"
ldap_modify: Other (e.g., implementation specific) error (80)
#
SELinux is currently disabled, the LDAP user/group recursive own everything under '/etc/openldap'. Googling has yielded many many results, but none of them covering procedures for TLS/STARTTLS on CentOS8 that I have found.
After a ton of digging, I determined the issue to be a problem with my private key, and so it refused to set the TLS options altogether. But I'll be inclusive of everything I had to verify here for this error.
So for starters, you need to make sure the public/private keys are producing the same hash (This was where my issue was) -
openssl x509 -noout -modulus -in /path/to/public.crt | openssl md5
openssl rsa -noout -modulus -in /path/to/private.key | openssl md5
Then, from the Debian guide -
If the modifications fail with ldap_modify: Other (e.g.,
implementation specific) error (80), check the file paths for typos,
and ensure the files are readable by the openldap user.
Use sudo to run commands as the ldap user to validate this. For example:
sudo -u ldap cat /path/to/public.crt
Or
sudo -u ldap file /path/to/public.crt
You may have to additionally look into SELinux if the above doesn't work.
I had this issue on Ubuntu 20.04 and I've been searching for answer for hours... The solution was to turn off slapd before adding or modifying olcTLS options. It is so stupid, because CentOS doesn't really care.
systemctl stop slapd
Then add the record:
ldapmodify -Y EXTERNAL -H ldapi:/// -f your_file.ldif
Though I've read that the order you add olcTLS records matter or that olcTLSCA settings should not be added if you use self-signed certs - all this seems to be false. This is my olcTLS file:
dn: cn=config
changetype: modify
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ldap/sasl2/server.crt
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ldap/sasl2/server.key
-
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ldap/sasl2/ca.crt
-
add: olcTLSCACertificatePath
olcTLSCACertificatePath: /etc/openldap/sasl2
Also don't forget to set the owner:group to openldap
chown -R openldap:openldap /etc/openldap/sasl2
And permissions:
chmod 0600 /etc/openldap/sasl2/*
I tried everything I could find in every possible thread on this, all to no avail. What finally worked was to first delete the existing olcTLSCertificateKeyFile entry:
dn: cn=config
changetype: modify
delete: olcTLSCertificateKeyFile
Then add it via a separate ldif file:
dn: cn=config
changetype: modify
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: xxx
(Yes, the key absolutely 100% belongs with the existing olcTLSCertificateFile cert, triply-checked via openssl modulus, etc.)

How to change artifactory admin default password through command line

i have installed latest version of Artifactory Pro (5.8.3) on Centos7. The default admin credentials are admin/password. i want to change the password through command-line but unable to do so.
Does any one has any inputs how to do this?
Following troubleshootings i tried:
jfrog rt c rt-server-1 --url=http://domain/artifactory --user=admin --password=password ...
nothing happens , when i try to use a new password i get 401: unauthorize error
jfrog guide tells to generate security.xml and add the hash code of the new password but security.xml does not get generated even after following all their steps.
also tried to use curl commands but no use.
If any one has gone through similar issue please share your findings. let me know if you need more info.know on case
JFrog CLI currently does not support changing of a user's password. the CLI config method you were using simply lets you configure your server and credentials to be used by other CLI command later.
What you can do is use a simple curl command to invoke the change password API as described here.
specifically, in your example changing the Admin's password to "NewPassword" will be something like:
curl -X POST -u admin:password -H "Content-type: application/json" -d '{ "userName" : "admin", "oldPassword" : "password", "newPassword1" : "NewPassword", "newPassword2" : "NewPassword" }' http://yourartifactory:8081/artifactory/api/security/users/authorization/changePassword

ldapsearch: no result when objectClass in search filter

I have an open-ldap-server configuration with a translucent_proxy
This is to enrich the companies ldap server entries with local attributes.
In general it works fine.
I have a company ldap server: ldap.c.com, this one serves
dc=company,dc=com and the usual subtrees (ou=People,group)
I have a local ldap server: ldap.my.c.com, this one serves an overlay of the ou=People,dc=company,dc=com.
so I could ask
ldapsearch -x -H ldap://ldap.c.com/ (uid=frank) mail mailLocalAddress
and will get something like
dn:uid=frank,ou=people,dc=company,dc=com
mail: f.name#company.com
and when asking my local ldap server the same question
ldapsearch -x -H ldap://ldap.my.c.com/ (uid=frank) mail mailLocalAddress
I will get my enriched result of
dn:uid=frank,ou=people,dc=company,dc=com
mail: f.name#company.com
mail: frank#my.c.com
mailLocalAddress: frank#my.c.com
mailLocalAddress: nick#my.c.com
FINE!
But when requesting any objectClass in the filter rule
ldapsearch -x -H ldap://ldap.my.c.com/ (&(uid=frank)(objectClass=posixAccount)) mail mailLocalAddress
gives me no results at all:
#search result
search: 2
result: 0 success
But the records do definitively have objectClasses of top,Person, inetorgPerson,posixAccount and some more set.
So what am I possibly doing wrong?
It looks like you are doing an unauthenticated ldapsearch, this could be the problem. First try to verify if you can see the objectClasses this way with:
ldapsearch -x -H ldap://ldap.my.c.com/ "(uid=frank)" objectClass
If this gives you no output you have probably some acl set, which prohibits you from seeing that. You can check them locally with something like (depending on your setup):
sudo ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=config "(olcDatabase=hdb)" olcAccess
There you can see who has access to that attributes and can use an authenticated ldapsearch (also depending a little bit on youre setup):
ldapsearch -x -H ldap://ldap.my.c.com/ -WD "uid=frank,ou=people,dc=company,dc=com" "(&(uid=frank)(objectClass=posixAccount))" mail mailLocalAddress

Uploading a file on a URL

Can anyone help me to find out a unix command that is used to upload/download a file on/from an URL?
Particular URL in which i'm trying to upload/download is protected with an user id and password.
I guess curl serves this purpose but not aware of how to use it? Could you please give me sugegstions on this?
curl has a command line argument named -d (for data) and you can use it like this to send a file(you need to add a # before a file-name to have curl treat it as a file and not a value:
curl -X POST -d #myfilename http://example.com/upload
You can add multiple -d arguments if you need to send a FORM value along with your file. Like so:
curl -X POST -d #myfilename -d name=MyFile http://example.com/upload

Resources