I am trying to correlate what Apache does for the AuthLDAPURL with ldapsearch. I have a setup where I can run an ldapsearch to successfully test a user's credentials, but I cannot seem to translate that to an Apache configuration.
Do you have any ideas on how to emulate what Apache is doing with an LDAP search, or how to create the AuthLDAPURL so it matches the ldapsearch?
This is on Ubuntu 22.04, OpenLDAP (May 12 2022), Apache (2.4.41).
I can do the following ldapsearches to show the user is in the system and the password is correct.
ldapsearch -x -LLL -H ldap://testserver -D "cn=admin,dc=testserver" -W -b "ou=people,dc=testserver" -s children "(&(objectClass=posixAccount)(uid=billy))" dn
Enter LDAP Password:
dn: uid=billy,ou=people,dc=testserver
root#testserver:/home/sysadmin# ldapsearch -x -LLL -H ldap://testserver -D "uid=billy,ou=people,dc=testserver" -W -b "dc=testserver" -s children "(objectClass=*)"
Enter LDAP Password:
<prints tree under dc=testserver>
Here is my Apache configuration:
<Location /svn/>
DAV svn
SVNParentPath /var/svn
SVNListParentPath On
AuthName 'Please use your Testserver account'
AuthType Basic
AuthBasicProvider ldap
AuthLDAPBindDN "cn=admin,dc=testserver"
AuthLDAPBindPassword "password"
# Test the user account
AuthLDAPURL "ldap://testserver:389/ou=people,dc=testserver?uid?sub?(ObjectClass=*)"
require valid-user
</Location>
Here is my LDAP configuration:
dn: ou=people,dc=testserver
objectClass: organizationalUnit
ou: people
dn: ou=groups,dc=testserver
objectClass: organizationalUnit
ou: groups
dn: uid=billy,ou=people,dc=testserver
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
cn: Bill
sn: Belichick
userPassword: {SSHA}pr4TabkZcr/ZAtiHBgL6bF1jvuvIJ6dn
loginShell: /bin/bash
uidNumber: 2001
gidNumber: 2001
homeDirectory: /home/bill
dn: ou=svn,ou=groups,dc=testserver
objectClass: organizationalUnit
ou: groups
dn: cn=svn_folder_repo1_rw,ou=svn,ou=groups,dc=testserver
objectClass: groupOfNames
cn: svn_folder_repo1_rw
member: uid=billy,ou=people,dc=testserver
Finally, the Apache error log reports ...
[Thu Aug 11 02:24:04.914162 2022] [auth_basic:error] [pid 4631] [client 192.168.99.1:49323] AH01617: user billy: authentication failure for "/svn/": Password Mismatch
*** --- Edit --- ***
I tried with a non user and got the same message.
[Thu Aug 11 11:43:13.916494 2022] [auth_basic:error] [pid 619] [client 192.168.99.1:60322] AH01617: user eric: authentication failure for "/svn/": Password Mismatch
Related
My ldap.conf looks like: (server and client on the same machine)
# TLS certificates (needed for GnuTLS)
TLS_CACERT /etc/ssl/certs/ca-certificates.crt
BASE dc=hdlldaptest,dc=net
URI ldap://localhost
Results of ldapsearch -x:
# extended LDIF
#
# LDAPv3
# base <dc=hdlldaptest,dc=net> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# hdlldaptest.net
dn: dc=hdlldaptest,dc=net
objectClass: top
objectClass: dcObject
objectClass: organization
o: qatest
dc: hdlldaptest
# admin, hdlldaptest.net
dn: cn=admin,dc=hdlldaptest,dc=net
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
# search result
search: 2
result: 0 Success
# numResponses: 3
I try to add a user using this file: qa_test.ldif
dn: uid=qa_test,ou=users,dc=hdlldaptest,dc=net
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
cn: qa_test
uid: qa_test
uidNumber: 16859
gidNumber: 100
homeDirectory: /home/qa_test
loginShell: /bin/bash
gecos: qa_test
userPassword: {crypt}x
shadowLastChange: 0
shadowMax: 0
shadowWarning: 0
Then I run
# ldapadd -x -W -D "cn=ramesh,dc=tgs,dc=com" -f qa_test.ldif
Enter LDAP Password:
I don't know what password I am supposed to use, I tried leaving as is and entering x. Adding a real password, but every time I run, I get invalid credentials. I thought that you add the password after the user was created.
The -D option is used for binding (which account is used to perform the operation), so you need to provide a DN corresponding to a user with sufficient permissions to achieve the ldapadd.
Usually that kind of operations are performed by the LDAP admin/manager, probably cn=admin,dc=hdlldaptest,dc=net in your case.
If your directory supports it, you can also bind using SASL mechanism, for example 'EXTERNAL' (usually TLS or Unix IPC) :
ldapadd -Y EXTERNAL -H ldapi:/// -f qa_test.ldif
The memberOf attribute is not showing in ldap simple search if I do the following then memberOf attribute is hidden.
ldapsearch -Y external -H ldapi:/// -b dc=example,dc=com
# udraz, Users, example.com
dn: uid=udraz,ou=Users,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: udraz
sn: Draz
givenName: Umar
mail: udraz#example.com
cn: Umar Draz
displayName: Umar Draz
uidNumber: 5000
gidNumber: 5000
gecos: Umar Draz
loginShell: /bin/bash
homeDirectory: /home/udraz
But if I do the following then memberOf attribute appear
ldapsearch -Y external -H ldapi:/// -b dc=example,dc=com memberOf
# udraz, Users, example.com
dn: uid=udraz,ou=Users,dc=example,dc=com
memberOf: cn=developers,ou=Users,dc=example,dc=com
Would you please help me how to solve this
The ldapmodify command hangs:
$ ldapmodify -D "uid=admin,ou=system" -w secret -p 10389 -h localhost
But the ldapsearch command works fine:
$ ldapsearch -D "uid=admin,ou=system" -w secret -p 10389 -h localhost -b "ou=system"
# extended LDIF
#
# LDAPv3
# base <ou=system> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# services, configuration, system
dn: ou=services,ou=configuration,ou=system
ou: services
objectClass: top
objectClass: organizationalUnit
# sysPrefRoot, system
dn: prefNodeName=sysPrefRoot,ou=system
objectClass: top
objectClass: organizationalUnit
objectClass: extensibleObject
prefNodeName: sysPrefRoot
# consumers, system
dn: ou=consumers,ou=system
ou: consumers
objectclass: top
objectclass: organizationalUnit
# groups, system
dn: ou=groups,ou=system
ou: groups
objectClass: top
objectClass: organizationalUnit
# admin, system
dn: uid=admin,ou=system
keyAlgorithm: RSA
privateKeyFormat: PKCS#8
displayName: Directory Superuser
sn: administrator
cn: system administrator
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: tlsKeyInfo
userCertificate:: MIIBgTCCASsCBgFZwG57UzANBgkqhkiG9w0BAQUFADBCMQswCQYDVQQGEwJV
UzEMMAoGA1UEChMDQVNGMRIwEAYDVQQLEwlEaXJlY3RvcnkxETAPBgNVBAMTCEFwYWNoZURTMB4XD
TE3MDEyMTA5NDk0M1oXDTE4MDEyMTA5NDk0M1owUDELMAkGA1UEBhMCVVMxDDAKBgNVBAoTA0FTRj
ESMBAGA1UECxMJRGlyZWN0b3J5MR8wHQYDVQQDExZzdGVwaGFuZS1UaGlua1BhZC1YMzAxMFwwDQY
JKoZIhvcNAQEBBQADSwAwSAJBAJ8Vkmb185ftKslZiq4O3xwMvcn7POSHqicja6S/1Fd13RCZbcSl
fryzcFToYxN7kDhWv/Sr17A+BAvnf+0LT/0CAwEAATANBgkqhkiG9w0BAQUFAANBAEmF0ag90ymJ4
sd/l4DGwGu/gipm5Vjl9JjvVzCS7UuvKZ4l9g/FRcuMg9AmjGPsGOP06LgSM/oGUenOleUk9Hc=
userPassword:: c2VjcmV0
publicKey:: MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAJ8Vkmb185ftKslZiq4O3xwMvcn7POSHqi
cja6S/1Fd13RCZbcSlfryzcFToYxN7kDhWv/Sr17A+BAvnf+0LT/0CAwEAAQ==
publicKeyFormat: X.509
uid: admin
privateKey:: MIIBUwIBADANBgkqhkiG9w0BAQEFAASCAT0wggE5AgEAAkEAnxWSZvXzl+0qyVmKr
g7fHAy9yfs85IeqJyNrpL/UV3XdEJltxKV+vLNwVOhjE3uQOFa/9KvXsD4EC+d/7QtP/QIDAQABAk
BOmpwSH6jTAq7HemTZiCOZeno0WN1HlfjvCcNgTiCfbaY20l34ydGw+6FsSINPh/sYv62AJEYIjk/
5KWNTZFBBAiEA5lQyCefJ1BZzLX/X2qdZVVF7p0rEpZ0bHyzt043HN2UCIQCw0JsmXRbH9Qct4g/b
MadK6a4QXTxy0LXjFqbZojKouQIgGdaoJmRSR/CcyyXkWSsc4m1ZqdLBbLLLMBwiMfFdv+ECIBdpq
AGudePIWEkFFCBsNMDArKHSFr0FUfBeAX3z8k1RAiB5RI7iYw1alVEaXtL2TMyLxp4UlIi/xCtBFd
7N988icg==
# system
dn: ou=system
ou: system
objectClass: top
objectClass: organizationalUnit
objectClass: extensibleObject
# partitions, configuration, system
dn: ou=partitions,ou=configuration,ou=system
ou: partitions
objectClass: top
objectClass: organizationalUnit
# interceptors, configuration, system
dn: ou=interceptors,ou=configuration,ou=system
ou: interceptors
objectClass: top
objectClass: organizationalUnit
# configuration, system
dn: ou=configuration,ou=system
ou: configuration
objectClass: top
objectClass: organizationalUnit
# Administrators, groups, system
dn: cn=Administrators,ou=groups,ou=system
uniqueMember: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
cn: Administrators
objectClass: top
objectClass: groupOfUniqueNames
# users, system
dn: ou=users,ou=system
ou: users
objectClass: top
objectClass: organizationalUnit
# search result
search: 2
result: 0 Success
# numResponses: 12
# numEntries: 11
I just built and installed the apacheds-2.0.0-M23 and openldap-2.4.44 products on my Lubuntu 16.04 box.
ldapmodify reads from stdin, because you didn't specify an LDIF file via -f.
I start my test openldap server on RedHat enterprise linux 6.5. I configured it properly I think. I add my base.ldif file which looks like that:
dn: dc=example,dc=com
dc: example
description: Root LDAP entry for example.com
objectClass: dcObject
objectClass: organizationalUnit
ou: rootObject
dn: ou=People,dc=exapmle,dc=com
ou: People
description: All people in organisation
objectClass: organizationalUnit
Using command:
ldapadd -x -W -D "cn=Manager,dc=example,dc=com" -f base.ldif
I got an output:
[root#melita-bladekp ~]# ldapadd -x -W -D "cn=Manager,dc=example,dc=com" -f base.ldif
Enter LDAP Password:
adding new entry "dc=example,dc=com"
adding new entry "ou=People,dc=exapmle,dc=com"
ldap_add: Server is unwilling to perform (53)
additional info: no global superior knowledge
But i tried second time and I receive:
[root#melita-bladekp ~]# ldapadd -x -W -D "cn=Manager,dc=example,dc=com" -f base.ldif
Enter LDAP Password:
adding new entry "dc=example,dc=com"
ldap_add: Already exists (68)
So it looks okay for me, next I tried to add an user:
dn: uid=ldapuser100,ou=People,dc=example,dc=com
uid: ldapuser100
cn: ldapuser100
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}$6$E/tH1oRF$9.Km8Xs/wDIFgWgTT.domcw0PJGUZqK7mqdFPaNru2il5LMgsxaowq5bvjulQLR8CqSq.Pw.brZU77fzviQPG.
shadowLastChange: 16460
shadowMin: 0
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 1400
gidNumber: 1400
homeDirectory: /exports/ldapuser100
Using command:
[root#melita-bladekp ~]# ldapadd -x -W -D "cn=Manager,dc=example,dc=com" -f ldapuser100.ldif
Enter LDAP Password:
adding new entry "uid=ldapuser100,ou=People,dc=example,dc=com"
ldap_add: No such object (32)
matched DN: dc=example,dc=com
And I receive that DN didn't exists. I think there is problem with that base file, do you have any idea what I can do to fix it?
My conf files(I think that the conf files are ok):
/etc/openldap/ldap.conf
BASE dc=example,dc=com
URI ldap://localhost
TLS_REQCERT never
/etc/openldap/slapd.conf
include /etc/openldap/schema/corba.schema
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/duaconf.schema
include /etc/openldap/schema/dyngroup.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/java.schema
include /etc/openldap/schema/misc.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/openldap.schema
include /etc/openldap/schema/ppolicy.schema
include /etc/openldap/schema/collective.schema
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
TLSCACertificatePath /etc/openldap/certs/ldap.crt
TLSCertificateFile /etc/openldap/certs/ldap.crt
TLSCertificateKeyFile /etc/openldap/certs/ldap.key
database config
access to *
by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
by * none
database monitor
access to *
by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read
by dn.exact="cn=Manager,dc=example,dc=com" read
by * none
database bdb
suffix "dc=example,dc=com"
checkpoint 1024 15
rootdn "cn=Manager,dc=example,dc=com"
rootpw {SSHA}MdddSPNLtlsVia4T534qLL6LWLRy2lBB
directory /var/lib/ldap
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
It looks like you have a typo in the dn of your LDIF
dn: ou=People,**dc=exapmle**,dc=com
If you change exapmle to example and re-run the LDIF with continue on error you should get the example entry and then you will be able to add your user afterwards.
I'm using LDAP for ssh autorithation.
userPassword with {crypt} working fine, but {md5} doesn't work.
ldapmodify -Vv -D "cn=Manager,dc=*,dc=*" -W -f *.ldif
*.ldif:
dn: uid=*,ou=People,dc=*,dc=*
changetype: modify
replace: userPassword
userPassword: {CRYPT}eGUw6pD1aAClQ
*.ldif:
dn: uid=*,ou=People,dc=*,dc=*
changetype: modify
replace: userPassword
userPassword: {MD5}ICy5YqxZB1uWSwcVLSNLcA==
Standart configuration:
https://wiki.gentoo.org/wiki/Centralized_authentication_using_OpenLDAP
Solved by using ssha:
slappasswd -h {ssha} -c 'some_salt'.
it's better then plain md5.
https://developer.apple.com/library/mac/documentation/Darwin/Reference/Manpages/man8/slappasswd.8.html
Result:
ssha512
slappasswd -h {ssha} -c '$6$%s' -s 123
{CRYPT}$6$s2mWoK1ZzwO0v02J$yi19QVOQB0ESrHwnCV.bl0RjwmwxWlNMl9z9FB0AqC9fL8SX2Q8Q2/k0Zj.l0qNtOacq6SWMdmfkDWQ4L1cqp.
dn: uid=test1,ou=People,dc=*,dc=*
uid: test1
cn: test1
sn: test1
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {CRYPT}$6$s2mWoK1ZzwO0v02J$yi19QVOQB0ESrHwnCV.bl0RjwmwxWlNMl9z9FB0AqC9fL8SX2Q8Q2/k0Zj.l0qNtOacq6SWMdmfkDWQ4L1cqp.
shadowLastChange: 16176
loginShell: /bin/bash
uidNumber: 0
gidNumber: 0
homeDirectory: /home/test1
gecos: test1