openldap-technical

openldap-technical@openldap.org

21 participants
9802 discussions

Is there any way to change structuralObjectClass of an LDAP entry?
by Marco Pizzoli 28 Feb '13

28 Feb '13

Hi all, yes, I already know this is not possible. But I have a particular scenario and maybe someone could give advice. In an LDAP tree I inherited some times ago, I have entries created many years ago by using a schema definition which implied an entry to acquire as structuralObjectClass a custom objectClass. This custom objectClass (let's say it's called custObjectClass) inherits from inetOrgPerson and mandates some specific attributes. Now, all entries are created expliciting the following objectClasses: - top - person - organizationalPerson - inetOrgPerson - custObjectClass The outcome is these entries have custObjectClass as structuralObjectClass. Now, I would like to make some cleaning on this tree, and I would like to change some schema definition on objects. First of all, I would like to NOT have custObjectClass as structuralObjectClass. Obviously I could slapcat my slapd engine, change the ldif and then re-import as new. But I would prefer to not switch off my slapd engine in the meantime. I can't afford that, to be honest... One idea I had was to create a replica consumer, change on it the schema definition (custObjectClass inheriting from TOP and being auxiliary instead of structural), and let the replication create the entries with the correct "structurality". I self-discovered this way is not viable, considering OL refuses to insert an entry with source structuralObjectClass not being defined structural on the slave as well. Now I'm asking for help to the community. Any hint welcome. How would you do? Thanks in advance Marco

2 1

additional info: objectClasses: value #0 invalid per syntax
by Jimmy Royer 28 Feb '13

28 Feb '13

Hello, I am starting out with openldap and I don't know it that much. I got the error mentioned in the title when trying to add an object class, which is apparently a very common one per my google searches. I've read that common causes are: * extraneous white space (especially trailing white space) * improperly encoded characters (LDAPv3 uses UTF-8 encoded Unicode) * empty values (few syntaxes allow empty values) This is the object class file I am trying to add, I picked it as an example on some website, to have something minimal and make it easier to test: # cat exObjectClasses.ldif dn: cn=schema changetype: modify add: objectClasses objectClasses: ( 2.16.840.1.113730.3.2.2.9 NAME 'blogger' DESC 'Someone who has a blog' SUP inetOrgPerson STRUCTURAL MAY blog ) I've checked if there was any trailing spaces at the end with the following: # cat -vte exObjectClasses.ldif dn: cn=schema$ changetype: modify$ add: objectClasses$ objectClasses: ( 2.16.840.1.113730.3.2.2.9$ NAME 'blogger'$ DESC 'Someone who has a blog'$ SUP inetOrgPerson STRUCTURAL$ MAY blog )$ I've made sure the file is UTF-8: # iconv -f ASCII -t UTF-8 exObjectClasses.ldif > exObjectClasses.ldif.utf8 And I don't think there are any empty values defined in the LDIF file. So when I type this command, I still have the "invalid per syntax error: # ldapmodify -x -W -H "ldaps://127.0.0.1" -D cn=Manager,dc=modelsolv,dc=com -f exObjectClasses.ldif Enter LDAP Password: modifying entry "cn=schema" ldap_modify: Invalid syntax (21) additional info: objectClasses: value #0 invalid per syntax This is the content of the /etc/openldap/slapd.conf file: # cat slapd.conf # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/corba.schema include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/duaconf.schema include /etc/openldap/schema/dyngroup.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/java.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/collective.schema # Allow LDAPv2 client connections. This is NOT the default. allow bind_v2 # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args # Load dynamic backend modules # - modulepath is architecture dependent value (32/64-bit system) # - back_sql.la overlay requires openldap-server-sql package # - dyngroup.la and dynlist.la cannot be used at the same time # modulepath /usr/lib/openldap # modulepath /usr/lib64/openldap # moduleload accesslog.la # moduleload auditlog.la # moduleload back_sql.la # moduleload chain.la # moduleload collect.la # moduleload constraint.la # moduleload dds.la # moduleload deref.la # moduleload dyngroup.la # moduleload dynlist.la # moduleload memberof.la # moduleload pbind.la # moduleload pcache.la # moduleload ppolicy.la # moduleload refint.la # moduleload retcode.la # moduleload rwm.la # moduleload seqmod.la # moduleload smbk5pwd.la # moduleload sssvlv.la # moduleload syncprov.la # moduleload translucent.la # moduleload unique.la # moduleload valsort.la # The next three lines allow use of TLS for encrypting connections using a # dummy test certificate which you can generate by running # /usr/libexec/openldap/generate-server-cert.sh. Your client software may balk # at self-signed certificates, however. TLSCACertificatePath /etc/openldap/certs TLSCertificateFile "\"OpenLDAP Server\"" TLSCertificateKeyFile /etc/openldap/certs/password # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! # enable on-the-fly configuration (cn=config) database config access to * by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * none # enable server status monitoring (cn=monitor) database monitor access to * by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read by dn.exact="cn=Manager,dc=my-domain,dc=com" read by * none ####################################################################### # database definitions ####################################################################### database bdb suffix "dc=modelsolv,dc=com" checkpoint 1024 15 rootdn "cn=Manager,dc=modelsolv,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw SECRET # rootpw {crypt}ijFYNcSNctBYg # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap # Indices to maintain for this database index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub # Replicas of this database #replogfile /var/lib/ldap/openldap-master-replog #replica host=ldap-1.example.com:389 starttls=critical # bindmethod=sasl saslmech=GSSAPI # authcId=host/ldap-master.example.com(a)EXAMPLE.COM I was able to add a few entries in LDAP so far. So I know I am able to reach the server, the connection is fine, and LDAP is somewhat functional. But I can't modify the schema with objectclasses. Is there anything obvious that I am doing wrong? Do you have any recommendation for debugging further? Regards, Jimmy Royer

4 4

Limit on number of attrs in replica conf?
by Marco Pizzoli 28 Feb '13

28 Feb '13

Hi all, Is it possible I discovered a limit on the number of attributes I can specify on the "attrs" parameter of the replica directive in slapd.conf? In my config file, for the replica directive, I explicited a long list of attributes. On the provider side I can see, on the provider slapd logs, that only 8 of the attrs I specified on the replica directive are actually asked. Plus objectClass, structuralObjectClass and entryCSN. Is that the expected behaviour? I already checked on the man page and I don't see this limitation explicited Thanks in advance Marco

1 1

internal_modify in overlays
by Tim Watts 28 Feb '13

28 Feb '13

Hi, Does anyone know of a bit of code I can look at that does an *internal* (completed inline) LDAP_MOD_REPLACE operation on one attribute without chaining (ie it does a return 0)? I've found Sun docs for doing this in a slapi plugin but not an openldap slapd plugin. Reason: Basically, I've been hacking on smbkrb5pwd.c and discovered if I do a "return 0;" at the end, I can prevent chaining (not documented but found some openldap hacking - denyop.c - that demonstrated this). At this point, smbkrb5pwd.c has changed our MIT Kerberos principal's password, and "return 0" prevenrs_modsts slapd from chaining onto the code that tries to set a local hash into userPassword. And it does it without causing a nasty client error. I thought: would it not be nice to set userPassword: to {SASL}UID(a)KERB.REALM now... Each user's auth method gets switched upon the first successful password change that propagates to kerberos. However, all the existing overlays seem to set extra attributes by setting up a request in ->rs_mods off the original request. I assume these get actioned after a "return SLAP_CB_CONTINUE". So - how do set an attribute if we are halting the chain at our overlay? Cheers :) Tim -- Tim Watts Personal Blog: http://squiddy.blog.dionic.net/ http://www.sensorly.com/ Crowd mapping of 2G/3G/4G mobile signal coverage

2 2

Re: meta backend subtree directive ignored by conversion to cn=config
by francesco.policastro＠selex-es.com 27 Feb '13

27 Feb '13

I see. So I need to look at ACL, because my real meta configuration contains two trees coming from different forests, sharing nothing. It's the result of a merge of two companies, each with its AD, and I use OpenLDAP to authenticate users against a single meta domain, after a long job to rename many users who just shared the only object I did not want, i.e. the sAMAccountNname. Thanks, Francesco

1 0

Re: meta backend subtree directive ignored by conversion to cn=config
by Pierangelo Masarati 27 Feb '13

27 Feb '13

> Sorry! > I mistyped the uri where the user is found (this happens because I saw > this behaviour on the real configuration and I had to massage it). > The search command, issued from the openldap server itself, is: > > ldapsearch -xLLL -H ldap:/// -D ""cn=LdapBindUser,dc=newco,dc=com" -w > secret1 -E pr=647/noprompt -b 'DC=newco,DC=com' 'sn=policastro' dn > > I find two records, one correct and one unexpected: > > dn: cn=Policastro > Francesco,ou=Users,ou=2nd-location,dc=first,dc=newco,dc=com" (matches the > line marked with *) > > dn: cn=Policastro Francesco,ou=UsersDisable,dc=second,dc=newco,dc=com OK, I got the point. You're probably misusing this feature. If you want to prevent a portion of the subtree from being returned, you need to use ACL. The subtree-{in|ex}clude is only used during candidate selection. This means that it is used while deciding whether or not an operation must be propagated to a specific target. For example, let's say that target #1 is rooted at "ou=Sub 1,dc=org", and target #2 is rooted at "dc=org", and it is known that target #2 does not contain a subtree named "ou=Sub 1,dc=org", adding subtree-exclude "ou=Sub 1,dc=org" to target #2 prevents searches whose searchBase is (a subordinate of) "ou=Sub 1,dc=org" to span target #2 in addition to target #1. p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

Re: meta backend subtree directive ignored by conversion to cn=config
by francesco.policastro＠selex-es.com 27 Feb '13

27 Feb '13

Sorry! I mistyped the uri where the user is found (this happens because I saw this behaviour on the real configuration and I had to massage it). The search command, issued from the openldap server itself, is: ldapsearch -xLLL -H ldap:/// -D ""cn=LdapBindUser,dc=newco,dc=com" -w secret1 -E pr=647/noprompt -b 'DC=newco,DC=com' 'sn=policastro' dn I find two records, one correct and one unexpected: dn: cn=Policastro Francesco,ou=Users,ou=2nd-location,dc=first,dc=newco,dc=com" (matches the line marked with *) dn: cn=Policastro Francesco,ou=UsersDisable,dc=second,dc=newco,dc=com Francesco Policastro From: Pierangelo Masarati <masarati(a)aero.polimi.it> To: <openldap-technical(a)openldap.org> Date: 27/02/2013 10:36 Subject: Re: meta backend subtree directive ignored by conversion to cn=config Sent by: <openldap-technical-bounces(a)OpenLDAP.org> On 02/26/2013 02:19 PM, francesco.policastro(a)selex-es.com wrote: > Even worse: if I start the server using slapd.conf, not cn=config, the > subtree-include directives seem to be ignored. > With reference to the previously attached file if I search users from the > root ( "dc=newco,dc=com") I find them also outside the included subtrees; > e.g I find users under "ou=UsersDisable, > ou=Users,ou=2nd-location,dc=first,dc=newco,dc=com". > Is it there anything wrong in my config file? Did I misunderstand the > directive? According to your configuration file, whose relevant directives I summarized below, the entry "ou=UsersDisable,ou=Users,ou=2nd-location,dc=first,dc=newco,dc=com" matches the 3rd subtree-include of the 1st target (marked with [*]). So it seems to behave as intended. p. ----- database meta suffix "dc=newco,dc=com" ... uri "ldap://server1.it.domain1.com/dc=first,dc=newco,dc=com" ... subtree-include "ou=Applications,ou=Groups Shared,dc=first,dc=newco,dc=com" subtree-include "ou=Users,ou=1st-location,dc=first,dc=newco,dc=com" subtree-include "ou=Users,ou=2nd-location,dc=first,dc=newco,dc=com" [*] subtree-include "ou=Users,ou=3rd-location,dc=first,dc=newco,dc=com" ... uri "ldap://server2.domain2.net/ou=organizationalUnit,dc=second,dc=newco,dc=com" ... subtree-include "ou=Users,ou=1st-location,ou=organizationalUnit,dc=second,dc=newco,dc=com" subtree-include "ou=My-ou,ou=1st-location,ou=organizationalUnit,dc=second,dc=newco,dc=com" subtree-include "ou=Remote Sites,ou=organizationalUnit,dc=second,dc=newco,dc=com" -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

N-Way Multimaster with syncrepl and delta-repl -- slapd stops responding
by Robert W. Smith 27 Feb '13

27 Feb '13

Hi, I am running a 4-way multi-master configuration with a number of slaves in remote locations. I am currently running openldap 2.4.33 on top of CentOS 6.3 (I built 2.4.33 from a modified base centos 6 spec file). I was originally running the centos base openldap 2.4.23 using N-way multimaster using the syncrepl configuration but I was having problems with the masters and slaves staying in perfect sync--other than this 2.4.23 was running stably since last spring. I'll try to be brief in what has happened since Feb 1. * I upgraded the 4 masters to 2.4.33 and kept the syncrepl configuration. The syncrepl masters were using RefreshAndPersist while the slave consumers were using RefreshOnly. * After the upgrade the 2.4.33 masters began locking up, not refusing connections, but not returning queries--this would happen 3-4 per day. When one master locked all the masters would lock. Slaves appear to not be affected by this. * I downgraded back 2.4.23 in all of the masters only to have the lock-ups continue. * I slapcat'ed the database on one master and blew away the databases on all the other masters and slaves and rebuilt everything. I rebuilt one master and one slave and rsync'ed the slapd.d directory where needed. Then I started each master one-by-one to validate that they mirrored the databases correctly. Then I repeated this on the slaves. Unfortunately the masters would continue to lock up as above. * So, seeing that the lock-ups were occurring regardless of the openldap version I decided to go back to 2.4.33 and make the move to delta-replication. * This past weekend I finally got delta-replication working. I did the slapcat-rebuild slapd.d-slapadd on one master and rsync'ed slapd.d to each master one at a time. All was well and all databases were in perfect sync. * Unfortunately the masters would continue to lock, accepting connections but never servicing the request so all queries would hang. Looking at this again today I noticed that my masters were all running at near 100% CPU but continuing to service queries. Depending on the # of CPUs only one or two threads would be running this high. Using strace -tt -p <pid-ofthread>, this is what would be spewing out: 18:52:05.713266 sched_yield() = 0 18:52:05.713323 sched_yield() = 0 18:52:05.713380 sched_yield() = 0 18:52:05.713438 sched_yield() = 0 18:52:05.713495 sched_yield() = 0 18:52:05.713553 sched_yield() = 0 18:52:05.713611 sched_yield() = 0 18:52:05.713668 sched_yield() = 0 18:52:05.713726 sched_yield() = 0 18:52:05.713783 sched_yield() = 0 18:52:05.713840 sched_yield() = 0 18:52:05.713898 sched_yield() = 0 I haven't correlated this to the slapd daemons hanging, yet. There is nothing interesting in the logs when the slapd daemons would hang. Again when one master hangs they all would hang. I would restart each master one by one and on occasions when one master restarted the others would start servicing again. Other times it would take two or three restarts to get all of the masters servicing again. The only gain with delta-replication is that they only hang once a day now and usually after I had gone home. For now I have implemented a small script that is run from cron every two minutes to test the slapd daemons if they are hung doing a simple ldapsearch and if so then restart the slapd daemon. This is done on all four masters. My database is not large at all with only ~100 users but it is critical as it is the backend authentication for everything including the remote access. Here is the slapcat of my cn=config database (minus the schemas and operational attributes). It is a fairly typical delta-replication configuration. The accesslogs use hdb as that is what most (all) of the accesslogs examples show. The main database is bdb. Any suggestions would be greatly appreciated. Regards, Bob --bs dn: cn=config objectClass: olcGlobal cn: config olcConfigFile: slapd.conf olcConfigDir: slapd.d olcArgsFile: /var/run/openldap/slapd.args olcAttributeOptions: lang- olcAuthzPolicy: none olcConcurrency: 0 olcConnMaxPendingAuth: 1000 olcGentleHUP: FALSE olcIdleTimeout: 0 olcIndexSubstrIfMaxLen: 4 olcIndexSubstrIfMinLen: 2 olcIndexSubstrAnyLen: 4 olcIndexSubstrAnyStep: 2 olcIndexIntLen: 4 olcLocalSSF: 71 olcPidFile: /var/run/openldap/slapd.pid olcReadOnly: FALSE olcSaslSecProps: noplain,noanonymous olcSecurity: tls=1 olcServerID: 1 ldap://auth1noc.man.o3b.local olcServerID: 2 ldap://auth2noc.man.o3b.local olcServerID: 3 ldap://auth1noc.btz.o3b.local olcServerID: 4 ldap://auth2noc.btz.o3b.local olcServerID: 5 ldap://auth1gw.nma.o3b.local olcServerID: 6 ldap://auth2gw.nma.o3b.local olcServerID: 7 ldap://auth1gw.sun.o3b.local olcServerID: 8 ldap://auth2gw.sun.o3b.local olcServerID: 9 ldap://auth1gw.per.o3b.local olcServerID: 10 ldap://auth2gw.per.o3b.local olcSockbufMaxIncoming: 262143 olcSockbufMaxIncomingAuth: 16777215 olcThreads: 16 olcTLSCipherSuite: HIGH:MEDIUM:SSLv2 olcTLSCertificateFile: /etc/openldap/cacerts/auth-o3b.crt olcTLSCertificateKeyFile: /etc/openldap/cacerts/auth-o3b.key olcTLSCRLCheck: none olcToolThreads: 1 olcWriteTimeout: 0 olcTLSCACertificateFile: /etc/pki/tls/certs/o3b-master-ca.crt olcTLSVerifyClient: never olcLogLevel: sync olcConnMaxPending: 101 dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib64/openldap olcModuleLoad: {0}syncprov.la olcModuleLoad: {1}memberof.la olcModuleLoad: {2}ppolicy.la olcModuleLoad: {3}accesslog.la dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: {0}to dn.base="" by * read olcAccess: {1}to dn.subtree="cn=monitor" by dn.base="cn=rootdn,dc=o3bnetworks .net" read olcAccess: {2}to dn.base="cn=subschema" by * read olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 0 olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSecurity: tls=1 olcMonitoring: FALSE olcPasswordHash: {SSHA} dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by dn.base="cn=rootdn,dc=o3bnetworks.net" write by dn.bas e="cn=syncdn,dc=o3bnetworks.net" read by * none olcAddContentAcl: TRUE olcLastMod: TRUE olcLimits: {0}dn.base="cn=rootdn,dc=o3bnetworks.net" size=unlimited time=unli mited olcLimits: {1}dn.base="cn=syncdn,dc=o3bnetworks.net" size=unlimited time=unli mited olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=config olcMirrorMode: TRUE olcMonitoring: FALSE olcRootPW:: *** olcSyncrepl: {0}rid=001 provider=ldap://auth1noc.man.o3b.local bindmethod=simp le binddn="cn=syncdn,dc=o3bnetworks.net" credentials="33jJ9nSkSD" keepalive=0 :5:0 starttls=yes tls_reqcert=allow tls_cipher_suite=HIGH:MEDIUM:SSLv2 search base="cn=config" scope=sub schemachecking=off type=refreshAndPersist retry="5 5 300 +" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)( reqResult=0))" syncdata=accesslog olcSyncrepl: {1}rid=002 provider=ldap://auth2noc.man.o3b.local bindmethod=simp le binddn="cn=syncdn,dc=o3bnetworks.net" credentials="33jJ9nSkSD" keepalive=0 :5:0 starttls=yes tls_reqcert=allow tls_cipher_suite=HIGH:MEDIUM:SSLv2 search base="cn=config" scope=sub schemachecking=off type=refreshAndPersist retry="5 5 300 +" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)( reqResult=0))" syncdata=accesslog olcSyncrepl: {2}rid=003 provider=ldap://auth1noc.btz.o3b.local bindmethod=simp le binddn="cn=syncdn,dc=o3bnetworks.net" credentials="33jJ9nSkSD" keepalive=0 :5:0 starttls=yes tls_reqcert=allow tls_cipher_suite=HIGH:MEDIUM:SSLv2 search base="cn=config" scope=sub schemachecking=off type=refreshAndPersist retry="5 5 300 +" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)( reqResult=0))" syncdata=accesslog olcSyncrepl: {3}rid=004 provider=ldap://auth2noc.btz.o3b.local bindmethod=simp le binddn="cn=syncdn,dc=o3bnetworks.net" credentials="33jJ9nSkSD" keepalive=0 :5:0 starttls=yes tls_reqcert=allow tls_cipher_suite=HIGH:MEDIUM:SSLv2 search base="cn=config" scope=sub schemachecking=off type=refreshAndPersist retry="5 5 300 +" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)( reqResult=0))" syncdata=accesslog dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {1}syncprov olcSpCheckpoint: 1000 60 dn: olcOverlay={1}accesslog,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: {1}accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogSuccess: TRUE olcAccessLogPurge: 2+00:00 1+00:00 dn: olcDatabase={1}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcConfig objectClass: top objectClass: olcHdbConfig olcDbDirectory: /var/lib/ldap/accesslog olcSuffix: cn=accesslog olcDbConfig: [Deleted] aXIgLXEgb3B0aW9uKS4g olcAddContentAcl: FALSE olcDbCacheFree: 1 olcDbCacheSize: 1000 olcAccess: {0}to * by self write by dn.base="cn=rootdn,dc=o3bnetworks.net" r ead by dn.base="cn=authdn,dc=o3bnetworks.net" read by dn.base="cn=syncdn,dc= o3bnetworks.net" read olcDbDirtyRead: FALSE olcDbIDLcacheSize: 0 olcDbDNcacheSize: 0 olcDbIndex: default eq olcMaxDerefDepth: 15 olcLimits: {0}dn.base="cn=syncdn,dc=o3bnetworks.net" size=unlimited time=unli mited olcDbSearchStack: 16 olcLastMod: TRUE olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbNoSync: FALSE olcDbShmKey: 0 olcReadOnly: FALSE olcSecurity: tls=1 olcRootDN: cn=accesslogdn olcDatabase: {1}hdb dn: olcOverlay={0}syncprov,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE dn: olcDatabase={3}monitor,cn=config objectClass: olcDatabaseConfig olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=monitor,cn=Monitor olcRootPW:: bW9uaXRvcg== olcSecurity: tls=1 olcMonitoring: FALSE olcDatabase: {3}monitor dn: olcDatabase={3}bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcSuffix: dc=o3bnetworks.net olcAddContentAcl: FALSE olcLastMod: TRUE olcLimits: {0}dn.base="cn=syncdn,dc=o3bnetworks.net" size=unlimited time=unli mited olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=rootdn,dc=o3bnetworks.net olcRootPW:: *** olcSecurity: tls=1 olcMirrorMode: TRUE olcMonitoring: TRUE olcDbDirectory: /var/lib/ldap olcDbConfig: [Deleted] olcDbNoSync: FALSE olcDbDirtyRead: FALSE olcDbIDLcacheSize: 0 olcDbIndex: objectClass pres,eq olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbIndex: uidNumber pres,eq olcDbIndex: gidNumber pres,eq olcDbIndex: memberUid pres,eq,sub olcDbIndex: displayName pres,eq,sub olcDbIndex: sambaSID pres,eq,sub olcDbIndex: sambaDomainName pres,eq olcDbIndex: sambaGroupType pres,eq olcDbIndex: ou pres,eq,sub olcDbIndex: sambaSIDList pres,eq olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbSearchStack: 16 olcDbShmKey: 0 olcDbCacheFree: 1 olcDbDNcacheSize: 0 olcAccess: {0}to * by self write by group/groupOfNames/member.exact="cn=ldap admins,dc=o3bnetworks.net" write by dn.base="cn=authdn,dc=o3bnetworks.net" r ead by dn.base="cn=syncdn,dc=o3bnetworks.net" read by users read by anonym ous read olcDbCacheSize: 1000 olcDatabase: {3}bdb olcSyncrepl: {0}rid=011 provider=ldap://auth1noc.man.o3b.local bindmethod=simp le binddn="cn=syncdn,dc=o3bnetworks.net" credentials="33jJ9nSkSD" keepalive=0 :5:0 starttls=yes tls_reqcert=allow tls_cipher_suite=HIGH:MEDIUM:SSLv2 search base="dc=o3bnetworks.net" scope=sub schemachecking=off type=refreshAndPersist retry="5 5 300 +" logbase="cn=accesslog" logfilter="(&(objectClass=auditWrit eObject)(reqResult=0))" syncdata=accesslog olcSyncrepl: {1}rid=012 provider=ldap://auth2noc.man.o3b.local bindmethod=simp le binddn="cn=syncdn,dc=o3bnetworks.net" credentials="33jJ9nSkSD" keepalive=0 :5:0 starttls=yes tls_reqcert=allow tls_cipher_suite=HIGH:MEDIUM:SSLv2 search base="dc=o3bnetworks.net" scope=sub schemachecking=off type=refreshAndPersist retry="5 5 300 +" logbase="cn=accesslog" logfilter="(&(objectClass=auditWrit eObject)(reqResult=0))" syncdata=accesslog olcSyncrepl: {2}rid=013 provider=ldap://auth1noc.btz.o3b.local bindmethod=simp le binddn="cn=syncdn,dc=o3bnetworks.net" credentials="33jJ9nSkSD" keepalive=0 :5:0 starttls=yes tls_reqcert=allow tls_cipher_suite=HIGH:MEDIUM:SSLv2 filter ="(objectclass=*)" searchbase="dc=o3bnetworks.net" scope=sub schemachecking=o ff type=refreshAndPersist retry="5 5 300 +" logbase="cn=accesslog" logfilter= "(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog olcSyncrepl: {3}rid=014 provider=ldap://auth2noc.btz.o3b.local bindmethod=simp le binddn="cn=syncdn,dc=o3bnetworks.net" credentials="33jJ9nSkSD" keepalive=0 :5:0 starttls=yes tls_reqcert=allow tls_cipher_suite=HIGH:MEDIUM:SSLv2 filter ="(objectclass=*)" searchbase="dc=o3bnetworks.net" scope=sub schemachecking=o ff type=refreshAndPersist retry="5 5 300 +" logbase="cn=accesslog" logfilter= "(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog dn: olcOverlay={0}memberof,olcDatabase={3}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcMemberOf olcOverlay: {0}memberof olcMemberOfDangling: ignore olcMemberOfRefInt: FALSE dn: olcOverlay={1}syncprov,olcDatabase={3}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {1}syncprov olcSpCheckpoint: 1000 60 dn: olcOverlay={2}ppolicy,olcDatabase={3}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top objectClass: olcPPolicyConfig olcOverlay: {2}ppolicy olcPPolicyDefault: cn=O3b,ou=Password,ou=Policy,dc=o3bnetworks.net dn: olcOverlay={3}accesslog,olcDatabase={3}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: {3}accesslog olcAccessLogOps: writes olcAccessLogSuccess: TRUE olcAccessLogDB: cn=accesslog olcAccessLogPurge: 2+00:00 1+00:00

3 5

slapo-rwm intercept and maasage an attribute?
by Tim Watts 27 Feb '13

27 Feb '13

Hi, Following on from SASL/EXOP password related issues, I'd like to try something. When an EXOP PASS MOD happens, I'd like to catch it before it updates userPassword: in the hdb backend and chance the data to {SASL}<uid>@FIXED.REALM.NAME I've been through the slapo-rwm man page several times and all over google and I'm more confused that I was to start with. Could anyone give me a hint please? 2 problems: What context does this update happen in? Is it a exopPasswdDN context or a modifyAttrDN context? Bearing in mind I want to catch where the Password Modify EXOP goes to write the userPassword entry. How do I pull the uid of the current bind doing the password change? I'm guessing it is a $ parameter defref, but I do not see any examples? Many thanks, Tim BTW, if there's a better mailing list for "user" questions I'll happily bugger off there :) -- Tim Watts Personal Blog: http://www.dionic.net/tim/ "It would be better to live under robber barons than under omnipotent moral busybodies."

3 4

Re: meta backend subtree directive ignored by conversion to cn=config
by Pierangelo Masarati 27 Feb '13

27 Feb '13

On 02/26/2013 02:19 PM, francesco.policastro(a)selex-es.com wrote: > Even worse: if I start the server using slapd.conf, not cn=config, the > subtree-include directives seem to be ignored. > With reference to the previously attached file if I search users from the > root ( "dc=newco,dc=com") I find them also outside the included subtrees; > e.g I find users under "ou=UsersDisable, > ou=Users,ou=2nd-location,dc=first,dc=newco,dc=com". > Is it there anything wrong in my config file? Did I misunderstand the > directive? According to your configuration file, whose relevant directives I summarized below, the entry "ou=UsersDisable,ou=Users,ou=2nd-location,dc=first,dc=newco,dc=com" matches the 3rd subtree-include of the 1st target (marked with [*]). So it seems to behave as intended. p. ----- database meta suffix "dc=newco,dc=com" ... uri "ldap://server1.it.domain1.com/dc=first,dc=newco,dc=com" ... subtree-include "ou=Applications,ou=Groups Shared,dc=first,dc=newco,dc=com" subtree-include "ou=Users,ou=1st-location,dc=first,dc=newco,dc=com" subtree-include "ou=Users,ou=2nd-location,dc=first,dc=newco,dc=com" [*] subtree-include "ou=Users,ou=3rd-location,dc=first,dc=newco,dc=com" ... uri "ldap://server2.domain2.net/ou=organizationalUnit,dc=second,dc=newco,dc=com" ... subtree-include "ou=Users,ou=1st-location,ou=organizationalUnit,dc=second,dc=newco,dc=com" subtree-include "ou=My-ou,ou=1st-location,ou=organizationalUnit,dc=second,dc=newco,dc=com" subtree-include "ou=Remote Sites,ou=organizationalUnit,dc=second,dc=newco,dc=com" -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical