I read this book : "Mastering OpenLDAP". It is an old book - 2007 - the version of Openldap is the 2.3 in this book.
I use Openldap 2.5 (Ubuntu 22.04).
It is written that I can add two attributes by using ldapmodify this way:
dn: uid=nicholas,ou=Users,dc=example,dc=com
changetype: modify
add: description title
description: This is a test
title: Cartesian philosopher
but when I try it, it doesn't work:
thierry#thierry-VirtualBox:~$ ldapmodify -x -w secret -D 'cn=Manager,dc=example,dc=com'
dn: uid=nicholas,ou=Users,dc=example,dc=com
changetype: modify
add: description title
description: This is a test
title: Cartesian philosopher
ldapmodify: wrong attributeType at line 4, entry "uid=nicholas,ou=Users,dc=example,dc=com"
Although it works well if I add one attribute, and then another. Why ?
thierry#thierry-VirtualBox:~$ ldapmodify -x -w secret -D 'cn=Manager,dc=example,dc=com'
dn: uid=nicholas,ou=Users,dc=example,dc=com
changetype: modify
add: description
description: This is a test
modifying entry "uid=nicholas,ou=Users,dc=example,dc=com"
^C
thierry#thierry-VirtualBox:~$ ldapmodify -x -w secret -D 'cn=Manager,dc=example,dc=com'
dn: uid=nicholas,ou=Users,dc=example,dc=com
changetype: modify
add: title
title: Cartesian philosopher
modifying entry "uid=nicholas,ou=Users,dc=example,dc=com"
^C
thierry#thierry-VirtualBox:~$ ldapsearch -x -w secret -D 'cn=Manager,dc=example,dc=com' -LLL '(uid=nicholas)'
dn: uid=nicholas,ou=Users,dc=example,dc=com
cn: Nicholas Malebranche
sn: Malebranche
uid: nicholas
ou: Users
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
title: Cartesian philosopher
description: This is a test
Thank you for your help.
The manpage has an example of making multiple changes:
dn: cn=Modify Me,dc=example,dc=com
changetype: modify
replace: mail
mail: modme#example.com
-
add: title
title: Grand Poobah
-
add: jpegPhoto
jpegPhoto:< file:///tmp/modme.jpeg
-
delete: description
-
So in your case, yours should look something like this:
dn: uid=nicholas,ou=Users,dc=example,dc=com
changetype: modify
add: description
description: This is a test
-
add: title
title: Cartesian philosopher
-
Related
I'm trying to import a user into OpenLDAP on Alpine Linux. Here's the LDIF that I named searchUser.ldif:
# Search account
dn: uid=search,dc=home
changetype: add
objectClass: top
objectClass: person
objectClass: inetOrgPerson
cn: search
sn: search
uid: search
The command I used to import it is:
ldapadd -x -D "cn=Manager,dc=home" -w supersecret -f searchUser.ldif
The error I get is:
ldap_add: Invalid syntax (21) additional info: objectClass: value #2 invalid per syntax
My understanding of this is the objectClasses are numbered, starting with 0, and that #2 indicates the problem is with inetOrgPerson.
I've done this successfully using OpenLDAP on Raspberry Pi OS (debian). However, I get the feeling the Debian package automates some configuration steps that the Alpine package does not. One of those steps I think Debian does during the package install is to import inetOrgPerson schema.
I've tried to do the schema import manually. Here are the steps I took prior to trying the LDIF import...
I scripted my install of OpenLDAP on Alpine, like so:
export DOMAIN="dc=home"
echo "Installing packages..."
apk add openldap openldap-back-mdb openldap-clients
echo "Configuring for v2.3+ style slapd.d config directory..."
install -m 755 -o ldap -g ldap -d /etc/openldap/slapd.d
sed -i~ \
-e 's/^cfgfile=/#cfgfile=/' \
-e 's/^#cfgdir=.*/cfgdir=\"\/etc\/openldap\/slapd.d\"/' \
/etc/conf.d/slapd
rm /etc/openldap/slapd.conf
echo "Customizing for domain: ${DOMAIN}..."
sed -i~ \
-e 's/\.la$/.so/' \
-e "s/dc=my-domain,dc=com/${DOMAIN}/" /etc/openldap/slapd.ldif
echo "Importing configuration..."
slapadd -n 0 -F /etc/openldap/slapd.d -l /etc/openldap/slapd.ldif
chown -R ldap:ldap /etc/openldap/slapd.d/*
echo "Configuring slapd service..."
install -m 755 -o ldap -g ldap -d /var/lib/openldap/run
service slapd start
rc-update add slapd
The slapd service started and I could connect to it with command-line tools and from a client over port 389. So far, so good.
The next thing I did was to import schema for cosine and inetOrgPerson. I believe the Debian package did this automatically, because I don't recall having to do this previously.
Here's what I did on Alpine to import the schema:
slapadd -n 0 -F /etc/openldap/slapd.d -l /etc/openldap/schema/cosine.ldif
slapadd -n 0 -F /etc/openldap/slapd.d -l /etc/openldap/schema/inetorgperson.ldif
There were no errors.
I then created an organization using the command ldapadd -x -D "cn=Manager,dc=home" -w secret -f org.ldif and this LDIF as org.ldif:
dn: dc=home
objectclass: dcObject
objectclass: organization
o: Home
dc: home
dn: cn=Manager,dc=home
objectclass: organizationalRole
cn: Manager
This too was successful.
I can also create organizational units with this LDIF:
# Organizational unit for users
dn: ou=People,dc=home
changetype: add
objectClass: organizationalUnit
ou: People
# Organizational unit for groups.
dn: ou=Groups,dc=home
changetype: add
objectClass: organizationalUnit
ou: Groups
So I think my server is okay, but I may have done something wrong with the inetOrgPerson schema import that's causing the Invalid syntax (21) error.
Is the way I'm importing the inetOrgPerson schema correct? Is there a way to verify it?
I believe the problem was due to incorrect ownership for the new files in the /etc/openldap/slapd.d/cn=config/cn=schema directory. Once I fixed that, I was able to import the search user.
Because I ran the slapd commands as the root user, the resulting schema config files were owned by root. I discovered this when I restarted the slapd service and it failed with this error in /var/log/messages:
ldif_read_file: Permission denied for "/etc/openldap/slapd.d/cn=config/cn=schema/cn={1}cosine.ldif"
The solution was to change ownership on the files. This is the correct ownership:
alpine:/etc/openldap/slapd.d/cn=config/cn=schema# ls -l
total 32
-rw------- 1 ldap ldap 15575 May 5 12:43 cn={0}core.ldif
-rw------- 1 ldap ldap 11361 May 5 14:53 cn={1}cosine.ldif
-rw------- 1 ldap ldap 2855 May 5 14:53 cn={2}inetorgperson.ldif
So the answer to this question is...
Yes, importing with slapadd -n 0 -F /etc/openldap/slapd.d -l /etc/openldap/schema/inetorgperson.ldif worked fine, but the command should have been run as the ldap user so the ownership is correct. (Or run as root and change ownership after.)
One way to verify the schema is to look inside the /etc/openldap/slapd.d directory. Specifically, /etc/openldap/slapd.d/cn=config/cn=schema shows evidence of the schema I added.
Even with the potential for incorrect file ownership, I see this as a much easier way to add schema than some of the other tutorials I've found that involve creating and editing a temporary slapd.conf file.
I need to set password policy only to a specific OU, and it will be applied to all users that will be crated/moved in this OU.
I have OPENLDAP 2.4.44 installed on CentOS 7, and I configured it in this way (I used this guide: https://ktree.com/blog/OpenLDAP-password-policy-implementatio-on-ubuntu.html):
Step1. Enable policy Overlay, It can be done by installing the schema.
$ ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/ppolicy.ldif
For Verification, whether it is done or not
[root#TST-LDAP01]# ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=schema,cn=config dn
dn: cn=schema,cn=config
dn: cn={0}core,cn=schema,cn=config
dn: cn={1}cosine,cn=schema,cn=config
dn: cn={2}nis,cn=schema,cn=config
dn: cn={3}inetorgperson,cn=schema,cn=config
dn: cn={4}ppolicy,cn=schema,cn=config
Step2. We need to write to the directory where are all policies will be filename: policies_1.ldif
$ vim policies_1.ldif
dn: ou=Policies,cn=Manager,dc=mydomain,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Policies
description: Password policy config files
To apply to the directory:
$ ldapadd -D cn=Manager,dc=mydomain,dc=com -W -f policies_1.ldif
Step3. Now, We load the Modules handling the policies.
$ vim policy_module.ldif
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: ppolicy
To apply to the directory :
$ ldapadd -Y EXTERNAL -H ldapi:/// -f policy_module.ldif
For verification, modules loaded?
[root#TST-LDAP01]# ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=module{0},cn=config
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib64/openldap
olcModuleLoad: {0}syncprov.la
olcModuleLoad: {1}ppolicy
Step4. Now tell directory where to look for the policies.
$ vim policy_overlay.ldif
dn: olcOverlay={1}ppolicy,olcDatabase={2}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: {1}ppolicy
olcPPolicyDefault: cn=DefaultPPolicy,ou=Policies,cn=Manager,dc=mydomain,dc=com
To apply to the directory
$ ldapadd -Y EXTERNAL -H ldapi:/// -f policy_overlay.ldif
For Verification, Overlays in use
[root#TST-LDAP01]# ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b olcDatabase={2}hdb,cn=config
dn: olcDatabase={2}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {2}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=mydomain,dc=com
olcRootDN: cn=Manager,dc=mydomain,dc=com
olcRootPW: {SSHA}1AMIpQs6xbFa8wYre5rdBGm+fCmTCVXz
olcDbIndex: objectClass eq,pres
olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub
dn: olcOverlay={0}ppolicy,olcDatabase={2}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: {0}ppolicy
olcPPolicyDefault: cn=DefaultPPolicy,ou=Policies,cn=Manager,dc=mydomain,dc=c
om
Step5. Now we can create default policy objects.
$ vim Default_Policies.ldif
dn: cn=DefaultPPolicy,ou=Policies,cn=Manager,dc=mydomain,dc=com
cn: DefaultPPolicy
objectClass: pwdPolicy
objectClass: device
objectClass: top
pwdAttribute: userPassword
pwdMaxAge: 2592000
pwdExpireWarning: 2160000
pwdInHistory: 3
pwdCheckQuality: 1
pwdMinLength: 8
pwdMaxFailure: 3
pwdLockout: TRUE
pwdLockoutDuration: 30
pwdGraceAuthNLimit: 0
pwdFailureCountInterval: 0
pwdMustChange: TRUE
pwdAllowUserChange: TRUE
pwdSafeModify: FALSE
To apply to the directory
$ ldapadd -D cn=Manager,dc=mydomain,dc=com -W -f Default_Policies.ldif
For Verification
[root#TST-LDAP01]# ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=DefaultPPolicy,ou=Policies,cn=Manager,dc=mydomain,dc=com
dn: cn=DefaultPPolicy,ou=Policies,cn=Manager,dc=mydomain,dc=com
cn: DefaultPPolicy
objectClass: pwdPolicy
objectClass: device
objectClass: top
pwdAttribute: userPassword
pwdMaxAge: 2592000
pwdExpireWarning: 2160000
pwdInHistory: 3
pwdCheckQuality: 1
pwdMinLength: 8
pwdMaxFailure: 3
pwdLockout: TRUE
pwdLockoutDuration: 30
pwdGraceAuthNLimit: 0
pwdFailureCountInterval: 0
pwdMustChange: TRUE
pwdAllowUserChange: TRUE
pwdSafeModify: FALSE
Now is it possible to set Default_Policies only to ou=ExternalUsers,cn=Manager,dc=mydomain,dc=com and all new users have this settings?
Thanks
Marco
sorry, can't comment due to my reputation score but a similar question was answered here: https://serverfault.com/questions/830147/openldap-password-policy-for-a-group
The following may help but it is user specific:
Create custom policy for example:
dn: cn=pwdLockoutDuration,ou=Policies,dc=test,dc=com
objectClass: device
objectClass: pwdPolicy
objectClass: top
cn: pwdLockoutDuration
pwdAttribute: userPassword
pwdExpireWarning: 500
pwdMaxAge: 600
pwdMaxFailure: 3
Then add a subentry to the user:
dn: cn=test4,ou=Users,dc=test,dc=com
changetype: modify
add: pwdPolicySubentry
pwdPolicySubentry: cn=pwdLockoutDuration,ou=Policies,dc=test,dc=com
I need to check users for membership in a group on FreeIPA. (Currently I'm testing on the command line to get the search right before writing the actual code in Node). Based on searches, I'm using the following query:
ldapsearch -x -b "uid=testuser,cn=users,cn=accounts,dc=smnet,dc=com" '(memberof=cn=testgroup,cn=groups,cn=accounts,dc=smnet,dc=com)'
But the result I get is:
# extended LDIF
#
# LDAPv3
# base <uid=testuser,cn=users,cn=accounts,dc=smnet,dc=com> with scope subtree
# filter: (memberof=cn=testgroup,cn=groups,cn=accounts,dc=smnet,dc=com)
# requesting: ALL
#
# search result
search: 2
result: 0 Success
# numResponses: 1`
However, if I leave off the filter:
ldapsearch -x -b "uid=testuser,cn=users,cn=accounts,dc=smnet,dc=com"
I get:
# extended LDIF
#
# LDAPv3
# base <uid=testuser,cn=users,cn=accounts,dc=smnet,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# testuser, users, accounts, smnet.com
dn: uid=testuser,cn=users,cn=accounts,dc=smnet,dc=com
givenName: test
sn: user
uid: testuser
cn: test user
displayName: test user
initials: tu
gecos: test user
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
objectClass: inetuser
objectClass: posixaccount
objectClass: krbprincipalaux
objectClass: krbticketpolicyaux
objectClass: ipaobject
objectClass: ipasshuser
objectClass: ipaSshGroupOfPubKeys
objectClass: mepOriginEntry
loginShell: /bin/sh
homeDirectory: /home/testuser
uidNumber: 253000005
gidNumber: 253000005
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
Which is what I'm expecting. Is my query wrong? Or am I misinterpreting the results?
In case it matters, this is with the latest Fedora server, with Free IPA included in the install process, running in a VirtualBox VM.
Both your queries are done with anonymous bind to LDAP (-x switch to ldapsearch). FreeIPA does not allow to see membership information unless you are authenticated. Create a user and use its credentials to authenticate in your searches, then you'll get both member and memberof attributes visible.
I am trying to add custom attributes and object classes in my LDAP(ODSEE) but having issues.
Initially, I had issues with adding the custom attributes and classes, but was finally it worked. My custom definitions look like below(got the test code from one of the sites for testing)
dn: cn=schema
changetype: modify
add: attributeTypes
attributeTypes: ( 1.3.6.1.4.1.4203.666.1.90
NAME ( 'personStatus' )
DESC 'person Status'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
MULTI-VALUE )
dn: cn=schema
changetype: modify
add: objectClasses
objectClasses: ( 1.3.6.1.4.1.4203.666.1.100
NAME 'YoLinuxPerson'
DESC 'Yo Linux Person’
SUP inetOrgPerson
AUXILIARY
MAY personStatus )
My user ldif is as below
dn: uid=acc, ou=People, dc=example,dc=com
**objectClass: YoLinuxPerson*******************Custom
objectClass: organizationalPerson
objectClass: person
objectClass: top
cn: aaaaa Vaughan
sn: Vaughan
facsimileTelephoneNumber: +1 408 555 3372
givenName: Kirsten
l: Sunnyvale
mail: aaaaa#example.com
ou: Human Resources
ou: People
roomNumber: 2871
telephoneNumber: +1 408 555 5625
uid: aaaaa
**personStatus: abcdefghij**********************Custom
userPassword:: e1NTSEF9WhgljhlWxzZUdDUVVFUW05OTg1bmJSUkpoNHdYUVgrZkE9P
I tried multiple ways but everything fails. If I remove the "personStatus: abcdefghij" the ldapadd command works, but if I have it there, it fails saying
[config]$ ldapadd -h -p -D "cn=" -w -f User.ldif
adding new entry uid=acc, ou=People, dc=example,dc=com
ldap_add: Object class violation
I also did a ldap search
- ldapsearch -D -w -h -p -b "cn=schema" -s base 'objectclass=*'
and it displayed all the results including the custom attribute (which I am having issues with), but i could not see the custom objectClass(which I can add to the user).
I tried with Apache Studio also, it fails with the same message. I am not sure what I am missing. Any help is appreciated. Thanks.
There's a problem with the objectClass definition :
Either it extends inetOrgPerson, and thus it's a STRUCTURAL objectClass,
Or it is AUXILIARY and doesn't need to extend inetOrgPerson.
But your issue may be that you need to restart DSEE to be able to set the entry with the new objectClass and attribute (I vaguely remember an issue in that domain, but it's been more than 5 years since I last played with DSEE).
I'm wanting to add members to an AD distribution group. I enter the following command (putting in dummy values in some places):
ldapmodify -v -h 111.111.111.11 -D "CN=binding_user,DC=example,DC=com" -x -w password -f entrymods
The file 'entrymods' contains:
dn: CN=group_name, OU=Groups, DC=example, DC=com
changetype: modify
add: member
member: CN=Smith\, John, OU=Users, DC=example, DC=com
I'm getting the following output:
ldap_initialize( ldap://111.111.111.11 )
warning: no attributes to change or add (entry="CN=group_name, OU=Groups, DC=example, DC=comchangetype: modifyadd: membermember: CN=Smith\, John, OU=Users, DC=example, DC=com")
modifying entry "CN=group_name, OU=Groups, DC=example, DC=comchangetype: modifyadd: membermember: CN=Smith\, John, OU=Users, DC=example, DC=com"
modify complete
ldap_modify: Invalid DN syntax (34)
additional info: 00000057: LdapErr: DSID-0C090A5B, comment: Error processing name, data 0, vece
Find a user without a Comma in their DN and try it again that way. It is saying the referenced object does not exist. Now I am not sure if it is the DN:
CN=Smith\, John, OU=Users, DC=example, DC=com (The member being added)
or the group DN:
CN=group_name, OU=Groups, DC=example, DC=com
Looking at the member DN being added, the comma (properly escaped, I would say) is easy enough to test and eliminate from being an issue if it was.