openldap-technical

openldap-technical@openldap.org

20 participants
9802 discussions

Re: Phantom certificates?
by Andrew D. Arenson 07 May '14

07 May '14

On Wed, May 07, 2014 at 09:42:33AM +0200, Hallvard Breien Furuseth wrote: > On 05/06/2014 05:26 PM, Andrew D. Arenson wrote: > >(...) if I set > >TLS_CACERTDIR to /etc/openldap/certs, which has the cert8.db file, but > >as far as I can tell has no actuall certificates in that database, ldap > >search tells me, surprisingly, that the server's certificate _IS_ verified. > > > > How is openldap verifying my server's certificate? > > Maybe this is a variant of ITS#5582: Setting TLS_CACERT to any > certificate.pem file also tells OpenSSL to check the system's > standard installed certs. OpenLDAP should have a separate > option for that, or the opposite - an option not to do that. Thanks. I didn't find an option for turning on/off the use of a system's standard installed certs. Are you saying that you think something like that _does_ exist, or that you simply think it should? I tried moving my certs directory out of the default location of /etc/pki/tls, but was still unable able to generate a failure to verify the certificate when TLS_CACERTDIR was set to /etc/openldap/certs. Andy -- Andrew D. Arenson | aarenson (@) iu.edu Advanced Biomedical IT Core, Research Technologies, UITS | W (317) 278-1208 RT is a PTI Cyberinfrastructure & Service Center | C (317) 679-4669 Indiana University Purdue University Indianapolis | F (317) 278-1852

2 1

Re: LMDB integrity with MDB_NOSYNC on various filesystems
by Howard Chu 06 May '14

06 May '14

Dimitrios Apostolou wrote: > Hello, > > I'm reading in LMDB docs that MDB_NOSYNC will not allow database > corruption under certain conditions: > >> However, if the filesystem preserves write order and the MDB_WRITEMAP >> flag is not used, transactions exhibit ACI (atomicity, consistency, >> isolation) properties and only lose D (durability). I.e. database >> integrity is maintained, but a system crash may undo the final >> transactions > > > Do we know if these conditions are valid for modern filesystems like ext3, > ext4, XFS and how this is affected by various mount options (e.g. ordered, > writeback etc)? Read up on the specific filesystems you're interested in. These things change too frequently for us to track, and it's your responsibility to know what you're deploying. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

deploying password policy module
by Paul B. Henson 06 May '14

06 May '14

We are planning to deploy the password policy module to satisfy our security groups requirement for account lockouts (a.k.a., intentionally provided DoS attack vectors <sigh>). I had a couple of questions regarding the deployment I was hoping someone might be kind enough to answer. Does the password policy module need to be loaded on all of the servers simultaneously, even if there are no password policies defined? We typically stage configuration changes, pulling servers out of the load balancer, updating them, testing them, and then putting them back, such that at no time is service unavailable. The password policy module extends the schema though, and I don't want a server with it loaded potentially trying to replicate unknown attributes to one without it loaded. It's not clear whether simply loading the module would potentially cause this, or if password policy attributes would only be replicated if the module was actually configured with a default policy or if a user had a specifically defined policy. So, would it be safe to stage the initial configuration change loading the module as long as no policies are in place or used (until all of the servers have been updated), or is it required to shut down all of the servers simultaneously to make the change? We are only planning to avail of account lockouts, not any of the other functionality of the module. As such, unless I misunderstand, the following policy should enable lockouts but not apply any of the other restrictions: dn: cn=default,ou=policies,dc=example,dc=com cn: default objectClass: pwdPolicy pwdAttribute: userPassword pwdLockout: TRUE pwdLockoutDuration: 1800 pwdMaxFailure: 100 pwdFailureCountInterval: 300 This would be the default policy. We also have some number of service accounts which we would not want subject to lockouts, if I understand correctly, configuring those accounts with an explicit password policy pwdPolicySubentry like this: dn: cn=serviceaccount,ou=policies,dc=example,dc=com cn: default objectClass: pwdPolicy pwdAttribute: userPassword Should leave them with no restrictions? Finally, there is a requirement for the helpdesk to be able to manually unlock a locked out account. For an account that is currently locked out, would deleting the pwdAccountLockedTime and pwdFailureTime attributes reset it to a normal state? Thanks much.

3 15

Replication for small-bandwidth, mobile systems
by jan＠pki-labor.de 06 May '14

06 May '14

Hello all, we're challenged with a PKI scenario with multiple CAs (Certification Authorities) publishing into multiple directories. Each CA has its own distinct namespace (=DIT) and the directories shall be Muli-Master replicated. So far, I think this can be handled via syncrepl. Now I'm looking for a possibility to replicate (push) certain directory contents (e.g. revocation list updates from the CAs) to mobile systems which are connected via low bandwidth media (some kBPS like slow Modems, which also is already in use for other applications) and the connections are not always available (e.g. client out of radio reachability). As far as I understood several documents on syncrepl, it is not really useful on low bandwidth connections. This push service should therefore compress data or at least only transfer the differences. Is there a standardized protocol or other mechanism to accomplish that? If not, is there a way to trigger something when updates are coming in via replication? We would then think of using/building a special transfer mechanism that does the job. Thanks in advance for any hint! Best regards, Jan

1 0

not able to use idassert-bind successfuly
by Charles Bueche 05 May '14

05 May '14

Dear members, We are trying to create a LDAP proxy to hide two distinct AD servers behind a "single LDAP view". The goal is to authentify and authorize extranet and internal users using a single LDAP server, as LDAP clients (eg Apache) should only talk to a single LDAP server, and not be aware about the multiple AD servers behind the proxy. Our understanding is that we can create a meta database with two back-ends, using distinct uri/suffix/etc. What works: - using an AD user to talk to the proxy, which then is re-used by the proxy to talk to the back-end What does not work: - one "front-end", simple-bind LDAP-user used to access the LDAP-proxy, and only known to the proxy - one back-end user per back-end (known in AD). So we want to first search where a user is by using a front-end account, and then retry a bind with the user's effective username and password using its correct DN. Our config: -------------------------------------------------------------------- database meta suffix dc=meta,dc=x1,dc=ch uri "ldaps://ad1.ad.x1.ch/OU=O3,dc=meta,dc=x1,dc=ch" suffixmassage "OU=O3,dc=meta,dc=x1,dc=ch" "OU=O3,dc=ad,dc=x1,dc=ch" idassert-authzFrom "dn:*" idassert-bind bindmethod=simple tls_reqcert=allow binddn="CN=ldapsrvusr,OU=Service Accounts,OU=O3,dc=ad,dc=x1,dc=ch" credentials="abcdef12345" -------------------------------------------------------------------- When we try to use idassert-bind above, we always get the following error in the log: ... 535a1f25 conn=1000 op=1 <<< meta_search_dobind_init[0]=4 535a1f25 conn=1000 op=1 <<< meta_back_search_start[0]=4 535a1f25 conn=1000 op=1 meta_back_search: ncandidates=1 cnd="*" 535a1f25 conn=1000 op=1 >>> meta_search_dobind_init[0] 535a1f25 conn=1000 op=1 meta_search_dobind_init[0] mc=0x7f17fc008ef0: non-empty dn with empty cred; binding anonymously ... so it looks our identity is never used beyond the proxy to talk to the AD. help welcome. TIA, Charles

1 1

slapd-ldap with translucent and rwm
by Balazs Kovacs 05 May '14

05 May '14

Hi, I'd like to set up an LDAP backend toward a remote LDAP server. The base DN of the searches for the remote server is runtime information and can be any valid DN. I used slapd-ldap and found slapo-rwm which seems like doing exactly what I need so I configured a suffixmassage, where I replace the local DN to the remote base DN. So far so good, I got everything working. I even applied some more manipulations on searches and results by rwm. I was almost done except for one (not so) tiny thing: I wanted to have local overrides on certain attributes. I was glad to encounter slapo-translucent as it documents: "Entries retrieved from a remote LDAP server may have some or all attributes overridden, or new attributes added, by entries in the local database before being presented to the client". I started to set it up, but for me it looks like impossible to combine it with rwm. I used the following example to set up translucent: http://www.openldap.org/lists/openldap-technical/201205/msg00125.html I tried to apply rwm together with translucent like 1) first. I thought this is the ideal setup since I want the suffixmassage only when I turn to the remote LDAP and I want the suffixmassage to be reverted when back from remote. --- 1) dn: olcOverlay=rwm,olcDatabase={0}ldap,olcOverlay={0}translucent,olcDatabase={1}hdb,cn=config And the result was: adding new entry "olcOverlay=rwm,olcDatabase={0}ldap,olcOverlay={0}translucent,olcDatabase={1}hdb,cn=config" ldap_add: Object class violation (65) I was a bit disappointed but tried other combinations as well. 2) dn: olcOverlay={0}translucent,olcDatabase={2}hdb,cn=config dn: olcDatabase={0}ldap,olcOverlay={0}translucent,olcDatabase={2}hdb,cn=config dn: olcOverlay={1}rwm,olcDatabase={2}hdb,cn=config This one resulted in suffixmassage for remote ldap, but also for the translucent local hdb search, which is obviously not a valid dn for the local DB. As an extra I also faced ITS#5941 ( http://www.openldap.org/its/index.cgi/Software%20Bugs?selectid=5941) 3) dn: olcOverlay={0}rwm,olcDatabase={2}hdb,cn=config dn: olcOverlay={1}translucent,olcDatabase={2}hdb,cn=config dn: olcDatabase={0}ldap,olcOverlay={1}translucent,olcDatabase={2}hdb,cn=config This one resulted in intact suffix for ldap and a suffixmassage for local, which is again useless for my case. --- I also tried to look at if I can use the obsolete suffixmassage option of the slapd-ldap, but that does not seem to have an olc schema by looking at the source. After these trials my conclusion was that I have to find a completely different way of doing this. Is it not possible to do a suffixmassage on an ldap backend over translucent? For me this is so much a basic use case that I am surprised. Can someone explain if this is a known missing feature or an intentional limitation? If the latter, why? Any proposal how to solve local overrides inside slapd? (I wouldn't like to run two slapd to separate rwm from translucent) Thanks and Regards, Balazs Kovacs ps: using OpenLDAP 2.4.28 on an Ubuntu 12.04 LTS

1 0

N-Way Multimaster replication
by Flatfender 04 May '14

04 May '14

All, I'm trying to get N-Way Multi-master replication working, and can see each server polling each other but replication doesn't see to update. I have two servers auth03 and auth04. Both servers are Centos 6.5 with OpenLDAP 2.4.23-34.el6_5.1 from the Base/Updates CentOS repository. What I see is that each server seems to contact the other and both get log entries like this. I can post more logs if need be. I haven't been able to find much on "got empty syncUUID" Apr 14 15:44:32 auth03 slapd[1467]: daemon: epoll: listen=11 active_threads=0 tvp=zero Apr 14 15:44:32 auth03 slapd[1467]: connection_get(22) Apr 14 15:44:32 auth03 slapd[1467]: connection_get(22): got connid=0 Apr 14 15:44:32 auth03 slapd[1467]: =>do_syncrepl rid=004 Apr 14 15:44:32 auth03 slapd[1467]: =>do_syncrep2 rid=004 Apr 14 15:44:32 auth03 slapd[1467]: do_syncrep2: rid=004 got empty syncUUID with LDAP_SYNC_ADD Apr 14 15:44:32 auth03 slapd[1467]: connection_get(22) Apr 14 15:44:32 auth03 slapd[1467]: connection_get(22): got connid=0 Apr 14 15:44:32 auth03 slapd[1467]: daemon: removing 22 Apr 14 15:44:32 auth03 slapd[1467]: do_syncrepl: rid=004 rc -1 retrying (29 retries left) Here is the configs for each server: Each server has a unique server ID as well. I haven't tried to get my main user database replicating, as it appears the config database isn't replicating yet. Auth03 Config: slapcat -s olcDatabase={0}config,cn=config dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth" manage by dn.base="cn=Admin,cn=config" manage by dn.exact="uid=sync repl,ou=System,dc=livegamer,dc=com" read by * none olcRootPW:: <redacted> olcAddContentAcl: TRUE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=config olcSyncUseSubentry: FALSE olcMonitoring: TRUE structuralObjectClass: olcDatabaseConfig olcSyncrepl: {0}rid=004 provider="ldaps://auth04.pax.livegamer.com" type=refre shAndPersist retry="60 30 300 +" searchbase="cn=config" bindmethod=simple bin ddn="uid=syncrepl,ou=System,dc=livegamer,dc=com" tls_reqcert=allow credential s=<redacted> olcSyncrepl: {1}rid=003 provider=ldaps://auth03.pax.livegamer.comtype=refresh AndPersist retry="60 30 300 +" searchbase="cn=config" bindmethod=simple bindd n="uid=syncrepl,ou=System,dc=livegamer,dc=com" tls_reqcert=allow credentials= <redacted> olcMirrorMode: TRUE entryCSN: 20140414153033.402795Z#000000#003#000000 modifiersName: cn=config modifyTimestamp: 20140414153033Z dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov structuralObjectClass: olcSyncProvConfig entryUUID: 9cec0db6-5377-1033-940a-233ba8867211 creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20140408144128Z olcSpCheckpoint: 100 10 entryCSN: 20140409154557.570189Z#000000#003#000000 modifiersName: cn=config modifyTimestamp: 20140409154557Z dn: olcOverlay={1}syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {1}syncprov structuralObjectClass: olcSyncProvConfig entryUUID: 4c7ef0fe-538c-1033-941d-1b46f26937f8 creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20140408170933Z olcSpCheckpoint: 100 10 entryCSN: 20140409154608.786640Z#000000#003#000000 modifiersName: cn=config modifyTimestamp: 20140409154608Z Auth04 Config: slapcat -s olcDatabase={0}config,cn=config dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW:: <redacted> olcAddContentAcl: TRUE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=config olcSyncUseSubentry: FALSE olcMonitoring: TRUE structuralObjectClass: olcDatabaseConfig olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth" manage by dn.base="cn=Admin,cn=config" manage by dn.exact="uid=sync repl,ou=System,dc=livegamer,dc=com" read by * none olcSyncrepl: {0}rid=003 provider=ldaps://auth03.pax.livegamer.comtype=refresh AndPersist retry="60 30 300 +" searchbase="cn=config" bindmethod=simple bindd n="uid=syncrepl,ou=System,dc=livegamer,dc=com" tls_reqcert=allow credentials= <redacted> olcSyncrepl: {1}rid=004 provider=ldaps://auth04.pax.livegamer.comtype=refresh AndPersist retry="60 30 300 +" searchbase="cn=config" bindmethod=simple bindd n="uid=syncrepl,ou=System,dc=livegamer,dc=com" tls_reqcert=allow credentials= <redacted> olcMirrorMode: TRUE entryCSN: 20140414152957.400652Z#000000#004#000000 modifiersName: cn=config modifyTimestamp: 20140414152957Z dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov structuralObjectClass: olcSyncProvConfig entryUUID: aabb3a20-5377-1033-8399-57009c40c824 creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20140408144151Z olcSpCheckpoint: 100 10 entryCSN: 20140409154507.269469Z#000000#004#000000 modifiersName: cn=config modifyTimestamp: 20140409154507Z dn: olcOverlay={1}syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {1}syncprov structuralObjectClass: olcSyncProvConfig entryUUID: 5151199a-538c-1033-83f9-bd35daeffcf0 creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20140408170941Z olcSpCheckpoint: 100 10 entryCSN: 20140409154526.632472Z#000000#004#000000 modifiersName: cn=config modifyTimestamp: 20140409154526Z Please let me know what additional info I may need to provide. Thank you Matt P.

3 3

development mailing list?
by Paul B. Henson 02 May '14

02 May '14

I subscribed to the development mailing list Tuesday, to migrate a thread discussing the password policy implementation that I was told belonged there. However, neither of my two postings to that list seem to have been delivered. I am definitely subscribed, having received a message from the list, and my messages to openldap-technical are coming through fine, so I don't think my mail isn't reaching the list. The list description says the list is semi-moderated, so I'm assuming that as a new subscriber my postings are awaiting approval. Reviewing the archives, it doesn't seem like it's that busy of a list. I was just wondering if anyone knew how long it usually took for a new subscriber to be approved for posting? Thanks.

1 0

Q: syncprov_sendresp IDs
by Ulrich Windl 02 May '14

02 May '14

Hi! Can anybody explain what the "rid", "sid", and "to" IDs refer to in the syncprov_sendresp message? Example: slapd[28206]: syncprov_sendresp: to=002, cookie=rid=006,sid=003,csn=20140430111351.287889Z#000000#001#000000 I guess the original is from SID==1, the local SID==003. Does it send to SID==2? If so, what is rid==6 referring to? Regards, Ulrich

2 3

Duplicate dynamically an OU with another RDN ?
by Sylvain 02 May '14

02 May '14

Hi ! I have a branch "ou=people" where RDN are in the form "X1234" and NEVER change for one people. Ex. : uid=X1234,ou=people,dc=example,dc=org In this node, I have the login under "eduPersonPrincipalName" attribute which MAY change. Some applications doesn't allow us to define which login to use and so take "uid" attribute by default, not so cool. Is there any possibility in OpenLDAP to duplicate dynamically an OU with another RDN to have for example : uid=sylvain,ou=peoplebis,dc=example,dc=org ? Best regards, Sylvain

5 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical