How does openldap allowed nslcd to access DB without authentication?
Server Side Configuration
Started slapd service and modified olcSuffix, olcRootDN, olcRootPW, olcAccess as shown below
dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcSuffix
olcSuffix: dc=sam,dc=com
dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcRootDN
olcRootDN: cn=samio,dc=sam,dc=com
dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcRootPW
olcRootPW: {SSHA}v3AAHxk25g32BxWSUTyWUQltdFqZPbbJ
dn: olcDatabase={1}monitor,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read by dn.base="cn=samio,dc=sam,dc=com" read by * none
Then added nss.ldif inetorgperson.ldif cosine.ldif as shown below.
ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/cosine.ldif
ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/nss.ldif
ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/inetorgperson.ldif
Now Added some users as shown below.
ldapadd -x -w samio -D cn=samio,dc=sam,dc=com -f users.ldif
users.ldif
dn: dc=sam,dc=com
dc: sam
objectClass: top
objectClass: domain
dn: cn=samio,dc=sam,dc=com
objectClass: organizationalRole
cn: samio
description: LDAP Manager
dn: ou=People,dc=sam,dc=com
objectClass: organizationalUnit
ou: People
dn: ou=Group,dc=sam,dc=com
objectClass: organizationalUnit
ou: Group
dn: uid=pinehead,ou=People,dc=sam,dc=com
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
cn: pinehead
uid: pinehead
uidNumber: 9999
gidNumber: 100
homeDirectory: /home/pinehead
loginShell: /bin/bash
gecos: pinehead [Lead Penguin (at) Linux Academy]
userPassword: pinehead
shadowLastChange: 17058
shadowMin: 0
shadowMax: 99999
shadowWarning: 7
dn: uid=tcox,ou=People,dc=sam,dc=com
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
cn: tcox
uid: tcox
uidNumber: 10000
gidNumber: 100
homeDirectory: /home/tcox
loginShell: /bin/bash
gecos: Terry Cox [Super Dude (at) Linux Academy]
userPassword: tcox
shadowLastChange: 17058
shadowMin: 0
shadowMax: 99999
shadowWarning: 7
Client Side configuration
Now on the client machine, Installed all the required packages and ran the following
authconfig --update --enableldap --enableldapauth --ldapserver=172.31.7.3 --ldapbasedn=dc=sam,dc=com --enablemkhomedir
I could able to successfully login now.
[root#25811cb8b71c ~]# ssh tcox#localhost
Password:
[tcox#25811cb8b71c ~]$ pwd
/home/tcox
[tcox#25811cb8b71c ~]$
Im surprised that how does the Openldap server allowed the nslcd client to access db without authenticating? Help me know what am I missing here.
This means your server allows for anonymous bind, which you can disable :
Create an ldif file, say authbind.ldif and add the following :
dn: cn=config
changetype: modify
add: olcDisallows
olcDisallows: bind_anon
-
dn: olcDatabase={-1}frontend,cn=config
changetype: modify
add: olcRequires
olcRequires: authc
Then run :
ldapmodify -Y EXTERNAL -H ldapi:// -f authbind.ldif
The above works in OpenLDAP Online Configuration (OLC) mode.
For those using the old static configuration, just add the following to slapd.conf and restart your server :
disallow bind_anon
require authc
Related
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
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.)
educating myself with openldap. I thought that olcRootDN would have admin priviledges by default, but that does not seem to be the case. Is it normal to have to setup olcAccess rules for olcRootDN?
Thanks.
dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /usr/local/var/openldap-data
olcSuffix: dc=EXAMPLE,dc=COM
olcRootDN: cn=Manager,dc=EXAMPLE,dc=COM
olcRootPW:: c2VjcmV0
olcDbIndex: objectClass eq
structuralObjectClass: olcMdbConfig
entryUUID: 3b3e5552-c11d-4e20-a61a-ad82d9f18e22
creatorsName: cn=config
createTimestamp: 20190221042051Z
entryCSN: 20190221042051.752732Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20190221042051Z
bash-4.4#
bash-4.4#
bash-4.4# ldapwhoami -D cn=Manager,dc=EXAMPLE,dc=COM -W -H ldaps://ldap.EXAMPLE.COM
Enter LDAP Password:
dn:cn=Manager,dc=EXAMPLE,dc=COM
bash-4.4#
bash-4.4#
bash-4.4#
bash-4.4#
bash-4.4# ldapmodify -D cn=Manager,dc=EXAMPLE,dc=COM -H ldaps://ldap.EXAMPLE.COM -f /etc/openldap/kerberos_index.ldif -W
Enter LDAP Password:
modifying entry "olcDatabase={1}mdb,cn=config"
ldap_modify: Insufficient access (50)
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.
So I'm trying to add records from an ldif file. What's weird is that with one file that I generated, the command works fine. When I try to run it with a different file (generated the same way), it looks like it runs, but returns me to the cli prompt immediately. No error, no add text indicating it worked. I've looked at the files, and they basically look identical.
With the file that works, if I remove all the records except one, you would expect it to still work. But it doesn't. If I copy all the records from the "good" file to the "bad" file, it doesn't work.
ldapmodify.exe -a -x -D "cn=ldapadmin,dc=..." -w <password>; -h <hostname> -f test-OUT_2.ldif -v -n
I'm not sure what is going on, but does anyone have any troubleshooting advice in regards to ldapmodify and this ldif file?
Here's a sample entry. Each entry separated by a blank line.
dn: cn=J811280798,ou=Active,dc=domain,dc=com
changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: cojudExtended
displayName: doe, john
cn: doe, john
givenName: john
cn: J811280798
sn: doe
mail: john.doe#domain.com
userPassword: {SSHA}86uhsAvPgBXm8yEmhrnCUiE/tyObn+NZ
uid: bap08jd
I used use Encode qw(encode_utf8); to encode my output to UTF-8 and it's working like it should.