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
Related
Having lot of aliases might be confusing, such as when they are brought by zsh git plugin for instance. I wonder if it's possible to display the definition next to the alias for each one. I'm surprised I'm not able to find, so maybe I've used wrong terms when searching for it. If so, please apologize ...
Current behavior:
$ gg<Tab>
gg gga ggf ggfl ggl ggp ggpnp ggpull ggpur ggpush ggsup ggu
Desired behavior :
$ gg<Tab>
gg 'git gui citool'
gga 'git gui citool --amend'
ggpull 'git pull origin "$(git_current_branch)"'
ggpur ggu
ggpush 'git push origin "$(git_current_branch)"'
ggsup 'git branch --set-upstream-to=origin/$(git_current_branch)'
glgg 'git log --graph'
glgga 'git log --graph --decorate --all'
I've found a similar idea for displaying files list info that can be configured like this :
zstyle ':completion:*' file-list all. But I've found nothing in the doc for a similar feature related to alias expansion.
A similar problem is also solved for parameters completion :
docker -<Tab>
--config -- Location of client config files
--debug -D -- Enable debug mode
--help -h -- Print usage
--host -H -- tcp://host:port to bind/connect to
--log-level -l -- Logging level
--tls -- Use TLS
--tlsverify -- Use TLS and verify the remote
--userland-proxy -- Use userland proxy for loopback traffic
--version -v -- Print version information and quit
Thanks !
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.)
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
I have been setting up an OpenLDAP server on a system that already uses FreeIPA for user authentication. The purpose is to provide an authentication method for a spring application.
I have been noticing some odd things when run ldapadd and ldapmodify commands. I thought that this may have been related to a an incorrect password so I tried to update the olcRootPW.
I thought it might be a good idea to find the RootDN account and the current RootDN password hash:
sudo ldapsearch -H ldapi:// -LLL -Q -Y EXTERNAL -b "cn=config" "(olcRootDN=*)" dn olcRootDN olcRootPW
This returned:
dn: olcDatabase={2}hdb,cn=config
olcRootDN: cn=Manager,dc=myldap,dc=local
olcRootPW: {SSHA}6amwprJqmgudYDYPbJaO3BgeAp6898
So far so good, so lets update the password with an ldif file - newpass.ldif:
dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcRootPW
olcRootPW: {SSHA}KPxel+B7Ua6Q9PPaM7xdaGSDqK0A1234
Run this command:
sudo ldapmodify -H ldapi:// -Y EXTERNAL -f ~/newpass.ldif
So far so good, we get a success message:
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "olcDatabase={2}hdb,cn=config"
Its a good idea to change the password in the normal DIT with this ldif:
dn: cn=Manager,dc=myldap,dc=local
changetype: modify
replace: userPassword
userPassword: {SSHA}KPxel+B7Ua6Q9PPaM7xdaGSDqK0A1234
When I apply this ldif with this command:
sudo ldapmodify -a -v -H ldap:/// -x -D "cn=Manager,dc=myldap,dc=local" -W -f ~/newpasswd.ldif
I get the following failure:
ldap_initialize( ldap://:389/??base )
Enter LDAP Password:
replace userPassword:
{SSHA}KPxel+B7Ua6Q9PPaM7xdaGSDqK0A1234
modifying entry "cn=Manager,dc=myldap,dc=local"
ldap_modify: No such object (32)
I have been seeing this a lot when using the "-D" switch and I can't figure out what is going on?
I saw the same thing when adding this ldif:
dn: dc=myldap,dc=local
objectClass: top
objectClass: dcObject
objectclass: organization
o: myldap.local
dc: myldap
dn: cn=Manager,dc=myldap,dc=local
objectClass: organizationalRole
cn: Manager
description: Directory Manager
dn: ou=People,dc=myldap,dc=local
objectClass: organizationalUnit
ou: People
dn: ou=Group,dc=myldap,dc=local
objectClass: organizationalUnit
ou: Group
Running this command give the error:
sudo ldapadd -x -D cn=Manager,dc=myldap,dc=local -W -f baseldapdomain.ldif
Enter LDAP Password:
ldap_bind: No such object (32)
Any ideas?
I decided to run the openLDAP on the same host as the application and then run slapd on a different local port:
sudo /usr/sbin/slapd -u ldap -h "ldapi:/// ldap:/// ldap://localhost:9090"
So when applying ldif files this works:
sudo ldapadd -x -D cn=Manager,dc=cdfldap,dc=local -H ldap://localhost:9090 -W -f baseldapdomain.ldif
I am still have issues starting slapd using systemd with a custom port but that can wait for now.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I'm running OpenLDAP 2.4-28 on XUBUNTU 12.04.
I'm reading "Mastering OpenLDAP" and configuring along with the book.
When I try to perform the following search (page 47):
$ ldapsearch -x -W -D 'cn=Manager,dc=example,dc=com' -b "" -s base
I am prompted for the password. Then I enter "secret" but I get the following error:
ldap_bind: Invalid Credentials (49).
The following is my slapd.conf:
# slapd.conf - Configuration file for LDAP SLAPD
##########
# Basics #
##########
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/inetorgperson.schema
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
loglevel none
modulepath /usr/lib/ldap
# modulepath /usr/local/libexec/openldap
moduleload back_hdb
##########################
# Database Configuration #
##########################
database hdb
suffix "dc=example,dc=com"
rootdn "cn=Manager,dc=example,dc=com"
rootpw secret
directory /var/lib/ldap
# directory /usr/local/var/openldap-data
index objectClass,cn eq
########
# ACLs #
########
access to attrs=userPassword
by anonymous auth
by self write
by * none
access to *
by self write
by * none
and here is the ldap.conf:
# LDAP Client Settings
URI ldap://localhost
BASE dc=example,dc=com
BINDDN cn=Manager,dc=example,dc=com
SIZELIMIT 0
TIMELIMIT 0
I don't see an obvious problem with the above.
It's possible your ldap.conf is being overridden, but the command-line options will take precedence, ldapsearch will ignore BINDDN in the main ldap.conf, so the only parameter that could be wrong is the URI.
(The order is ETCDIR/ldap.conf then ~/ldaprc or ~/.ldaprc and then ldaprc in the current directory, though there environment variables which can influence this too, see man ldapconf.)
Try an explicit URI:
ldapsearch -x -W -D 'cn=Manager,dc=example,dc=com' -b "" -s base -H ldap://localhost
or prevent defaults with:
LDAPNOINIT=1 ldapsearch -x -W -D 'cn=Manager,dc=example,dc=com' -b "" -s base
If that doesn't work, then some troubleshooting (you'll probably need the full path to the slapd binary for these):
make sure your slapd.conf is being used and is correct (as root)
slapd -T test -f slapd.conf -d 65535
You may have a left-over or default slapd.d configuration directory which takes preference over your slapd.conf (unless you specify your config explicitly with -f, slapd.conf is officially deprecated in OpenLDAP-2.4). If you don't get several pages of output then your binaries were built without debug support.
stop OpenLDAP, then manually start slapd in a separate terminal/console with debug enabled (as root, ^C to quit)
slapd -h ldap://localhost -d 481
then retry the search and see if you can spot the problem (there will be a lot of schema noise in the start of the output unfortunately). (Note: running slapd without the -u/-g options can change file ownerships which can cause problems, you should usually use those options, probably -u ldap -g ldap )
if debug is enabled, then try also
ldapsearch -v -d 63 -W -D 'cn=Manager,dc=example,dc=com' -b "" -s base