I added an LDAP entry with ldapadd and ldif file.
Now I have one entry.
I changed ldif file and tried to add a new entry.
dn: dc=my-domain,dc=com
objectclass: dcObject
objectclass: organization
o: dsm
dc: MY-DOMAIN
dn: cn=Manager,dc=my-domain,dc=com
objectclass: organizationalRole
cn: Manager
dn: cn=singer,dc=my-domain,dc=com
objectclass: organizationalRole
cn: singer
I got :
ldap_add: Already exists (68)
How can I add another entry in OPENLDAP?
Appears you are trying to add these again: (Remove these lines)
dn: dc=my-domain,dc=com
objectclass: dcObject
objectclass: organization
o: dsm
dc: MY-DOMAIN
dn: cn=Manager,dc=my-domain,dc=com
objectclass: organizationalRole
cn: Manager
Related
I have done LDAP setup on ubuntu, using apt install slapd ldap-utils
after doing all setup/configuration, added one test user also and here I get:
$ ldapsearch -x -b "dc=param,dc=co,dc=in"
# extended LDIF
#
# LDAPv3
# base <dc=param,dc=co,dc=in> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# param.co.in
dn: dc=param,dc=co,dc=in
objectClass: top
objectClass: dcObject
objectClass: organization
o: param
dc: param
# admin, param.co.in
dn: cn=admin,dc=param,dc=co,dc=in
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
# testuser, param.co.in
dn: uid=testuser,dc=param,dc=co,dc=in
cn: test
sn: test
mail: testuser#param.co.in
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: testuser
# search result
search: 2
result: 0 Success
# numResponses: 4
# numEntries: 3
Now I wanted to add OU with following ou.ldif file:
cn: ou=people,dc=param,dc=co,dc=in
objectClass: top
objectClass: organizationalUnit
ou: people
cn: ou=groups,dc=param,dc=co,dc=in
objectClass: top
objectClass: organizationalUnit
ou: groups
But it is giving no results i.e. no success neither error after adding this file using command:
$ ldapadd -x -W -D "cn=admin,dc=param,dc=co,dc=in" -f ou.ldif
Enter LDAP Password:
$
What wrong thing exactly am i doing here?
change 'cn' to 'dn' for distinguished name. 'cn' is common name which would just be 'people' or 'groups' (except OUs don't need a CN). so it would be:
dn: ou=people,dc=param,dc=co,dc=in
objectClass: top
objectClass: organizationalUnit
ou: people
dn: ou=groups,dc=param,dc=co,dc=in
objectClass: top
objectClass: organizationalUnit
ou: groups
I'm running OpenLDAP 2.4.42, and this is my configuration file:
include C:/OpenLDAP/schema/core.schema
include C:/OpenLDAP/schema/cosine.schema
include C:/OpenLDAP/schema/inetorgperson.schema
pidfile C:/data/slapd/pidfile.pid
database config
database monitor
access to dn.subtree="cn=Monitor" by dn.exact="uid=Admin,dc=my,dc=org" write
access to * by * write
database bdb
include C:/data/pwm/openldap.schema
directory C:/data/slapd/db/bdb
suffix dc=example,dc=it
rootdn cn=root,dc=example,dc=it
rootpw secret
access to * by * manage
index default pres,eq
index cn eq,sub
index sn pres,eq,sub
index objectClass eq
With this slapcat (cut) output:
dn: cn=paul,dc=example,dc=it
objectClass: organizationalRole
cn: paul
dn: l=somewhere,dc=example,dc=it
objectClass: top
objectClass: locality
l: somewhere
dn: cn=john,l=somewhere,dc=example,dc=it
objectClass: organizationalRole
cn: john
structuralObjectClass: organizationalRole
dn: ou=users,dc=example,dc=it
objectClass: organizationalUnit
ou: users
structuralObjectClass: organizationalUnit
dn: cn=charles,ou=users,dc=example,dc=it
objectClass: person
objectClass: pwmUser
cn: charles
sn: charles
userPassword:: bWFyY28y
structuralObjectClass: person
Why does this return results (actually the "charles" entry):
ldapsearch -W -D cn=root,dc=example,dc=it -b "ou=users,dc=example,dc=it"
while this gives "no such object"?
ldapsearch -W -D cn=root,dc=example,dc=it -b "dc=example,dc=it"
I would think that the latter is the most general version of a search, where I'm asking for everything under that suffix.
I'm going to publish a certificate for my email using LDAP.
I already have a LDAP up and running (AD LDS) on windows 2012.
I'm going to add records using ldif file.
Here its contents
dc: dc=mysubdomain,dc=mydomain,dc=com
dn: dc=mysubdomain,dc=mydomain,dc=com
objectClass: top
objectClass: domain
dc: mydomain
dc: mysubdomain
description: Some root stuff
dn: ou=mysubdomaincertificates,dc=mysubdomain,dc=mydomain,dc=com
objectClass: top
objectClass: organizationalUnit
ou: mysubdomaincertificates
dn: Mail=test#mysubdomain.mydomain.com,ou=mysubdomaincertificates,dc=mysubdomain,dc=mydomain,dc=com
objectClass: top
objectClass: person
objectClass: inetOrgPerson
cn: Test Test
sn: Test
Mail: test#mysubdomain.mydomain.com
userSMIMECertificate: #<What to put?>
I'm stuck in compiling my ldif file. As I understand, I need to put some binary encoded in Base64 with some prefix {CERT} or something.
My questions are
Will this ldif file make modifications into the directory?
Do I have problems except userSMIMECertificate field?
For example I'm using dc twice in the domain object, is it ok?
Am I missing some other important line?
What is exact syntax of putting certificate content in the userSMIMECertificate? (I've made a search, but could not find the examples)
Here is your LDIF with the appropriate changes:
dn: dc=mysubdomain,dc=mydomain,dc=com
changetype: add
objectClass: top
objectClass: domain
dc: mysubdomain
description: Some root stuff
dn: ou=mysubdomaincertificates,dc=mysubdomain,dc=mydomain,dc=com
changetype: add
objectClass: top
objectClass: organizationalUnit
ou: mysubdomaincertificates
description: Provide some descriptive text here.
dn: Mail=test#mysubdomain.mydomain.com,ou=mysubdomaincertificates,dc=mysubdomain,dc=mydomain,dc=com
changetype: add
objectClass: top
objectClass: person
objectClass: inetOrgPerson
cn: Test Test
sn: Test
Mail: test#mysubdomain.mydomain.com
userSMIMECertificate: file:///path-cert-file
As a useful supplement to the existing answer from Terry Gardner
To avoid that your ldif depends on an external file, you might want to specify the userSMIMECertificate in such a way:
userSMIMECertificate:: Q29udGVudC1EaXNwb3NpdGlvbjogYXR0YWNobWVudDsKCWZpbGVuY
W1lPXNtaW1lLnA3cwpDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3BrY3M3LXNpZ25hdHVyZTsK
[...]
This is basically the base64-encoded file contents.
In order to get rid of file dependencies, it's easiest to import the ldif with the file dependencies, then export the object to a new ldif. The export should create above format.
I want to use LDAP to automount the user's home and the nfs. I followed this tutorial to configure ldap and automount. (automount information: fstype=nfs,hard,intr,nodev,nosuid,rw 192.168.0.1:/home/serveur/dupont)
dn: cn=dupont, ou=nfs, ou=services, dc=projet, dc=sys
objectClass: top
objectClass: automount
cn: dupont
I have a syntax error when trying to add this file.
$ ldapadd -x -f au.ldif -W -D cn=admin,dc=projet,dc=sys
ldap_add: Invalid syntax (21)
additional info: objectClass: value #1 invalid per syntax
I can't seem to find the source of this error.
$ ldapsearch -x
# extended LDIF
#
# LDAPv3
# base <dc=projet,dc=sys> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# projet.sys
dn: dc=projet,dc=sys
objectClass: top
objectClass: dcObject
objectClass: organization
o: nsalab
dc: projet
# admin, projet.sys
dn: cn=admin,dc=projet,dc=sys
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
# people, projet.sys
dn: ou=people,dc=projet,dc=sys
objectClass: top
objectClass: organizationalUnit
ou: people
description: Branche gens
# etudiants, people, projet.sys
dn: ou=etudiants,ou=people,dc=projet,dc=sys
objectClass: top
objectClass: organizationalUnit
ou: etudiants
description: Branche etudiants
# personnel, people, projet.sys
dn: ou=personnel,ou=people,dc=projet,dc=sys
objectClass: top
objectClass: organizationalUnit
ou: personnel
description: Branche personnel
# services, projet.sys
dn: ou=services,dc=projet,dc=sys
objectClass: top
objectClass: organizationalUnit
ou: services
description: Branche services
# groupes, services, projet.sys
dn: ou=groupes,ou=services,dc=projet,dc=sys
objectClass: top
objectClass: organizationalUnit
ou: groupes
description: Branche groupes
# nfs, services, projet.sys
dn: ou=nfs,ou=services,dc=projet,dc=sys
objectClass: top
objectClass: organizationalUnit
ou: nfs
description: Branche nfs
# mongroupe, groupes, services, projet.sys
dn: cn=mongroupe,ou=groupes,ou=services,dc=projet,dc=sys
objectClass: top
objectClass: posixGroup
cn: mongroupe
gidNumber: 1111
description: groupe de test mongroupe
# dupont, etudiants, people, projet.sys
dn: uid=dupont,ou=etudiants,ou=people,dc=projet,dc=sys
objectClass: top
objectClass: posixAccount
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: dupont
cn: Dupont Jean
sn: Dupont
givenName: Jean
uidNumber: 1100
gidNumber: 1111
homeDirectory: /home/aware/dupont
loginShell: /bin/bash
mail: dupont#projet.sys
l: France
ou: mongroupe
# search result
search: 2
result: 0 Success
# numResponses: 11
# numEntries: 10
I had to activate the right schema.
The autofs-ldap.schema file needs to be converted to LDIF format. You
can do this with the slapcat utility as described in the
OpenLDAPServer guide, or you can just visit
launchpadlibrarian.net/55451730/autofs.ldif and grab this one
that's already been converted (rename it autofs-ldap.ldif and put it
in /etc/ldap/schema for consistency's sake).
And use ldapadd to import it into the database.
$ ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/autofs-ldap.ldif
You have to activate the right schema:
The autofs-ldap.schema file needs to be converted to LDIF format. You can do this with the slapcat utility as described in the OpenLDAPServer guide, or you can just visit launchpadlibrarian.net/55451730/autofs.ldif and grab this one that's already been converted (rename it autofs-ldap.ldif and put it in /etc/ldap/schema for consistency's sake).
And use ldapadd to import it into the database.
$ ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/autofs-ldap.ldif
I am trying to simulate Active Directory's memberOf attribute in Apache Directory. I have added the following entry for memberOf to my LDIF file:
dn: m-oid=1.3.6.1.4.1.18060.0.4.3.2.1,ou=attributeTypes,cn=other,ou=schema
m-usage: USER_APPLICATIONS
m-equality: distinguishedNameMatch
objectClass: metaAttributeType
objectClass: metaTop
objectClass: top
m-name: memberOf
m-oid: 1.3.6.1.4.1.18060.0.4.3.2.1
m-obsolete: FALSE
m-noUserModification: FALSE
m-syntax: 1.3.6.1.4.1.1466.115.121.1.27
When I start ApacheDS the following warning is logged:
WARN [ContainerBackgroundProcessor[StandardEngine[Catalina]]] entry.ServerStringValue - Cannot normalize the value :Encountered name based id of memberOf which was not found in the OID registry
This causes problems later on because my application tries to user the memberOf attribute as a search filter.
Is anything wrong with the way I specified the LDIF entry?
For my integration test cases on top of embedded Apache Directory Server I've added both memberOf and sAMAccountName attributes defined in Microsoft Active Directory server.
#########################################################
# MICROSOFT SCHEMA for sAMAccountName and memberOf
# these two attributes are not defined in Apache Directory Server
#########################################################
dn: cn=microsoft, ou=schema
objectclass: metaSchema
objectclass: top
cn: microsoft
dn: ou=attributetypes, cn=microsoft, ou=schema
objectclass: organizationalUnit
objectclass: top
ou: attributetypes
dn: m-oid=1.2.840.113556.1.4.221, ou=attributetypes, cn=microsoft, ou=schema
objectclass: metaAttributeType
objectclass: metaTop
objectclass: top
m-oid: 1.2.840.113556.1.4.221
m-name: sAMAccountName
m-equality: caseIgnoreMatch
m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
m-singleValue: TRUE
dn: m-oid=1.2.840.113556.1.4.222, ou=attributetypes, cn=microsoft, ou=schema
objectclass: metaAttributeType
objectclass: metaTop
objectclass: top
m-oid: 1.2.840.113556.1.4.222
m-name: memberOf
m-equality: caseIgnoreMatch
m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
m-singleValue: FALSE
dn: ou=objectclasses, cn=microsoft, ou=schema
objectclass: organizationalUnit
objectclass: top
ou: objectClasses
dn: m-oid=1.2.840.113556.1.5.6, ou=objectclasses, cn=microsoft, ou=schema
objectclass: metaObjectClass
objectclass: metaTop
objectclass: top
m-oid: 1.2.840.113556.1.5.6
m-name: simulatedMicrosoftSecurityPrincipal
m-supObjectClass: top
m-typeObjectClass: AUXILIARY
m-must: sAMAccountName
m-may: memberOf
#######################################################
# Megacorp employees
#######################################################
dn: cn=EmployeeABC,ou=nl_users,DC=corp,DC=megacorp,DC=COM
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectclass: simulatedMicrosoftSecurityPrincipal
cn: EmployeeABC
sn: EmployeeABC
givenName: EmployeeABC
mail: EmployeeABC#megacorp.com
MEMBEROF: CN=just-users,OU=mc_groups,DC=corp,DC=megacorp,DC=com
MEMBEROF: CN=best-users,OU=mc_groups,DC=corp,DC=megacorp,DC=com
SAMACCOUNTNAME: employeeabc
The ApacheDS team is aware of the desire for the memberOf virtual attribute. They mention that it will be part of the 2.1.0 release:
Le 5/20/13 5:53 PM, Danielsen, Jay a écrit :
I see from the January 2013 archives that memberOf virtual attribute is not yet supported.
Are there any plans or work-in-progress to support memberOf in an upcoming release ? Morst certainly in 2.1.0.
We are currently busy cleaning the 150 remaining issues before a
2.0.0-RC1 release, so I think this is something we can have in the next 6 months.
You can create a JIRA to request such a feature.
Thanks !
-- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
And here is the JIRA request.
You may need to add the schema that contains 'memberOf' into the ApacheDS configuration.