openldap-technical

openldap-technical@openldap.org

9868 discussions

User restriction
by Stuart Cherrington 10 Jun '10

10 Jun '10

Hi, I'm migrating from a Sun One DS service to Openldap 2.4. In our current setup, the ldap.conf on each client the nss_base_passwd line is configured as nss_base_passwd ou=people,dc=ldn,dc=sw,dc=com?sub?ismemberof=cn=access,ou=auth,dc=ldn,dc=sw,dc=com This ensures that only users within the CN 'access' can login to the servers. Have exported and imported the data and carried out necessary cleaning up work, the ldapsearch brings back identical output when examining 'cn=access,ou=auth,dc=ldn,dc=sw,dc=com' but on my client which talks to the Openldap server, I cannot login with any accounts is the above setting is in place. I'm presuming that the issue is about the config of the above line but try as I might I can't get it to work correctly. Any help would be appreciated. Thanks, Stuart Cherrington. _________________________________________________________________ http://clk.atdmt.com/UKM/go/197222280/direct/01/ Do you have a story that started on Hotmail? Tell us now

7 8

Re: smbk5pwd: ldappassword hangs
by Frank Van Damme 10 Jun '10

10 Jun '10

2010/6/7 Quanah Gibson-Mount <quanah(a)zimbra.com>: > --On Monday, June 07, 2010 11:56 AM +0200 Frank Van Damme > What version of OpenLDAP are you using? You've failed to mention that > anywhere. 2.4.11 (Debian 5.0). -- Frank Van Damme A: Because it destroys the flow of the conversation. Q: Why is it bad? A: No, it's bad. Q: Should I top post in replies to mailing lists or on Usenet?

2 1

help SSL on Openldap and java
by s g 10 Jun '10

10 Jun '10

> > Our requirement is that we need to test if a server certificate from > Openldap server is valid and then upload to our trust store and use the > certificate for further communications using SSL to the ldap server. > I configured Openldap for SSL as per the Openldap admin guide - generated > the 3 certificates cacert.pem,servercert.pem and serverkey.pem and put the > corresponding entries in slapd.conf file. My assumption is cacert.pem is the > file for the CA,servercert.pem is the server certificate file(?!) and the > serverkey.pem is the file containing the private key to the server. After > configuring my client ldap.conf file to point to cacert.pem as per the > following directives - > > TLS_CACERTDIR <path to my cacert.pem file> > TLS_REQCERT hard > > I was able to execute an ldapsearch command successfully. My problem is > that after adding cacert.pem to my truststore, I am unable to use the > certificate in java using SSL. I get the following exception - > > javax.naming.CommunicationException: simple bind failed: > vcheung-181.lab.xxxx.net:636 [Root exception is > javax.net.ssl.SSLHandshakeException: > sun.security.validator.ValidatorException: Netscape cert type does not > permit use for SSL server] > at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:197) > at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2658) > at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:287) > at > com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:175) > at > com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:193) > at > com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:136) > at > com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:66) > at > javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667) > at > javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288) > at javax.naming.InitialContext.init(InitialContext.java:223) > at javax.naming.InitialContext.<init>(InitialContext.java:197) > at > javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:82) > at > com.xxxx.analyst.manager.database.LDAPSchemaTest.areAllAttributesPresent(LDAPSchemaTest.java:84) > at > com.xxxx.analyst.presentation.action.ReCreateDomainAction.doAttributeCheck(ReCreateDomainAction.java > :249) > at > com.xxxx.analyst.presentation.action.ReCreateDomainAction.execute(ReCreateDomainAction.java:182) > at > org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) > at > org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) > at > org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) > at > org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at com.xxxx.util.ReLiveUserFilter.doFilter(ReLiveUserFilter.java:70) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > com.xxxx.analyst.util.ReAccessFilter.doFilter(ReAccessFilter.java:191) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) > at > org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39) > at > org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153) > at > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482) > at > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482) > at > org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) > at > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.jav > a:744) > at > org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) > at > org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112) > at java.lang.Thread.run(Thread.java:619) > > Caused by: javax.net.ssl.SSLHandshakeException: > sun.security.validator.ValidatorException: Netscape cert type does not > permit use for SSL server > at > com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174) > at > com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1591) > at > com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:187) > at > com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:181) > at > com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:975) > at > com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:123) > at > com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:516) > at > com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:454) > at > com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:884) > at > com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1096) > at > com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:623) > at > com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:59) > at > java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65) > at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123) > at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:393) > at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:334) > at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:192) > ... 47 more > > > I googled for the above exception and from what I got, I thought I had to > configure for a client certificate but we have to test the server > certificate for validity not the client certificate. I am not sure I am > following the procedure correctly. My question is - > Is servercert.pem the file that I need to use as server certificate. How > can I validate it(I mean make sure that it is a valid server certificate > file)? (Pointing to the servercert.pem file in ldap.conf gave me an error) - ldap_create ldap_url_parse_ext(ldaps://vcheung-181.lab.xxxx.net:636) ldap_bind_s ldap_simple_bind_s ldap_sasl_bind_s ldap_sasl_bind ldap_send_initial_request ldap_new_connection ldap_int_open_connection ldap_connect_to_host: TCP vcheung-181.lab.xxxx.net:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 172.25.4.181:636 ldap_connect_timeout: fd: 3 tm: -1 async: 0 ldap_ndelay_on: 3 ldap_is_sock_ready: 3 ldap_ndelay_off: 3 TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 1, err: 19, subject: /C=US/ST=California/O=yyyy/OU=yyyy/CN=vcheung-181.lab.xxxx.net, issuer: /C=US/ST=California/O=yyyy/OU=yyyy/CN=vcheung-181.lab.xxxx.net TLS certificate verification: Error, self signed certificate in certificate chain TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS: can't connect. ldap_perror ldap_bind: Can't contact LDAP server (-1) Is there some other directive in ldap.conf file which points to this file ( > I thought only 3 valid directives are present > TLS_CACERTDIR,TLS_CACERT,TLS_REQCERT). There were other directives TLS_CERT > - but these point to the client certificate. > Thanks Sirisha.

3 4

Write through an LDAP Proxy?
by Christoph Berkemeier 10 Jun '10

10 Jun '10

Greetings, i would like to use multiple OpenLDAP Server with Samba. As Samba uses only one database server, i considered it would be suitable to use a ldap proxy in front of my master and my slaves servers. I tried it with the proxycache overlay, but after some testing and combing the internet for information it seems this does not work for write-request. Is this information correct? And if it is, are there some alternatives? Best Regards, Christoph Berkemeier

5 9

pam_ldap doesn't bind SIMPLE for anonymous auth?
by Jo Rhett 10 Jun '10

10 Jun '10

I'm seeing a problem where I can authenticate as a user using the ldap tools (ie ldapsearch) but I am unable to login using PAM. Comparing debug on the server shows that ldapsearch is doing a new BIND, where's PAM is not: Jun 4 14:58:52 ldap-server slapd[5158]: => dn: [1] Jun 4 14:58:52 ldap-server slapd[5158]: => acl_get: [2] attr userPassword Jun 4 14:58:52 ldap-server slapd[5158]: access_allowed: no res from state (userPassword) Jun 4 14:58:52 ldap-server slapd[5158]: => acl_mask: access to entry "uid=jrhett,ou=Users,dc=equinix,dc=com", attr "userPassword" requested Jun 4 14:58:52 ldap-server slapd[5158]: => acl_mask: to value by "", (=0) Jun 4 14:58:52 ldap-server slapd[5158]: <= check a_dn_pat: anonymous Jun 4 14:58:52 ldap-server slapd[5158]: <= acl_mask: [1] applying auth(=xd) (stop) Jun 4 14:58:52 ldap-server slapd[5158]: <= acl_mask: [1] mask: auth(=xd) Jun 4 14:58:52 ldap-server slapd[5158]: => access_allowed: auth access granted by auth(=xd) Jun 4 14:58:52 ldap-server slapd[5158]: send_ldap_result: conn=75 op=2 p=3 Jun 4 14:58:52 ldap-server slapd[5158]: send_ldap_result: err=49 matched="" text="" Jun 4 14:58:52 ldap-server slapd[5158]: send_ldap_response: msgid=3 tag=97 err=49 Jun 4 14:58:52 ldap-server slapd[5158]: conn=75 op=2 RESULT tag=97 err=49 text= Now ldapsearch has identical debug output down until just below the access_allowed line. Jun 4 15:02:54 ldap-server slapd[5158]: => acl_get: [2] attr userPassword Jun 4 15:02:54 ldap-server slapd[5158]: access_allowed: no res from state (userPassword) Jun 4 15:02:54 ldap-server slapd[5158]: => acl_mask: access to entry "uid=jrhett,ou=Users,dc=equinix,dc=com", attr "userPassword" requested Jun 4 15:02:54 ldap-server slapd[5158]: => acl_mask: to value by "", (=0) Jun 4 15:02:54 ldap-server slapd[5158]: <= check a_dn_pat: anonymous Jun 4 15:02:54 ldap-server slapd[5158]: <= acl_mask: [1] applying auth(=xd) (stop) Jun 4 15:02:54 ldap-server slapd[5158]: <= acl_mask: [1] mask: auth(=xd) Jun 4 15:02:54 ldap-server slapd[5158]: => access_allowed: auth access granted by auth(=xd) Jun 4 15:02:54 ldap-server slapd[5158]: conn=83 op=0 BIND dn="uid=jrhett,ou=Users,dc=equinix,dc=com" mech=SIMPLE ssf=0 Jun 4 15:02:54 ldap-server slapd[5158]: do_bind: v3 bind: "uid=jrhett,ou=Users,dc=equinix,dc=com" to "uid=jrhett,ou=Users,dc=equinix,dc=com" Jun 4 15:02:54 ldap-server slapd[5158]: send_ldap_result: conn=83 op=0 p=3 Jun 4 15:02:54 ldap-server slapd[5158]: send_ldap_result: err=0 matched="" text="" Jun 4 15:02:54 ldap-server slapd[5158]: send_ldap_response: msgid=1 tag=97 err=0 Jun 4 15:02:54 ldap-server slapd[5158]: conn=83 op=0 RESULT tag=97 err=0 text= Jun 4 15:02:54 ldap-server slapd[5158]: daemon: activity on 1 descriptor Jun 4 15:02:54 ldap-server slapd[5158]: daemon: activity on: Can someone give me a clue what's going wrong here? The key to this problem is that I'm trying to avoid putting system logins, rootbinddns on each server, and just do anonymous bind's for authentication. No configuration file on this client has a valid Manager or any other authentication password, and I'm trying to keep it that way. In theory, this should work ;-) I mean, ldapsearch works fine ... -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

4 5

Tool to covert from LDIF cn=config to slapd.conf?
by Nick Urbanik 09 Jun '10

09 Jun '10

Dear Folks, It is nice that the tools convert from slapd.conf to the LDIF configuration. Is there a tool that converts the other way round? I could write one, but I'd rather use an existing wheel if there is one. -- Nick Urbanik http://nicku.org 808-71011 nick.urbanik(a)optusnet.com.au GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24 I disclaim, therefore I am.

2 1

Re: ldapsearch -w "password" only check first 8 words ?
by Zdenek Styblik 09 Jun '10

09 Jun '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/09/10 07:23, shyuejyh.tw wrote: > yes , i use crypt to hash my password .. > so .. the problem is crypt just hash first 8 words , right ? > > and i just need change another hash function like md5 ? > > thanks a lot for your help :-) > > Yep, that's correct. Zdenek - -- Zdenek Styblik Net/Linux admin OS TurnovFree.net email: stybla(a)turnovfree.net jabber: stybla(a)jabber.turnovfree.net > --- 10/6/9 (三)，Zdenek Styblik <stybla(a)turnovfree.net> 寫道： > > > 寄件者: Zdenek Styblik <stybla(a)turnovfree.net> > 主旨: Re: ldapsearch -w "password" only check first 8 words ? > 收件者: "shyuejyh.tw" <shyuejyh.tw(a)yahoo.com.tw> > 日期: 2010年6月9日,三,下午1:05 > > > On 06/09/10 03:50, shyuejyh.tw wrote: >> Hi Everyone: >> i have a question , how can i change ldapsearch command to check password more than 8 words? > >> my openldap is 2.4.11 (Debian/Lenny) > >> when i use freeradius 2.0.4 to authentication a account, >> my password is 12345678 , than i type 123456789 , Pass ..... > >> this is radius's log: >> rlm_ldap: login attempt by "amo" with password "123456789" >> rlm_ldap: user DN: uid=amo,dc=hello,dc=com >> rlm_ldap: (re)connect to 127.0.0.1:389, authentication 1 >> rlm_ldap: bind as uid=amo,dc=hello,dc=com/123456789 >> rlm_ldap: waiting for bind result ... >> rlm_ldap: Bind was successful >> rlm_ldap: user amo authenticated succesfully >> ++[ldap] returns ok > > >> than i try use ldapsearch search a user (still use password 123456789) > >> ldapsearch -x -b "dc=hello,dc=com" -D "uid=amo,dc=hello,dc=com" -W -h localhost -LLL uid=jojo >> Enter LDAP Password: >> pass than find user information. > >> dn: uid=jojo,dc=hello,dc=com >> shadowLastChange: 123123 >> loginShell: /bin/csh >> gidNumber: 102 >> homeDirectory: /home/jojo >> uidNumber: 1002 > >> i guess ldapsearch command just check first 8 words, is this a bug or change something can fix it ? > >> thanks a lot > > > > > hello, > > isn't it because you're using CRYPT for password hash? > > Regards, > Zdenek > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwPJwoACgkQ8MreUbSH7ikPsgCgsvEjTOnwflV9Y4MkxuAJgAeN l5kAoMOWTUhLWGP6kY26LA2zvZ4zeLkN =nH2z -----END PGP SIGNATURE-----

1 0

could not config n-way multi-master because insufficient access
by owen nirvana 09 Jun '10

09 Jun '10

my env is Debian squeeze, OpenLDAP 2.4.17( from packages.debian.org) I create an OpenLDAP Server, and try to config N-Wat multi-master, according to OpenLDAP Admin Guide. i adding init.ldif file on the server , the following is the content *dn: cn=config objectClass: olcGlobal cn: config olcServerID: 1 dn: olcDatabase={0}config,cn=config* * objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW: secret* and I get error --- "insufficient access" , even if I set "acess to * by * write" in slapd.conf actually, I don't understand what the guide said. ''''''''''''' This sets up the config database: * dn: cn=config objectClass: olcGlobal cn: config olcServerID: 1 dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW: secret* '''''''''''''''''''''''''''' the above configuration block could not be import in my computer, it is said at the begin. '''''''''''''''''''''''''''' Now we setup the first Master Node (replace $URI1, $URI2 and $URI3 etc. with your actual ldap urls): * dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 $URI1 olcServerID: 2 $URI2 olcServerID: 3 $URI3 dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=$URI1 binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=002 provider=$URI2 binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=003 provider=$URI3 binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 - add: olcMirrorMode olcMirrorMode: TRUE* '''''''''''''''''''''''''''' the configuration block seems conflict with the former, why should I write "olcServerID: 1 $URI1" into LDAP Server if "olcServerID: 1" is right, and why should I not write an entire configuration, but two configuration file which seems conflict separately. I have set up an unlimit previledge, why LDAP Server report "insufficient access". what previledge should be set. thanks for help gtalk:freeespeech@gmail.com <gtalk%3Afreeespeech(a)gmail.com>

2 2

ldapsearch -w "password" only check first 8 words ?
by shyuejyh.tw 09 Jun '10

09 Jun '10

Hi Everyone: i have a question , how can i change ldapsearch command to check password more than 8 words? my openldap is 2.4.11 (Debian/Lenny) when i use freeradius 2.0.4 to authentication a account, my password is 12345678 , than i type 123456789 , Pass ..... this is radius's log: rlm_ldap: login attempt by "amo" with password "123456789" rlm_ldap: user DN: uid=amo,dc=hello,dc=com rlm_ldap: (re)connect to 127.0.0.1:389, authentication 1 rlm_ldap: bind as uid=amo,dc=hello,dc=com/123456789 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful rlm_ldap: user amo authenticated succesfully ++[ldap] returns ok than i try use ldapsearch search a user (still use password 123456789) ldapsearch -x -b "dc=hello,dc=com" -D "uid=amo,dc=hello,dc=com" -W -h localhost -LLL uid=jojo Enter LDAP Password: pass than find user information. dn: uid=jojo,dc=hello,dc=com shadowLastChange: 123123 loginShell: /bin/csh gidNumber: 102 homeDirectory: /home/jojo uidNumber: 1002 i guess ldapsearch command just check first 8 words, is this a bug or change something can fix it ? thanks a lot

2 1

Can't add attribute (error 65)
by Dan OReilly 09 Jun '10

09 Jun '10

Using the following slapd configuration, I can't add an attribute value to an existing user: # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/ppolicy.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args TLSCipherSuite HIGH:MEDIUM TLSCertificateFile /usr/local/etc/openldap/slapd-cert.pem TLSCertificateKeyFile /usr/local/etc/openldap/slapd-key.pem access to attrs=userPassword by * auth access to * by * read ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "dc=psccos,dc=com" rootdn "cn=Manager,dc=psccos,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 xxxxxxxx # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /usr/local/var/openldap-data # Indices to maintain index objectClass eq Below you can see the ldapmodify command that fails, and below that, the file that contains the modifications: $ sudo ldapmodify -w cowabunga -D "cn=Manager,dc=psccos,dc=com" -f /home/oreilly/mod.ldif modifying entry "cn=Renee Walker,ou=people,dc=psccos,dc=com" ldap_modify: Object class violation (65) additional info: attribute 'pwdInHistory' not allowed $ cat /home/oreilly/mod.ldif dn: cn=Renee Walker,ou=people,dc=psccos,dc=com changetype: modify add: pwdInHistory pwdInHistory: 6 $ Any idea why this behavior occurs? ------ +-------------------------------+----------------------------------------+ | Dan O'Reilly | "There are 10 types of people in this | | Principal Engineer | world: those who understand binary | | Process Software | and those who don't." | | http://www.process.com | | +-------------------------------+----------------------------------------+

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical