Add a new schema in IBM SDS 6.4 - ldap

I'm tryring to import the below schema to my ldap instance
schematest.ldif
dn: cn=schema
objectClass: top
objectClass: ldapSubentry
objectClass: subschema
cn: schema
attributetypes: ( 1.3.18.0.2.4.708 NAME 'abstract' DESC 'Provides an abstract of a document entry.' EQUALITY 2.5.13.2 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications )
objectclasses: ( 2.5.6.18 NAME 'userSecurityInformation' DESC 'User security information.' SUP 'top' AUXILIARY MAY ( supportedAlgorithms ) )
Note: This file is just an example and no it's th real
For try to import/add this new shema in the config file I ran this command like in this documentation:
./idsldapadd -D cn=root -w password -i /home/path...../schematest.ldif
Anyone know what is the correct option for do that?
Add a new schema on IBM SDS 6.4

Related

Adding initial entries in openldap returns- ldap_add: No such object (32)

I'm trying to add two entries in ldap just below one another. But it's not letting me add. Error-
adding new entry "dc=R2D2"
ldap_add: No such object (32)
additional info: Unable to add entry 'dc=R2D2' because its parent entry 'null' does not exist in the server.
This is a new openLDAP server running on a Feora29. I've tried many modifications to my ldif file but it's still not working.
The LDAP expected structure:
dc=R2D2 -> o=TD
I have added objectClass: country on line 4 because it said:
adding new entry "dc=R2D2"
ldap_add: Object class violation (65)
additional info: Unable to add entry 'dc=R2D2' because it violates the provided schema: The entry does not have a structural object class.
This is the ldif i'm trying to add via ldapadd
dn: dc=R2D2
dc: R2D2
objectClass: dcObject
objectClass: country
objectClass: top
c=DE
dn: o=TD,dc=R2D2
o: TD
objectClass: organization
objectClass: top
The LDAP result code noSuchObject (32) returned for a failed add operation means that the parent entry was not found.
If dc=R2D2 is really the full DN of the entry to be added, then you have to define a database with this particular DN used as database suffix.
For static OpenLDAP config method this would look like:
[..]
database mdb
suffix dc=R2D2
[..]
See also: OpenLDAP Software 2.4 Administrator's Guide
I guess this is because your ldif has an unnecessary space character at line 4 (after "country" like "country ").
I have been able to successfully execute ldapadd command with the following ldif that has no unnecessary space character after "country":
dn: dc=R2D2
dc: R2D2
objectClass: dcObject
objectClass: country
objectClass: top
c: DE
dn: o=TD,dc=R2D2
o: TD
objectClass: organization
objectClass: top

How to create LDAP aliases in Openldap and Phpldapadmin?

I am trying to do this example with an email field :
https://coderwall.com/p/c0w6-q/create-ldap-aliases-in-openldap
This is the .ldif that should create both :
# this is the user
dn: uid=aka,c=VN,ou=users,ou=school,o=vdm,dc=domain,dc=com
objectclass: top
objectClass: extensibleObject
objectclass: posixAccount
objectclass: inetOrgPerson
cn: Alexander Fake
employeetype: developer
gecos: Alexander Fake
gidnumber: 14564103
homedirectory: /home/aka
loginshell: /bin/bash
mail: alexander.fake#domain.com
sn: Fake
uid: aka
uidnumber: 14583105
userpassword: {SSHA}SgmdndrPR5UVLOAmDs5JOJvqr3WmPYob
# this is the alias
dn: mail=alexander.Fake#domain.com,dc=mailAccount,dc=domain.com,dc=mail,dc=domain,dc=com
changetype: add
objectClass: alias
objectClass: top
objectClass: extensibleObject
objectclass: inetOrgPerson
uid: aka
aliasedObjectName: uid=aka,c=VN,ou=users,ou=school,o=vdm,dc=domain,dc=com
I can only import/export ldif, I use phpldapadmin for administration.
When the aliases is craeted it produce the following error :
This update has been or will be cancelled, it would result in an attribute value not being unique. You might like to search the LDAP server for the offending entry.
Does anyone know how to create aliases on openldap and phpldapadmin ?
This is basically correct. Just:
Remove the uid=aka attribute from the aliasedObject. It doesn't need it. It refers to another object which has that UID value.
Also remove inetOrgPerson from the alias. It isn't a person, it's an alias for a person.
The objectClass attribute only needs to contain top and alias; and extensibleObject so you can provide a cn or whatever attribute you like as part of the DN, if you want to do that: it doesn't seem to be necessary judging by my DIT.
Poor quality source material. Don't rely on arbitrary Internet junk. Use the official documentation.

Unable to create partition in LDAP ApacheDS

I'm newbie on LDAP and I'd like to create my first schema using an LDIF file. Here is the first part of the LDIF file:
dn: dc=demo,dc=com
objectclass: top
objectclass: domain
dc: demo
dn: ou=Users,dc=demo,dc=com
objectClass: organizationalUnit
objectClass: top
ou: Users
description: demo.Com Users
dn: uid=bob,ou=Users,dc=demo,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
cn: User Test
sn: Test
displayName: User Test
givenName: User
mail: bob#demo.com
ou: Users
uid: bob
userPassword:: e1NTSEF9MGhuUjhnWkFNZFpKVUNwZXFwcFEzeUQ2YkJNOTVQUVo4WU9JSUE9P
Q==
Even if the LDIF declares the top domain "demo.com" the following error is raised:
"Entry
dn[n]: dc=demo,dc=com
objectclass: top
objectclass: domain
dc: demo : ERR_268 Cannot find a partition for dc=demo,dc=com]"
On the other hand, creating the partition "demo.com" manually with ApacheDS studio UI (and removing the first dn block) it works. I'm a bit confused! Any help to sort out the problem?
Importing your LDIF file into ApacheDS will just create the entries not the partition. Since all your entries have to be stored in a partition you get the below error when the partition doesn't exist:
ERR_268 Cannot find a partition for dc=demo,dc=com
Every partition has a suffix or base DN associated with it which will act as the parent entry for all the other entries stored in the same partition. In your case the suffix will be:
dc=demo,dc=com
Notice that the suffix is also an entry (just like any other entry in your directory).
Creating a new DIT (Directory Information Tree) involves the following steps:
Create a new partition.
Create suffix entry.
Create additional entries.
Some utilities (like Apache Studio) will create the suffix entry automatically when you create the partition (I think that's what's confusing you) but in reality they are two different operations.
You can read more about ApacheDS partitions here.

openldap add mail attribute to users

I'm trying to add 'mail' attribute to users on my openldap server but somehow it fails.
I tried using ldapmodify but I get this:
ldap_modify: Object class violation (65)
additional info: attribute 'mail' not allowed
Here's how my schema looks like:
# LDIF Export for ou=users,dc=mydomain,dc=com
# Server: (ldap.mydomain.com)
# Search Scope: sub
# Search Filter: (objectClass=*)
# Total Entries: 63
version: 1
# Entry 1: ou=users,dc=mydomain,dc=com
dn: ou=users,dc=mydomain,dc=com
objectclass: organizationalUnit
objectclass: top
ou: users
# Entry 2: uid=tom.hanks,ou=users,dc=mydomain,dc=com
dn: uid=tom.hanks,ou=users,dc=mydomain,dc=com
cn: tom.hanks
description: User account
gecos: tom.hanks
gidnumber: 100
homedirectory: /home/tom.hanks
loginshell: /bin/bash
objectclass: account
objectclass: posixAccount
uid: tom.hanks
uidnumber: 1005
userpassword: blahblah
Include objectclass: iNetOrgPerson to add the mail attribute.
In order to give the user the Attribute mail you first have to add the mail attribute to the user's olcObjectClasses.
This can be done by a modification via an ldif like this:
dn: cn={12345}someName,cn=schema,cn=config
changetype: modify
delete: olcObjectClasses
olcObjectClasses: {1}
-
add: olcObjectClasses
olcObjectClasses: {1}( 1.3.6.1.4.1.12344556.1.1.1 NAME 'yourObjectClassEGAccount' DESC 'some description' SUP inetOrgPerson STRUCTURAL MUST ( requiredparam1 $ requiredParam2 $ reqParam3 ) MAY ( optionalParam1 $ optionalParam2 ) ) )
-
See the documentation for ldapmodify for details: Oracle ldapmodify Doc
The modification is then given to ldap via the following command (command line):
sudo ldapmodify -f filename.ldif
make sure to read the documentation on whether you need further parameters like eg. -h for hostname or -Y for a proxyDN: lmodify Doc

OpenLDAP Dynamic Groups not searching by member

I'm confused! :)
I've got a dynamic group in OpenLDAP:
dn: cn=DynamicGroup,ou=Group,dc=MyDomain
cn: DynamicGroup
objectClass: groupOfURLs
memberURL: ldap:///ou=People,dc=MyDomain??one?(&(objectClass=User)(isInDynamicGroup=TRUE))
When I search for it, it gets expanded (the dynlist module is set up correctly):
$ ldapsearch -H "ldapi:///" -b "dc=MyDomain" -s sub -LLL -d 0 -QY EXTERNAL 'cn= DynamicGroup'
dn: cn=DynamicGroup,ou=Group,dc=MyDomain
cn: DynamicGroup
objectClass: groupOfURLs
memberURL: ldap:///ou=People,dc=MyDomain??one?(&(objectClass=User)(isInDynamicGroup=TRUE))
member: cn=User One,ou=People,dc=MyDomain
member: cn=User Two,ou=People,dc=MyDomain
Brilliant. Exactly what I'd expect.
However, if I search on it by member I get nothing!
$ ldapsearch -H "ldapi:///" -b "dc=MyDomain" -s sub -LLL -d 0 -QY EXTERNAL 'member=cn=User One,ou=People,dc=MyDomain' 'cn'
dn: cn=Developers,ou=Group,dc=MyDomain
cn: Developers
dn: cn=VPNUsers,ou=Group,dc=MyDomain
cn: VPNUsers
But, no cn: DynamicGroup ! :(
Nothing! :(
Does anyone have an hint for me as to why that might not be working?
Update:
I thought that it might be that the member attribute was not formally mentioned in the dynlist schema. I've added it, but it still doesn't work:
dn: cn={6}dyngroup,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: {6}dyngroup
olcObjectIdentifier: {0}NetscapeRoot 2.16.840.1.113730
olcObjectIdentifier: {1}NetscapeLDAP NetscapeRoot:3
olcObjectIdentifier: {2}NetscapeLDAPattributeType NetscapeLDAP:1
olcObjectIdentifier: {3}NetscapeLDAPobjectClass NetscapeLDAP:2
olcObjectIdentifier: {4}OpenLDAPExp11 1.3.6.1.4.1.4203.666.11
olcObjectIdentifier: {5}DynGroupBase OpenLDAPExp11:8
olcObjectIdentifier: {6}DynGroupAttr DynGroupBase:1
olcObjectIdentifier: {7}DynGroupOC DynGroupBase:2
olcAttributeTypes: {0}( NetscapeLDAPattributeType:198 NAME 'memberURL' DESC 'I
dentifies an URL associated with each member of a group. Any type of labeled
URL can be used.' SUP labeledURI )
olcAttributeTypes: {1}( DynGroupAttr:1 NAME 'dgIdentity' DESC 'Identity to use
when processing the memberURL' SUP distinguishedName SINGLE-VALUE )
olcAttributeTypes: {2}( DynGroupAttr:2 NAME 'dgAuthz' DESC 'Optional authoriza
tion rules that determine who is allowed to assume the dgIdentity' EQUALITY a
uthzMatch SYNTAX 1.3.6.1.4.1.4203.666.2.7 X-ORDERED 'VALUES' )
olcObjectClasses: {0}( NetscapeLDAPobjectClass:33 NAME 'groupOfURLs' SUP top S
TRUCTURAL MUST cn MAY ( member $ memberURL $ businessCategory $ description $
o $ ou $ owner $ seeAlso ) )
olcObjectClasses: {1}( DynGroupOC:1 NAME 'dgIdentityAux' SUP top AUXILIARY MAY
( dgIdentity $ dgAuthz ) )
structuralObjectClass: olcSchemaConfig
entryUUID: 997a529e-a081-1033-8148-81c0722e60ba
creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
createTimestamp: 20140715153657Z
entryCSN: 20140715153657.339934Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20140715153657Z
It looks like from an attribute search perspective the member attribute either isn't matching, or it's doing the search prior to the dynlist expansion:
root#auth-new:/vagrant/LDAP# /usr/bin/ldapsearch -H "ldapi:///" -b "dc=MyDomain" -s sub -LLL -d 0 -QY EXTERNAL 'member=*' 'cn'
dn: cn=Developers,ou=Group,dc=MyDomain
cn: Developers
dn: cn=VPNUsers,ou=Group,dc=MyDomain
cn: VPNUsers
Update: using an auto group it now works:
dn: olcOverlay=autogroup,olcDatabase={2}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAutomaticGroups
olcOverlay: autogroup
olcAGattrSet: {0}groupOfURLs memberURL member
olcAGmemberOfAd: memberOf
The dynlist overlay doesn't implement the feature you're looking for. You're correct about the expansion happening later than the search filter. See for example the thread starting at http://www.openldap.org/lists/openldap-software/200708/msg00250.html
You may want to look at the contributed autogroup overlay, which maintains membership info in the database (where it can be searched and filtered) but updates it automatically when needed.