OpenLDAP memberof Overlay not showing - ldap

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

Related

Apache AuthLDAPURL and ldapsearch

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

Receive invalid credentials (49)when trying to add a user to LDAP

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 `ldapmodify` command hangs

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.

Using md5 at userPassword (OpenLDAP)

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

inetOrgPerson with member or memberOf?

What works
Suppose I have inetOrgPersons in ou=people,dc=example,dc=com. Example:
dn: cn=John Doe,ou=people,dc=example,dc=com
objectClass: inetOrgPerson (structural)
objectClass: person (structural)
objectClass: top (abstract)
cn: John Doe
sn: Doe
givenName: John
mail: john.doe#example.com
uid: john.doe
In addition I have several organizations:
dn: o=foo,dc=example,dc=com
objectClass: organization (structural)
objectClass:top (abstract)
o: foo
dn: o=bar,dc=example,dc=com
objectClass: organization (structural)
objectClass:top (abstract)
o: bar
For each organization there is a groupOfNames:
dn: cn=users,o=foo,dc=example,dc=com
objectClass:groupOfNames (structural)
cn: users
member: cn=John Doe,ou=people,dc=example,dc=com
dn: cn=users,o=bar,dc=example,dc=com
objectClass:groupOfNames (structural)
cn: users
As you can see, cn=John Doe,ou=people,dc=example,dc=com is listed as a member of cn=users,o=foo,dc=example,dc=com but not of dn: cn=users,o=bar,dc=example,dc=com.
Problem
I want to note membership at the inetOrgPersons, too.
memberOf is not in the schemas I currently use for a user. Is there any schema available that provides memberOf?
member is part of groupOfNames but this objectClass conflicts with inetOrgPerson:
[LDAP: error code 65 - invalid structural object class chain (inetOrgPerson/groupOfNames)]
Question
How can I note the membership in cn=users,o=foo,dc=example,dc=com on cn=John Doe,ou=people,dc=example,dc=com?
If you're using OpenLDAP you need to use the 'memberof' overlay, which maintains a real 'memberOf' attribute among the operational attributes.
Note that it won't affect memberships that already exist, only new ones from when you first load the overlay. See the OpenLDAP documentation.
Depending on the server in use, memberOf might be a virtual attribute and would not be listed in the entry, but rather is generated by the server. Some other servers use isMemberOf instead of memberOf. memberOf or isMemberOf would be generated upon request by server.
One could search:
ldapsearch -h hostname -p port \
-b dc=example,dc=com -s sub \
'(memberOf=cn=users,o=foo,dc=example,dc=com)'
or
ldapsearch -h hostname -p port \
-b dc=example,dc=com -s sub \
'(isMemberOf=cn=users,o=foo,dc=example,dc=com)'
to get the distinguished names that are members of cn=users,o=foo,dc=example,dc=com.
To get the groups of which a known distinguished name is a member:
ldapsearch -h hostname -p port \
-b dc=example,dc=com -s sub \
'(cn=Joe User)' isMemberOf
or
ldapsearch -h hostname -p port \
-b dc=example,dc=com -s sub \
'(cn=Joe User)' memberOf
The object class violation occurs because groupofNames and inetOrgPerson are both structural object classes. Only one structural object class is permitted per object. Some broken directory servers (DSEE for example) will allow multiple structural object classes per object, though. In one of your examples it appears the person and inetOrgPerson are in the same object together, this is a different case because inetOrgPerson is a descendant of person.