While adding the password policy in the openldap file it throws error While running from the command line
root#openldap-server:/etc/ldap/slapd.d# ldapadd -D cn=admin,dc=zariga,dc=com -w password -f passwordpolicy.ldif
adding new entry "cn=DefaultPPolicy,ou=Policies,dc=zariga,dc=com"
ldap_add: Object class violation (65)
additional info: no structural object class provided
This is the LDIF file
dn: cn=DefaultPPolicy,ou=Policies,dc=zariga,dc=com
cn: DefaultPPolicy
objectClass: pwdPolicy
objectClass: top
pwdAttribute: userPassword
pwdMaxAge: 3024000
pwdExpireWarning: 1814400
pwdInHistory: 4
pwdCheckQuality: 1
pwdMinLength: 9
pwdMaxFailure: 4
pwdLockout: TRUE
pwdLockoutDuration: 600
pwdGraceAuthNLimit: 0
pwdFailureCountInterval: 0
pwdMustChange: TRUE
pwdAllowUserChange: TRUE
pwdSafeModify: FALSE
You're trying to add an object to LDAP with only pwdPolicy objectClass which is defined as AUXILIARY (see Password Policy for LDAP Directories, ch. 5.1) and every object added to LDAP server must have a STRUCTURAL objectClass.
You need to change your LDIF file to include one STRUCTURAL objectClass like device (or any other that you fancy but it's type is STRUCTURAL).
For instance:
dn: cn=DefaultPPolicy,ou=Policies,dc=zariga,dc=com
cn: DefaultPPolicy
objectClass: device
objectClass: pwdPolicy
objectClass: top
...
Related
Actually, in my LDAP, I have a groups ou populated with groupOfNames objects and a roles ou populated with groupOfMembers objects.
I also configured the memberOf overlay to retrieve the groupOfMembers (ie roles) the user belong to in the memberof attribute.
My goal is to have also an attribute memberOfGroup with the list of groupOfNames (ie groups) the user belong to.
In order to do that I created an new schema with Attribute Type definition for memberOfGroup attribute :
cn={14}memberOfGroup,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: {14}memberOfGroup
olcAttributeTypes: {0}( 1.3.6.1.4.1.51127.3.2.2.3
NAME 'memberOfGroup'
DESC 'The groups the user belong to'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
The problem I have is that when I try to set it as operational attribute is :
# ldapmodify -Y EXTERNAL -H ldapi:/// -f test.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn={14}memberOfGroup,cn=schema,cn=config"
ldap_modify: Other (e.g., implementation specific) error (80)
additional info: olcAttributeTypes: "1.3.6.1.4.1.51127.3.2.2.3" is operational
With test.ldif :
dn: cn={14}memberOfGroup,cn=schema,cn=config
changetype: modify
replace: olcAttributeTypes
olcAttributeTypes: ( 1.3.6.1.4.1.51127.3.2.2.3
NAME 'memberOfGroup'
DESC 'The groups the user belong to'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION
USAGE DSAOperation )
In parallel, I also defined the second memberOf overlay.
The first for roles (work) :
dn: olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config
objectClass: olcMemberOf
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: {0}memberof
olcMemberOfDangling: ignore
olcMemberOfRefInt: TRUE
olcMemberOfGroupOC: groupOfMembers
olcMemberOfMemberAD: member
olcMemberOfMemberOfAD: memberOf
The second for groups (not work) :
dn: olcOverlay={1}memberof,olcDatabase={1}mdb,cn=config
objectClass: olcMemberOf
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: {1}memberof
olcMemberOfDangling: ignore
olcMemberOfRefInt: TRUE
olcMemberOfGroupOC: groupOfNames
olcMemberOfMemberAD: member
olcMemberOfMemberOfAD: memberOfGroup
Can someone explain me what is wrong with the creation of operational attribute and the error I have ?
In ldif you have USAGE DSAOperation
Operational attributes can be used only by the directory itself, and can't be added or modified by a user. OpenLDAP module memberof creates it automatically when a user is added to some group(and also removes when user is removed).
If you want some custom attribute for group membership tracking, then you can create a simple attribute(not operational), but in this case ldap server won't update users' membership automatically.
I am using openldap to create a simple user and simple group.
dn: cn=User2 Engineer,ou=users,dc=example,dc=net
cn: User2 Engineer
gidnumber: 501
givenname: User2
homedirectory: /home/users/u2engineer
loginshell: /bin/sh
objectclass: inetOrgPerson
objectclass: posixAccount
objectclass: top
sn: Engineer
uid: u2engineer
uidnumber: 1002
userpassword: {MD5}xxxxxxx
# Entry 1: cn=network engineers,ou=groups,dc=example,dc=net
dn: cn=network engineers,ou=groups,dc=example,dc=net
cn: network engineers
gidnumber: 501
memberuid: user1ene
memberuid: u2engineer
objectclass: posixGroup
objectclass: top
I would like to relate the user to the group by adding memberof attribute to user entry.
it mean i need to add groupOfNames objectclass to user, groupOfNames is in core.schema
but it can add that objectclass to user neither via phpldapadmin nor ldapmodify.
i got error:
LDAP said: Object class violation
Error number: 0x41 (LDAP_OBJECT_CLASS_VIOLATION)
I am sure that core.schema has been imported to openldap successfully.
What is the possible cause?
How can I add memberof attribute to users?
Thanks!
-SG-
You can't. The memberOf attribute is an operational attribute maintained automatically by the memberof overlay. You can't set it yourself.
Adding the groupOfNames object class to the user entry doesn't make sense either. That object class is for, err, groups of names, such as roles, and it has a member attribute to which you add the DN of the user. Then the memberOf attribute of the user is automatically updated to include the DN of the group.
You're doing this all back to front.
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
I just Installed OpenLDAP on Ubuntu Server 12.10, and I added an ldif file using slapadd -c -l init.ldif as the following :
dn:dc=tpw,dc=uca,dc=ma
dc: tpw
objectClass: dcObject
objectClass: top
objectClass: domain
dn: ou=people,dc=tpw,dc=uca,dc=ma
ou: people
objectClass: organizationalUnit
objectClass: top
dn: ou=groupes,dc=tpw,dc=uca,dc=ma
ou: groupes
objectClass: organizationalUnit
objectClass: top
dn: uid=admin,ou=people,dc=tpw,dc=uca,dc=ma
uid: admin
sn: Admin
cn: Admin
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
userPassword:: e1NIQX0wRFBpS3VOSXJyVm1EOElVQ3V3MWhReE5xWmM9
mail: admin#uca.ma
givenName: admin
dn: cn=GI,ou=groupes,dc=tpw,dc=uca,dc=ma
uniquemember: uid=admin,ou=people,dc=tpw,dc=uca,dc=ma
cn: GI
objectClass: groupOfUniqueNames
objectClass: top
dn: cn=GP,ou=groupes,dc=tpw,dc=uca,dc=ma
uniquemember: uid=admin,ou=people,dc=tpw,dc=uca,dc=ma
cn: GP
objectClass: groupOfUniqueNames
objectClass: top
dn: cn=GT,ou=groupes,dc=tpw,dc=uca,dc=ma
uniquemember: uid=admin,ou=people,dc=tpw,dc=uca,dc=ma
cn: GT
objectClass: groupOfUniqueNames
objectClass: top
Now my ldap tree looks like this :
Then I tried to add a new inetOrgPerson using Apache Directory Studio, but I got this error :
[LDAP: error code 80 - index generation failed]
Then I tried the same thing using phpLDAPadmin, but I got this error :
Impossible d'ajouter l'objet au serveur LDAP.
LDAP dit :: Other (e.g., implementation specific) error
Erreur numéro :: 0x50 (LDAP_OTHER)
Then I created a file which I named xx.ldif :
dn: uid=xx,ou=people,dc=tpw,dc=uca,dc=ma
cn: XX
givenname: xx
mail: xx#edu.uca.ma
objectclass: inetOrgPerson
objectclass: organizationalPerson
objectclass: person
objectclass: top
sn: XX
uid: xx
userpassword: toor
And I tried to add this entry using this command via terminal :
sudo ldapadd -x -D cn=Manager,dc=tpw,dc=uca,dc=ma -W -f xx.ldif
But I got this error :
ldap_add: Other (e.g., implementation specific) error (80)
additional info: index generation failed
How can I solve this problem ?
PS : In another scenario I deleted my database and I modified the file init.ldif wich contains all the entries I want to add, and I added the entry xx, then I imported my file using the slapadd command, but In this way I have to delete the database every time I want to add a new entry, which is not practical.
Edit1 :
This is the output of the command slapindex :
WARNING!
Runnig as root!
There's a fair chance slapd will fail to start.
Check file permissions!
5370d6f9 /etc/ldap/slapd.conf: line 95: rootdn is always granted unlimited privileges.
5370d6f9 /etc/ldap/slapd.conf: line 112: rootdn is always granted unlimited privileges.
5370d6f9 hdb_db_open: database "dc=tpw,dc=uca,dc=ma": database already in use.
5370d6f9 backend_startup_one (type=hdb, suffix="dc=tpw,dc=uca,dc=ma"): bi_db_open failed! (-1)
slap_startup failed
The first thing is that init.ldif file seems to be misconfigured :
domainComponent "uca" (dc=uca) is missing, there should be an entry (dcObject or domain objectClass) to define this attribute that holds a component of the domain name.
dcObject is intended to be used in entries for which there is an appropriate structural object class. For example, if the domain represents a particular organization, the entry would have as its structural object class 'organization', and the 'dcObject' class would be an auxiliary class.
domain is a structural object class used for entries in which no other information is being stored. The domain object class is typically used for entries that are placeholders or whose domains do not correspond to real-world entities.
In your .ldif file you can replace the first entry "dn: dc=tpw,dc=uca,dc=ma" with these 2 (then delete your database again and redo the slapadd command) :
dn: dc=uca,dc=ma
objectClass: top
objectClass: organization
objectClass: dcObject
dc: uca
o: an organization name (mandatory with 'organization' objectClass)
dn: dc=tpw,dc=uca,dc=ma
objectClass: top
objectClass: domain
dc: tpw
Second thing : obviously you have landed into an index issue. I think you do want to use indexes but if not, find and remove any line beginning with index from slapd.conf, e.g. :
index objectClass eq.
Remember to stop slapd and run slapindex after every change comitted to the index definitions in slapd.conf, and ensure all ldap clients have been disconnected before running slap commands to prevent database already in use messages.
So take the hints given you by slapindex. Don't run slapd as root, fix lines 95 and 112, and don't run slapd twice, or fix whatever is causing it to think the database is already in use.
While this isn't relevant to the OP's question, I ran into a similar error of:
bdb_db_open: database already in use
or
hdb_db_open: database "dc=XXX,dc=XXX,dc=XXX": database already in use.
One of our Openshift nodes went down and the PVC's (mount) /var/lib/ldap/ __db.001, __db.002 and __db.003 had become locked. After googling for hours, the only solution I found was to perform the following (and note, since it was OpenShift, I had to use a debug pod to get a shell).
mkdir /var/lib/ldap/backup
mv /var/lib/ldap/__db.* /var/lib/ldap/backup
Try and restart slapD, if it still fails as it did with one of OpenLDap instances, then move the alock file
mv /var/lib/ldap/__db.* /var/lib/ldap/backup
Restart slapD or in our instance delete the OpenShift pod and let it be recreated. Everything may now be working as it did for us - hope this might help anyone else running into the same issue.
I am working with OpenLDAP and client browser as Apache directory Studio.
I did whatever required for enforcing ppolicies to the openLDAP users still I think its missing something and someware.
This is my ppolicy.ldif
dn: dc=maxcrc,dc=com
objectClass: top
objectClass: domain
dc: maxcrc
dn: ou=People,dc=maxcrc,dc=com
objectClass: organizationalUnit
objectClass: top
ou: People
description: Container for user entries
dn: ou=policies,dc=maxcrc,dc=com
objectClass: top
objectClass: organizationalUnit
ou: policies
dn: cn=default,ou=policies,dc=maxcrc,dc=com
objectClass: pwdPolicy
objectClass: top
objectClass: device
cn: default
pwdAttribute: userPassword
pwdAllowUserChange: TRUE
pwdCheckQuality: 1
pwdExpireWarning: 86400
pwdInHistory: 6
pwdLockout: TRUE
pwdLockoutDuration: 1920
pwdMaxAge: 172800
pwdMaxFailure: 4
pwdMinLength: 6
pwdSafeModify: FALSE
dn: uid=jery,dc=maxcrc,dc=com
objectClass: pwdPolicy
objectClass: posixAccount
objectClass: top
objectClass: account
cn: maxcrc jery
gidNumber: 1011
homeDirectory: /home/jery
pwdAttribute: userPassword
uid: jery
uidNumber: 1011
pwdPolicySubentry:cn=strong,ou=policies,dc=maxcrc,dc=com
dn: cn=strong,ou=policies,dc=maxcrc,dc=com
objectClass: device
objectClass: top
objectClass: pwdPolicy
cn: strong
pwdAttribute: userPassword
pwdMaxAge: 1296000
pwdMinLength: 4
still it allows to add userPassword from apache directory studio with more than 4 character.can anyone tell me why is it so? Thanks in advance .
below is my sldap.config file
# BDB Backend configuration file
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
ucdata-path ./ucdata
include ./schema/core.schema
include ./schema/cosine.schema
include ./schema/nis.schema
include ./schema/inetorgperson.schema
include ./schema/openldap.schema
include ./schema/dyngroup.schema
include ./schema/ppolicy.schema
moduleload ppolicy.la
moduleload syncprov.la
moduleload back_bdb.la
moduleload back_ldap.la
pidfile ./run/slapd.pid
argsfile ./run/slapd.args
# Enable TLS if port is defined for ldaps
TLSVerifyClient never
TLSCipherSuite HIGH:MEDIUM:-SSLv2
TLSCertificateFile ./secure/certs/server.pem
TLSCertificateKeyFile ./secure/certs/server.pem
TLSCACertificateFile ./secure/certs/server.pem
#######################################################################
# bdb database definitions
#######################################################################
database monitor
database bdb
suffix "dc=maxcrc,dc=com"
# invokes password policies for this DIT only
overlay ppolicy
# Default ppolicy
ppolicy_default "cn=strong,ou=policies,dc=maxcrc,dc=com"
# Some ppolicy directives
ppolicy_use_lockout
ppolicy_hash_cleartext
# ACL1
#access to attrs=userPassword
# by self write
# by anonymous auth
# by group.exact="cn=Manager,dc=maxcrc,dc=com"
# write
# by * none
# ACL3
#access to *
# by self write
# by group.exact="cn=Manager,dc=maxcrc,dc=com"
# write
# by users read
# by * none
rootdn "cn=Manager,dc=maxcrc,dc=com"
# Cleartext passwords, especially for the rootdn, should
# be avoid. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw secret
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory ./data
dirtyread
searchstack 20
# Indices to maintain
index mail pres,eq
index objectclass pres
index default eq,sub
index sn eq,sub,subinitial
index telephonenumber
index cn
The password policy overlay requires you not to carry out the operation as the rootDN. You should use an admin login defined in the DIT that has the appropriate permissions.