openldap-technical

openldap-technical@openldap.org

4 participants
9898 discussions

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

28 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

Jim Vanes
by Jim Vanes 26 Feb '13

26 Feb '13

   http://www.locksmithsbethnalgreen.com/va/bm9wtj55qrblk7e27s4pn.gs39g?assmdd…   Jim Vanes2/26/2013 6:23:42 PM

1 0

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

26 Feb '13

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? Thanks, Francesco Policastro

1 0

slapd, SASL passthrough and changing passwords smashing userPassword
by Tim Watts 25 Feb '13

25 Feb '13

Hi folks, I hope this is a quick and easy one :) I have slapd 2.4.23 working with passthrough to MIT kerberos via saslauthd. I use smbkrb5pwd (a hack on smbk5pwd) to pass password changes through to kerberos (creating or modifying the target principle as required) To enable a particular user to bind to slapd with their kerberos password, I'm setting: userPassword: {SASL}myuid(a)MY.KERBEROS.REALM.EXAMPLE.COM This works *very nicely*. Except one thing... Using passwd via pam_ldap or ldappasswd directly smashes userPassword: and replaces the value with the password hash. Both machanisms are doing EXOP password changes. Is there any way to stop this happening when the mechanism in userPassword is {SASL} ? Or maybe there is another way to enable global SASL password passthroughs? ====== I'm in a transition phase. I need to import the slapcat output from the old LDAP server to my new one. At this point, all authentication should be done with the existing userPassword hash. Password changes should update this hash and create/modify principles on the kerberos server. 3 months later, I want to switch the auth mechanism on all accounts to passthrough to kerberos, at which point, ldappasswd should still work but via smbkrb5pwd updating kerberos. Maybe my strategy is wrong, but that's the basic problem I need to solve. Am I trying this the wrong way? Cheers and thanks in advance for any ideas. Tim -- Tim Watts Personal Blog: http://www.dionic.net/tim/ "She got her looks from her father. He's a plastic surgeon."

3 4

Access permissions to add new entries
by Philip Colmer 25 Feb '13

25 Feb '13

Hi I wanted to run a scenario past everyone to see if there is a better approach to the one I am thinking of implementing. The OU structure we have is: +- dc=example,dc=com +-- ou=accounts +--- ou=subsidiary1 +--- ou=subsidiary2 +--- ou=special +--- ou=staff +--- ou=the-rest I have two groups defined - one group needs to be able to create new entries under the staff OU, and the other group needs to be able to create new entries under the OUs subsidiary1, subsidiary2 and the-rest. Nobody (except for LDAP admin) should be able to create entries under OU special. More specifically, I want group members to be able to *add* new entries but modification and deletion of entries should only be done by the LDAP admin. I *may* want to allow group members to modify entries in the future but certainly just add for now. A couple of notes about subsidiary1/subsidiary2: * they aren't really called that :-) * more will get added over time, with corresponding changes in permissions required. In other words, I can't use a regex to match against "subsidiary", but I want an ACL implementation that, if possible, can cope with future OUs being created without modifying the ACLs. So, my thinking is: 1. Have an ACL that blocks write access to "special". 2. Have an ACL that grants write access to "staff" for members of the staff account managers group. 3. Have one ACL that grants write access to all other OUs for members of the non-staff account managers group. If that makes sense ... access to dn.exact="ou=special,ou=accounts,dc=example,dc=com" attrs=children by * none access to dn.exact="ou=staff,ou=accounts,dc=example,dc=com" attrs=children by group="cn=account-mgrs-staff,ou=mailing,ou=groups,dc=example,dc=com" add by * none access to dn.sub="ou=staff,ou=accounts,dc=example,dc=com" attrs=entry by group="cn=account-mgrs-staff,ou=mailing,ou=groups,dc=example,dc=com" add by * none How do I do the rules for the other OUs? Can I have just two rules? One to allow access to the children attribute and one to allow access to the entry attribute? If so, it would need to be on the OUs *beneath* ou=accounts so that members of the group cannot create entries within ou=accounts. So would this work? access to dn.one="ou=accounts,dc=example,dc=com" attrs=children by group="cn=account-mgrs-non-staff,ou=mailing,ou=groups,dc=example,dc=com" add by * none access to dn.sub="ou=accounts,dc=example,dc=com" attrs=entry by group="cn=account-mgrs-non-staff,ou=mailing,ou=groups,dc=example,dc=com" add by * none I'm not sure if members of account-mgrs-non-staff would be blocked from adding to ou=staff ... Suggestions or help appreciated. Regards Philip

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