openldap-technical May 2014

openldap-technical@openldap.org

68 participants
68 discussions

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

Can't override TLS_REQCERT
by Andrew D. Arenson 01 May '14

01 May '14

I found the previous post of someone else who faced the same problem I'm encountering, but I did not see a posted solution: http://www.openldap.org/lists/openldap-technical/201310/msg00084.html In /etc/openldap/ldap.conf, TLS_REQCERT is set to 'allow'. I would like to leave this setting, but override it for a specific invocation of ldapsearch. I have attempted to do so by setting TLS_REQCERT in ~/.ldaprc and be setting the LDAPTLS_REQCERT environment variable. Neither has worked. Interestingly, I _HAVE_ found that I can override TLS_CACERTDIR in either of those locations. Is this a bug? 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 4

What is the option '-e ppolicy' ?
by Thierry Thelliez 01 May '14

01 May '14

Hello, Looking at the test source code of 2.4.39 for the ppolicy script, I can see the ldapsearch is using a '-e ppolicy' option. The man page for ldapsearch lists 'general extensions' under -e and -E options. But I cannot figure out what these extensions are. What is '-e ppolicy' ? and when do you need it? Thanks, Thierry

4 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical May 2014